I. A little bit of history to begin with.

The evolution of accounting programs (that are practically age-mates to electronic computers) actually means the books of accounts being transferred from papyrus and parchment paper into electronic format. Excel spreadsheets are the moneyman’s best friends.

The same approach was applied to automobile construction in the earliest days of motor history:

• there existed a horse-drawn carriage;

• then horse power was replaced with a gasoline engine (earlier, however, it was often a steam- or an electric engine);

• voilà, an automobile is ready to go.

As time went by, there occurred a change in the approach used by automobile designers (if we consider the literal meaning of the English word "design").

CIS creators are not like this a second their mantra is likely to be — work is no bear, it won't go nowhere.

The inventory-control- or warehouse software appeared simultaneously with the first examples of accounting software; these two types underwent a similar kind of design: credit/debit ledgers were transferred into computers.

The final inventory-control program usefulness was limited to the information about what amount of what item is in stock (in pieces, grams, meters and other units pertaining to certain types of goods).

Thus, accounting- and inventory-control programs were living their own separate lives, being similar to such an extent that a cucumber is similar to a finger.

Nevertheless, one fine day an unknown genius came up with a victorious idea: to create a complex system that will account for the assets of an enterprise and will tie up both the unit-oriented (warehouse) and amount-oriented (accounting) types of inventory control.

So, how shall we interconnect a finger with a cucumber?

Quite a silly question, actually: we shall take good (the best) accounting software, good (the best) warehouse software, and ensure a "data exchange" between them (aka "synchronization" — what surge, as they say, that sound can start in each and every heart).

Let us recall the epigraph.

So this is how the "modular" ERP systems came into being: a warehouse "module"(WMS) gets interconnected with a "finance" module(ERP), sales module is integrated with CRM and so on and so forth.

The potential number of the interconnecting "modules" is limited by the solvency of the company and CEO’s credulity.

 

II. Great modular systems" cry results in little wool

Any "modular" system has at least three major advantages:

• it is easy to "produce" and "expand the functionality": you just keep on applying various "modules". A "module’s" origin is of no importance: the market-dominating systems are a true Gypsy bazaar full of all-planetary/international types of "modules" that were once written, then purchased one by one, or received for free together with the acquired company (it is a blasphemy not to use a freebie, right?), etc. The only thing a true Indian needs is to declare any handy trash to be a system "module" — in order to make it at least somewhat synchronized with the others.  How it will be done: web services or XML-files — doesn’t matter. We kid you not. 

• it is convenient to advertise. Meaning: to mesmerise the audience of a low immunity level with something like " — Oh, we’ve got so many modules, check it out!", " — Do you have the XXX module? We do!", etc 

• and to sell. Like, buy a warehouse module first, and when you have money, buy the "HR-module", and there is also a mega-super "IFRS-module" — you will find it useful when you go for an IPO; and so on and so forth. There you have some flexibility!

But sadly, nothing is perfect in this world. 

"Modular" systems have a tiny drawback: they are almost unserviceable.

Clearly, this disadvantage is not that important if regarded from a seller’s perspective; but what about a user’s point of view?

Take a look at your company.

