Like their cloud-native counterparts, many large or longstanding enterprises aspire to automate as much of their operations as possible. As a result, many of them get overly ambitious with their process automation goals and attempt to roll out sweeping, company-wide digital transformation initiatives. While ambition is a good thing, many of these initiatives take years to complete and often require ripping and replacing legacy systems.
Few organizations consider that end-to-end process automation takes a change in mindset that spans people, processes, and technology. Let’s look at three of the most common process automation mistakes and how organizations can work together to fix them.
Rolling Out Strategic Automation Initiatives Too Fast
While there’s nothing wrong with being strategic, thinking on too large of a scale is a common pitfall of overly ambitious automation projects. Taking on too much strategic work too early runs a high risk that the organization doesn’t see any business value for a long time. As a result, developers will most likely get stuck entirely in shaping a complex platform without understanding its use case.
Instead, break down more significant strategic initiatives into components, starting with the most urgent or essential projects. Here’s one way to approach it:
- Start with Pilot Project: This project aims to define and validate both architecture and stack. Very often, this pilot project is set up as a proof-of-concept (POC). However, it is essential to go live with that pilot to learn about all aspects of the workflow solution throughout the complete software development life cycle (SDLC).
- Accelerate to a Lighthouse Project: You should tackle a lighthouse project soon after running a successful pilot. This project should have a broader but still realistic scope that can be better leveraged to show off workflow automation’s architecture, tooling, and value to other people and teams within your organization.
- Progress to Broad-Scale Transformation: Leverage the lessons learned from the lighthouse project, empowering the people on that project team to run a Center of Excellence (CoE) to break down silos across teams and drive organization-wide change.
I call this approach “the art of gradual transformation.” Ideally, before approaching a large-scale automation project, try to map out the entire ecosystem of processes — including the people, systems, and devices at work in the background. Start by modernizing high-impact processes that affect customers the most. Then design a transformation approach that fits the business’ or customers’ needs rather than your technology stack’s requirements.
Handling Automation Projects in Silos
Even though a gradual transformation approach is recommended, it does not mean “siloed” or without structure. If each team chooses its own tools, it can be hard to affect organization-wide change or end-to-end process automation. Technology decisions have been a commitment for years and sometimes even decades. These decisions and the resulting maintenance affect more than just the current team in the trenches.
As mentioned above, a CoE approach can help break down organizational silos and share best practices on what has worked or not worked in previous automation projects. Ideally, this group does not dictate arbitrary standards but maintains a list of approved tools and frameworks that can be reused across the entire company.
Beyond tooling alone, a CoE can also maintain start guides, project templates, and reusable open source components/libraries for teams to leverage. In addition, they can serve as advocates for automation by running a community to raise awareness for new automation initiatives within the company. Within this framework, more teams can get inspired by the potential for automation within their departments.
Failing to Embrace Microservices Architectures
One important factor to address is the way software is built within the company. Embracing a microservices architecture in a legacy company is easier said than done. Often, there are legacy systems in place that are difficult to unseat. By one estimate, there are still more than 200 billion lines of code written in COBOL, a decades-old programming language. A wholesale replacement of these systems could cost upwards of $4 to $8 trillion (or more).
That’s where the gradual transformation approach comes into play. For example, many companies have surface-level automations with RPA implementations sitting on top of legacy systems (like those written in COBOL). A good approach for these scenarios would be to go through modernization in three main stages:
- Orchestrate all of these RPA bot-driven local task automations along with the end-to-end business processes
- Sunset these bots one by one in order of priority
- Invest in rewriting the underlying business logic as microservices, which can be orchestrated along with the end-to-end business processes.
The advantage of a microservices-based automation workflow is that it allows for a decentralized architecture where each team “owns” its own isolated processes. In the event something goes wrong with a single process, it can be easily controlled and fixed. From there, a process engine can “drive” these microservices-based processes across the organization and unify them where it makes sense.
To sum up, end-to-end process orchestration can’t happen in a vacuum. Stakeholders from across the organization should be involved, and projects should start small. Without a straightforward pilot project, large-scale, strategic automation efforts can quickly fail to prove their business value. By working together to define priorities, create best practices, and roll out the technological changes needed, organizations can ensure that end-to-end process automation happens successfully. To learn much more about process automation, sign up for the virtual CamundaCon 2021 event on September 22-23.