Modular ERP systems: what you will learn only after the implementation project’s failure

Do you happen to know that SAP, MS Axapta/Dynamics AX and most other well-known ERP systems are in fact ’modular’?

You might also have heard about the essentially different architecture of ERP solutions – "monolithic" systems.

Then you probably don’t know the differences between them are crucial and have to be considered when choosing a certain ERP-system. The wrong choice is the 98% guarantee the implementation of your project will end in failure.

I. A little bit of history
or the "modular" systems origin

This text was inspired by our communication experience with people from accounting and finance sphere. Their modus operandi results from the bookkeeping tradition that is more than five hundred years old and dates back to the notorious Luca Pacioli. According to some sources it is even older and dates back to the 13th century.

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 moneymen’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").

However, the accounting software doesn’t work this way: its creators in tune with the old proverb work is not a bear – it won’t go anywhere don’t mess with success and, in their homemade-antiquarian manner, keep
on trading a horse for a steam engine.

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 (otherwise referred to as
"how many grams this weighs") 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.

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.

By the way, Mary Shelley used the same simple algorithm to create a famous literary and movie character.

So this is how the "modular" systems came into being: a warehouse "module" gets interconnected with a "finance" module. The potential number of the interconnecting "modules" is limited by the same-order natural
factors in the same way certain factors constrain the heap of no longer needed modules items that stay together thanks to the friction force (and our old pal Newton’s theory). But let us not run before the hounds.

II. Who is happy with the "modular" systems.
And who sheds bitter tears because of them.

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 ХХХ module? We do!", etc
  
  
• and to sell.
  Like, buy a warehouse module first, and the, 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 Russia to 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.

Frankenstein could be a powerful monster only in the author’s imagination and on the movie screen.

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, in the meaning that joining a collective farm is, like, a voluntary matter. 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?If, again, we don’t perceive "business" in the meaning the whole kit and caboodle, led by the ill-famed Mikhal Ivanych, assigns it with.

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.

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?

Why would one think of Luzhkov here? 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.exponencially 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 (whether based on the Ultimate solutions) 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 enter 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.
Or, in certain advanced cases, the warehouse receipts are added to the system by the enterprise counterparts via the b2b/b2c sites — it is much cheaper; and the internal documents are mostly generated automatically.

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 1С, 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 (whether they are salesmen or specially hired people), 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);
• b) reported to be successfully implemented, i.e. simply installed into a certain system on the employees computers.

Let us immediately address those comrades who object by saying it is possible to "upload" the documents into the financial unit automatically, and there’ll be no monkey business.
"The theory is cold and dull, my friend."
The automatic "uploading" does not solve such problems as the original data correction, various discrepancies, the necessity to introduce changes retroactively, as well as to change the upload/download algorithms that follow the business process innovations.
The situation gets even worse. As long as there is a robot, people (to a certain extent) are not responsible for their work. Therefore, nobody will even try looking into the resulting nonsense.
The ending is rather predictable.

V. Monolithic systems: more difficult to understand,
much more advanced in their architecture.
But — they happen to be the right solution.

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

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

Monolithic IEM systems based on the Ultimate Solid platform

• 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 Ultimate 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 Ultimate 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.
Registers (named the "totals" in the system’s internal terminology) form the accounting basis in
the IEM-solutions done on the Ultimate Solid platform.

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. There is a total named "warehouse" in the Ultimate IEM-solution. The warehouse contains a certain amount of stock on hand, i.e. the specific number of products. The Ultimate
IEM-solution’s "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. We won’t talk about such thing as revaluation, so as to continue explaining in simple terms. Yet again, revaluation doesn’t appear out of nowhere. It has to be carried out and formalized by the document that will correct the gain/loss account balance by means of running another document correcting the prime costs of the goods on the specific list.

In exactly the same way, the Ultimate IEM solutions make it 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 platform architecture works.

The data contained in the Ultimate 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. Ultimate 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).
The advantages of this approach have been proved by practice; the accounting data provided by the Ultimate IEM-systems, is, by orders of magnitude, more true-to-life than that provided by "modular" systems.

VI. Replacement therapy
in the Ultimate monolithic solutions

Earlier we promised you to tell about the reasons why those who deal with accounting and finance usually don’t perceive the "modular" systems’ sellers too critically.

The reasons are quite trite.

Just as Schweik’s friend Blagnik led the dogs away by sausages, and pedophiles lure kids with chocolates, "modular" systems appeal to the finance guys/accountants because they cynically exploit the professional
deformations of thinking. Well, of course: here is the "ledger"! The ledger that occupies a special spot in every accountant’s heart and that has been the starting point of accounting for well over five hundred years.
Everything happens with its help: the "Ledger" is the staff of life. And an accountant’s heart melts!

And, by the way, we don’t have any financial "module". (as well as any "module" in principle; but other "modules" lie outside of accountants interests)!
A… Mamma mia! YOU DON’T HAVE A BOOK OF ACCOUNTS!!!

This is indeed true — we don’t.
Instead of the "book of accounts" — the freshest product that is just 500–800 years old (depends on the countdown’s starting point) and consists of several columns with numbers, we offer a system of "totals" that
reflects the client’s enterprise in its entirety.
The system "totals" have names that are clear to all employees (as opposed to the mysteriously numbered ciphers of the Russian Accounting Standards fraternity), such as "Warehouse stock balance",
"Current account balance", "Drivers’ merchandise debts" etc.

Nevertheless, the co-workers of accounting/financial Siberian mines don’t want to have an eyesore aka the foul simplification of the great art of bookkeeping (just like some British lord who wanted to read a hundred year-old Times issue every day during his breakfast). We promise you, dear people of finance, to bring the names, images and terms (used in the interface’s special accounting setup) up to the warm cozy blanket the familiar standards that have been used for centuries — provided we have your consent, of course!
You will have your Account 41 (and 50, and 62, and all kinds of other accounts — any account you want), and your "chart of accounts", too.

Let your eye be delighted, dear comrades!