Services+
EN DEContact
Advisory is where those decisions get made in the same conversation, strategy included. Platform strategy, AI strategy, and how the commercial, service and delivery organizations need to be set up to work differently: that is the same conversation, not a separate one.
Most organizations do not make bad decisions about change. They make five reasonable decisions in five separate rooms.
What the outcome should be, who owns it, how the work should run, which systems should hold what, and what the rules require. Each one is defensible alone. Together they often do not fit, and the misfit is discovered during the build, by the people who cannot fix it.
Find the sentence that sounds like your situation. Each one leads to the work that settles it, and none of them requires you to have done anything with us first.
“The strategy still has to be set, or it is agreed and the organization is not changing. Workstreams are running and nobody can say whether they still add up to the outcome”
What the strategy is, and who keeps the change coherent.
“A new system is about to change how a team works and nobody has decided how the organization should be set up for it. Or it is already live, nobody owns it, and decisions either do not get made or get remade next month”
How the organization is set up to own, decide and improve.
“The work breaks between teams and systems: everybody follows their own step correctly and the outcome is still wrong. Or AI and newer systems could now do this differently and the current design cannot take advantage of it”
How the work should run, and where AI changes it.
“Two systems both claim the same record, two others have to integrate, and every project starts by re-arguing the same boundaries and the same data foundations”
Which system holds what, how they connect, and why.
“AI is already in use across the business and nobody has written down where, or what the rules require of you”
What obligations may apply, and what has to change.
Two or three of those usually sound familiar at once. Tell us which two and we will tell you which one to do first.
That is normal, and it is the reason this branch exists as a branch rather than five unrelated services.
Each of these has its own page with the method, the deliverables and the boundaries. Here is what they are for.
Transformation Partner
Explore Transformation Partner →Somebody accountable for keeping the outcome, the operating design, the architecture, the delivery and the adoption pointing the same way while the change is underway. Not a project management office tracking the plan. The role that engages with the trade-offs and says when a workstream decision has quietly broken the outcome. It also starts earlier than most people expect. Where the platform strategy or the AI strategy is still open, this is the work that sets it, so the outcome everything else points at is one the business has actually chosen.
Operating Model Design
Explore Operating Model Design →How the organization is set up to run what it has: who owns it, who decides what, at what threshold, on what evidence, and what happens next. This is not only about a platform. It is the revenue organization, customer service operations and the delivery organization, and how each is structured before a system changes the way they work as well as after. It is the capability the organization keeps after the program ends, including whether a Center of Excellence is justified at all, which for most mid-market organizations it is not.
Business Process Consulting and Design
Explore Business Process Consulting and Design →How the work should run, redesigned rather than documented, to the point where a delivery team can build from it. Ownership per process, decision points, exceptions, data authority and the seams where handovers currently fail. AI and modern automation change what a good design looks like: steps that existed because a person had to read something, approvals that existed because nobody trusted the data, handovers that existed because two systems never spoke. We redesign for what is possible now, not for what was possible when the process was written.
What the application and information landscape should be, which system is authoritative for each business object, where the boundaries fall and what gets decommissioned. It covers how two systems integrate, how a business process is reflected in the systems that carry it, and the data foundations everything else depends on. These are the decisions that every future process inherits whether or not anyone wrote them down.
What AI your organization is actually running, which roles and obligations may apply to it, what evidence you would need, and what has to change. Readiness and governance design, not legal advice.
We have never met an organization whose transformation failed because one decision was stupid. What we see instead is five sensible decisions that do not reconcile.
The target operating model assumes a process that has not been designed.
Five rooms. No one decided.
The process design assumes a system boundary that architecture has not agreed.
The architecture assumes an owner the operating model has not appointed.
The AI use case assumes data authority nobody has established.
Each decision was made properly by competent people who were not in the room for the other four.
Then the build starts, and the misfits arrive as questions a configuration team cannot answer.
Who signs this off. Which system is right when they disagree. Is this exception the rule now. And the honest answer, most of the time, is that nobody decided, so somebody junior is about to.
Which is why this branch is organized the way it is. Not because organizations need five kinds of consulting, but because these five decisions constrain each other and are almost always made apart. Advisory is where they get reconciled while changing them is still cheap.
AI and modern platforms do not only make existing work faster. They change which work should exist at all, which turns a tooling question into a design question. If a decision can now be made from data the moment it arrives, then the process around it, the person who owns it and the system that holds it all need to be different. Designing for the old shape and adding AI on top is how organizations end up automating work they should have removed.
The instinct is to start with the biggest decision. Usually the right first move is the one everything else is waiting on, and it is often smaller and less interesting than the one you came in asking about.
These five overlap, and pretending otherwise would make the branch harder to buy. Here is exactly where each stops.
Keeps the change coherent while it runs.
Designs the ownership the organization keeps afterwards.
One is program-level and temporary. The other is organizational and permanent.
Decides how work should flow and which systems support it.
Decides who owns, governs and improves it.
Both use the phrase process owner. Process work means the owner of one process. Operating model work means the pattern that makes ownership durable across all of them.
Designs how one process should run.
Designs the landscape all of them run on.
And holds the decisions that apply across every process rather than inside one.
Decides what the landscape should be and why.
Decides who owns those decisions and how they get changed.
Architecture makes the call. The operating model makes the organization capable of making the next one.
It sits in Managed Services rather than here. Readiness designs the target state and the transition. Governance as a Service operates the recurring reviews, inventory and evidence.
Advisory decides what your organization should become. Discovery decides which use cases to work on, and in what order.
If you need a design decision about a future state, that is Advisory. If you have candidate use cases and competing investments and need to know which comes first, which comes next and which is not worth doing this year, that is Discovery. Discovery uses Advisory's output. It does not replace the design work.
Two of the five sound familiar?
Tell us which two, and we will tell you which one to do first.
Advisory engagements are scoped under their own agreement, with their own deliverables and their own acceptance. That is a commercial choice with a practical consequence: it makes it possible for the recommendation to be that the answer is smaller than you expected, that the capability you were about to buy already exists somewhere in your estate, or that a data problem has to be fixed before anything else is worth doing.
On design work we record the recommended system of record and the integration boundary for each material capability, with the reasoning, including where an existing system or another supplier's product is the better answer. Not every capability belongs on the platform we implement, and a design document that never says so is not a design document.
The people in the design conversation are the senior practitioners who would be there at go-live, because a design nobody has to live with tends to be more elegant than it is achievable.
A business owner who holds one of the numbers it affects.
Not because IT sponsorship is unwelcome, but because these five decisions cross sales, service, delivery, finance and technology, and a decision that only the technology function has agreed to is not yet a decision.
Every Advisory engagement produces artifacts your organization keeps and can act on without us.
What was decided, what the alternatives were, and why this one. So that when somebody proposes an exception in eighteen months, the conversation starts from the reasoning rather than from scratch.
Which role owns which decision, process, object or system, at which threshold, on what evidence. Roles rather than individuals, so it survives people leaving.
What belongs where, and specifically what stays outside the platform. The most useful line in an architecture document is often the one that says no.
What is still unresolved, who needs to resolve it and what it blocks. An advisory deliverable that presents itself as complete is usually hiding the interesting part.
Name the decision your organization cannot currently make, or the one that keeps getting remade. We will tell you which of the five settles it, what it depends on, and whether it should be first.
Advisory decides what should change and why. Implementation makes the change exist. The distinction matters commercially, because a partner whose revenue depends entirely on building has one honest answer available to almost every question, and that answer is build. When advice is scoped and paid for separately, the recommendation can legitimately be to do less, to reuse something you already own, to fix a data problem first, or to wait. Both types of work are necessary. Buying them as one decision is where the trouble usually starts.
Not always, and the test is specific. If the scope is clear, the process is agreed, ownership is named and the system boundaries are settled, go and build it. Advisory earns its cost when at least one of those four is missing, because each of them becomes a build assumption if nobody decides it deliberately. A useful signal: if two departments would answer the same scoping question differently, the decision has not been made yet and a configuration team is about to make it for you.
We can set it. A platform strategy or an AI strategy is a design decision like any other: what the organization should be able to do, in what order, on what foundation, and what that rules out. We establish where you are, agree what should be true in two or three years, and record the reasoning and the ownership. Where a strategy already exists and is agreed, we do not reopen it. Instead we test whether the current workstreams still add up to it, which is a different and usually shorter piece of work.
No. The subject is usually an organization: how the commercial organization is set up to sell, quote and order, how customer service operations are structured to answer, how the delivery organization is built to deliver and to see its own margin. Systems come into it because they carry the work and hold the records. A design that ignores them does not survive contact with a build, and a system design that assumes an organization nobody has set up is a plan to find the gap at go-live.
A target operating model describes how an organization intends to work: who owns which outcomes, who decides what, at what threshold, on what evidence, and how work reaches the people who do it. An organizational chart shows reporting lines, which is a much smaller claim. The practical difference is that a chart tells you who somebody's manager is, while an operating model tells you who can approve a change to a shared process without escalating. Most governance frustration is caused by having the first and not the second.
Process design takes the work as its subject and reaches into systems only as far as that process requires: which system owns which record, where the boundaries fall, what has to integrate. Enterprise architecture takes the landscape as its subject and makes decisions that apply across every process, present and future: capability allocation, authoritative systems per object, identity, integration patterns, what gets retired. One decides how a thing should flow. The other decides what should exist for things to flow through.
Somebody in the business who holds a number the platform affects, supported by a named platform owner with real decision authority rather than a queue of requests. The common failure is treating the administrator as the owner: they can execute changes and they cannot arbitrate between two departments that both want incompatible ones. Whether that becomes a formal Center of Excellence depends on scale. Where the platform serves one function and one team builds, a named owner with a decision list and one standing review does the same job with far less overhead.
When the step is genuinely necessary, the rules are clear and stable, the inputs are consistent, and the volume justifies the build. It is the wrong answer when the step should be removed entirely, when decision rights are unclear, when exceptions have become the main path, or when human judgment is the value being delivered. One trap is worth naming: manual work that exists to compensate for a broken upstream system should be fixed at the source, not automated in place.
Possibly, and the distinction that matters is the role you hold rather than whether you built anything. Obligations differ for organizations that develop AI systems and organizations that deploy them, and using AI features embedded in purchased software can still place you in the second category. What determines your position is the specific use case, its context and who is responsible for what. That is an assessment of your actual AI use, and where a formal legal determination is needed, that is a question for counsel and we will say so rather than guess.
Yes, and it is a common starting point. What we would establish first is what is actually configured, how far it deviates from standard behavior, whether it can still take vendor releases, and what your existing agreements already entitle you to. Those four answers regularly change the plan, and they are worth having before anyone designs the next thing on top of it.
At a decision your organization can act on, with the reasoning recorded and ownership named. What happens next depends on what the decision was: build it, sequence it against other investments through Discovery, or in a reasonable number of cases do nothing yet and revisit when a condition changes. We hand over artifacts you keep, and being able to execute the design without us is the point rather than a concession.