The requirements, both rigorous and contradictory, suggest that the solution is hard to find.

So we shall not flood the reader with a profusion of logical syllogisms but look up the answer right away at the end of the textbook.

First and foremost, to ever be implemented, an IEM System must be single, unique and of universal and exclusive coverage. All the company’s value chains without exception (preferably, all its structured business processes in general) should be in the system’s loop, and the IEM System must be the enterprise’s" only management system (and, ideally, the only system altogether).

The implementation of the singularity and universal coverage principle results in a single information field, with real time transactions, for the whole enterprise, and in all the company’s employees working in a single "system".

The functionality the whole zoo of three-letter ERP "modules" is implemented using the IEM features. In individual cases where it seems redundant to duplicate specific operations, such as low-level management of machine controllers (or drawing creative comp in external graphic packages), the respective software is bundled with the IEM System and then interact with it using a "browser-to-plugin" subordination model. In this case, too, the IEM System remains the monopolistic keeper and operator of the information on business process execution rules and on the enterprise’s current situation.

ERP means bottom-up integration of functional blocks. A working ERP "system" is designed by joining individual pieces of program code each of which (as the vendors state — and mean it!) implements the very "best practices" gathered from all over the world.

Still, at closer examination this approach means reducing the "spherical horse in vacuum" to an absurdity like picking raisins out of loaves that grow on trees.

Imagine an attempt to build the world’s "best enterprise" by just a posing "the best sales department" with the best warehouse" and "top procurement department" — each an award-winner at the respective worldwide contest. The world’s best e.g. warehouse may well belong to an Indian pharmaceutical; the best procurement department, to a Dubai company profiteering in electronic components; and the very best sales department, to a Chinese producer of fake brands. Shall we obtain anything meaningful by trying to combine those "best practices" in a single system?

The answer is obvious.

What about producing separate "industry solutions" for pharmacists and e-component resellers? The specifics of an individual enterprise’s business processes is not determined merely by the industry to which it belongs. The warehouses of a "next door pharmacy company" and a multi-billion pharmaceutical distributor are organized in almost totally different ways though both companies trade in the same pills.

If we remember the regulatory diversity in different jurisdictions? It will take quadrillions of specialized "solutions" providing for all conceivable combinations of parameters. Alas and alack, no matter from which side we approach, we arrive at the same conclusion: a classical ERP is inoperable in the general case. Exceptions are possible, but in individual cases: as we now, even a non-working clock tells the right time twice a day — we just need to know when to look at it.

All ERP vendors together claim their solutions to be "flexible" — which is in total disregard of the observed facts and operators" opinion — but let us assume "flexibility" as a mental experiment.

Imagine some super-powerful e.g. WMS model that can adapt well to the business processes of any warehouse. Is that it? No, it’s not.

Now that we are using fantasy, we should let it fly beyond one functional block; let us imagine, with the same degree of likelihood, a universal company-wide system, and… we shall arrive to the IEM System — now from the opposite side.

The fact that the requirements applicable to an IEM System formulated before are contradictory, if not directly antagonistic, lead to a dualistic nature of an IEM System.

Quite similar to wave-particle duality — or the law of the unity and struggle of opposites, a.k.a. Yin vs. Yang.

A system that is monolithically unified and all-embracing, from its operator’s perspective, is internally a superposition of two rigidly divided parts of opposite nature and purpose, that we’ll term the "platform" and "business logic space (BLS)".

The platform is versatile, closed, and invariant for all installations. It is actually an IEM interface of a DBMS. The BLS is open, specifically adapted for each installation and, consequently, absolutely unique. It serves as an IEM interface for the application developer (and for users when assembled).

The platform fully conceals the low-level automatic mechanisms for efficient data processing and thus makes the application developer comfortable at the BLS level. Tangible business objects are naturally reflected as high-level IEM model abstracts: the Warehouse object corresponds to the physical warehouse; a Document object, to a document, etc.

The superposition of dualistically opposed properties of the platform and business logic space, combined with the principle of IEM logical unity and universal coverage, accelerates application development and implementation by orders, guarantees data credibility and alignment at any time, and provides real-time transactions and many other benefits.

Hiding the platform’s sophisticated, costly and high-risk data processing mechanisms from the application developer is conducive to record-high productivity as compared to ERP, on the one hand, and record-high reliability, on the other.

Guaranteed isolation of the application developer from the complicated data processing mechanisms enables him to use an arbitrary high-level programming language in the BLS. And if we are free to choose one, then we needn’t compromise; let us choose the most modern, popular, and functional one for our core tasks. The application developer’s qualification bar obviously falls from the space-high ERP guru level to the general application developers" level — with their training duration and remuneration.

Let’s return to record-breaking productivity. Physical isolation of the platform is necessary but not sufficient. Oddly enough, after the advent of client/server technology (some 30 years ago) DBMS progress bypassed ERP systems. The aggregation of a typical ERP system with an arbitrary DBMS is good for presale only. Using basic SQL guarantees the lowest productivity among all possible options, like an unplugged screwdriver.

The cases of DBMS being replaced while the same ERP system is retained do occur, but as an oddity only. So we feel free to dismiss the fictitious advantages of arbitrary DBMS choice and closely integrate our IEM platform with the DBMS satisfactory to us, employing all the data processing tools currently available from the market leaders.

Dense integration enables us to regard the DBMS as part of the platform, in a sense. Or, conversely, to regard the IEM platform as a DBMS superstructure that implements an additional level of abstraction.

The sophisticated IEM data processing rules that are executed as documents move through stages of business processes, or the scripts for responding to external events (both are algorithmically the same) combine to provide enough intelligence for real substitution of humans with IEM algorithms at whole stages of business processes.

The abstract of the enterprise in the IEM System can easily be shown to be its virtual model with the best approximation possible for business purposes. The model’s granularity is only limited by how well the enterprise’s business processes are standardized.

The better the company’s business processes are standardized and formalized (in reality rather than declarations and bureaucratic pulp), the greater part of human personnel is naturally replaced with the IEM System’s scripts (virtual robots).

The obvious reduction of costs is accompanied by income growth that is not so obvious at first: sales grow as service quality improves dramatically ("the computer makes no mistakes") and becomes 24x7 available. So, at a high but more than attainable level of business process standardization, an enterprise automated with an IEM System becomes totally unmanned.

Of course this applies to the operational level, for no algorithmic system can perform creative functions — for formal mathematical reasons (according to Penrose).

Moreover, it will never be able to — irrespective of computation power or the algorithms" degree of sophistication. So our Part One message that AI is out of demand is compounded by the impossibility of ever creating one (on an algorithmic basis).

In practical reality, virtual IEM robots go the full way towards substituting office workers" virtual labour; blue collar workers are replaced with industrial robots; drivers, with unmanned vehicles, etc.

Ray Kurzweil predicts technological singularity by the middle of this century. We’ll take courage to correct the venerable visionary: in the business application area, singularity is here already.

It’s time to open our eyes.