So imagine a big and both structurally and geographically sprawling organization with thousands of employees, hundreds and thousands of motley suppliers, contractors, and providers of all sorts of services.
For certainty we’ll take a typical major CIS retail network with hundreds of shops in dozens of cities of a no small country, and millions of clients.
The network has contractual relations at the outlet (with buyers) and at the inlet — with suppliers of its core goods for sale and, let us say, service providers, i.e. suppliers of all the rest, including services.
In 99.9% of cases, its contractual relations with buyers (and even the purchase of a yoghurt at some X5 "Pyaterochka" discounter shop is a particular case of contractual relations, based on a public offer + a receipt), are standardized, however numerous.
At the same X5 discounter network, an unlimited number of buyers are all processed uniformly, and their relations with everyone are the same: take things off the shelf — pay the cashier — good-bye and thank you
for your purchase.
At the Metro shops that make huge efforts to create the semblance of wholesale relations with counterparties (for a degree of protection from Russian retail regulations — traditionally moronic, like any regulations imposed by officials no matter where), the customer processing business processes are a bit more diverse; the buyer (formally, always either a legal entity or a sole proprietor) may pay either in cash or by bank transfer.
At Ulmart, there are even more options; the buyer may be either a natural or a juridical person, and the latter may pay either way, and all may use balance offset, plus partial payment for purchases with accumulated
bonuses — in short, there are some ten outflow processing options (depending on how you count).
However: whatever number of options there may be (one like at Pyaterochka or ten like at Ulmart), it will be negligible as compared to the number of physical transactions using those options, that runs into millions.
To put it professionally, the customer service business processes in the above companies (and others of similar trade and scale) are fully standardized.
In respect of suppliers, all quite the contrary.
If we discard suppliers narrowly understood, meaning suppliers of the core goods-for-sale (foodstuffs for the
above-mentioned X5 shops), also handled in a highly standardized manner, albeit somewhat less so than are their customers, — there remains a variegated host of suppliers of all the rest (let’s call them SARs) required for the operation of a big and sprawling organization.
Here’s what SARs supply:
Incidentally, for each geographically detached unit the same goods mix may be (and sometimes is) supplied by different SARs.
The terms of work with each one are individual. Somewhere, one-time purchases are made on prepayment; elsewhere, regular purchases into the inventory and periodic payments in arrears (the periods may vary), or regular fixed payments but quoted in foreign currency and made at the current exchange rate; again, thousands of variants are possible.
This puts the related business processes into a heavenly order best described by the comprehensive term "thrash, haze and sodomy".
Here are some characteristic brushstrokes from Ulmart’s life (of course, the "before" picture) — relating only to their rent relations.
The annual losses would run into millions.
And that was about the rent alone.
The dia$par abstraction of a contract is essentially about
Physically, it is a document in the system that contains a payment plan and an expenditure plan (for this specific contract).
For example, if this a year’s rent contract that provides for monthly payments, while the company reports to its shareholders on a quarterly basis, then the payment plan will consist of 12 lines, and the expenditure plan will contain four lines, accordingly.
The "Contract" document’s head will contain the following information:
If there are more than two parties to the contract, then the payees will be indicated in each line of the payment plan.
If the contract is concluded with a natural person, then the taxation parameter tab will be activated. By default, the system will automatically form a second payment request for the tax authority indicating the natural person’s income tax amount (this default feature can certainly be disabled :)
As the initiator creates a new "Contract" document, its signable binary (*.doc, *.jpg, etc) version will be attached.
The initiator will first create a document in the "Contract Request" (draft) sub-type and move it into the "For Signature" sub-type.
The signatories are determined at this stage:
The list of approvers/signatories is formed automatically based on the approvals matrix, and documents can be signed via a mobile application — see here for more details.
The Discussion of a Contract:
If an additional agreement to a contract is concluded, the contract cannot be simply opened in the system so that its parameters can be changed.
The contract’s related document of the "Additional Agreement" type must be created and then pass the whole signing cycle like an ordinary contract. On being signed, the additional agreement will adjust the main contract automatically. Two types of adjustments are possible:
The system calculates the balance of the payments budget in each line of the payment plan and the balance of the expenditure budget in each line of the expenditure plan. If the budget is exceeded, the respective lines will be highlighted in red:
If at least one line’s budget in the payment or expenditure plan is exceeded, the whole document will be highlighted in red:
The budget can be controlled in two modes:
After obtaining all the signatures, the document moves into the "Contract" sub-type — a valid and binding contract.
Robots begin working with it to create payment requests, five days before the payment date, and expense documents.
Payment request can also be created manually without a contract — we’ve already discussed it here, but the charm of the contracts mechanism is that:
If the payment plan indicates the exact amounts (e.g. the fixed monthly rent), the system will automatically form payment requests to be signed following the shortcut path (for both the budget and necessity were checked as the contract itself was signed). In this case, as the user creates the contract, he checks the "Exact
Payment Schedule" box, and the system will create payment requests on its own, five business days before each payment date.
If only estimated amounts are known as the contract is created (the so-called "variables", e.g. payments for Internet ads or electricity bills), the system will notify the contract owner of the necessity to create a payment request for the exact amount. This request will also follow the short path.
There is functionality that facilitates the completion of the payment plan for typified cases:
In creating schedules, the system takes weekends and national holidays into account.
As each contract includes a payment plan, the system can provide the treasurer with any days", weeks", or months" summary forecast of what and when must be paid under all the contracts, broken down by entity and cash-flow item.
If using the contracts mechanism (as opposed to manually created payment requests) becomes the standard for all the company’s units, this report essentially represents the expenditure side of the cash-flow forecast.
We particularly note that this forecast is formed automatically.
On the basis of the cost plan included in the contract, cost forming documents are generated automatically.
So how did the Ulmart moneymen’s daily life change after the above features were implemented?
As usual, Comrades: Glory to God in the highest, and on earth peace, good will toward men.
The payments are made strictly within the budget.
Negotiating payments takes minimal time; 0 unneeded signing motions, and the treasury already has money to pay as required.
Among other things, this enabled Ulmart to reduce their rent losses to zero (with hundreds of rented
facilities). A windfall of millions.
Only one person monitors all the rent payments — in addition to his main financial duties: "It works? Don’t touch it!"
This is what efficient management is about.
At least it seems so.
Our dear readers who are lucky enough to work in organizations of similar scale are kindly requested to compare their own experience with that illustrated above.
P.S. The comparison must be most impressive for the personnel of companies operating immensely prestigious "document turnover automation systems" that cost at least hundreds of thousands of dollars (in their poorest man’s versions).