Money, planning and analytics: the loop that counts the business

This article is also available in Russian: Russian version.

The four classes in this article answer four questions every executive asks, and the questions come in a strict order. What has already happened — that is accounting, ERP. What we intend to do — the plan and the budget, EPM. What is happening right now and why — analytics, BI. What we are doing to change it — projects and portfolio.

The order is not a convention. Each class feeds on the data of the one before it, and skipping a step ends the same way every time: the system is live and nobody believes the numbers. A budget built on accounting where the balances of three warehouses were never reconciled is an exercise in penmanship. Analytics over sources where each department computes "revenue" differently shows three revenues and starts an argument instead of a decision. A portfolio where every status stays green until the last day is not a management system, it is a reporting ritual.

There is also a shared vulnerability that gets discussed less. All four classes work with numbers, and numbers inside a company are politics. Every number has an author who benefits from it looking a particular way. Mistaking an indicator for reality is especially dangerous here: one hundred per cent plan attainment while problems grow does not mean order, it means well-tuned reporting.

Below: what each class does, who needs it, and what has to be in place first. At the end — how they connect, the vendors you will meet, and a shared selection checklist.

What's in this article

• The system of record: ERP — what it counts, what it is made of, what forces the decision

• Budgets and planning: EPM and CPM — the budget cycle, consolidation, scenarios

• Analytics: BI and the road to decision support — from reports to decisions on data

• Projects and portfolio: from task tracker to PPM — what the company is doing to change

• How these four classes connect — the order of moves and a shared vocabulary

• The role of AI in the management loop — what works, where the boundary sits, why validation gets skipped

• Vendors you will actually meet — the names on your shortlist and how to read the tables

• Typical mistakes and a selection checklist — the failure modes and what to verify before you buy

The system of record: ERP

ERP gets bought first more often than any other class of IT system: to a top team it looks like understandable value and a solution to problems. It is also the most expensive sequencing mistake. In the pyramid of IT systems ERP sits at the top: without a working operational layer underneath, it does not count resources — it neatly adds up untrustworthy manual entry and inflates headcount. Automation stops reducing manual labour and starts creating it. Strip out the marketing and ERP is the system in which an enterprise counts its resources: money, people, materials, capacity. It is not a management system. What it does, what it does not do, what modules it has and what it computes.

What ERP does — and what it does not

ERP works on a horizon of a week to a quarter and answers head-office questions: what is our profitability, how much to purchase, when to refresh production capacity, where we stand on statutory reporting. It is a system about money and administrative accounting.

Hence the boundary that has broken more than one project: ERP is not suitable for running the shop floor. It does not deal in minutes, litres and units and cannot replan a shift in real time. That is what the production loop is for — MES, SCADA, APS; putting ERP there is like running a machine tool from the accounting department. That boundary is unpacked in the article on MES and the industrial loop.

A second caveat from practice. Most projects sold under the "ERP" label are hybrids: inside sit MES, WMS and MDM modules — production, warehouse and master data. So compare not the names of systems but the set of modules against your tasks. And the most dangerous mistake is to implement everything in one project across the whole organisation at once. That is a near-guaranteed failure.

The modules you actually meet

In practice, "implement ERP" almost always means choosing from these blocks:

• Finance and accounting — the core; the primary customer is the CFO and statutory reporting.

Effect: the close goes from weeks to days, and there is one version of the numbers.

Drawback: the most rigid part of the system — reworking the accounting policy after go-live is painful.

• Procurement and supply — requisitions, limits, contracts; the adjacent class is SRM.

Effect: commitments and limits become visible, and there are fewer "surprise" payments.

Drawback: without requisition discipline it degrades into after-the-fact registration of purchases already made.

• Master production scheduling — "how much and when", without shop-floor detail.

Effect: the sales plan is tied to capacity on a horizon of months.

Drawback: the temptation to plan the shop floor with it — MES territory, and without the lower levels of the pyramid the plan is detached from the actuals.

• Human resources — personnel records and payroll; in larger configurations, a separate HRM loop.

Effect: mandatory records and calculations without manual errors.

Drawback: HR functions deeper than record-keeping — hiring, development — are covered worse here than by specialised systems.

• Asset management — basic asset accounting; a full maintenance and repair loop is already the EAM class.

Effect: assets become visible in money terms.

Drawback: it creates the illusion that "we have maintenance management", which you do not.

• APS module — production scheduling; as a standalone class it is rarely viable, more often it is a module of ERP or MES.

Effect: a feasible plan instead of a desired one.

Drawback: demanding about the accuracy of standards — on inaccurate data it pushes the plan right, day after day.

