What are your best tips for defining process automation project scope and objectives?

Rightly said, stakeholder management is key to any process automation project getting a holistic view and to device the deployment strategy. Also a thorough evaluation of the anticipated cost savings and ROI has to be done to arrive at the most optimum solution. Timelines for deployment and impact on existing process (downtime needed for implementating the new solution) also have to be taken into consideration while selecting the solution and defining scope of supplies and engineering.

Any kind of automation and productivity should go by hand in hand. Clarity in objective and in depth process knowledge will make it happen. Consultency from experienced people and product experts from desired process field equipment will have added advantage while making specifications.

It is mandatory to have a deep understanding of the process you would like to automate, it is the step zero of the problem identification process. The success of an automation process depends on the final user, define properly their needs is pivotal. Your goal is not solely automate the process is to drive the change.

One thing I've found helpful is collaboration. No one's got all the answers; and automation is not a one-person show. It's about bringing diverse teams together to identify current gaps (As Is) and desired outcomes (To Be). This guides the "Jobs to be done," from quick wins to long-term solutions. Teamwork makes it happen!

The mistake I have seen far too often over the years from the early days before PDD/SDD were commonplace right up to today is adequate requirements for reporting. This is often because those documenting the to-be don’t ask the business the right questions or go granular enough, and almost always fail to even have a reporting requirements section in their docs. This means either the business misses the opportunity to report on the success of the automation or the developers will need to redo the code to account for the missing requirements.

In my experience, having a process flow model will help deliver the best value. Identifying tools, needed collaboration, dependencies must be prioritized during process mapping out. In the first quarter of the year, we had the goal to improve efficiency around processing of service requests using a real time performance calculation metric. During process mapping, we selected Excel VBA as the tool, a central repository (sharePoint) to achieve the results. An agile approach was also recommended. A process that will initially require 60 minutes was drastically reduced to 1 minute.

My client's HR department wanted to improve the employee onboarding process. A process improvement they made was to move the 'order tools and equipment for the new hire' process step to 7 days before the new hire's start date. This meant that managers could complete this step and several others at the same time within their IT system - amazing, right? Unfortunately, the IT department's SLA for providing IT equipment for new hires was 12 weeks, so a 7 day lead-time to provide IT equipment was completely unrealistic! The point here is that when you're working with multi-departmental processes, it's critical to involve stakeholders from all departments in the optimisation effort to ensure that process improvements are realistic and achievable.

The process characteristics is given by the touchpoints in terms of tasks, users, departments, etc. The more varied this matrix is, the higher the automation potential. While process flowcharts is good for a high-level understanding, I have found that the task level view is most critical. The role of a task in an overall process must be understood, and what its automation helps include / reduce / eliminate. (e.g. an airport web check-in reduces queues). A good question to ask in this is, what happens to the overall system if a specific task is left alone, made slower or faster. This approach gives a bottom-up view of how the tasks impact the overall process and gives a methodology in how best to fulfil the automation potential.

Downstream systems - if there is a dependency on downstream systems feeding the data to current process, then the downstream owners should also be included in the project and ensure that inputs data formats are not changed and that the upstream process owners will always be informed for changes to data. Upstream system - the reports or outcomes of current process may be an input for other processes hence the upstream process owners should also be part of the project who may get impacted due to automation.

The automation project can be split into multiple stages, with each stage dealing in the automation of one or more self-contained sub-processes. The sub-process prioritization & selection criteria, include the following, - which sub-process can be automated in the most complete manner - which sub-process currently has the maximum lead time to finish - which sub-process outcome has the maximum dependent processes - and similar perspectives Based on such parameters, each sub-process can be prioritized, scoped, completed and integrated in stages in an agile manner. This methodology ensures that the stakeholders understand how each automation stage has helped, what is the outcome, alongwith fewer last minute surprises.

Begin by brainstorming the project's deliverables, allowing you to develop a comprehensive vision of the final outcome. A good practice is to document a detailed description of the product/process, iterate it through collaboration with stakeholders to get to a shared vision on the final result. Next, collaborate with stakeholders to establish measurable metrics that will signify the project's completion. Then break down these deliverables into manageable pieces, making the project easier to manage and control. For each deliverable, define specific success or acceptance criteria and seek approval from stakeholders. This step ensures that all parties share a clear understanding of the 'definition of done' for each work segment.

Process Automation isn’t always going to be straight forward. Not all processes in their current form are something you can automate, at least not easily, even using the vast array of technology we have today We may not realise it, but much of the work we complete today was built around the greatest problem solving technology that has ever been invented (or evolved) “the human brain” - although some work is simple, a lot isn’t and not everything can be automated. In at least some of these circumstances, it maybe a human in the loop type scenario gets you 80%+ more efficient, even though people are still involved in the process, understanding the complexities of your process will help you find the right answer

Additionally, it can also be useful to think once you are successful in automating the process, how will that impact the downstream process, will automation generate benefits or bottleneck downstream and based on this you can consider increasing scope of automation. Example Customer On-boarding Process: Automating intake of customer information will streamline the initial process but will create increased backlog at operations team who perform data validation, data entry into systems, etc.

As process automation starts to be explored and identified, it is most likely that the end user will try to increase the scope. What are the limits of the project needs to be well defined at the planning phase. Scope creep is something that should be avoided in all projects and process automation is something that can be the best victim of it.

Automation is a thought you need to have in each step of execution. You need to focus on the outcome. It's always important to set your goals before starting automation.

A) Human angle: (1) Assign Trust- no matter who within the Org. volunteers 2 OWN the project, the best team or person is the "current process owner" & should always be "entrusted" to make the project a success. Nobody in workplace likes to be sidelined/ignored. (2) reward project success B) Technical angle :- B.1) Core IT team - the organisations IT function must be dealing directly with "process owners" for faster implementation (no matter, if that process owners has "another IT team" supporting the business unit supporting systems). B.2) Adoption review - IT should review if the delivered solutions are in use or abandoned. Abandoned reasons should be understood to gain insight about how effciently, the resources of IT can be utilised.