Best practices for finance process and technology transformation

Sep 23, 2020

This might be eye-opening: Your software requirements list doesn’t have to be super detailed. In fact, functional requirements may not be the most important factor in your financial software selection.

Shanice York, a CPA and manager in Wipfli’s financial and operational systems group, shared best practices for nonprofit firms undergoing finance process and technology transformations during a virtual Wipfli National Training Conference session on Sept. 22.  York walked participants through the stages of finance software evaluation, selection and implementation, sharing do’s and don’ts for each phase of the process.

“Nonprofits are always being asked to do more with less,” York said. “Often, legacy accounting systems can’t keep up with the demand on finance staff.” Challenges with reporting, inefficiency or growth can prompt leaders to revamp their finance systems and processes.

Evaluate the situation

Any software or process change should be preempted by an evaluation of the current situation. “Devote time to understand the ‘now.’ Even if you stay with your current solution, you learn a lot from evaluating all your options,” York said.

“Understanding the now” goes beyond software. York said it’s important to understand resource availability, timelines and the organizational culture as part of the current state. Without factoring in non-technical details like internal regulations or decision-making processes, software decisions could encounter costly delays. 

Integration is another critical success factor that’s often overlooked. Learn which systems talk to one another – or should. Try to understand how many systems exist, how they interact, and the longer-term vision for each software or process. “You don’t want to waste time or money integrating with a system that’ll be retired soon,” York explained.

Once you understand system integrations across the finance function, York said to prioritize and rank them – but “don’t get stuck in the rut of how it’s always been. You may have makeshift data flows or processes in play that work now. That doesn’t mean it can or has to stay that way.”

“You have to be realistic about system integrations,” she said. “Don’t assume that all legacy systems, integrations or processes can continue as is.”

Transformation is an opportunity to fix what’s broken – and not just software. The transformation process can bolster the finance function and reinforce its role as a value-add, strategic partner.

Write the requirements

Before you commit to a project, walk through the current state with stakeholders to understand what you do and why you do it. Then, analyze the situation against best practices, internal controls and organizational goals.

“Keep an open mind and be flexible,” York said. “Don’t assume that you’re already operating at best practice level 100 percent of the time.”

Rather than scribe a detailed list of functional requirements, York said to focus on core capabilities and unique or challenging requirements (most robust systems already meet general requirements, anyway).

Start with the end-state in mind, including reports, York said. “Decide what you’re trying to accomplish, document it and stick to your goals – those are your real requirements. Otherwise, it’s easy to get sidetracked by features or integrations that aren’t important or high value-add to the organization.”

Working with stakeholders, you can gain greater buy-in for projects – and the change management activities that accompany process or system changes. By defining and mapping out the future state together, you can come up with actionable plans and prevent common barriers.

Make a decision

Lengthy requirement lists used to drive the decision-making process but today other factors weigh-in just as heavily. Everything from culture to work location affect solution viability. Decision makers must consider:

  • Delivery model: When it comes to software systems, finance teams can choose between on-premises, hosted or cloud-based solutions. The delivery model can impact the rollout timing, total investment and operational impacts for years, possibly even more than a requirements list.
  • Software approach: Finance leaders can choose between software that is purpose-built (also referred to as “best in class”) or a package of solutions that are pre-integrated to work together. Each approach has its advantages, depending on your goals.
  • Partnerships: Every step of the process, from evaluation to execution, can be completed with internal resources or with the help of a professional services firm. Finance leaders should decide early how they’ll manage system and process changes so they can be appropriately supported with staff and other resources.
  • User feedback: You cannot undergo finance transformation without fully considering each user, York said. She suggested adding a planning loop to the project timeline to seek and incorporate user feedback. Depending on the organizational culture, users may weigh-in on vendor selection, requirements or more granular execution details down the road.

Execute the plan

Somebody within the organization has to be responsible for making sure the project is completed to the best of your organization’s ability. York said a strong project manager should be appointed early in the process (before any vendors are contacted).

A common mistake is assuming the project management role will fit into someone’s already-busy day. Organizations need to devote time, people and resources to ensure their process or software transformation is successful. Decide upfront how many hours a day or week you can lend to the project and adjust the schedule or reassign other duties as needed.

Proactive communication about deadlines, progress and training are also critical to a successful implementation. York suggested using a project management tool that everyone can access, rather than managing a rollout through email or spreadsheets.

Manage change

“Change is hard. Often, struggles are rooted in communication lapses with stakeholders. Either they didn’t get the opportunity to provide feedback or the plan didn’t match what they needed or expected,” York said.

She said ample time is needed for testing, training and support. And information about changes, deadlines and training needs to be communicated early, often and clearly.

Even without naysayers, finance teams need a support plan for after go-live.

“Sophisticated systems and processes will need support from time to time,” York said. “Finance teams should plan for an internal escalation path and ongoing communication and support for users.”

Share This Post