The Atlas and process management

Anyone who has spent years inside a company carries its map — in their head. They know where an order comes from, who signs it off, where it usually stalls, and whom to call when it does. That map is real and valuable, often more accurate than any diagram on a wall. It has one flaw: it lives in a single head.

A map in a head fails three quiet ways. It is private — it leaves with the person carrying it, and a replacement spends a year relearning it. It ages — it is updated by memory rather than by events, so even someone who knows the company well describes how it was, not how it is. And it cannot be queried: to the question “where is work stuck this morning” no mental map has an answer, because it remembers rather than counts.

This piece is about the gap between that map and one that lives in the system — and why the gap does not close with a nicer diagram. It closes when you stop looking at the company as a list of departments and start seeing it as a set of value chains: lead-to-cash, procure-to-pay, record-to-report. A department is where people sit; a chain is the path value actually travels.

A diagram describes intent; the system carries state

The usual answer to a private map is to draw it: a process diagram, boxes and arrows. Such a diagram is accurate the day it is made and wrong the next, because it describes intent — how work ought to flow — while the company carries state: where work actually is, right now. Intent and state diverge the moment reality stops behaving like the diagram, which is most of the time. Companies already know this from their own process documentation: a procedure in a quality manual is as accurate as the day it was signed off — it describes the agreed flow, not the one happening this morning, which is why nobody opens it when a decision is due. But the deeper flaw is not the drawing's accuracy. Even a perfectly correct diagram answers only how an invoice usually moves; it cannot be asked which invoices are stuck, where, and since when. A map you cannot question is a teaching aid, not an operating view.

A company is a set of value chains, not a list of departments

Departments are how you organise people and responsibility — they run vertically. Value moves horizontally, across departments. An order does not respect the org chart: it passes through sales, the warehouse and finance, and none of them sees the whole of it. The value chain is that horizontal path, and it is the unit on which a company genuinely earns and spends. Four chains carry most of that flow:

• Revenue — Lead-to-Cash: opportunity → quote → order → delivery → invoice → collection. It crosses sales, the warehouse and finance.
• Supply — Procure-to-Pay: need → approval → purchase order → receipt → invoice → payment. The invoice arrives over SEF, not by e-mail.
• Operations — Plan-to-Fulfill: plan → materials → production → quality → stock → delivery. The bill of materials explodes into requirements; the floor returns actuals.
• Finance — Record-to-Report: document → posting → controls → close → reporting. POPDV and the PP PDV return come out of the same journal.

The point of a chain is not its name but its ownership: a chain is nobody's job. Each department holds its own box and optimises it — sales pushes quotes, the warehouse speeds up shipping, finance closes the period. The handoff between two boxes is held by no one. That is where time leaks: not in a step, but in the gap between two. When a customer asks where their order is, the salesperson knows their own stretch — the quote went out, the order is open — but not that the delivery note is waiting in the warehouse because the material has not arrived from the supplier; every stretch of the path has an owner, and the whole path has none. A company that measures departments and not chains is blind exactly where it loses.

Bottlenecks live at the handoff, not in the step

A bottleneck is not a slow step. It is a place where work piles up faster than it drains — and piles form at handoffs: in the queue between “quote sent” and “order received”, between “invoice arrived” and “invoice posted”. The step itself may be fast while the handoff in front of it is blocked; the speed of the step does not help there.

The signal of a bottleneck is a queue, not an average

A total hides the location. “Average collection 37 days” is a correct number and useless for action: it does not say whether those 37 days accumulate in the quote→order gap, the delivery→invoice gap, or the invoice→collection gap. The queue does. Where documents sit and wait, and for how long, is the signal — and it exists only if the map carries state per node rather than an average per period. Every document carries a timestamp — an invoice arrives over SEF with one, a payment carries its value date on the statement — so the queue is not a guess but a computable fact: how many items are older than two days, which is the oldest, and in which gap it sits. An average flattens all of that into one figure that points nobody anywhere.

Where automation takes over