The selection rule is simple: the module critical to you must be mature at the vendor, not "on the roadmap". Maturity is verified by references in your industry, not by a presentation.

What ERP counts: indicators and metrics

The answer to "what does ERP give us" gets clear when you look past the modules at the numbers it can compute. ERP collects four end-to-end flows and hangs indicators on each.

Money: from transaction to statement. Planned and actual cost, variance of actual against plan, margin by product, order and customer. Receivables and payables, the payment calendar, cash gaps. Plan versus actual by budget line and cost centre. A separate one is the length of the close: days between month end and finished numbers. The most honest maturity indicator accounting has.

Inventory and procurement: from requisition to payment. Inventory turnover and days of stock, the share of dead stock, the accuracy of book balances against physical counts. On procurement: cycle time from requisition to delivery, the share of contracted versus unplanned purchases, the variance of purchase price against plan.

Capacity and plan: from plan to output. Capacity utilisation by area, attainment of the volume plan, standard hours per item, cost per processing stage. The caveat: ERP computes this on a horizon of weeks and months. Shift assignments and line output are the territory of MES.

Orders and customers: from order to cash. Order cycle time, the share of orders delivered on time and in full, average days to payment. This is where ERP meets CRM: the deal lives in CRM, the shipment and the money live in ERP.

People. Payroll cost, headcount and its dynamics, the working-time fund, the share of overtime. Anything deeper belongs to HR tech.

Where the boundary runs. ERP counts resource facts and what derives from them. It answers "how much did we spend and how much is left", not "what do we do about it". Scenario comparison, trends and executive dashboards live in the analytics loop; the budget model of a group lives in EPM; preparing the decision itself lives in decision support. That is why ERP is not a management system: it gives a trustworthy base on which management becomes possible.

The unit of measure decides everything. ERP works in money, on a horizon of weeks to quarters. Minutes, litres and units in real time belong to other classes. Practical rule: if an indicator is needed daily for the morning stand-up, its source is probably not ERP.

A number without a norm is useless. Every indicator above works only in comparison: against plan, standard, previous period, another unit. ERP stores both — but the standard is put in by the company, not the vendor. Empty standards tables are the commonest reason why "we have the system but no indicators".

What ERP gives the business — and its typical drawbacks

Effect. One accounting loop instead of a dozen spreadsheets: the close goes from weeks to days; numbers stop diverging between departments; a base appears for planning purchasing and production and for honest analytics on top. An indirect but important effect is the master data and process discipline the system forces you to maintain.

Drawbacks that get discussed less. Cost and duration: a full implementation runs one to three years, and migration eats up to half the budget. Rigidity: rebuilding processes after go-live is expensive, so a crooked process that made it into the system lives there for years. Dependence on input quality: ERP does not create data, it records it — and without the lower levels of the pyramid that means manual entry. Resistance: for half the users ERP is "extra reporting", and without motivation work the project stalls.

Who needs ERP, who is too early — and what to implement it after

You need it once the company has outgrown 50–100 people and accounting no longer adds up in heads and spreadsheets: several business units, real planning, statutory reporting under a full regime, more than one legal entity. Symptoms that it is time: the close stretches into weeks; the same numbers do not match across departments; purchasing decisions are made blind.

Too early, or not needed: under roughly 50 people a bookkeeping package, a CRM and an inventory tool are usually enough. A full ERP at that scale rarely pays back and eats the management attention needed to run it. By subclass: master scheduling is unnecessary for service companies without production; an HRM loop inside ERP is excessive under a hundred people.

What it connects to. ERP is the system of record of the landscape: customer data from CRM, production facts from MES, master data from MDM; upward it feeds BI and EPM. The cleaner those connections, the fewer manual reconciliations.

What to implement it after, and why. It depends on the profile. If the company designs its own products, one more input appears: ERP takes the bill of materials and the specification from the PLM, PDM and BIM loop instead of rebuilding them.

A manufacturing company goes up the pyramid from the bottom — its main difference from a trading one: process control and SCADA → MES → and only then ERP. You cannot reach the upper levels without the lower: ERP without production management feeds on manual entry, the data is untrustworthy, and headcount grows with the people typing it in. A trading or service company starts with CRM — its data is born at the point of contact — and with order in the master data, then ERP, then analytics. The rule: ERP before order in the processes casts the disorder in concrete.

What actually forces the ERP decision

Three mechanisms do the forcing, and they run on different clocks.

