top of page

Enterprise IT systems: a map of the classes

This article is also available in Russian: Russian version.

Digitalisation is impossible without IT systems. But IT projects fail far more often because the task was framed wrongly than because the technology was weak: the system is asked to do something it was never built for. In practice you constantly hear "we are implementing ERP", when what is actually being built is a management system for the whole enterprise, assembled from several different classes of IT system.

This article is a map of the entire landscape. For each class — the short version: what it does, which subclasses you meet in real life, who needs it. The deep dives, with the actual products, the role of AI and advice on the order of implementation, sit in six separate articles of the cycle, and each block links to the right one. I have grouped the map by management domains, because that is how these systems live inside a company — not alphabetically.

Where the pressure comes from now. The regulatory frame around this landscape has tightened on several sides at once, and none of it is an IT problem in the narrow sense. GDPR and its equivalents make personal data a board-level liability, and most of the classes on this map touch it. NIS2 pushes incident response, access control and supplier risk into the same conversation for a widening set of sectors. ISO/IEC 27001 has become the default language for proving that the control environment exists at all. The EU AI Act puts obligations on how AI is used, not only on how it is built, which lands squarely on the newest domain of this map. CSRD pulls sustainability data into the reporting perimeter that used to hold only financials, and that data is produced by production, energy and quality systems that were never designed to be audited. And under all of it, financial reporting under IFRS or GAAP and controls in the SOX sense rest on transactional data whose quality is decided at the very bottom of the landscape. The practical consequence is the same everywhere: the order in which you build matters more than the brand you buy. At the end of this article there is the full implementation-order map — who needs each class, what has to exist before it, and why the order is what it is.

The six deep dives: how to read on

The map of classes, which is the main body of this article, answers the question of what exists at all and why these classes stand next to each other. It is laid out across eleven management domains — that is, by the object being managed: money, the physical world, the document, the person.

The deep dives are assembled on a different principle: by the reader's task and by a shared entry threshold. That is why neighbouring domains of the map are sometimes glued into one article — counting money, planning and looking at analytics is one person's job, even though the objects of those domains are different. This is not a second map, it is a table of contents: the map says what belongs next to what, the table of contents says in what order to read about it.

Each article covers its domains in full. No class is left without a deep dive, and no class is covered twice.

  • 1. Production, assets and the warehouse — 4 Production and assets · 5 Logistics. what holds the article together: they run the physical world: the machine, the pump, the batch, the pallet

  • 2. Customers and sales — 3 Customers and the market. what holds the article together: they hold the history of the relationship with the buyer

  • 3. Money, planning and analytics — 1 Accounting and planning · 2 Analytics · 10 Projects and goals. what holds the article together: the four questions a manager asks: what happened, what are we planning, what is happening right now, what are we busy with

  • 4. Data and documents — 6 Documents and data. what holds the article together: where the master copy lives and who is accountable for it

  • 5. Routine automation and AI — 7 Processes and automation · 11 Artificial intelligence. what holds the article together: three ways to close a task without a large development project, at three different entry thresholds

  • 6. People and the IT function — 8 People · 9 IT function, security and the work environment. what holds the article together: the user here is an employee, not a customer and not a machine

Each article covers, for every class: what it does and what it does not do, who needs it and what has to be in place first, which vendors you will actually meet, where the real boundary of AI runs, and what to check before you buy.

Two classes on the map fall outside this set of six not by logic but by history: they already have their own separate article, written before the cycle. Those are business processes and modelling notations from domain 7 and IT infrastructure and cloud models from domain 9.

The map of classes by management domain

What follows is the map itself. It is grouped by management domains, because that is how these systems live inside a company rather than alphabetically. A domain is not a department and not a module — it is a set of classes collected on one principle: they manage the same object, or they answer the same question from the leadership. So each domain below first says what logic holds it together, and only then lists its classes.

Each class description covers what it does, where its boundary runs and when it becomes necessary. The link leads to the detailed review with actual products, the role of AI and a selection checklist.

Domain 1. Accounting and planning

