Why system projects derail
The usual setup: an implementation partner supplies consultants, IT supplies capacity, and the business is expected to "contribute". What is missing is someone who makes process decisions, resolves conflicting goals and answers for them. Without that role the project renegotiates every posting rule until the timeline breaks.
On top of that, a system change absorbs the commercial leadership entirely. Whoever owns the month-end close cannot steer a migration in parallel — both suffer.
What I take on
- Requirements analysis from a commercial perspective: which processes must the system represent, and which should be cleaned up beforehand?
- Selection process and negotiation with vendors and implementation partners
- Project leadership across all entities, including steering the implementation partner
- Data migration and reconciliation of opening balances
- Interfaces to e-commerce platforms, banks and upstream systems
- Go-live support and stabilisation of the first closes in the new system
Project lead for a group-wide rollout of Microsoft Dynamics 365 across ten international entities, including digitisation of commercial workflows and integration with the e-commerce platform. Earlier, built a shared service centre introducing NAVISION, D3 and NAPA3, and developed an SAP landscape in a listed group under US-GAAP and SOX.
Systems from own project work
- Microsoft Dynamics 365 — group-wide rollout as project lead
- SAP — further development in a listed group environment under US-GAAP and SOX
- NAVISION — introduced as part of a shared service centre
- Salesforce — CRM integration into commercial processes
Typical shape
ERP engagements run longer than pure bridging mandates — nine to eighteen months is common, often with a decreasing workload after go-live. Frequently the sensible combination is project leadership plus interim CFO responsibility for the running business, so both stay in one pair of hands.