Organizations use business process automation (BPA) to improve workflow and end-to-end business processes. The process typically begins with an analysis of a “physical process” or what it takes to get something done. From there, BPA analysts may tweak existing processes, improve tools to add value, or implement a new technical solution.
Of course, new technology alone is not a sign of project success. The solution must align with the organization’s process needs and must be implemented in such a way that users trust the system and find it easy enough to use. Miss those marks and ROI will be elusive. Hit them and reap the rewards. (For more, refer to my previous blog post 5 Benefits to Business Process Automation.)
But how do you properly engage participants and ensure the project is a success? Keep reading for my project strategy, but first, let’s review how BPA both differs and aligns with a traditional software development model.
Classical software engineering methodologies, primarily the SDLC (software development life cycle) worked well because it accommodated disparate software development. Documents were primarily used as the medium for communication between the roles. For example, “requirements” would be used to communicate the business process requirements from the end-users and analysts to the technology experts. Subsequently, “specifications” would be used to communicate the architecture and design from technology experts to developers and so on.
As many can attest, the documents quickly became outdated, culminating in a breakdown of communication and a misalignment between the business process and the technical solution implemented to automate it.
However, introducing flexibility in the SDLC (e.g. improved communication) can empower end-users, business analysts, technology experts, developers, trainers, quality assurance and maintainers. Not everyone learns the same. The more each role knows about the business process, the more aligned the technical replica1 will be to the physical business process, which again, is what is trying to be “automated.” Let’s refer to this as the SDLC 2.0.
We’ve now addressed the communication trap door of using the traditional SDLC documents in a project.
The more each role knows about the business process, the more aligned the technical replica1 will be to the physical business process; which again, is what is trying to be "automated."
The next shortcoming is the implied disparity of subsequent stages: requirements, specifications, implementation, testing, deployment, maintenance, etc. The shortcoming isn’t that there are distinct stages, but rather the lack of an oversight approach for process participants. Lacking this coordination often results in deviations from the business requirements. There should be periodic verification the solution that is being built aligns with the business process. That is where the strategy transpires. It is more than just a SDLC 2.0; the management of the project is also crucial.
Automating a business process requires full transparency, coordination and communication from the process participants all the way through to the developers. A proven way to accomplish this is to use an agile strategy (which many of you purists are probably thinking). However, the solution isn’t black and white, agile or waterfall. Classical SDLC coincides with more of a waterfall approach. There is sequence to BPA, so they naturally fit together. On the other hand, a waterfall approach does not fit well with scope changes, transparency, coordination and quick flexibility (i.e. NOT updating a plethora of documents). Agile is more of a natural fit for that.
We need the benefits of both: agile AND waterfall. Waterfall can capture the sequence and functional requirements of the business process, while agile can ensure the solution stays aligned with the business process so it’s automated properly.
Note: With today’s BPM tools, not all candidate processes will be large; small teams may be assigned.
Large, automation capable software packages are used to automate expansive processes with the premise of huge savings. Many little processes, quickly automated, can have the same amount of savings. Minutes matter. The savings can also be more quickly realized.
Now I’ve explained the deviations from traditional concepts, here is the strategy that has proven to be very dependable in ensuring the success of business process automation projects:
Please note steps 1 - 4 are most appropriate Waterfall, steps 5 -9 are more appropriate Agile.
This role must have a vested interest in the success of the project. They should also have a clear vision of the company’s initiatives and how automation of this process progresses those initiatives. The champion not only represents the process participants but must hold them accountable to any change.
What is the purpose of the business process? Is it cost-effective to try to automate? Here are some factors to consider:
Reference the physical process—that’s where the functional business requirements are true. Business processes are usually already defined, not invented, so start with the physical process. The physical process usually fulfills the desired outcome, which is why they are using it. However, efficiencies can be found in the processes themselves.
Use any number of technologies needed to capture it in a way that spans audiences and withstands time. In theory, you are translating the physical process into technology, so the end solution should be the best documentation. That’s the true technical replica of the business process. This is why I usually start out with wireframes, storyboards, and/or prototypes. That is the easiest form of communication between process participants and developers. Tools may include:
Expertise is valuable in this phase. It’s beneficial for someone to learn the process from scratch, without bias. Experts in this area are experienced in quickly learning the process and the actual technical translation of the physical process to the technical solution. They are often able to reduce redundancies, find efficiencies, and refine the process flow. Experts in this field are also adept at ensuring the final technical solution will have the desired outcome, which is usually aligned with the functional process.
At any rate, do not assume any pre-existing process documentation is accurate. Part of gathering requirements is to verify existing documentation and capture any additional aspects of the business process. Keep your functional process requirements simple and consistent so any user can understand.
Determine the base functionality needed to go-live and start the transition off the physical process. The physical process can still be used to supplement the technical solution, or even fall back to.
Remember the 80/20 rule. The expectation is that on average, to more quickly realize the benefits of automating the business process, only 80% of the functionality and features need to be implemented before the first release because they meet the desired outcome. The base functionality will probably be a subset of the business requirements captured in step #3.
Make sure users understand that, unlike physical processes, technology-assisted processes can be more easily enhanced, adapted to user feedback, and will improve with subsequent releases.
5. Engagement - Engage ALL Process Participants
Most business processes entail a multitude of technical skills, from the least technical to the most technical. However, the participants you engage must entail the multitude of the business process roles, which is usually just as extensive. If some participants aren’t involved, the business process may not be replicated accurately in the technical solution.
Here’s what a full engagement strategy gets you:
Start with base functionality and build upon it, breaking up the requirements captured in step #3, until the first release. Leave these agile iterations (sprint plans) to the agile experts.
Always underestimated, training is an absolutely critical piece of a successful business process automation project. If users don’t understand the technical replica, feel it’s unreliable, or find it difficult to use, they won’t use it. Technical processes are dependent on the users. If they don’t use it, the buck stops there. For example, if email is established as the main notification mechanism, the users must monitor their email.
I’ve seen many projects fail because proper training did not happen. Make sure that the training aligns with the breadth of technical expertise among the process participants. Automating some business processes introduces a number of new technologies to users, and they need to be properly trained on all the systems (i.e. e-mail, logging in to a website, etc.)
Testing is important to verify the end product aligns to the requirements and ultimately translates the physical business process accurately. Plan for extensive “role” testing, and conduct the necessary training (#7) to facilitate robust, thorough testing. When appropriate, the physical process can be used to parallel test the solution.
Go-live isn’t the end of the project, it’s just the first release. Plan for support, maintenance, DRP, change control and anything else necessary for the solution so it’s in place. Post go-live activities will determine the success of the solution. These may include continuous improvement efforts as well as auditing and accountability to ensure the tool is being utilized.
Positive participant feedback and utilization are both obvious indicators of project success. But ideally you’ve been able to integrate other quantitative measurements (step #2) into your project plan.
Not all projects go-live but that doesn’t mean they weren’t successful. Participants may determine that automating this particular process isn’t justified anymore. Perhaps priorities changed, scope change impacted the outcome expectations, or business processes changed. A discovery effort that leads to valuable new business insight may also be considered a success.
Patrick Brick is a Solutions Consultant at Omni specializing in Microsoft Technologies, SharePoint, and K2. With 15 years of diverse industry experience, Patrick understands how technology and software can be the cornerstone of continuous improvement within a business if leveraged and delivered, correctly. He ensures each solution’s architecture aligns, is extensible, and is scalable to the companies vision and initiatives. He also emphasizes working closely with end-users, application training, post release assessment, and data analysis in order to realize the entire investment. Patrick attended the University of Wisconsin-Oshkosh where he earned a bachelor degree in computer science, software engineering.
Omni Resources is a premier custom software development firm focused on building web-based & mobile applications, business process automation and data management solutions for manufacturing, healthcare, insurance, retail and SaaS companies.