The logic of the domain. These are the systems that account for the company's resources as a whole and plan them on a horizon from a week to a year. What unites them is the object of management: money, stock, obligations — the enterprise as a single economy, not one particular section of it.

Classes in this domain: ERP · EPM and CPM

ERP, enterprise resource planning. Responsible for money and resources on a horizon of a week to a quarter: finance, procurement, personnel, volume planning. It is the headquarters system, and that is also its boundary. It does not work in minutes and units, and it is no good for running a shop floor in real time. It becomes necessary at roughly 50–100 people, when the books stop reconciling in spreadsheets. For a manufacturer the order of implementation matters: ERP sits at the top of the IT systems pyramid, and without a worked-through production layer beneath it, it feeds on manual entry that nobody can trust. There is a second reason to care about the data underneath it: the numbers that leave the company under IFRS or GAAP, and the controls an auditor tests, are assembled here. Detailed review

EPM and CPM, budgeting and consolidation. A layer on top of accounting: the budget cycle, consolidation across a group of companies, what-if scenarios, OKRs and sustainability reporting. This is the CFO's instrument. It is normally implemented after ERP and analytics, for a simple reason: you can only consolidate what has already been accounted for. Where CSRD-style reporting applies, this is also the layer where non-financial data has to become as disciplined as financial data — which usually exposes how loose the source systems are. Detailed review

Domain 2. Analytics and decision support

The logic of the domain. These systems do not create data and do not run operations. They collect what has already accumulated in the other domains and turn it into grounds for a decision. What unites them is a function — interpreting somebody else's data rather than owning a subject area of their own. Hence their shared property: the quality of this domain is determined entirely by the quality of the sources beneath it.

Classes in this domain: BI · data warehouses and data lakes · decision support systems

BI, business intelligence. Collects data from the systems and turns it into reports, dashboards and summary indicators. It goes in after the first stable data source and grows together with the landscape. The main limitation is simple: analytics on top of chaos visualises the chaos, it does not put it in order.

Data warehouses and data lakes. The layer under analytics: a warehouse stores structured data against an agreed model, a lake accepts everything as it comes, unstructured included. Between them sits a preparation layer, and that layer usually eats the larger part of the project budget. A lake with no owner and no model turns into a swamp: putting things in is easy, getting them out is close to impossible.

Decision support systems. The youngest subclass in this domain: it answers not "what happened" but "what do we do about it". With generative AI it is developing faster than anything else here, and it sits at the summit of both implementation trajectories. The precondition is the same as for analytics: without reconciled facts and shared metric definitions it is built on sand.

Detailed review of the whole domain: Money, planning and analytics, the section on analytics.

Domain 3. Customers and the market

The logic of the domain. Every class here serves the relationship with the buyer, from first contact to repeat sale. What unites them is the addressee. The user sits outside the company, and the employee inside works with the history of the relationship with them. Hence the shared vulnerability of the domain: it is filled in by people, and the data in it is exactly as good as those people's motivation.

Classes in this domain: CRM and SRM · MarTech and CDP · contact centre and speech analytics · e-commerce, CMS and point of sale

CRM and SRM, working with customers and suppliers. CRM carries the customer journey from first contact through to service. It is the first system a small business buys and the source of customer data for the whole rest of the landscape. SRM is the mirror class for procurement and supplier relationships. Subclasses: sales, marketing, service, loyalty programmes, and for complex B2B offers also CPQ, the quote and configuration engine. Detailed review

MarTech and CDP, marketing and customer data. Campaigns, contact sequences, audience segmentation. A CDP assembles a single customer profile from every channel, end-to-end analytics shows which channel actually brings money, product analytics shows what people really do. It is normally implemented after CRM: there is nothing to automate marketing with if you have no data about the customer. This is also the part of the map where consent and lawful basis under GDPR stop being a legal formality and become a design constraint on the data model. Detailed review

