Most organizations understand that automation drives efficiencies. As agencies push to do more with less, automation is pervasive if not critical to digitization. However, starting with a faulty strategy sets up organizations for failure and acquired tech that demonstrates lousy ROI and fails to meet business expectations.
The main problem is that they aren’t prepared for extensive automation. They must first rebuild the infrastructure by reviewing and optimizing current workflows and processes, defining desired business outcomes, and establishing metrics to benchmark performance. When these are overlooked in a rush to automate, the investment rarely fulfills its intended ROI.
How do you avoid this consequence? The following are common pitfalls that lead to automation fails in government agencies.
Mapping current state versus ideal state
One of the chief reasons automation projects tank is because workflows are copied from IRL into the technology. This is problematic because inefficient workflows are being automated. If the real goal of automation is efficiency, quality, adherence to mandates, etc.–the root cause must be determined and course-corrected.
Our approach includes diligently documenting current, manual processes before automation. Documentation provides a visual for abstracting and adopting new workflows. Abstraction provides opportunities to eliminate unnecessary steps and help prioritize the areas to automate initially.
Many of our clients wish to automate their public records requests (PRR). Some take queries via their website, others require residents to send an email, and so forth. Over the years CPS has learned that PRRs work most efficiently when they are driven by a Laserfiche Form which is hosted on the client’s website. We start with a form because it’s an easy way to ask for and receive data. This data can be used to push information/documents using staff approvals and collaboration. Also, data can be populated from (or to) other systems (with the old way, everything had to be entered manually). My point is that the new process was engineered for efficiency and compliance and it met the goal. The old process was compliant (with a lot of effort), but really inefficient. Mapping the agency’s current state fostered the creation of the new (ideal) state.
Not goal setting or establishing metrics
Business processes have to be tied to organizational goals and have clearly defined outcomes for two reasons. First, it communicates how it will deliver value and impact overall business performance. Two, it enables your team to track the efficacy and ROI of the automation over time.
In the case of the PRR request project, as we were documenting processes, they collected metrics:
Length of time of request through to completion
Length of time mandated
Deficiency rate (How often the process failed)
The number of phone requests, online requests, in-person requests, and email requests
By doing this, they were able to see where they needed to make improvements, set more specific goals and metrics, and then track their performance against those.
Ignore your stakeholders
Automation isn’t your average initiative –– it’s a cultural shift and must involve all of your stakeholders. The most successful automation implementations involve stakeholders at all levels. This helps avoid the responsibility of automation falling squarely on one team’s shoulders and instead makes it an organizational priority. It also ensures you get the expertise and input of all stakeholders to realize the full potential of automation and avoid the potential issue.
In a technology effort, obviously, IT needs to always be included as a stakeholder, if not the driver of an automation project. Issues arise if IT isn’t included. One issue is the duplication of efforts and inconsistent standards across various teams and departments. Silos happen, and when automation is isolated, you run the risk of teams re-creating their own automation and applying different standards. But in most cases, automated assets created for one process, workflow, or team can often be replicated in other scenarios to increase ROI and decrease technical debt.
