A Superhero’s Toolkit: The Engine Behind Automation

  • June 24, 2019
  • Optimum Consultancy Services
  • Feature
A Superhero’s Toolkit: The Engine Behind Automation
A Superhero’s Toolkit: The Engine Behind Automation

By Jack Wilson, Process Engineer, Optimum Consultancy Services

My previous articles have suggested that the engine powering BPA and RPA initiatives is human effort. However, this is no ordinary human effort, but rather the unsung superhero powers of Project Managers, Business Analysts, and Process Engineers! But even superheroes have toolkits that can make or break their ability to power automation for large complex processes. This article covers a few of those tools.


A Detailed Business Requirements Document (BRD)

You may be asking, “Isn’t that the rather dull document with the charts and endless list of requirements?” Actually, you’re right…unfortunately. Many folks view this document has a hastily written hodge-podge of flowcharts, tables, endless sections, and the long, uncontextualized list of requirements at the end, that’s quickly forgotten once the document is executed or the project begins to fall apart.

I would argue that for a complex detailed process, a well-written BRD tells the concise story about why the requirements at the end are even listed. Literally, the Business Analyst needs to know the client’s business. Without understanding this background information related to job responsibilities, product, customers, and challenges, it’s hard to know what the stakeholders may be forgetting to tell you in the requirements workshops, assess the impact of potential changes made to the project after the BRD’s execution, or even determine the right-fit solution. And when those long-term projects leave the team wondering “why did we decide to do it that way?”, the BRD should be the go-to manual that ties the requirements to the business need.

Additionally, the BRD should not morph into a Functional Requirement Document (FRD) or Technical Design Document, although there will be some exceptions (such as very small projects or totally IT-centric projects). Combing the BRD with the FRD turns an already unwieldy document into a complete disaster. The IT side just wants to read their action items to get the development started while the Business side won’t sign it because they see code and script indicated below their flowchart diagram. So, while business requirements should be detailed and contextualized, the IT team should prepare their Technical requirements and work with the BA to ensure a synergy between the two documents.

And those charts? If visuals can be easily digested by the reader, they should support client engagement and further requirements elicitation.


Process Mapping According to Project Management Methodology

“Why wouldn’t the process mapping be performed according to project management methodology?” you might ask. There’s a lot of reasons. Some Business Analysts just love to be unique, while others may not even be familiar with best practices in project management methodology. Or maybe the BA has never had a robust lessons-learned session with their Project Manager following a project’s closeout.

Whatever the reason, incorporating these best practices into the BRD’s process mapping visualizations allows a diverse set of stakeholders to extract meaning from the varying charts, and helps the project team to catch mistakes early on (often being wrong in your understanding of a client’s process is just as valuable as getting it right).

For example, the SIPOC method is a great visualization for understanding the inputs, owners, outputs, and audience associated with parts of an overall process, and is especially useful when determining automated task assignments, escalations, notifications, and permission levels.

On the other hand, a generic process flowchart helps to detail the sequence of events while enabling stakeholders to critique possible outcomes sprouting from a decision diamond. This type of chart is beneficial in determining which parts of the process can benefit from an automation tool and the extent to which that benefit is realized (ROI). The flowchart is also helpful when utilizing a tool to automate a process that moves from one phase or stage to the next.

For those projects that are heavy on data transfer within a system, relational diagrams are often the best visual for communicating data paths, along with their origination and endpoint(s). However, even a well-designed relational diagram can be overwhelming for certain stakeholders (and can require a plotter to print), so put thought into whether this is the most effective visualization for process mapping.

System diagrams are great visuals to use to depict information flowing between multiple systems and are useful for determining ERP solutions or data transfer between these systems utilizing RPA technology.


Utilizing the Toolkit

In short, know your audience. The BRD and its process mapping components take a lot of time. Don’t waste this time skimping on background or creating visuals that don’t speak to the project’s stakeholders. Also, creativity is a plus. Morphing multiple process-mapping types together may be exactly what the client needs to see…but also don’t overdo it just to release your inner artist. When it comes time to present visuals to a large stakeholder team, know that not all these stakeholders are going to see them the same way, and be prepared to draw up a quick alternative visualization on the white board just in case!

About the Author

Jack Wilson is a Process Engineer with Optimum Consultancy Services, a software consulting firm specializing in business optimization through advisory services and modern software solutions. For more information, visit www.OptimumCS.com.

Learn More

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..