Contact centre, telephony and speech analytics. Receiving and handling enquiries across every channel. Speech analytics turns conversations into data about the quality of sales and service; chatbots and voice robots absorb the routine enquiries. For a mid-sized business this is often the first "intelligent" system in the company. One mandatory condition: it must be wired into CRM, otherwise the domain produces no customer data at all and merely connects lines. Detailed review

E-commerce, CMS and point of sale. Storefront, basket, checkout; a CMS for content sites, till systems for retail, subscription billing for service models. The till stands slightly apart: it is a fiscal obligation, it goes in immediately and does not wait its turn. The storefront, on the other hand, needs a clean product catalogue — without one it turns into a stream of returns. Detailed review

Domain 4. Production and assets

The logic of the domain. These classes manage physical objects: the machine, the assembly, the batch. What unites them is the material world and the fact that is born in it. The engineering model of a product does not belong here, however much intuition says otherwise: it manages nothing physical, it holds the master description of what is to be made, and therefore lives in the data domain. Hence the defining property of this domain: it does not forgive lies in the data. An accounting system survives an inaccurate reference book; predictive maintenance built on work orders closed retroactively will predict exactly that fiction.

Classes in this domain: SCADA and process control · MES · APS · IIoT · BMS and BAS · EAM and maintenance · QMS, EHS and LIMS

The production stack: SCADA, MES, APS, IIoT. Everything between the sensor and the shop-floor plan. Process control systems and controllers drive the equipment directly, SCADA gives the operator real-time supervision, MES manages production on a horizon of shifts, APS calculates equipment schedules, industrial IoT platforms collect data off the hardware. Building management and automation systems, BMS and BAS, belong here too. For a manufacturer this is the foundation of the IT systems pyramid: data is born here, and the upper levels are trustworthy exactly to the degree that this layer has been worked through. It is demanding on infrastructure and on the accuracy of the model: an error in a digital twin costs you equipment, and that has been tested the hard way. Detailed review

EAM and maintenance management. Maintenance policy, planning of technical service, the economics of each individual asset. Subclasses: the asset register, mobile inspection rounds, the spare parts store, predictive diagnostics. In the mid-market the international term is CMMS; for real estate it is IWMS and CAFM. The classic traps here are not technical: resistance from the maintenance crews, and the risk of turning the system into formal reporting where plan completion is a hundred per cent while downtime keeps growing. Detailed review

QMS, EHS and LIMS, quality and industrial safety. Non-conformance management, corrective and preventive actions, quality audits, laboratory control. A separate layer covers occupational health, industrial safety and environment. For regulated industries this domain is not optional, and it is also what feeds sustainability reporting. It normally goes in on top of basic production accounting: you can only manage the quality of a process you already measure. Detailed review

Domain 5. Logistics

The logic of the domain. Three classes answering one question: where is the goods right now, and where does it need to be next. What unites them is the movement of a material flow through space and time. It differs from the production domain in that nothing here is created or physically changed — things are only moved and stored.

Classes in this domain: WMS · TMS · SCM

WMS, warehouse management. Location-based storage, receiving, put-away, picking speed, shelf-life control. A warehouse needs a master item list and a flow of orders, so this domain normally goes in after the accounting layer. The rule is simple: the system will lay out across its locations exactly the same mess that was sitting on the shelves, only now you have paid for it.

TMS, transport management. Routes, tariffs, dock slots, control over shipments and contractors. It works for an own fleet and for hired carriers alike. The effect here is counted in kilometres and idle time, not in interfaces.

SCM, supply chain management. The chain as a whole: demand forecasting, inventory norms, replenishment planning, supplier collaboration. This is the most mature ground for AI on the entire map, because demand forecasting is a task with a long history and an obvious metric. The data requirements match: two to three years of history and a clean item list.

Detailed review of the whole domain: Production, assets and the warehouse, the section on the warehouse and logistics.

Domain 6. Documents and data

The logic of the domain. These classes automate no business process at all. They hold what every other process uses: the document and the master record. What unites them is the subject of storage, not a section of work. The product model belongs here too: bill of materials, versions and drawings are also a master record, simply about a product rather than about a customer or a material. Hence this domain's place in the queue: it becomes necessary not when it hurts, but when there are more than two systems and they have started to disagree with each other.