• Vendor maintenance end-of-life and cloud migration. Every major on-premise suite eventually leaves mainstream support, and the successor is a cloud or hybrid product with a different data model. This is not a marketing push, it is a support contract running out: after that you run the system at your own risk, with extended support priced to make you move. Confirm the end-of-maintenance date for your exact release with your vendor — editions differ, extensions get announced — and plan backwards from it.

• Audit and reporting requirements. Where SOX applies, internal control over financial reporting has to be demonstrable in the system, not assembled in spreadsheets at year end. IFRS or GAAP group reporting requires a consistent chart of accounts and traceability from transaction to statement. CSRD sustainability reporting pulls non-financial data — energy, emissions, supply chain — into the same discipline, which older systems were never built to carry. Each turns "we reconcile it manually" into an audit finding.

• Data residency rules. Where personal or regulated data has to stay in a jurisdiction, the choice narrows to the deployment options your vendor offers there. A constraint on the shortlist rather than a reason to replace a system, but it kills good candidates late if nobody checks early.

In practice: on an older on-premise suite the question is no longer "whether to move" but "will we choose and pilot before the implementation market for our platform gets crowded". Everyone on the same product hits the same window, and the binding constraint is not licences, it is the number of experienced teams.

A sense of scale. Do not put a number in the board paper before a survey. Cost is driven, roughly in this order, by the number of legal entities and statutory regimes you report under; the number of users and how many are full-function; the integrations with systems you already have; and how far you allow customisation away from the standard configuration. On duration: a compact go-live takes 6–9 months, a full mid-size implementation about a year, a group two to four years in waves by site. Licences are the wrong thing to count — services are usually a multiple. Budget separate lines for implementation (process analysis, documentation, sign-off, configuration), support, infrastructure, data migration and running two systems in parallel.

The ERP vendors you will actually meet

Shortlists in this class are stable across markets. The names that come up in most selections, with the profile each usually fits. No ranking, no claim about who is bigger.

• SAP S/4HANA — large multi-entity groups, process and discrete manufacturing. comment: the heavy end; cost sits in the implementation, not the licence

• Oracle Fusion Cloud ERP / NetSuite — Fusion for large groups, NetSuite for mid-market multi-entity growth. comment: two different products from one vendor — do not let an RFP blur them

• Microsoft Dynamics 365 Finance & Operations — mid-market and upper mid-market: distribution, services, discrete manufacturing. comment: usually shortlisted where the Microsoft stack is in place

• Infor CloudSuite — industry editions: process manufacturing, food and beverage, aerospace. comment: verify that the edition for your industry is the mature one

• IFS — asset-intensive industries, field service, EAM in one product. comment: strong asset and service side; check the finance side against your reporting

• Epicor — discrete manufacturing and distribution, mid-market. comment: closer to the shop floor than most

• Sage — finance-first deployments, multi-entity accounting. comment: strong accounting core; check what else you would still buy

• Odoo — small and mid-size companies, modular, open-source core. comment: cheap to start; the cost reappears as customisation and maintenance ownership

How to read the table: not a ranking, a list of candidates admitted to comparison. Three systems for your profile on the shortlist, reference visits, a pilot on one loop — then a decision.

Budgets and planning: EPM and CPM

The budget cycle in a company without EPM looks the same everywhere: forty spreadsheets collected by email, two weeks of consolidation, three versions of the "final" model. Then the owner asks "what if revenue drops fifteen per cent?" and everything is recalculated from scratch. This class turns that into a process. What it is made of, who needs it, what it comes after.

What the class does — and what it does not

EPM is a layer over accounting: budgets, plans, consolidation of several legal entities, scenarios, plan versus actual, management reporting.

What it does not do: it does not replace accounting or put it in order. You can only consolidate what has been recorded — if one legal entity names its cost lines differently, EPM will not fix that, it will expose it. And it does not decide: the system computes scenarios, the choice between them stays a management act.

Subclasses: what the class consists of

Budgeting and planning. Collection forms, budget versions, approval, limits, plan versus actual.

Effect: the cycle compresses from weeks to days, and there is always exactly one version.

Drawback: without a documented planning methodology the system only speeds up the collection of the same wrong numbers.

Group consolidation. Combining the reporting of several legal entities, eliminating intragroup turnover, reconciling different accounting policies.

Effect: the group sees itself as a whole, and the close stops being an emergency.

Drawback: the subclass most demanding of consistent master data — divergences in cost lines and analytical dimensions surface exactly here.

Scenario modelling. "What if" on revenue, exchange rate, prices, volumes; stress tests.

Effect: the owner's question is answered in hours rather than in a week.

Drawback: the quality of a scenario equals the quality of the model — an elegant tool on bad assumptions produces an elegant wrong forecast.

