The process for implementing or changing a data extraction, validation or reconciliation process in most firms is the same whether you’re building your first process or your hundredth.
It usually looks something like this:
Scoping and documenting requirements makes sense when you’re implementing an entirely new platform or solution. But it’s clearly an inefficient way of working when every single change is managed in this way.
Unsurprisingly, the process outlined above can take months from beginning to end. That’s a serious blocker on agility – teams often need to make changes to processes, or spin up new controls, in days or weeks. Not every business change will be flagged months or years in advance, like regulatory changes are.
There are two main reasons why firms stick to this way of working:
- They believe that this is the best way to enforce their governance policies. BRDs give oversight over process changes, and restricting the capacity for change to the IT team limits the potential for automation that could damage the business.
- This has historically been the only way to effect change, because the technology used by Operations is so technical and relies on coding that the average business user simply can’t operate it themselves. They’re left briefing everything into IT as though it’s a major system overall, even if they just want to build a new reconciliation.
This is symptomatic of a legacy mindset – technology has changed a lot in the last few years. This way of working is outdated and brings significant cost for the business. It’s possible to both empower operations to own and manage their own technology while also strengthening your firm’s control framework to increase compliance and transparency.
It’s especially important to make the switch away from following the BRD process on a daily basis because it often has the opposite effect of what was intended in the first place. Teams need controls fast in order to keep the lights on, so staff will resort to spreadsheets or EUDAs rather than attempt to go through the official channels to create automation.
In other words, the very controls put in place to protect the business ironically often increase risk and cost, while decreasing transparency and agility because following the policies simply isn’t realistic.
Remember, we’re not talking about implementing a new platform. This clearly requires a well-documented understanding of the scope and requirements of the project. Getting it right first time provides the solid foundation that enables self-sufficiency and agility. But users will never be able to benefit from all that hard work upfront if their hands are still tied by legacy change management at every turn thereafter.
BACK TO
TRANSFORMING OPERATIONS