3 Requirements for Getting Technical Buy-In to Improve Financial Operations
You have a transformational Financial Operations strategy in mind that requires technical innovation and buy-in from the IT organization. CIOs are notoriously cynical about any technology introduced into their purview, but even the most xenophobic executives recognize that there is an inherent benefit to smoother, more efficient, more compliant operations. Particularly in finance, a reasonable business case will not be turned away.
Here’s what you need to know to get your point across and build consensus to move financial operations projects forward.
Understanding the CIO’s Pains
You can become a better partner to the CIO and build a more robust financial operations infrastructure if you can immediately grasp their major concerns: Security, Stack, and Maintenance.
First of all, security is a given. Whatever solution that is proposed in this day-and-age needs to meet enterprise-grade level security. That equates to a robust infrastructure where roles can be defined for the various levels of workflow, operation, and analysis.
Next is understanding how a particular solution will fit into the technology stack that is in place and planned for the future. For example, how will a particular solution mesh with an ERP system? There are many point solutions out there – specific applications that might handle one or two processes – yet there are also solutions that consolidate them to be more seamless, strengthen the integrity and control, reduce the IT costs, while still employing best practices.
And of course, there is the maintenance effort for a solution. Custom projects in particular are major resource-drains and generally should not be employed unless no existing solution will work. For backend operations, buying is almost always better than building. But even when buying, look for solutions that have minimal IT impact (fast implementation, quality support, highly configurable, scalable for growth).
Fighting Against Custom Build
One of the primary reasons businesses think a custom-built backend solution is preferable to an “off-the-shelf” solution is that their business processes are unique. The issue with custom IT projects is that what you gain in control and micromanagement is often lost in time-to-value, maintenance costs and complexities, and operational responsibility. Of course, you can cook your own meals, but if you’re hungry and don’t have all the groceries on hand and have unexpected guests, maybe making every meal from scratch in perpetuity is not the best strategy.
To assess your thinking, it’s important to ask yourself some basic questions.
- What is the problem we are trying to solve and how unique is it?
- What is at risk by not solving this problem?
- If we attempt a solution in-house, do we have the expertise and resources to do it right?
- Does an existing proven solution exist that we can apply and adapt to?
IT is better employed (and probably happier) to solve truly challenging, value-add problems where there is no existing code available. That said, the software space is highly innovative right now with successful solutions that work – even for finance organizations!
Know the Evaluation Questions IT Will Ask Your Vendor
A healthy dose of technical cynicism is required to being a CIO. They are bombarded with promising products on an hourly basis. Here are some of the questions IT is going to want answers and justifications to during the selection process.
- What technologies and methodologies are being used to secure access and ensure data integrity?
- Which organizations and/or users will need access? Who will administer them? What level of access is there?
- How will this solution impact our existing technology?
- What integrations are required? How are they integrated?
- What data center requirements are there for us?
- If the solution is in the cloud, which cloud? Is it multi-tenant?
- What certifications has the solution achieved? For example, SSAE 16 SOC, ISAE 3402 Type II, etc.
- Will we be able to sandbox our environment or use sample data for a deep evaluation?
- Will implementation disrupt our existing infrastructure?
- Will the solution require anyone to enter our environment?
- How long does implementation take and what skills are required?
- Are there any third-parties involved during implementation?
- What does the project timeline look like?
Rollout / Maintenance
- What is the typical rollout period for an organization of our size/complexity?
- What methodologies are used to ensure adoption from end-users?
- What is the support plan from the solution provider?
It behooves you to work with your solution vendor to ensure they can answer these questions before even introducing your IT team. After all, it is a waste of their time if the solution cannot clear even basic technical requirements.