Part 3 in the Finance Automation series
Companies are going digital through large-scale transformation programs, and it’s no different for the finance function. In the second blog in this series, “A CFOs Digital Finance Transformation Roadmap,” Bart and I described the various technologies that finance can use in its digital transformation. However, your traditional ways of working might not be the best way to implement them and fit them into your business model. Large-scale three-year transformation programs just don’t work for digital because technology will have developed significantly during that time. That’s why you hear about companies needing to become “agile.” But what does agile really mean in the context of getting started on your digital transformation? That is what we will explore here.
Agile!?! Isn’t that just some fancy consultant-speak with little meaning?
Getting your finance function to work in innovative ways to go digital will not be easy. But properly explained, your teams can understand the necessity of these ways of working to accelerate delivery of digital products in your finance function, be they BI, automation, robotics, and so forth. We would like to bring two to your attention: design thinking and DevOps.
Design thinking: understanding the problem
Design thinking is a relatively new concept. A common approach to design thinking is to follow a certain model. This is the one we recommend.
Empathize: Put yourself in the shoes of the users who face the problem. Sit down with them to understand their experience.
Define: Based on the inputs collected from the users, create a persona. This should be a fictive person. Describe the pain points, role, needs, and the emotions of the problem.
Ideate: Brainstorm on potential solutions. Here it is important that you ask yourself if the proposed solution is going to be desired by the users, if the idea is feasible, and if it is viable. As a result of this exercise, it should meet the outputs from steps 1 and 2. Based on the proposed solution, start building a low-fidelity user experience (UX) design. The low-fidelity design is shared again with the users, and you gather feedback. Based on the feedback, you adjust your design. This process needs to undergo several iterations until you can create a final design, also known as a high-fidelity UX design.
Prototype: Once your design is ready, have a small team of engineers or developers build a prototype. Demonstrate your prototype regularly to your end users during the process, which should not take more than a few weeks. The prototype is not aimed at meeting all architectural standards and fulfilling all other internal requirements, but only to prove that the proposed solution could work.
Test: Once the prototype is done, start testing it, engaging some end users for whom you are building the prototype. After successful testing, hand it over to DevOps to move from prototype into production.
DevOps: accelerating the solution
In classic IT projects, one of the most common project management methodologies is the waterfall approach. This approach has certain phases, such as requirements gathering, design, implementation, test, and then deployment into production. However, the requirements are defined at the beginning of the project and cannot change during the project. This is, of course, a challenge, since you receive feedback from end users only in the test phase or even worse, in the deployment phase.
DevOps uses an agile approach such as scrums and sprints, with the aim of greatly lowering the lead time from experiencing a problem to having a digital solution in place. The intent of the scrum is to gather feedback from users as soon as possible and is based on the minimum viable product (MVP) concept: limiting requirements to the minimum that delivers value to the user.
How does scrum work? First, you form scrum teams, which should comprise no more than eight to be efficient. These teams consist of engineers, quality assurance (QA) engineers, a product owner, and a scrum master.
The main task of the product owner, who represents end users, is to prioritize the backlog. In the backlog, all full-list items that could be built by this team are maintained. In a sprint, which should take one to four weeks, you pick up items from the backlog. The goal of each sprint is to provide value to the end user and deploy the solution into a productive environment. During a sprint, certain items are developed and tested. At the end of the sprint, in the sprint review session, the solution is presented to the end users for their feedback.
Based on the feedback, the product owner can prioritize topics to be picked up in the next sprint. It is advisable to plan a project in several sprints and then deploy in production. With each sprint, you will get feedback from the end users, and therefore, your final solution will be of higher quality with greater user satisfaction.
Always conduct a sprint retrospective in the scrum team to discuss what went well and what did not, and create actions to improve. This will benefit team collaboration and the quality of the work.
This is “agile” explained in simple terms: understand the problems, design a solution seeking frequent feedback, produce the design through sprints, and deploy. Even the finance function can do this!
But remember, just because you go agile and scrum doesn’t mean it will be easy. Rather, you should think of it as failing fast to succeed sooner!
Our next blog explores the factors beyond technology to consider when embarking on your finance transformation.
For more on this topic, see A CFO’s Digital Transformation Road Map.