Classes in this domain: ECM · e-document exchange · CLM · MDM · PIM · integration platforms · data governance · PLM, PDM, BIM and CAD

ECM, e-document exchange and CLM, document flow and the contract cycle. Internal document flow, legally binding exchange with counterparties and public authorities, electronic signature. A separate layer is contract lifecycle management: creation, approval, control of obligations and deadlines. This is not the same thing as records administration, and confusing the two is expensive. Electronic document flow is the flagship project of any digitalisation strategy, and its point is process optimisation, not moving paper into a digital form. Detailed review

MDM and PIM, reference and master data. Reference data is the heart of any system. Dirty reference data breaks end-to-end analytics before it has had time to pay for itself. MDM holds master records for customers, counterparties and materials; PIM is responsible for product attributes, without which you can build neither a storefront nor the storage rules in a warehouse. This is a foundation that becomes necessary as soon as there are two or three systems in the landscape. Detailed review

PLM, PDM, BIM and CAD, data about the product and the built object. The product and the object in digital form. CAD covers design and calculation, PDM stores engineering data and versions, PLM runs the product lifecycle end to end, BIM holds the information model of buildings and infrastructure. The product model is normally primary to production: the process route comes out of it rather than out of a technologist's head, which is why this layer is rolled out before MES. Formally it is an engineering project; in substance it is a project about data, and that is exactly why it stands here and not among the production systems. Detailed review

Integration platforms and data governance. An integration bus and cloud integration services connect systems to each other, replacing the cobweb of point-to-point links. Data governance and data catalogues set the policy: who owns the data, by what rules it changes, what counts as the master version. This is the layer companies usually buy last and then wish they had bought first. Its review sits in the same article as reference data.

Domain 7. Processes and automation

The logic of the domain. These classes have no subject area of their own. They are built on top of any systems in order to describe a process, speed it up, or close a manual seam between two applications. What unites them is a method of action, not an object. And they share one property: not one of them changes a process — all three set it in concrete.

Classes in this domain: BPM · RPA · IDP · low-code and no-code

BPM, business process management. Modelling, execution and control of processes: where, when, who does what work. Process mining reconstructs the real course of a process from digital traces in the systems, rather than from the way the process is described in a policy document. It is worth automating a process that is described and has an owner. Detailed review: business processes and modelling notations

RPA and IDP, automating the routine. Software robots perform operations directly in system interfaces, while intelligent document processing recognises and extracts data from invoices, delivery notes and certificates. The trigger for implementation is two or more employees busy moving data between systems by hand. Only a stable process can be robotised: a robot on top of chaos breaks weekly. And there is a separate boundary: wherever systems can be joined by a supported integration, a robot in the interface is an expensive prosthesis. Detailed review

Low-code and no-code, applications without programmers. The business assembles working applications out of ready-made blocks without joining the queue for development. The strength of the class is speed: weeks instead of quarters on small tasks. There are two boundaries. The first is complex logic and performance: what is easy at the start runs into the platform's ceiling. The second is support: without shared reference data, an application register and publication rules, this class breeds a zoo within a year or eighteen months, and nobody manages it. Detailed review

Domain 8. People

The logic of the domain. The object of record here is the employee and their path through the company: hiring, onboarding, training, scheduling, development, departure. What unites them is a person's lifecycle, not the function of a department. The shared constraint of this domain is legal: everything processed here belongs to the most sensitive category of data in the company, and under GDPR and its equivalents the employer carries the accountability for it.

Classes in this domain: HRM · ATS · HR e-document flow · WFM · LMS · knowledge bases

HR tech: HRM, ATS, HR e-document flow, WFM. The personnel core is legally mandatory from the first employee and is usually predetermined by the company's accounting system. Above it come the add-ons, and each one switches on at its own trigger: an applicant tracking system at roughly thirty hires a year, shift management wherever there is shift-based staff, HR e-document flow to take paper out of personnel procedures, pulse surveys to measure engagement. This is one of the fastest-growing segments of the market. Detailed review

