Speak with the team
Talk to an advisor
Integration & Readiness
A platform decision is an integration decision. We map the boundaries between ERP, document management, HR and analytics before a shortlist is drawn — so the comparison stops being abstract.
Where to start
The first question is not what the platform can do. It is what crosses the boundary between the platform and everything already in place: which data, in which direction, at what frequency, with which owner.
System integration work is almost entirely about those boundaries, and most project overruns trace back to boundaries that were never specified. Map them before the shortlist, and the comparison becomes far less abstract.
The constraint
In most German enterprises the ERP is the system of record, and everything else has to reconcile with it. That makes ERP integration the constraint the rest of the architecture inherits, whether the ERP is SAP, Oracle NetSuite, or something older that still works.
Finance postings, master data, cost centres and approval hierarchies all have expectations about where the truth lives. A new platform that cannot describe how it meets those expectations in concrete terms is not ready to be selected.
Underestimated layers
Document management is the layer buyers underestimate most often. Contracts, invoices and supplier records need to be findable, versioned and tied to the process that produced them. If a procurement or HR platform generates documents the document management system cannot index, the gap gets closed manually and stays manual.
Check the document boundary early: it is cheap to design and expensive to retrofit.
DMS boundary
Does the platform emit documents your DMS can retrieve by document type, supplier and case number — or does an employee file each one by hand? The answer decides whether the archive stays a record or becomes a liability at audit.
Cheap to design, expensive to retrofit
Multi-entity
HR and finance data has to consolidate across legal entities while respecting local requirements. The German ones are specific: payroll, works council involvement, and reporting expectations. A cloud HCM platform such as Workday handles the consolidation well when the standard model fits.
Scope the configuration before the decision
Handoffs
Business process automation usually fails at handoffs, not inside steps. A procurement approval that leaves the procurement platform and enters the ERP, then returns for a contract signature, has three owners and two systems.
Workflow orchestration is the discipline of naming who owns each handoff and what happens when it stalls. Platforms provide the tooling. The ownership model is something the organisation has to decide, and it is worth deciding before go-live rather than during the first month-end.
Ask about workflow orchestrationThe procurement platform captures the request. Its owner is the procurement lead.
A purchase order posts against a cost centre. Its owner is finance operations, not the requesting team.
The contract re-enters the procurement platform as a document. Its owner is legal or the signatory delegate.
The signed record is indexed to the case. Its owner is the archive team.
What the logs show
Process mining is useful precisely because it does not ask people what they do. It reads system logs and shows the actual path a purchase requisition or an onboarding takes, including the loops and the workarounds.
Applied before a platform decision, it turns a vague sense that procurement is slow into a specific list of steps, systems and exception rates. That list is a far better input to selection than a requirements workshop alone.
A practical check
Five points that decide whether a candidate platform is ready to be selected. If a vendor cannot walk through these with your architects, that is itself a useful finding.
The finished state
A ready state is not a perfect state. It is a state where the boundaries are documented, the owners are named, and the failure behaviour of each interface is understood.
At that point a platform comparison becomes almost mechanical: which candidate meets the documented requirements with the least bespoke work. Organisations that reach this state tend to make faster decisions and revisit them less often.
Documented
The map lives in one file, not in a slide. A new joiner can read it in an afternoon and know who to ask.
Named
Each interface has a person who answers when it stalls at month end.
Understood
When an integration is unavailable, the transaction is retried, queued, or rejected — the choice is documented, tested once, and not discovered in production.
Why we run this first
Skipping readiness work does not remove the cost, it moves it. Integration scope discovered after contract signature becomes change requests, timeline slippage, and occasionally a platform that is technically live but operationally avoided by the teams it was bought for.
We have seen the pattern often enough to treat readiness as the first deliverable, not as a phase that comes after the interesting decisions.
Questions we hear
It is not mandatory, but it changes the quality of the input. Process mining replaces opinion about how work flows with the recorded path through your systems, including exceptions. That makes requirements more specific and vendor comparisons less speculative.
It depends on how many systems are in scope and how well the current interfaces are documented. The useful output is a boundary map, a master data ownership list, and a review of failure behaviour, not an exhaustive audit of every field.
Yes, and it is often the better route. Starting with the single decision in front of you, for example a procurement platform or a low-code tool, produces a usable answer faster and leaves the wider landscape for a later pass.
The next sensible step
Book an integration review with the München office and we will map the boundaries, name the owners, and hand you a shortlist-worth document in a single sitting.
Königsallee 45 · 80539 München · +493020095341