Automation is not evenly spread along a chain. It gathers where the input is structured and the rule is deterministic, and in the Serbian context those points are concrete and nameable: the supplier invoice arriving over SEF instead of by e-mail; the three-way match of purchase order, receipt and invoice; statement matching by the model 97 reference; depreciation of fixed assets; issuing goods in FEFO expiry order; filling the POPDV ledger from the document that fed it. Between them sit the manual handoffs — an approval, a disputed discount, a quote waiting on a human reply. Seeing which nodes are automated and which are manual is itself a management view: the next automation goes to the manual handoff in front of the largest queue, not to whatever is easiest to build. That reverses the usual order of investment — you do not start from what a team can ship quickly, but from the handoff holding the longest queue, harder to build though it is, because that is where the saving is largest.

Crossings: one bottleneck, three chains

The chains are not independent parallel tracks — they share nodes. Stock belongs to three: the receipt from procurement, finished goods from production, and delivery to the customer. The invoice belongs to three: sales, procurement and posting. A shared node is where a single bottleneck multiplies. If stock availability is wrong, it hits the customer reservation, the production plan and the purchase proposal at once — three chains, one cause. The same holds for the invoice: the outgoing one from sales and the incoming one from procurement are different documents, yet they enter the same journal and the same POPDV ledger, so an error at that node shows up on both the PP PDV return and the partner balance. A departmental view sees three separate problems in three meetings; a view through the chains sees one node.

The Atlas is a view, not another report

The objection to all this is that the company already has reports and dashboards. It does — and a dashboard is a set of answers to questions someone knew in advance to ask. Twelve tiles are twelve metrics chosen up front. A view through the flow answers a different kind of question: not “how much” over a period, but “where, right now”. It surfaces the queue nobody thought to put on a tile. A month-end receivables report says how much is uncollected; the flow shows that half of that balance sits on two invoices from the same customer, stuck on a disputed discount — the same number, but with a place and a cause. A report is a snapshot looking backward; the flow is a live cross-section. That is why the Atlas is not another report — it is the thing a report is a summary of.

1. 1

   Start from the chain, not the module

   The question is not “what is in sales”, but “where did the opportunity stall on its way to cash”. A module is a place; a chain is a path.

2. 2

   Look at handoffs, not steps

   A slow step is fixed with training or people. A blocked handoff is fixed only once it is seen — and it is seen only on a map that joins two steps into one flow.

3. 3

   Find the queue

   A node where documents pile up and wait is a bottleneck, however fast the step itself. The queue is the signal; the average hides it.

4. 4

   Ask whether the handoff before the queue is automated

   If it is, the cause of the queue is in the rule and is fixed in the rule. If it is not, that is where the next automation goes — in front of the queue, not anywhere.

5. 5

   Check whether the node is shared

   A bottleneck on a shared node — stock, invoice — is not one problem but three, and it is fixed once. A shared node deserves attention before the rest.

How NG One approaches it

The NG One Atlas draws the company as four parallel value chains, crossing at shared nodes — stock and invoice — rather than as a radial spider around a logo or a single linear chain, because a company is not linear. Every node carries state: how many documents are active, what waits, what is late, how much was handled automatically. That state is not a figure typed beside an icon but the result of a query over the tenant's real documents, under the permissions of the person looking — so a node with nothing to count has no place on the map. Automated nodes are marked, so one screen shows both where value moves and where automation has taken over. Which perspective the Atlas opens by default depends on the role — Lead-to-Cash for a salesperson, Record-to-Report for finance — because the same flow does not mean the same thing to everyone, and a map that shows everyone everything shows no one their own work. The live-state examples the Atlas shows — “12 quotes awaiting a reply”, “2 lots in quarantine”, “83% of the bank statement matched” — come from a demo tenant.

The goal is not a nicer diagram. It is a map that carries state, that can be questioned, and that shows the handoff no one holds. A company that can see where its work is stuck knows what to fix next and what it is worth. A company with a diagram in a drawer knows how things were meant to run — and notices the difference only once the bottleneck has already cost something.