High-quality deployed IEM-system implements a virtual model, which is
- complete
- closed
- unambiguously corresponding
real enterprise projection with all material diversity thereof.
Just imagine a mirror your business looks at. Such business mirror reflects only entities and processes having money measurement. However, it is a complete one.
Do you remember when in Terminator the Arnold Schwarzenegger character having lost his human-like disguising soft tissues turned into a skeleton-like metal robot with burning red eyes? Though its killer features and capabilities retained.
IEM virtualization for a real enterprise discards unimportant husk reflecting required value-adding chains only.
Which are business processes.
Your bath mirrors reflects your movement momentarily (for human perception).
IEM-model parameters evolve simultaneously as the real enterprise changes.
A real mirror reflects you with infinite for human perception resolution. You are indistinguishable from your reflection.
IEM-model level of details (as for any moment) is finite by definition. It makes sense to switch from the mirror analogy to your smartphone selfie camera. Image granularity depends on electronic hardware settings and capabilities. The clearer your image, the more memory is required to store images and more processor resources to handle them.
IEM-model level of detail depends on business requirements and its readiness to invest in model adjustments and real status maintenance.
Practical case: Reflection of a real accounting process for obtaining and recording documents on corporate client shipments.
The shipments are delivered from New York to Alaska by transport companies, while documents signed by your customers return with some delay.
Options to reflect issues with obtaining documents in IEM-models:
- none at all.
Document flow per se does not produce or spend any cash - it is an issue for accountants to handle, for that matter, they are paid for that. Transparency and control equal zero
- let’s introduce two states for shipment document with a “Document received” check-box: Document debt and No debt.
While goods are shipped the box by default is unchecked (Document Debt status), it is checked by an accountant once he/she obtains signed documents.
So, what we’ll get it is basic accounting and minimal analytical tools - document debt for customers and managers, debt gravity (duration), options for automatic remainders to be sent and/or fines/penalties to be imposed.
But with all that we are still unaware where documents for a particular shipment are located.
- Let's tighten up our total-control-maniac dial.
Each hardcopy of any way-bill/invoice bears a unique barcode generated by your system when the document is printed out. Each operation with this hardcopy (printing, signing by an authorized person, placing into transportation container, etc.) is recorded with barcode readers since your IEM-system logs operation author and time.
Then the documents are sent within an envelope container, which, in turn, is a full-featured piece of cargo when sent by a transportation company (or DHL). At each moment of time IEM-system knows for sure in which envelope a particular page is located, while integration with delivery company/courier service API can provide information on current envelope location along the way.
While placing received signed documents in the central archive your accountant scans barcodes of a particular page, folder, shelf and stack.
And the total-control-maniac can within half a second get exact data on location of any of dozens or hundreds of millions of paper sheets of way-bills along with complete history for each of them.
Upscaling level of detail for an IEM-model theoretically is unlimited.
Which is an alternative for real enterprise IEM-virtualization system offered by conventional ERPs?
They do not offer anything at all.
Moreover, typical ERP-integrator would have a hard time trying to grasp the gist of your question.
ERP per se CANNOT offer any entire enterprise model due to fundamental architecture limitations: Since conventional ERP is NOT an integral consistent system at all.
It’s like a bum who went to a dump site and picked pieces of mirrors, beer bottles and window glass. Such “integration” is made with a packing tape, saliva and thwacking things together. What are you going to see in such a "mirror"?
Stretching too far? Give me a break. It is exactly the way ERP-systems of market leaders during last 50 years were developed.
And, essentially, there we have a solution to a puzzle of extraordinary huge failure rate: Since ERP vendors perceive deployment as breaking, cracking, kinking and turning inside out for business processes of rationally arranged living company to conform with raving and sheer nonsense of disorganized, chaotic pile of bullshit and trash bearing pseudo-scientific names.
Here we talk, naturally, about those legendary "best practices".