Goals and indicators: OKR, KPI. Cascading objectives, connecting strategy to the budget.

Effect: goals stop living separately from the money.

Drawback: it easily turns into a reporting ritual — the indicators are green and the strategy has not moved.

ESG and non-financial reporting. Collection and disclosure of non-financial indicators.

Effect: investor and counterparty requirements are met systematically, not in an annual scramble.

Drawback: needed where it is required of you — otherwise it is overhead.

Who needs the class, who is too early — and what to implement it after

You need it in a group, a business with several legal entities or a complex budget cycle. Symptoms that it is time: the budget is assembled in dozens of files; the close takes weeks; answering "what if" takes days; versions diverge between units.

Too early, or not needed: a single legal entity with a simple cost structure is fine with the budgeting module of its accounting system plus discipline.

The portfolio arrives here from below, out of the project management systems: EPM consolidates the portfolio's money, but the projects themselves do not live in it.

What it connects to and when to implement it. As a rule it goes in after ERP and the analytics loop — you can only consolidate what has been recorded, and scenarios are built on data already collected and cleaned. Input: accounting data from ERP and BI; output: reporting to owners, investors and auditors.

What the class gives the business — and its typical drawbacks

Effect. Cycle speed: planning and closing stop eating the finance function's calendar. One version of the truth in the group's numbers. And control: scenarios turn the conversation about risk from a clash of opinions into a calculation.

Drawbacks that get discussed less. The class is expensive not in licences but in methodology: describing a group's budget model is a project in itself, and without it the implementation stalls. It preserves methodological errors: wrong allocation logic will now be applied quickly and to everyone. And it requires financial discipline from the units — the system will not make them plan honestly.

Which level of effect you are buying

A useful frame before you start. Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation" separates two levels of change: point optimisation delivers an improvement an order of magnitude smaller than transformation — rebuilding how the business itself is arranged (on the book's cases, roughly half a point of EBIT against five). The difference is not diligence, it is ambition.

For EPM this translates literally. You can automate the existing budget process: same forms, same deadlines, only faster — optimisation, and its effect is honestly modest. Or change the way you manage: move from an annual budget to rolling planning, tie goals to money, decide on scenarios. The second delivers several times more and costs several times more — in effort, not licences. The mistake is buying the tool for the second and doing the first, then being surprised by the return.

What is actually driving EPM decisions

Two things move this class, and neither is a software feature. First, reporting obligation: IFRS or GAAP group reporting and, where CSRD applies, non-financial disclosure push the same requirement — one model, one set of definitions, an auditable trail from source to statement. Spreadsheet consolidation survives an unaudited year, not a signed one. Second, the platform shift: planning products moved to the cloud, and the market split between broad platforms that model anything and narrower products that ship a working budget process out of the box.

A sense of scale. Cost drivers: legal entities, consolidation rules that deviate from the standard, planning users, source systems feeding the model, and how much of your methodology exists on paper before the project starts. A first working cycle typically takes 4–8 months. Most specialised platforms quote on request, so treat any early number as a placeholder and cost it after a survey. The main budget risk is not the licence but the methodology: an unagreed consolidation model costs more to rework than to build.

Analytics: BI and the road to decision support

A familiar scene: the CFO has one revenue figure, the commercial director another, and half an hour goes on establishing whose is right. Both came out of systems, both are "correct" — they were computed differently. The analytics loop exists so that this scene does not happen: one version of the truth, without waiting a week for a report. What the loop consists of, why BI over chaos visualises chaos, and what has to exist before the first dashboard.

What the loop does — and what it does not

The analytics loop collects data from the operating systems — ERP, CRM, production — brings it to a common form and turns it into a picture for decisions: reports, dashboards, "what if".

What it does not do: it does not create data or put it in order. BI shows what is in the sources, at exactly the quality it sits there. If master data is dirty and departments define revenue differently, analytics will not fix that, it will highlight it. Order in data is the neighbouring class, unpacked in the article on MDM and data management.

Subclasses: what the loop consists of

BI platforms — reports and dashboards. The shop window: visualisation, regular reporting, self-service — an employee assembles the view they need without filing a request with an analyst.

Effect: the executive sees the business today rather than in last month's report; manual spreadsheet reconciliation goes away.

Drawback: BI over chaos visualises chaos — a beautiful dashboard on dirty data only makes the error more persuasive. And self-service without rules breeds hundreds of personal dashboards with contradictory numbers.

Data warehouses and data lakes. The storage under the shop window: data from all systems in one place, with history, without loading the operating systems. A classic warehouse holds structured data for reporting; a lake holds raw data for future tasks; a lakehouse combines the two.

