Something More....

In workshops, customers naturally describe the process they follow today - spreadsheets, calculations, approvals, reports and manual workarounds. Each one can quickly become a requirement for the new system. But if we accept everything exactly as it is, we may simply recreate the existing Excel process in a new platform. Would this really be a transformation? Or just an automation. The questions worth asking are:   • Why is this step required?   • What decision does it support?   • Is this level of detail useful?   • Could the process be simplified or standardised?   • Are we addressing a business need—or preserving a workaround created by an old system? Challenging a requirement does not mean dismissing the customer’s experience. It means combining their business knowledge with our delivery experience to achieve a better outcome. I recall one instance when experience from an earlier subledger to General-ledger mapping exercise in a project helped me challenge a...

After working on EPM and FP&A solutions for many years, one thing has become clear to me: most planning transformation programs do not fail because of the technology.They struggle because a few fundamental questions are left unanswered during the early stages. What level should we actually plan at? Who owns what - be it assumptions, workflows, admin tasks? Are our hierarchies stable enough to support the build? Is the process truly agreed upon, or are we just automating different interpretations of it? A good EPM tool can easily handle driver-based planning, workflows, complex allocations, and seamless data integration. But it cannot compensate for unclear ownership, poor master data, or a process that changes across every business unit. This is where solution architecture becomes critical. It isn’t just about designing cubes, dimensions, forms, and reports. It is about guiding the business to make structural decisions that lead to a scalable planning model. In my view, a ...