LMS and knowledge bases. Corporate learning: courses, tests, development paths, onboarding of new joiners. A knowledge management system is a single store of what the company knows. The important detail today: a well-kept knowledge base has become the fuel for corporate AI. The assistant is built on top of it, not instead of it — and given contradictory internal policies it will confidently pick one version and never mention that there was a second. Detailed review

Domain 9. IT function, security and the work environment

The logic of the domain. These classes serve no business process. They serve the company's very ability to work: that the systems are alive, that access is granted to the right people, that mail and documents open. What unites them is that they are the hygiene layer underneath everything else. Hence the domain's typical misfortune: its effect is visible only when it is absent, and in a budget discussion it loses to any visible project.

Classes in this domain: ITSM · ITAM and CMDB · monitoring · information security · digital workplace · cloud models

ITSM, ITAM and monitoring, IT service management. Requests, incidents, changes, the service catalogue, service level agreements. ITAM and CMDB keep track of IT assets and the relationships between them; monitoring watches the health of the systems. ITSM is often the company's first school of process management. The key condition for survival: asset records must be fed by automatic discovery — a register built by hand is already lying within a quarter. Detailed review

Information security. This is a layered domain, and its classes cover different lines of defence. DLP protects against data leakage. IDM, IAM and PAM manage accounts, access and privileges. SIEM and SOAR collect events and organise response. EDR and XDR cover endpoints. NGFW and SASE handle the network. Vulnerability management stands separately, as does backup — the last line, which is verified by restoring, not by faith. Physical security adds video analytics and access control systems. ISO/IEC 27001 is the usual frame for proving that all of this is a managed system rather than a pile of tools, and NIS2 has pushed incident response and supplier risk up the agenda for a widening set of sectors. With the arrival of generative AI came deepfakes of an executive's voice and attacks on corporate assistants, and the old defensive rules do not catch them. Detailed review

The digital workplace. Office suites, corporate mail and calendar, messengers, video conferencing, portals, file storage, reference and legal databases. This is the layer every company has, regardless of size, and the one most often up for replacement or consolidation. It is not a project with a payback calculation, it is an environment — and replacing it breaks on people and habits, not on technology. Detailed review

Cloud models. Every class on this map is deployed either on your own premises or as a service. SaaS gives you a finished application from the cloud, IaaS rented servers and networks, PaaS a platform for your own development. Controlling cloud spend is called FinOps, and it becomes necessary earlier than the company expects to be surprised by an invoice. Detailed review

Domain 10. Projects and goals

The logic of the domain. These classes answer the question of what the company is doing in order to change. What unites them is the management of change rather than of ongoing operations. The peculiarity of this domain is that it barely depends on the maturity of the rest of the landscape: project discipline requires neither ERP nor analytics, so the class appears early.

Classes in this domain: task trackers · PPM · PSA · OKR tools

Project and task management systems. Kanban boards and task tracking for a team. PPM manages the project portfolio once projects start competing for the same people. PSA calculates project economics in a services business. OKR tools hold the cascade of goals from strategy down to the individual. The main selection rule is to match the size of the task: a corporate platform gets in a small team's way, and a lightweight tracker will not hold a portfolio of fifty initiatives. Detailed review

Domain 11. Artificial intelligence

The logic of the domain. The youngest domain on the map, and the only one that would not have made it into a review like this two years ago. What unites these classes is not a subject area but a mode of work: none of them operates on records in a database — they operate on the meaning of text, of images and of sequences of actions. Its place in the landscape is unusual too: it is laid on top of whatever data and process maturity already exists, not instead of it.

Classes in this domain: model-serving platforms · RAG assistants · copilots · AI agents · MLOps · AI governance