Effect: history is not lost when systems change, and heavy queries do not knock over the working ERP.

Drawback: the most capital-intensive layer; a lake without an owner and a data model turns into a swamp in a couple of years, and nobody can get anything out of it.

The data preparation layer (ETL/ELT). Invisible but mandatory: pull the data from the sources, clean it, bring it to a single model.

Effect: the reconciliations and joins analysts used to do by hand run automatically and identically every day.

Drawback: fragility — any change in a source system breaks the pipeline; supporting this layer is a permanent cost line forgotten at budgeting time.

Decision support systems. The youngest subclass here and the fastest growing since generative AI arrived. It is also the top step of both implementation trajectories: on generative AI, decision support is assembled over a finished data layer. The shift is from "what is happening" to "what to do about it": scenarios, recommendations, answers against the corporate knowledge base.

Effect: a decision is prepared in minutes rather than days; the company's knowledge stops living only in people's heads.

Drawback: the quality of a recommendation equals the quality of the data and documents underneath it — and a recommendation is harder to verify than a number in a report.

Who needs the loop, who is too early — and what to implement it after

You need it wherever there are three or more systems and reconciliation between them is manual. Symptoms that it is time: a regular report takes days to assemble in a spreadsheet; units disagree on the numbers for the same thing; decisions are made on gut feel because getting data takes too long.

Too early, or not needed: on one or two systems the built-in reports are enough; a full warehouse will not pay back at that scale. Decision support without a data layer underneath is a top floor with no staircase.

What it connects to and when to implement it. The loop goes in after the first stable data source and grows with the landscape. Connecting a system nobody has put in order to analytics multiplies chaos by attractive visualisation. In the pyramid this is the level above the systems of record: input from every system, output to the executive and into the EPM budget loop. It stands on a single data model and shared master data: without them, three "J. Smiths" from three systems never merge into one customer.

What the loop gives the business — and its typical drawbacks

Effect. One version of the truth instead of meetings about whose number is right. Speed: a question to the data takes minutes, and decisions stop waiting for the reporting day. And findings: bottlenecks and margin leaks invisible while data is spread across six systems.

Drawbacks that get discussed less. The loop depends entirely on data quality in the sources — and shows it honestly, which not everyone enjoys. Cost of ownership: the warehouse, the preparation layer and its support are permanent costs, not a one-off project. And the cultural shift: if executives keep deciding on gut feel, the loop is an expensive wrapper for old habits — data becomes an asset only when decisions rest on it.

What is actually driving BI decisions

The practical question has moved. It is no longer "which tool draws the nicest chart" — mainstream platforms cover the basic scenarios and now compete on AI features and the semantic layer. Two shifts matter. The centre of gravity moved down the stack: the platform choice matters less than whether there is a governed data layer and an agreed definition of each metric underneath. And cloud warehouse economics changed the failure mode: consumption runs up easily on unmanaged queries, so cost ownership goes to a named person on day one. What remains is which tool takes root with your users.

A sense of scale. Cost drivers: sources connected, how clean each is, the ratio of viewers to authors, and whether you build a warehouse or report straight off the sources. A pilot on one source takes a couple of months; a mid-size implementation up to six months of services plus annual licences; a large one up to a year. A full warehouse is a separate project of the same order, and its support costs a noticeable share of the implementation every year. Cost it after a survey of your sources, not from a price list.

Projects and portfolio: from task tracker to PPM

There are usually more projects in a company than the executive thinks: to the three official ones add a dozen initiatives nobody calls projects but which eat the same people. While there are few, everything holds on memory and meetings. Then the familiar pattern starts: deadlines drift, people are busy in four places at once, and a project's status depends on whom you ask. Here is the class that treats this — and why on its own it treats nothing.

What the class does — and what it does not

PM systems hold the work of projects: tasks, deadlines, dependencies, owners, statuses. PPM adds the portfolio level: which projects we run at all, how they compete for people and money, what moves when we are overloaded.

What it does not do: it does not create project management. That is its defining characteristic — unlike systems of record, almost everything here depends on discipline, not configuration. The system will show a missed deadline; it will not make planning realistic or make the team update statuses honestly.

Subclasses: what the class consists of

Task trackers and team boards. Tasks, sprints, kanban, comments, files.

Effect: the team's work is visible as a whole, and agreements do not get lost in correspondence.

Drawback: a board shows tasks, not a project: without dates, dependencies and owners of outcomes it is a to-do list, not management.

Classic project planning. Schedules, dependencies, milestones, critical path, baseline.

