We are lucky enough to visit many people to discuss with them ideas for improving their business processes. Recently we received some very candid feedback: “I love your software, I can really see how it could add value here. But frankly, right now, I'm afraid of introducing any changes.”
We enquired further to try and understand why. The answer we got was that “you see, the Finance team are on a real treadmill, they don’t have time to look at this, and I don’t want to give them change fatigue.”
It is of course not an uncommon scenario, and one that many of us can relate to. Yet a quick glance at business literature will reveal evidence that companies have achieved success and beaten their competitors through continuous process improvement. Most famously, this was embraced by the Japanese manufacturing industry in the 50’s with Toyota introducing their Toyota Production System. Motorola in the 80’s created their Six Sigma methodology which was then adopted elsewhere, including by Jack Welch who made it central to the business strategy at General Electric in 1995.
Many of these cross-pollinated ideas were considered in the software industry when trying to manage constant change. They culminated in 2001 with publication of The Agile Manifesto, drawn up by a group of software developers after the bursting of the dot com bubble. Agile software development is now widespread in the software industry (a search on Amazon gives 3,476 results) and a similar approach is very suitable for businesses seeking process improvement. Our advice when speaking to people is to think in terms of phases of delivery with the following characteristics:
Break your tasks into small deliverables, typically lasting from one to four weeks. For a business process, don’t think you have to automate all of it in one big project – pick the painful, repetitive or risk prone parts of the process first. Add to these and enhance the process incrementally. Make sure you are adding value through the process of automating; e.g. by showing evidence of increased efficiency, reduced error risk or more rigorous audit compliance.
One of the controversial aspects of agile development is the reduced burden on documentation. The Agile view is that stand-alone documents will often gather dust and become out of date. Think of what you would want to read if someone was handing over the process to you. Use tools where the automation of the process also includes the ability to document the process in-situ. This then becomes a living document which can be collated on demand, based on notes created throughout the building process.
Have frequent, preferably daily, meetings between the designers of the process and stakeholders of that process to review progress and select the tasks to be worked on next. Expect changing priorities and adapt to them.
Use tools and techniques that allow for a quality focus. In the case of an automated process, this might be the introduction of automated checks for data quality and range checks on expected results. Introduce approval steps into the workflow where results need to be verified or signed off. Peer review of process changes is also important, so it is essential to have the facility to easily demonstrate to peers how a process has changed over time.
In following the above suggestions we expect our users to spend less time on the treadmill and more time on value added work, including of course, motorising their own treadmill.