LLM platforms, RAG and AI agents. Model-serving platforms give the company a controlled perimeter: where the model runs, what data it can reach, what is logged. RAG assistants answer from the corporate knowledge base with a link back to the source. Copilots help inside the working tool. Agents do not answer, they act: they call systems themselves and execute steps of a process. MLOps covers running models in production; AI governance covers risk management and the question of which scenarios may be handed to AI at all — and under the EU AI Act that question has acquired a legal weight it did not have before. The top step of both implementation trajectories, executive decision support, is assembled on precisely this layer. It is the fastest-growing class on the map and the one whose risks are most underestimated. Detailed review

In what order to implement all this

There is one principle: a company builds a house starting from the foundation. The goal is data of a quality you can actually make decisions on, without inflating headcount with people who "key everything in" by hand. So a system goes first to where the data is born — and where that is depends on the profile of the business.

Hence two implementation trajectories, a model of Dzhimsher Chelidze: depending on the profile of the business, a company either climbs the IT systems pyramid or starts from the point of contact with the customer.

A manufacturing company climbs the IT systems pyramid, in which the landscape is built bottom-up, starting from the production systems, like a house from its foundation. Simplified, the chain looks roughly like this: process control and SCADA → MES (sometimes in a simplified form, as production accounting) and industrial automation → ERP → analytics and EPM → executive decision support built on generative AI. You cannot arrive at the upper levels without working through the lower ones. ERP without production management degenerates into manual data entry that nobody can trust. The base of the pyramid is process control: the controllers and sensors that drive the equipment directly. SCADA is the bridge between that level and the production systems — it makes what is happening on the hardware visible to people and to data.

A trade or services company, which has no production layer, starts where its data is born — at the point of contact with the customer. In simplified form the chain looks roughly like this: CRM → e-document flow and the digital workplace / RPA → order in the reference data → ERP → BI → EPM → executive decision support built on generative AI.

What both trajectories share: processes first, then the system — the system sets in concrete whatever discipline already exists. Every article in the cycle has a section on who needs a class and what has to come before it; all of them rest on the same map, and it is reproduced below in full.

The implementation-order map: who, after what, and why

This is the summary map by Dzhimsher Chelidze on which the whole cycle rests: for each class, the threshold at which it becomes necessary, what has to appear in the company earlier, and why the order is what it is. The thresholds are orientation points, not standards: they shift with the industry and with how formalised your processes are.