Effect: it is visible which delay eats the deadline and which does not, and what moving a milestone costs.

Drawback: it requires planning skill; a beautiful schedule nobody maintains goes stale in two weeks.

PPM — portfolio management. A register of projects, priorities, resources, decision gates.

Effect: it becomes visible that twenty initiatives compete for the same five people — and there is a basis for an honest "no".

Drawback: needed where projects genuinely compete for resources; on three projects it is an extra layer.

PSA — project economics in services. Time recording, rates, project profitability, billing.

Effect: it is visible which projects and clients earn money and which eat the margin.

Drawback: it rests on time recording, which employees dislike; without explaining the "why", the numbers are invented.

Resource planning. People's workload, competencies, assignment conflicts.

Effect: overload is visible before someone burns out and derails three projects at once.

Drawback: accuracy depends on the honesty of workload data — which is discipline again, not software.

Who needs the class, who is too early — and what to implement it after

You need it from roughly five parallel projects; PPM from the point where projects compete for the same people. Symptoms that it is time: status depends on whom you asked; deadlines shift down a chain and nobody sees the link; people are assigned to several projects at once and nobody checked whether that adds up in hours.

Too early, or not needed: one or two projects are fine with a shared file and a weekly meeting; PSA is only needed where projects are sold to clients.

What it connects to and when to implement it. An early class: it does not require a mature landscape — project discipline is established independently of what else is implemented around it. Upward, the portfolio feeds EPM (projects are part of the budget) and analytics.

Why the system does not create project management

Worth stopping on, because it is the main cause of failure in this class. Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation" states a regularity that applies to any implementation, but for PM systems reads almost literally: four elements work in a specific order — strategy, people, processes and only then technology. The order is not decorative: technology amplifies what is already built and is powerless where nothing is.

In practice: if projects have no sponsor with authority, if deadlines are assigned from above without a conversation about scope, if status stays green right up to the failure — a tracker will not help. It makes those problems visible, which is useful, but curing them is a management job. First the agreements on how we run projects, then the tool that supports them.

The same order works at the personal level. Management agreements start with the executive holding their own goals, decisions and commitments rather than recalling them at the status meeting. The honest boundary: that is one person's private loop — it replaces neither a tracker nor a PPM system and does not run the team's projects.

What the class gives the business — and its typical drawbacks

Effect. Transparency: one status instead of three. Control of overload: people assigned beyond capacity are visible before the failure, not after. And a basis for refusal: the portfolio shows the price of every new "and let's also do this".

Drawbacks that get discussed less. It requires constant data maintenance — daily work by participants, not a one-off configuration. It slides easily into control for its own sake: the more mandatory fields, the less honest the data. And the commonest trap: the system gets implemented instead of the management agreements, then blamed for "not working".

What is actually driving project and portfolio decisions

Two trends matter. The classes are converging: trackers have grown portfolio and resource features, enterprise PPM products have acquired lightweight boards, and the old "team tool versus corporate tool" split no longer maps onto vendors. And everyone covers the basic scenarios, which moves the question to what your teams will adopt — a tool people avoid is worth nothing at any price.

A sense of scale. Cloud trackers are priced per user per month, several have free tiers for small teams, and the launch takes a week. Portfolio management and project economics are a different class and budget: enterprise licences plus implementation, with cost driven by users, integrations with finance and HR, and how much of your gating and resource model has to be configured rather than used as delivered. In both cases the decisive factor is not the licence but keeping the data current: an unmaintained tracker is worth nothing on any plan.

How these four classes connect

The four classes form a vertical: fact → plan → interpretation → action. The mistake is almost always an attempt to build the vertical from the top.

The order of moves. ERP is the foundation: it holds the fact from which everything else is computed. The budget loop goes in once the fact is consolidated and a planning methodology exists; otherwise consolidation exposes divergences in the group's master data and you fix them by hand mid-project. The analytics loop is deployed once there are more than two systems and the numbers stop agreeing. Project management lives outside this vertical but feeds on it: without cost and resource accounting the portfolio is computed on feelings.

A shared prerequisite — master data and definitions. All four classes share one precondition layer: common master data and a common metric dictionary. That is the territory of data and documents, and it gets closed before the project rather than during it. Until "revenue", "margin" and "customer" mean the same thing to everyone, every system in this group will compute correctly — and differently.

A shared prerequisite — facts from the operational loops. ERP does not create data, it receives it. Orders come from the customer loop, production facts and warehouse movements from the production and logistics loop. This is the central condition: an ERP placed on an unworked operational layer feeds on manual entry. The data then cannot be trusted, and headcount grows with the people typing it in.

