Business Process Is Not An Option
By
Ian Hancock

Back in the 1990’s computer-based Business Process Modeling was really becoming popular, with process automation hot on its heels. Large organizations recognized that in order to scale up to meet future demand, they needed to be able to handle repetitive form-based work consistently, quickly and simply. Massive budgets were spent regularly on projects to automate the processes. Process optimization became the core aim and was supported with business simulation.

Fast forward 20 years, to today, and many more businesses are involved in modeling and automating their processes. The cost to implement these processes has naturally reduced, largely through the abundance of lower cost software tools and server hardware, but the cost to design and architect them is still not low, and the risk of a project failure due to bad design is still high. When this is coupled with the fact that business models are changing faster and faster, what could have been a great process two years ago, could be invalidated as the rules of the game just changed.

Take a look at the telecoms industry, specifically mobile phone stores. Starting out with a small selection of devices and contracts, that covered calls and text messages, it has rapidly moved to many devices, contracts that blend devices and services, multiple network options, and the addition of data tariffs. Each week new phones are released, and deals are changing. The process of making a sale is always in a state of flux, and the staff needs to be tuned into the latest methods, instantly; all this across thousands of stores nationwide. It is clear that process is not an option, it is essential. But if process is so expensive to build, and so easy to become outdated, how can a business stay ahead?

Process modeling and automation are shifting emphasis. No longer is it all about the efficiency of the process, but now it is more about how rapidly a process can adjust to environmental changes. Process agility and its ability to transform business agility is now crucial to enable organizations to stay relevant, amongst a sea of startups, that can bring new technology and fresh thinking to create disruption.

So we need to build our processes to be agile, meaning our documentation will always be out of date? Right? Well agile gets a good deal of bad press with regards to documentation. Lean documentation means just enough, not none. Going back to our phone shops, if there were no documentation, then the stores would have no idea what they were selling, or how to sell. More than ever, processes are becoming the core documentation for business. Where a process could have lived for years, and been handed down to new staff, or automated, now the lifecycle of a process could be months or even weeks. Keeping teams up to date is a real communication challenge.

So enter stage left ‘eBPA’ or Enterprise Business Process Analysis. The ivory towers of the 90s are gone, and social has become king. Democracy is invading the world of the process modelers, and everyone is an expert. Gartner speaks of eBPA as “Business Process Analysis for the masses” and is providing thought leadership, as businesses need to envision a world where process is a living entity. In order to adapt and survive it is essential to build collaboration into process design, and it is by involving the wider organization that innovation can really thrive.

But many organizations have tried social technology and seen it offer little value. It is true that social without a goal can just be chaos, and indeed marrying social technology with process design will not turn everyone into a process expert. But by building a framework that allows others to collaborate, with clear aims, it is possible to encourage and nurture a collective intelligence that can truly make a difference.

In conclusion, think about your processes differently, they are unlikely to remain the same next year, and may change next week. Make them visible and available and use technology to allow the widest group possible to write on them, make suggestions, or highlight difficulties. Spend time to manage the feedback, and use this to drive innovation. But most importantly build processes modularly, so that they can adapt to change.

Ian Hancock joined Casewise in 2012, with the remit of building a new technical strategy to support the product and solution offerings. In order to achieve this, he took a holistic view of the entire development structure and processes, and began honing and aligning them to better serve the business. Ian has a strong background in software development, becoming a competent programmer even before leaving secondary school. He holds an Honors degree in Computer Science from the University of Salford and began his career developing engine control software in the Aerospace industry. Ian has over 15 years experience developing and managing the development of Enterprise Architecture modeling tools, through three previous companies; Popkin Software Ltd, Telelogic AB and IBM Rational.