The rows on the manufacturing trajectory are MES/SCADA, EAM, PLM, QMS. The rows on the trade and services trajectory are CRM, e-commerce and point of sale, contact centre, MarTech. Every other class is shared by both.

  • CRM / SRM — sales take more than one contact; the first class for a small business. implement after: — a starting class. why this order: fastest effect; the source of customer data for everything else

  • MES, SCADA, APS, IIoT — production with shift-level planning. implement after: digitalising the process route; before or alongside ERP. why this order: data is born on the lower levels; without them the upper systems feed on manual entry

  • ERP — 50–100+ people, full accounting, more than one legal entity. implement after: manufacturing profile — after the production layer; trade and services — after CRM and order in the reference data. why this order: ERP sits at the top of the pyramid: without the lower levels it is manual entry and unreliable data

  • PLM / PDM / BIM — development of complex products, or construction. implement after: discipline in working with CAD. why this order: the product model is normally primary to production

  • EAM and maintenance — a fleet of equipment, high cost of downtime. implement after: the asset register; in parallel with MES. why this order: without a single asset register, maintenance stays a spreadsheet journal

  • ECM / e-document exchange / CLM — 30+ people or external document flow; CLM from around 100 contracts a year. implement after: — an early class. why this order: the flagship project of a digitalisation strategy and an early entry into process management

  • Data and integration: MDM, PIM, ESB — 2–3 systems and more, end-to-end analytics, migrations. implement after: the appearance of 2–3 systems. why this order: integration and reference data are the foundation; before that MDM is overkill

  • BI, DWH, decision support — 3+ systems and manual reconciliation. implement after: the first stable data source; grows with the landscape. why this order: BI on top of chaos visualises chaos

  • Information security — the base layer for everyone; SIEM and a SOC from mid-size upwards. implement after: base layer immediately; SIEM normally after order in IT assets. why this order: you cannot protect what has not been inventoried

  • WMS / SCM / TMS — a warehouse of any real size, own logistics. implement after: normally ERP or the accounting layer. why this order: a warehouse needs a master item list and a master order flow

  • ITSM / ITAM — an IT function of five people or more, or external SLAs. implement after: — as IT grows. why this order: ITSM disciplines IT before IT disciplines the business

  • HR tech: HRM, ATS, WFM, HR e-documents — personnel core from the first employees; ATS from around 30 hires a year. implement after: core immediately, add-ons by trigger. why this order: personnel records are a legal obligation, the rest goes by where it hurts

  • LMS and knowledge bases — 50+ people or regular hiring. implement after: normally the HR core. why this order: the knowledge base is the future fuel of corporate AI

  • Project management systems — 5+ parallel projects. implement after: — an early class. why this order: project discipline requires no landscape

  • Contact centre and speech analytics — more than a couple of dozen enquiries a day. implement after: normally CRM. why this order: without CRM, calls do not turn into customer data

  • E-commerce, CMS, point of sale — online sales; tills for retail. implement after: storefront after CRM and a master product list; the till is a fiscal obligation and goes in immediately. why this order: a storefront without a clean catalogue produces returns and chaos

  • MarTech and CDP — B2C or content-driven B2B; CDP from around three contact channels. implement after: normally CRM and the digital channels. why this order: there is nothing to automate marketing with if you have no customer data

  • EPM / CPM — a group of companies, a budget cycle, consolidation. implement after: normally ERP and BI. why this order: you can only consolidate what has been accounted for

  • QMS and EHS — manufacturing; in regulated industries, mandatory. implement after: normally basic production accounting. why this order: you can only manage the quality of a measured process

  • Low-code — the queue for development runs longer than three months. implement after: in SMB — shared reference data and integration rules; in mid-size and above — normally an integration bus. why this order: otherwise it breeds new silos

  • BPM — described procedures and a process owner already exist. implement after: — outside the general queue, driven by process-management maturity. why this order: it is worth automating a process that is described and has an owner

  • RPA and IDP — moving data between systems consumes the labour of 2+ people. implement after: stabilising the processes you intend to robotise. why this order: a robot on an unstable process breaks weekly

  • AI platforms, LLMs, agents; executive decision support — data and processes have accumulated, and there is an owner. implement after: the domain you are strengthening, and the rules for working with data. why this order: the top step of both trajectories: it goes on top of maturity, not instead of it

  • Digital workplace — everyone; actively when the office suite is being replaced or consolidated. implement after: — a hygiene layer. why this order: mail, office and messenger are an environment, not a project

The map reads top-down only within its own trajectory: a manufacturer starts with the production layer, a trade or services company starts with CRM. There is no universal single sequence for everyone, and trying to derive one is the most common mistake in digitalisation roadmaps.

Almost every modern system is a hybrid

In practice the boundaries between the classes in this review blur. Almost any mature system today is a hybrid: ERP grows a CRM module and a procurement portal, an ECM system grows a process designer, a BI platform grows data preparation tooling. As practice shows, value for the business sits in cross-functional interaction, so IT systems start covering more and more territory. That is why developers and vendors assemble platforms out of modules, and a "pure" class from the classifier is met less and less often in real life. Three things follow from this, and all three are worth checking when you choose.

First: the modules must stay autonomous. Good architecture lets you develop the system piece by piece: you launch the warehouse, add production six months later, add treasury a year after that. Each module is switched on, extended and replaced separately, without breaking everything else. Bad architecture is built as a monolith: to change one piece you have to touch everything, and any customisation turns into a mini-implementation. One of the control questions to ask a vendor: "Can we run only one of your modules and replace the neighbouring one with a third-party product?" The answer will tell you a great deal about what is inside the platform.

This requirement has an international name: Gartner calls the approach composable ERP — assembling the system from independent blocks, packaged business capabilities. The technical standard for that autonomy is called MACH architecture, four principles behind four letters: microservices, API-first, cloud-native, and a front end decoupled from the internal logic. So the question in the paragraph above is not nitpicking, it is the global standard for selecting solutions.