Where the upper boundary runs. The top of this vertical is not a dashboard, it is a decision. In both implementation trajectories described in the hub article the top is held by decision support systems for management built on generative AI. They are assembled over the analytics loop and unpacked in the article on routine automation and AI. But that is the top floor: without consolidated facts and shared definitions it is built on sand.

What a broken order looks like. A company buys a budgeting system before consolidating its accounting. It puts in BI before the sources are in order — and the loop honestly shows everyone that they are not. It buys an enterprise portfolio system for five projects and gets a heavy process on a light task, plus guaranteed sabotage. In all three cases the technology works and trust in the numbers never appears.

The role of AI in the management loop

This is where AI has its clearest job: it takes the preparation of numbers off people and leaves them the decision. It is also where the check that tells you what you bought is skipped most often.

What AI already solves. In accounting, three scenarios. Demand and inventory forecasting: the most mature application of AI anywhere. Automatic classification of item master data: months of manual cleaning saved during a migration, and many will migrate as their platform reaches end of maintenance. And a reporting assistant answering "show me procurement variances for the quarter" instead of a report builder. In budgeting: forecasting line items from history, anomaly detection in plan versus actual, draft commentary for the reporting pack. In analytics: natural-language queries, automatic explanation of anomalies — the system says what drove the number down — and answers on company policy with a link to the source. In projects: draft plans and decomposition, a status summary assembled from correspondence, early warning on risk — the model notices projects where activity dropped while the deadline is close.

What is coming (a forecast, not a fact). Agents running standard procurement-cycle operations from requisition to posting under human control. A CFO's assistant preparing the analysis for the budget committee. Analyst agents assembling material for a meeting from its agenda. A PMO head's assistant proposing resource reallocations.

Conditions without which it will not fly. Data: two to three years of clean transaction history, cleaned master data, consistent cost lines and dimensions across the group. A forecast on dirty data lies without blushing, and a model trained on incomparable series honestly returns an incomparable result. Processes: an established planning loop and a documented methodology — AI speeds up the calculation, it does not replace the decision about how to calculate. And, most important here: shared metric definitions before any AI. If departments compute "revenue" differently, the assistant silently picks one and will not tell you there were two. People and security: a group's financials are a sensitive loop; the model's permissions are never wider than those of the employee it assists, and it must not tell a person what they are not entitled to see.

The check that gets skipped most often. The typical failure here is procedural, not technical. A forecasting pilot looks convincing in the demo, it is rolled out across the group at once, and only then does it emerge that nobody compared it against the previous way of planning. In Dzhimsher Chelidze's "Artificial Intelligence. A Practical Guide to Implementation" this is the validation stage of the project lifecycle: after the pilot, comparison against a baseline and a Go/No-Go decision point. Skipping it is the most expensive time saving in AI projects, because the error is then found at scale.

Hence a practical requirement: the baseline is fixed before the pilot. How long budget collection takes today. What the current forecast error is. How much time goes into preparing the committee analysis. Without those numbers the argument about effect becomes an argument about feelings, and the loudest voice wins.

The honest boundary. AI does not fix data and does not replace methodology. It answers the question asked, not the one that should have been asked — framing stays with the human. The CFO is accountable for the budget, not the model. Three failure modes worth recognising on sight. Demand forecasting on unreconciled balances across three warehouses: the model is blamed for errors that live in the master data. An assistant over contradictory policies: given two conflicting documents it produces a smooth but wrong answer. A planning assistant over formally filled-in statuses: it honestly summarises fiction and gives it the look of analysis.

Vendors you will actually meet

The names below show up on most shortlists in these four classes. No ranking, no market shares, no claims about who leads.

The system of record (ERP) — the eight names above: SAP S/4HANA · Oracle Fusion Cloud ERP and NetSuite · Microsoft Dynamics 365 Finance & Operations · Infor CloudSuite · IFS · Epicor · Sage · Odoo. The profile each fits is in the ERP section; at the shortlist stage what matters is module maturity against your processes, not the badge.

Planning, analytics, projects

• EPM and CPM — Anaplan · OneStream · Oracle EPM · SAP Analytics Cloud · Workday Adaptive Planning · Board · Pigment

• BI — Power BI · Tableau · Qlik · Looker · ThoughtSpot

• Data layer under BI — Snowflake · Databricks · BigQuery · dbt

• Trackers and boards — Jira · Asana · monday.com · Smartsheet · Wrike

• PPM and enterprise project management — Planview · Clarity · Microsoft Project for the Web · Smartsheet · Wrike

