Implementing an IEM System — enjoy the process and get profit at the end
has been added.
When you draw a chart of your enterprise using the "to be" model of your IEM System you become a real creator, but if you are trying to implement an ERP system you are doomed to fail.
The process of implementing an ERP system is over when you realize that you will never get a desired result. People responsible for this task keep "implementing" it until they retire or are dismissed.
A piece of IEM wisdom
A duly implemented IEM System is a cybernetic model representing a complete and comprehensive simulator of the existing enterprise.
This is a cybernetic representation of the enterprise, to put it simple.
The implementation process is divided into two phases:
creative: you draw a target model for your enterprise (value chain configuration)
technical: you implement the model in line with IEM logic
The Integrator and the Prospect executives closely cooperate during the Creation Phase. The second phase is not that complicated and solely a concern of the Integrator.
An appropriately prepared "to be" business model is a precondition for successful implementation of an IEM System. Such model obviously CANNOT be created without motivated involvement of the Prospect decision makers.
If there is no such involvement, the Integrator must quit the project.
You contact a IEM System integrator.
It should never be otherwise: the IEM Paradigm requires potential customers to be interested in the project and it directly prohibits pushing sales.
So, you let them know, "We are so interested in your services, let's arrange a meeting to discuss the matter."
But it's you who is going to speak at the meeting — the Customer speaks, the Integrator listens — that is the rule.
You tell the Integrator about your business and problems, the reasons why you contacted them, your needs and dissatisfaction with the current state. The more details, the better.
The Integrator listens and asks clarification questions. The Integrator DOESN'T have to tell or show you anything.
Their major task for the acquaintance phase is to get a general idea about:
Main business processes of the enterprise — what it is about and how it works;
How reasonable and feasible the targets set by the Prospect are;
How reasonable Prospect's decision makers and how feasible the proposed project implementation arrangements are, taken into account possible conflicts between the Prospect's stakeholders.
In other words, the Integrator should screen out obvious freaks and/or potential customers with potential threats to project implementation.
At the first meeting, the Integrator gets information to think it over the next few days.
IEM cybernetics mathematically creates win-win situations. The Integrator runs at least the same risks as the Customer (see below), as compared to the process of ERP system implementation when it's a one-way traffic game.
If project risks, given all human factors, are found acceptable by the Integrator and the Customer's enterprise is decided appropriate for IEM implementation, then the next phase comes.
While at the acquaintance stage we generally tried to figure out, what kind of business you have and how it operates now, at the preanalysis stage we try to agree on a mutual vision of what the result should look like. I.e. — how your business will look like and operate after a successful deployment of IEM System (a so called "to be" model).
Continuing the comparison with the factory from the text on presentations, — at this point we learn the following:
what you need is indeed a factory
what it will manufacture
its production volume
external conditions for construction
external conditions for raw materials supply and sales of future factory products.
And a million of other less important factors (let’s keep it simple).
Continuing with the comparison continuum — what do you want to see as an output? A stroller? An egg boiler? A submarine? No problem. Problems start, when you want to have a shoehorn with nuclear ICBM.
What we do at this stage (from here on we’re talking about a to be state):
agree on how main processes of the company being automated are going to work. By main we mean the ones that add value (and them only).
make decisions on main roles (equivalent of job positions in the traditional bureaucratic organization chart logic) and their functions — "who does what". The main roles are the participants of the main business processes.
What we don’t do at this stage: all the rest. We don’t go deep into detail; we don’t discuss technical issues and future secondary business processes.
All of that is very important, but it’s not the main thing. Details are clarified at the next stage — "Technical requirements".
We won’t commit a major sin against scientific accuracy, if we equate this stage with business processes reengineering.
We must say that very often in the course of discussions we come to conclusions, unexpected by the potential customer.
If, as a result of the reengineering, there are no significant discrepancies between how we perceive the to be state and how the potential customers do — then great, we move on.
In case there are significant discrepancies, then alternatives are possible:
if the Prospect speaks such nonsense that under no circumstances it’s going to be viable (as a rule, this disease progresses against a background of a lordly high-handedness, intergalactic megalomania and way too much inadequacy), then our relations end. Continuing with the doctor-patient analogy, if a patient disagrees with a diagnosis, what kind of effective treatment are we talking about? Consult another specialist.
if the Prospect insists on including into the to be model some garbage, that however, has no influence on the project as a whole (this definition includes both completely harmless (as much as useless) gimmicks, that are so dear to the owner, and obviously harmful, but small-scale adjustments), then (as a rule) the Integrator does what the customer wants.
However, he records his "minority opinion" on each piece of such garbage, as well as an outcome prediction, in the form of a disclaimer within the Technical requirements (see the next stage). The patient is asking the doctor to "please, please add to the prescription that spirituous tincture, that’s nothing for you. My wife forbids me, but now that this is for my health and is prescribed by a doctor, she wouldn’t mind!" "OK, dear patient, I’ll add three vials here, you just don’t overuse it too much!"
All our activities within the preanalysis stage are completely free of charge.
Its duration, depending on the case, ranges from a week to a month.
A typical list of activities, apart from meeting with decision makers on the part of the potential customer, includes a series of interviews with heads of the main (in the sense, defined above) functional organization units, observation of their work ("a Gemba walk"), and, in some cases, interviews with linear staff — candidates for main roles in the to be model.
2. Technical requirements preparation and approval
After we come to a mutual vision of what we want to have in the end, it all becomes simply technical, starting with developing and approving of the Technical requirements (TR).
The TR is a document, which clearly and exhaustively describes operations of the company in the to be state in IEM-abstraction. In other words, the TR describes what the system has to do — rather than how. The TR is an analogue of a workpiece drawing, rather than a description of miller machine operator actions to manufacture it.
The TR contains:
a rigorous description of all business processes implemented: both main (discussed at the preanalysis stage) and secondary (a back office, roughly said);
a list of business objects and their properties;
a list of reports and their properties;
user roles and rights.
The TR does not contain the favorite motive to flap mouths for many many hours (this refers to a certain character type, frequent among customer representatives): descriptions of screen forms, location of checkboxes and buttons.
This phenomenon is primarily characteristic of (but not be limited to) companies that are run high-handedly (=poorly); discussing buttons for their employees is a rare chance to feel (at least some) importance and power.
We’ll say it again: the workplace ergonomics is very important, but it is discussed (and corrected on the fly) during the training process of those users, who are going to use it.
Why do use the capital T in the word "Technical"? Because it’s the most important document.
It defines the project scope — what needs to be done — which, consequently, defines both the timeframe and the money.
Once again in other words: the Technical requirements content defines hundred percent of the future functionality of the system. If something is not mentioned there, it won’t be done, regardless of it even being self-obvious to the customer. More precisely, it might be done, but with a separate budget and in time outside the limit.
Caveat emptor, as Ancient Romans used to say. They had an eye for both commerce and management of most complicated projects.
So read it carefully and more than once, discuss, argue, make corrections. As opposed to the frequent approach: "come on, guys, it’s OK, let’s just do it, we’ll figure it out later in case anything goes wrong".
It’s better to think an extra week and save a lot more "later". Including the nerve cells that are so hard to restore.
The time for producing a TR usually ranges from two weeks to two months.
3. Issuing a quotation
After the TR has been approved, we calculate money and time, and issue the quotation. If compared to ERP for the same type of business it will cost 10 to 100 times less and deployed within months not years.
Satisfied? Let’s do it.
Since risks are shared fairly, the Integrator cannot be paid in advance. However, a small prepayment can be made to prove that Customer's intentions are firm.
4. Project work proper
Programmers and analytics do their work, users go through training, websites are designed
(if necessary), automatic data transfer from the old system is set up. Other general efforts are also made.
All of this is time-consuming, often troubling, but, in essence, trivial.
This is a great moment and whether it is a success depends on a number of factors like how well the TR was detailed, as well as initial system tests and users training. This is a moment of truth for all the parties involved.
The new system reaches its standard mode of operation within a month.
There should not be any serious troubles if there was a good project manager and fruitful collaboration between the parties and the company gets back on track within a week.
Does the IEM System functions normally? It's time to pay. Since risks are shared fairly, the Customer has the right to reject to implement the system within a month from the date of its commissioning. Without any explanations. Thus, the Customer may NOT pay for the system.
Besides, the Integrator must make a refund of all prepayments received.
It seems that due to such payment arrangements there has not been (yet) any failure with implementation of IEM projects.
In case of success, the Integrator receives both money for the project and a bunch of requests from the Customer's partners which witness the result.
In case of failure, both the Customer and Integrator suffer losses in time and money.
Rare examples of successful implementation of ERP systems (the actual number of which is about 10 times less than reported) are characterized by the following: The Spiral of Silence is a situation when a NON-customizable model of business processes on which a ERP system is based luckily matches the company profile: even a broken clock is right twice a day.
However, when there is a modern business operated in a competitive market, such coincidence is impossible even theoretically.
6. Very large-scale implementation
This is a case of either geographically extensive (like Walmart), or multibusiness companies (like GE).
In both instances, company's operations are obviously broken down into interdependent or entirely independent business units.
Thus, the risk of simultaneous transfer of all business units to the IEM platform clearly exceeds the benefit, so each business unit should be transferred one by one (or in groups).
The business units already controlled by the IEM System change information with lagged components of the entire enterprise, such as external suppliers/customers with the help of information tools (web services, smart contracts, b2b platforms, etc.).
The process of other business units connecting to the IEM System is like a black hole absorbing stardust around it — individual businessunits joins a single IEM information space and disappears in its solid uniformity.
Such staged implementation DOES NOT contradict the IEM imperatives of integrity and completeness: all business processes of each individual business unit are completely absorbed by the IEM System.
As more business units join the single IEM information space, the information tools used by departments (business units) are no longer needed and replaced with IEM business logic tools.
"It's easy and pleasant to tell the truth." The process of IEM System implementation is both profit and fun.
Do you remember unexpected conclusions made at the Preanalysis phase? The IEM System can sometimes be paid off even before its.
Anyway, after the IEM System is put into operation, it lays a solid foundation for the enterprise to evolve naturally into an ideal cybernetic IEM Enterprise.
Though this ideal state can't be ultimately reached, the process of improving may turn out to be very profitable.
Japanese call it kaizen.