Where are you in the product life cycle?

Most organizations view the first few years of a new software as the “bleeding edge.” However, being on the backside of the software life cycle can be just as bad. The image below is the way I typically envision the life of a product.

At the end of a product’s life cycle you will usually experience:

• Slower patch development times
• Less support for issues
• Fewer available resources for support (maintenance or development)
• Issues with product compatibility
• Higher maintenance and support costs

In addition to these issues, there are often more conflicts with ancillary software. Taking an example from SAP’s Business Planning and Consolidation (BPC) software, changes to the Microsoft suite (Office or SQL Server) may result in frequent compatibility issues that will take longer and longer to address.

Where are you in the life of your process?

Much like the software that may not have aged well, the processes and procedures reflected in your software may not have done so either. If you implemented software five or more years ago, odds are your process is out-of-date. IT professionals are often unaware of this because users tend to find work-arounds for the areas that no longer work for them. When evaluating new software, consider your process. Best practices in business processes and software change over time. Using new software in the way you’ve “always done things” may not be the best use of your resources (including human capital and investment in software).

What are the stakes?

Much like driving a car with more than 200,000 miles on the odometer, you risk getting stranded with your aging software — what are the consequences if you have an issue? Are you a public company that needs to have your 10-Ks and 10-Qs filed within a statutory deadline? If so, you may be risking regulatory and reputational consequences. Maybe you’re not a public entity, but you have strict lending reporting requirements, or you report to some other type of regulatory body.

Are you missing out?

Are you missing opportunities by neglecting to make changes to your software? It’s possible there is newer software available with more features and lower maintenance costs. As you review your software, consider your workforce as well. Trying to recruit and retain employees when you are still using a DOS-based system may not be that easy.

Ready to make a jump? Look before you leap

So you’ve reviewed your options, and you’re ready to make a change. It’s important to take your time.  Consider all of your options and opportunities. Make sure you understand exactly what you need in a software package. Don’t try to implement your old software in a new platform — this never ends well. 

Deciding to stay put for now

You may have considered all your options, reviewed your process and the associated risks, and decided that now is not the time to make a change. That’s okay. Not every organization needs to make a change, and at a minimum you have established a baseline for the needs of your organization. Many software vendors will offer quality support up to and well after the end of life for a software platform, but don’t assume this will be the case. Have conversations with your software vendor and other professionals familiar with the product to ensure you are forging ahead with the best information possible.

A better way forward

At the end of the day, your software and your process is well … yours! You represent the experts in determining what your organization needs — if you’ve considered this advice, you’ll make a good decision. I know it!

The post Software End-of-Life Considerations appeared first on SandPoint Consulting.

Understanding the Key Players

Typically in the data governance process there are:

The Numbers People

Your accounting group (consolidations) or your planners (forecasts). These are the people that can vouch for the accuracy and completeness of the data, but they may not always know where it comes from or who uses it. Interacting with this group, you’re likely to encounter accounting terms like out-of-balance, eliminating entries, or journal entries. Sometimes this group is technical enough to understand scripting or IT change governance processes, but often they are only familiar with the concepts at a high level.

The Technical Team

Depending on your organization, this group can vary greatly. It may consist of accountants and planners with enough technical expertise to run the show on the setup and configuration side of the software. They may also be part of the more traditional IT group. Either way, the best situation is when you have someone that can understand the accounting, planning, and technical sides of things.

The “Real” IT Crew

Most organizations will have a core IT support group. This can vary from a small core group that keeps the servers and network up and running, to a full bench of IT professionals. This group doesn’t usually have much of an accounting background and will need help when a wide-eyed accountant tells him or her, “Your balance sheet is out-of-balance and the intercompany transactions seem to be the issue.”

The Fuzz

Again, most organizations will have at least a core contingent of staff dedicated to oversight. This may include an internal audit function, IT audit group, or a SOX project management office. The experience and depth of understanding within this group ranges from individuals who are well-versed in ITIL and ITSM methodology to those just looking to make sure the I’s are dotted and the T’s crossed.

The Bosses

Everyone has someone they answer to — all these groups do as well. Each group will have a different set of expectations and demands. The finance and accounting group will likely get pushed to “get it done,” while the oversight groups will be looking to ensure nothing slips through the cracks. 

Where Finance Tech Ownership Breaks Down

Ideally, all of these groups would work together like a well-oiled machine, but we know that isn’t always the case. Commonly, conflicts between these groups are usually the result of a lack of understanding and communication. Conflict usually arises in the following types of situations:

• A “small” change is necessary, and the numbers people can’t understand why they need to go through a change management process.
• The finance group has put together what they believe is clear documentation of what needs to happen (including supporting data), but the IT group in charge of making the change has difficulty understanding what the accountants need.
• The governance group has been reviewing the system changes and wonders why the accounting group needs so many changes. If the process was well-designed and aligned, does it need to change so much?
• The bosses want to know why everything wasn’t done yesterday (or why everyone keeps complaining).

Often, the first step toward conflict resolution is to take a deep breath and relax. Remember, each group of stakeholders just wants what’s best for the organization. No one is looking to ruin someone else’s day. As previously noted, most of these conflicts are the result of miscommunication. 

Advice for Each Group

Having seen this process play out at many organizations over the years, here is some advice for each of these groups to improve outcomes:

To the Accountants

Make sure you’re not speaking in acronyms — remember you’re probably not talking to someone with years of accounting experience. Clearly document exactly what it is that you need and avoid using accounting-specific terms like balancing or intercompany. Consider what it was like before you spoke in terms of debits and credits.

Take the change management process seriously.  Too often, I have observed the accounting and finance group has no interest in performing detailed testing on anything other than “real” numbers (which usually means the production system). If the IT group feels you’re putting data at risk, they are going to put the brakes on any changes you’re requesting.

To the IT Group

Be sure to take the requests of the business seriously. It’s a pretty sure thing that these requests aren’t the result of boredom or a desire to see you running in circles. Typically, there is immense pressure from their superiors to make the system work the way they think it should — more often than not, there is little understanding of how complex small changes can be.  

Where there is immense pressure, there is incentive to get a problem solved as soon as possible. This can result in users attempting all sorts of workarounds. If you want to avoid a “shadow” IT group, demonstrate you are doing your best to meet their needs.

To the Governance Group

While no one is asking that you turn a blind eye to deficiencies, try to frame your process as a value-added effort to assist the company. Often, users understand there is a governance process but don’t understand the purpose of this endeavor. The best governance groups I have worked with have framed their efforts as helping the business and the users to have the most efficient and secure process possible.

To the Bosses

We all know things have to get done and they need to get done now. However, the amount of pressure you apply is directly related to the level of risk individuals are willing to take to avoid that pressure. I have seen many companies create an environment of risk avoidance, to the point that no one is willing to take any risks for fear of sticking their necks out. Seek ways to encourage a growth mindset within your organization.

Moving Forward with Shared Ownership

With very few exceptions, we are all trying to do the best job we can. Try to see yourself and your department as a builder and enabler, not as a gatekeeper and punisher. When we lead with respect and communicate across teams, everyone wins – and the work gets done faster, with fewer bumps along the way.

The post Financial Tech Ownership: Aligning Finance, IT, and Governance appeared first on SandPoint Consulting.