Two notes on the table. Several products appear in more than one row on purpose — the boundary between a tracker and a portfolio tool has genuinely blurred, and where a product lands depends on the edition you buy, not the brand. And for the data layer there is no honest short list at all: the composition depends on your infrastructure, your volumes and where your data is allowed to live.

How to read these tables. Not rankings — lists of candidates admitted to comparison. The procedure is the same every time: three systems for your profile on the shortlist, reference visits in your industry and at your scale, a pilot on one loop, then a decision. The deciding factor differs by class. In ERP it is module maturity against your processes. In budgeting, the complexity of your model: the more legal entities and non-standard consolidation rules, the more platform flexibility matters and the less its library of prebuilt forms does. In projects, the level of the task: an enterprise system gets in a small team's way, and a lightweight tracker will not hold fifty initiatives.

Typical mistakes and a selection checklist

The mistakes repeat from class to class, so here they are in one list.

1. Implementing into broken processes. The system will not create order — it will cast the disorder in concrete. Processes first, automation second.

2. Automating a process without changing it. The same budget, faster, is optimisation. If you expected transformation, disappointment is guaranteed: different levels of effect, different money.

3. Choosing by name rather than by modules. "They have an ERP too" is not an argument: compare the maturity of specific modules against your tasks.

4. Dragging ERP onto the shop floor. Operational production belongs to the production loop; covering it with an ERP module ends with spreadsheets on the supervisors' desks.

5. Underestimating data migration. Moving master data and balances is often a third and sometimes half the budget, and the plan allows a week for it.

6. Implementing before the group's master data is in order. Consolidation exposes the divergences, and you fix them by hand mid-project.

7. Implementing analytics without a metric dictionary. Until "revenue", "margin" and "customer" are defined consistently, every dashboard has its own truth.

8. Measuring success by the number of dashboards. A hundred reports nobody looks at are decoration. Success is measured in decisions made on data.

9. Building a data lake without an owner. Dumping "everything for the future" in there is the easy part; getting anything out is impossible.

10. Building scenarios on unverified assumptions. The tool lends confidence to numbers that have not earned it.

11. Implementing a system instead of agreements. In projects it is "how we run them" first, "in what" second.

12. Buying an enterprise system for five projects. A heavy process on a light task guarantees sabotage. And the reverse: a lightweight tracker will not hold a portfolio.

13. Making dozens of fields mandatory. The stricter the form, the less honestly it is filled in.

14. Counting workload only on official projects. Half of people's work is off the list, and overload happens exactly there.

15. Using data as grounds for punishment. One such episode and statuses are green forever.

16. Skipping pilot validation. Without comparison against a baseline it is unclear what you have actually bought.

17. Deferring a migration to the last moment. Everyone on the same platform reaches end of maintenance in the same window, and the supply of experienced teams does not expand to meet them — dearer and slower for everyone who waited.

Checklist before choosing a system

1. A list of critical modules, processes and executive questions is compiled — before talking to vendors, not out of their presentations.

2. A dictionary of key metrics with formulas is agreed: the units have accepted the same definitions. A precondition for all four classes at once.

3. The methodology is documented: consolidation rules, planning sequence, agreements on running projects — who the sponsor is, who accepts the result, how scope changes.

4. An audit of sources and master data is done. Their quality shapes the project more than the platform choice — I would start there.

5. A baseline is fixed before the pilot: budget collection time, current forecast error, share of projects with a current status, time spent preparing reporting. Otherwise there is nothing to prove the effect with.

6. A shortlist of three systems for your profile, each with a reference in your industry and at your scale. Not a presentation — a working implementation.

7. The pilot runs on one loop or one budget cycle with a measurable criterion — and with a Go/No-Go point appointed in advance.

8. The data migration and master data cleaning plan is a separate budget line. So are the data preparation layer and ongoing support.

9. Total cost over five years is calculated: licences, implementation, support, people. Not the contract price.

10. Owners are assigned by name: for the data, for each dashboard, for each AI scenario. Otherwise in a year nobody can say which numbers to trust.

11. There is an agreement on how data will be used: for managing, not for post-mortems with consequences. I would say it out loud before go-live — after the first punishment based on data, honesty in the system never comes back.

What's next

The overall map of the classes is in Types of enterprise IT systems. Other instalments: Production, assets and warehouse · Customers and sales · Data and documents · Routine automation and AI · People and the IT function · IT infrastructure.

To go deeper, see Dzhimsher Chelidze's books "Digital Transformation for Directors and Owners" and "Artificial Intelligence. A Practical Guide to Implementation", and "Artificial Intelligence. Freefall" — available to download free.

If you still have questions, you can come to us for training or consulting.