3 common process automation mistakes (and how to fix them) – IDM.net.au

Like their cloud-native counterparts, many large or long-standing 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. Lets take a 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 is the first. While theres 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 doesnt see any business value for a long time. As a result, developers will most likely get completely stuck in shaping a complex platform without understanding its use case.

Instead, try to break down larger strategic initiatives into component parts, starting with the most urgent or important projects first. Heres one way to approach it:

Start with Pilot Project: The goal of this project is 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 important to go-live with that pilot to really learn about all aspects of the workflow solution throughout the full software development life cycle (SDLC).

Accelerate to a Lighthouse Project: Soon after running a successful pilot, you should tackle a lighthouse project. This project should have a broader, but still realistic scope which can be better leveraged to show off architecture, tooling, and value of workflow automation 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 Centre 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 stacks 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 effect organization-wide change, or end-to-end process automation. Technology decisions are 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 ofcode written in COBOL, a decades-old programming language. A wholesale replacement of these systems could cost upwards of $US4 to $US8 trillion (or more).

Thats where the gradual transformation approach comes into play. For example, many companies have surface-level automations in place 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 a modernization in three main stages:

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 cant happen in a vacuum. Stakeholders from across the organization should be involved, and projects should start small. Without a clear pilot project, large-scale, strategic automation efforts can easily 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 virtualCamundaCon 2021event on September 22-23. Jakob Freund is CEO at Camunda, a business process management solution provider.

See original here:

3 common process automation mistakes (and how to fix them) - IDM.net.au