To Challenge or Not to Challenge Customer Requirements?

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 customer’s proposed approach to tracking detailed costs. Instead of adding cost lines as another dimension in the cube, I proposed treating them as a pseudo-subledger and applying the same subledger to General-ledger mapping principle. This retained the required level of detail while simplifying the business process and avoiding unnecessary complexity in the underlying cube design.

How do you balance respecting customer requirements with challenging the process behind them?



#Fintech #EPM #Hyperion #Board #FPandA #BusinessTransformation #SolutionArchitecture


Comments

Popular posts from this blog

Groovy Series 1: Groovy + PBCS = New possibilities !!!

Using Planning functions with Dynamically created members

Dynamic names for export files