Second: the heart of a hybrid is not the modules but the database and the interaction between them. Modules come and go, the data stays. And "the database" here does not necessarily mean one database management system for everything. Yes, a single store across all IT systems makes development, analytics and AI implementation dramatically simpler. But the core value is not the store — it is a single data model, consistency, interoperability and reuse of data between modules. The useful questions here are:

  • How is the reference data structured?

  • Who is the master source for each object: the customer, the material, the piece of equipment?

  • Do the modules reuse the same data, or does each keep its own copy?

If a customer has been created three times — in CRM, in ERP and in the service system — those three records will never merge back into one, and end-to-end analytics across processes and departments will not work. In our training sessions we call this the canonical data model, and its absence is a textbook mistake: every new integration costs more than the last, the reference data accumulates workarounds, and developing anything AI-based becomes impossible outright. Consistency, interoperability and reuse of data between modules and IT systems is exactly what separates a single information space from a zoo of systems sold under one sign.

Third: data quality is a concern from day one, not a "we will tidy up later". There are two main tasks here. Automate the capture of primary data — sensors, integrations, scanning, anything that takes the human out of data entry: people make mistakes, sometimes by accident and sometimes on purpose. And constrain manual entry wherever it remains: dropdowns, reference lists and validation instead of free-text fields. The rule is hard: dirty data gives a dirty result. No analytics module and no AI compensates for that.

So when you choose a hybrid platform, what you are really choosing is not a set of functions but a data model and a module architecture: how autonomous the modules are, how consistent they are, and what the rules for reusing data are. Functions can be caught up with; architecture almost never can. That is why in our own product, Sokol, we put the emphasis precisely on capturing quality data and on how artificial intelligence works with context.

A deep dive into the data foundation: MDM and PIM: managing data and reference data

The shared limit of all these systems

Every system in this review shares one limit. They answer the question "what is happening": ERP shows the finances, MES shows production, BI assembles it into a dashboard. But the question a leader actually asks is different — "what do I do about it". And answering that needs not system data but context, and the context is not in the systems: goals, past decisions and the reasoning behind them, agreements made with people. That context lives in someone's head and in scattered notes, and it is the first thing to be lost.

The answer to this is not another corporate system but a personal management loop: a place where goals, decisions, communications and results are linked to each other and accumulate. Such a loop works regardless of what has been implemented in the company — it belongs to the leader, and it is personalised to them, to their strengths and their weak spots.

You can start with no system at all, with discipline: a weekly review of goals, notes on decisions, coming back to what was deferred. We do this in Sokol: it ties goals to the daily work of managing, helps prepare decisions and hold strategic focus — that is, it turns that same discipline into a system. The honest boundary: Sokol replaces none of the systems in this review and does not connect to your ERP or MES. It works one level above, with the leader's personal loop, and it requires no company-wide implementation.

Bottom line

What you are choosing is not a box but an architecture: which classes you need, in what order (this is critical — get it wrong and you get investment without return), how autonomous the modules are, and how they will exchange data. And the main thing that has not changed in years: IT systems will not fix broken processes, weak management or absent motivation. Processes and people first, the system afterwards.

For a small or mid-sized trade and services business the order is usually this: CRM first, to digitalise the customer journey; then inventory accounting, electronic document flow and order in the reference data. ERP comes when the company has outgrown 50–100 people and needs full accounting. After that, analytics and — increasingly — AI assistants over the company's own data. A small manufacturer goes the other way, from the production layer and up the pyramid: there is no universal sequence for everyone.

What next

To go deeper, there are the books by Dzhimsher Chelidze: "Digital Transformation for Directors and Owners" (parts 1–3), "Artificial Intelligence. Freefall" — third edition, free download — and "Artificial Intelligence. A Practical Guide to Implementation". The articles in this cycle draw on two lists from the last of those: the six traps of AI implementation and the seven sins of digitalisation. If questions remain, you are welcome to come to us for training or consulting.

How all this maps onto your company — training and consulting.

bottom of page