You certainly have some or other kind of sales department ("Sales module"…), finance/accounting ("Finance module"), warehouses ("Warehouse module"). As well as many other "modules", but let us consider the above-listed ones and use them in our virtual story. Now imagine how your company will work if we remove the "warehouse" module from its structure (in order to ensure "flexibility" and "control" the budget")?

Hmm?

Exactly.

We will get a closer analogy with the "modular" ERP-system if we think of reorganizing your business by making most of the outsourcing idea — up to the level of idiocy:

• a unified company no longer exists;

• each functional unit’s business processes are transferred to the "outsourcing" level: now independent contractors deal with them. Warehouse services are provided to you by one company, while call-center services are outsourced by somebody else; yet another contractor sells the goods, etc. etc.;

• common "coordination" and "synchronization" are done by the headquarters ("ledger" module) via the regular collection of reports from contractors and holding conferences dedicated to how we can bring everything to order without order"

Can you imagine how it will work in reality?

What if business conditions force you to adjust your business processes all the time?

Uh-huh.

This is exactly how "modular" systems work in practice.

An experienced reader would exclaim: "What rot! What about thousands of modules implemented worldwide?"

As a rule, dear readers, the situation is exactly the way we described it.

 

III. How they actually function

"Modular" systems gave the world a certain... shall we say... possibility or something of the kind... In short: now we can witness independent "performance" or "running" based on different "modules".

A simplified and simulated example: there is a warehouse receipt.

If it is "run" in the "warehouse" module, it will write off the goods stored at the warehouse (in units). You might also not "run" it.. Let it just stay there, in the list of documents — it won’t prevent you from printing a warehouse receipt out and dispatching goods from the actual warehouse. If it is run in the finance "module", it will reduce the amounts on the inventory account, will record the profit in the sales section, and assign certain customers with debts. You are free not to do it either. If the receipt is run in the "CRM module", then the customer will have accrued bonuses, which will be reflected in the client’s portfolio. But you might as well not... — well, you know.

This independent "performance" on different "modules" (pardon the abundance of quotation marks) allows for quite legal tricks, like, for example, running your receipt in the "warehouse module" and not running it in the "finance" one.

According to such systems" creators, this is what we call (attention!) "flexibility"!

Thus, you can easily write the goods off the warehouse (the warehouse documentation will be in order), and there will appear no changes in the financial accounting segment. Is it possible to imagine a more favourable situation for performing a theft of cosmic proportions?

Can you, hand on heart, imagine a situation (actually preconditioned by business requirements and shareholders" interests) when such "flexibility" can be justified?
 

Another example: "error correction".

Imagine a finance department employee who found, for instance, an error in the "running" process, generated by the merchandise "module". He tries addressing someone from the logistics department, but the logistic people don’t find this interesting (and it isn’t their problem, anyway) or the responsible person went on vacation, or something else happened.

What are the next steps the finance person will take? He will duly write a letter explaining the problem, and then correct the error in "his own" financial "module" (such and such amount got transferred from and to such and such account).

This will happen for the first couple of times.

Then, if the problem is not eliminated, the employee will not even bother writing any letters — he will simply make the necessary corrections (he’s got urgent reports to write and has no time to lose). Then the IT service, requested by the finance department, will write an algorithm to make these corrections occur automatically, thus saving the finance people loads of their time.

Note — the corrections will occur only in the finance "module" and affect its results only; the errors in the merchandise "module" are corrected/created by logistic people/warehouse employees absolutely independently.

Just imagine the degree of the data (non-)compliance of the two "modules" with each other (and how many other "modules" has every "modular system!) and with the reality, multiplied by several upcoming years — given the staff always follows the path of least resistance.

How would you describe the final usefulness this, so to speak, "system" has to offer, with relation to business?

Yes, indeed.

Totally.
 

What cybernetics say.

What is a process approach which is so much (and fairly) talked about when a business is estimated as a bunch of value chains?

The process approach is natural for IEM systems as they are natural themselves.

Here is a simple example — a supply chain from a manufacturer to an end consumer with a retailer somewhere in the middle.

All system's users operate within a unified  information field. A purchaser creates an interim goods receipt note approved by the supplier and sends it to the warehouse for which the goods are intended with a push of a button.

The goods arrive. The warehouse manager accepts the goods by signing a delivery note and entering it to the warehouse accounting system. And so forth until the goods are received by the end consumer.

The current status of delivery, location of any single item or the entire lot, settlements for delivery, truck loading availability at the warehouse can be monitored online by any person responsible for delivery.

From the users' point of view, an ERP system is a bunch of outdated workstations which are actually a set of applications developed by different suppliers in the different decades.

Just imagine that you have the phone call service, warehouse accounting, invoicing functions running as separate applications.

All these modules are "integrated" within a heavily advertised EPR system sold to you by a car dealer like salesman.

To transmit data from the phone call service to the warehouse module you need to synchronize it with a number of interim modules.

Well, nobody bothers to actually do it so, as it threatens not only their "process approach" but the whole company operations.

Thus, an alleged super set of hyper functions of the system remains to exist in handouts, while people actually use Excel or paper copies.

And data is manually entered into a hyper system retrospectively.

 

IV. Deceptive ease in the implementation

Quite often the "modular" systems supporters (=beneficiaries, in all meanings of the word) position "modularity" as an advantage, underlining its gradual implementation. Like, first we implement it at our finance department and run it; then we implement it at the warehouse, then at the sales department, and so on.

Isn’t it logical?

Again, let us read the epigraph. One doesn’t have to be an ERP professional to understand it.

Everything is very simple: to begin with, a specific "module" introduced in a particular functional unit does, at least, double the unnecessary paperwork, and, therefore, CRM-system. Firstly it will be of no help, secondly it is gibberish all-in-all, exponentially increases the chance of errors, discrepancies and other similar screw-ups.

Let us consider the "finance" example: the "gradual" introduction of "modular" systems tends to start exactly with "finance". This is not accidental — the "finance guys" are usually those people who eagerly let the others pull the wool over their eyes — for the reasons mentioned below.

Any ERP-system, however perfect it might be, requires the data input.

If the end-to-end company automation is done correctly, such data gets entered by the end users.

In this case, the data input is, in fact, limited to the sales/purchases specialists who key in the information about warehouse receipts, and the cashiers who add the information about sales transactions etc. I.e., the system gets filled with the new data in a natural way: as a result of the employees performing their actual duties.

What happens when socialism is being built in a single country a single finance unit undergoes "modular" automation?

All data has to be entered at least twice: first, a seller writes a warehouse receipt out in his old system (via CRM system, for instance; or even does it by hand) — these documents reflect the actual transactions.

Then, all these documents have to be transferred (re-typed) into the very same "finance module".

And who will do it?

Each and every person involved in this monkey business will clearly understand the hopeless stupidity of this work. The quality will be just in tune, also.

As a result, two consequences are inevitable:

• the accuracy of the "finance module" information will leave very much to be desired. More precisely, it will be plain nonsense, exactly like there is no semifresh sturgeon. This will be just the beginning. Then the data will cease to be added altogether, since the "finance people" themselves will stop using the modules — again, because it makes no sense. Good old Excel spreadsheets will be used, for real.

• further implementation of other system "modules" will face the unconquerable (and absolutely justified by the above-mentioned reasons) sabotage.

Are you ready to say what such "gradual" implementation will result in?

Yup.
 

​​​​​​​Depending on the employees" proneness to eye-washing, and the administration’s propensity for self-deception, the project will be either

• formally suspended (another option — quietly forgotten);

• reported to be successfully implemented, i.e. simply installed into a certain system on the employees computers.

 

V. Monolithic systems:

What do we offer instead of the sad "modular" trash?

Monolith: there is no other Module but Unified Monolith, and IEM is its Embodiment.

Monolithic IEM systems

• cover all business processes at the enterprise that undergoes automation (this is the continuity-of-accounting principle’s necessary consequence);

• business objects of the expanded IEM-solution mean direct, unambiguous and comprehensive projecting of your company’s actual functional units, and the business processes that tie them in;

• each business transaction (=document) in the IEM System automatically and inevitably generates a cascade of all changes that fully reflect the changed situation in the company.

Let us explain the latter thesis in more simple terms.

Totals form the accounting basis in the IEM System.

We won’t manage to give a simple, complete and (most importantly) clear definition of a "total"; therefore, we will give an informative example.

Let us imagine your company’s warehouse.. The warehouse contains a certain amount of stock on hand, i.e. the specific number of products. The "warehouse" total shows the same quantity of the same product, which any warehouse employee (or, to be precise, anyone who has the rights) can see in the corresponding report generated by the system.

The items stocked at your warehouse are worth a certain amount of money — in fact, this is their total prime cost. The person, who generates the "warehouse" total’s turnover balance sheet, will see this very figure.

In order to change the situation at some real warehouse, it is necessary to either dispatch or receive some goods (there are also other options, such as to debit/write off as a result of inventory, to overestimate breakage and so on, but we shall neglect them to retain simplicity) — and nothing else.

Real life does not presuppose that goods at any warehouse appear out of thin air: miracles do not happen. The total value of goods stocked at any warehouse can be either reduced (after their dispatch), or increased (through their receipt), but the prime costs of the warehouse stock can’t change miraculously without any change in the stock’s quantitative and qualitative composition.

In exactly the same way, in the IEM System it is impossible to write off EITHER products OR money from the warehouse. The "warehouse" total’s state can change only as a result of running the documents that reflect the actual business operations (whether it is the goods receipt, dispatch, inventory or markdown) — this is how the IEM System architecture works.

Thus, the IEM -"total" is the precisely complete reflection of your company’s actual business object — with all its meaningful properties. The "total" (the object’s reflection) changes in synchronization with its actual progenitor: all the properties, taken together.

A warehouse employee views the "warehouse" as an automated book of accounts; an accountant views it as Account 41; a finance guy perceives it as the "Commodities and materials at warehouses" article in the balance sheet; while a developer views it as a multidimensional cube.

But the "warehouse" total’s essence is that it always remains true to its nature.
 

​​​​​​​The data contained in the IEM System totals is the same for all departments and employees.

All users of management information work with the very same totals, but employ them for their own unique purposes. IEM System provides each user with the opportunities (considering the analytical data slice and grouping) necessary to accomplish the user’s objectives.

A management balance sheet, an income statement and a statement of cash flows are based on these totals.

As a result, the multiple data alignment occurs in a natural and automated way; if there is an error, it will be simply impossible to correct it in some separate "module" — for the complete lack thereof.

The error will either appear in the report given to the shareholders, or get corrected by the department responsible for its occurrence (the department might also correct the error-generating business process).

In mathematical language it's called guaranteed accuracy of data provided by a monolithic IEM information container: either all the data it contains is true, or it is entirely false.