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 architecture and stack. This pilot project is often set up as a proof-of-concept (POC). However, going live with that pilot is essential 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 groups and drive organization-wide change.
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. I call this approach “the art of gradual transformation.”
Handling Automation Projects in Silos
Even though a gradual transformation approach is recommended, it does not mean “siloed” or without structure. 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. If each team chooses its own tools, it can be hard to affect organization-wide change or end-to-end process automation.
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 company.
Beyond tooling alone, a CoE can also maintain start guides, project templates, and reusable open-source components/libraries for teams to leverage. Within this framework, more teams can get inspired by the potential for automation within their departments. In addition, they can serve as advocates for automation by running a community to raise awareness for new automation initiatives within the company.
Failing to Embrace Microservices Architectures
Embracing a microservices architecture in a legacy company is easier said than done. One important factor to address is how software is built within the company. Often, there are legacy systems in place that are difficult to unseat. By one estimate, over 200 billion lines of code are still written in COBOL, a decades-old programming language. A wholesale replacement of these systems could cost $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 isolated processes. If 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. Large-scale, strategic automation efforts can quickly fail to prove their business value without a straightforward pilot project. 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 more about process automation, sign up for the virtual CamundaCon 2021 event on September 22-23.
