ServicesTech stack review
Do we need new technology, or more from what we have?
Usually more from what you have. Most of what a cross-functional operating model needs is already licensed and partly configured — it is defined inconsistently across platforms rather than missing. A review establishes what each system should be authoritative for, which makes the case for buying, or for not buying.
What it looks like
- The same fact is maintained in three systems, each by a different team
- A new tool is proposed for a problem another system already covers
- Reporting is rebuilt for each audience because no layer is trusted
- Nobody can say which system is authoritative when two disagree
- Licences are renewed without anyone establishing what they are used for
- Every function can justify its own stack, and the total cannot be justified
Why it happens
Each system was chosen to solve one function’s problem
Implementations are scoped, funded and governed inside a department, and each is usually done well. The processes that cross functions run through systems that were designed separately.
No layer is authoritative, so every layer is rebuilt
When no system is named as the source for a definition, each one keeps its own version. The cost appears downstream as reconciliation, and as a number no executive can defend without checking it first.
A cut that moves work still books as a saving
Rationalizing a tool without redesigning the work relocates the work rather than removing it, and it reappears later as overtime, error rates or a rehire.
How we approach it
We start with one workflow: a process that crosses three or more functions, mapped end to end with the people who own its steps.
- Start from the questions the business needs answered, not from the systems or the measures.
- Inventory the decisions, not the datasets, and name what each system should be authoritative for.
- Convert the forecasts and reports each function maintains into one another, and record what breaks.
- Price each candidate change in work before pricing it in dollars.
- Trace one employment event end to end to see which systems re-enter the same facts.
What you get
- A written statement of what each system is authoritative for, and what the others inherit
- The list of definitions currently maintained in more than one place
- A view of which capability is genuinely missing, and which is already licensed
- Of last year’s ten largest booked savings, how many still show the cost line down today
- The number of systems into which one hire’s name, start date, manager and cost centre are typed by a person
Related perspectives
Paper 01
From Data Lake to Decision Layer
Why finance keeps rebuilding the number in Excel — and what it takes to stop
Paper 02
Where ERP Returns Are Actually Decided
The return is traded away in design meetings, long before anyone measures it
Paper 03
Building a CEO/CFO-Ready Reporting Infrastructure
Four functions, four correct answers, one question, nobody owning the seam
Paper 13
Removing Work, Not Moving It
Why a cut that moves work instead of removing it still books as a saving
Paper 15
Hire to Retire Runs on One Event
The hire happened once. Whether it is entered once is an architecture decision, not an HR one.
Paper 16
One Demand Signal, Four Currencies
Your four forecasts are not four opinions about one number. They are four different quantities
Questions we are asked
- How do we know if we’re getting value from our enterprise software?
- Ask what each system is authoritative for, and whether anything downstream inherits that definition rather than rebuilding it. Where a definition is maintained in three places, the licence is being paid for three times and reconciled by people.
- Should we buy new tools or optimize what we have?
- Establish what you already own first. Most of what a horizontal operating model needs is licensed and partly configured, and defined inconsistently rather than missing. A review makes the case either way on evidence rather than on assumption.
- Are you tied to any vendor?
- No. We have no platform to replace and no implementation practice to feed, so a review can conclude that the right answer is to buy something, or that it is not. We start with the platforms you already own and design how they work together.
- What does a review produce?
- A written statement of what each system should be authoritative for, the list of definitions currently maintained in more than one place, and a view of which capability is genuinely missing. It is a decision document, not an inventory.
Value. Realized.
Start with one workflow.
Choose one process that crosses three or more functions. We map it end to end with you, and mark every place the same problem gets solved twice.