Most people have purchased a piece of furniture from IKEA and tried to assemble it using the instruction. Despite that we often find it quite complicated to assemble the furniture we most often end up with a new chair, couch, table etc.
Attending the IBM Impact 2013 conference in Las Vegas this week I’ve heard a lot about IBM’s approach towards Business Process Management and especially their embracement of the BPMN notation. While a common language is critical for collaboration and communication we should not hesitate to ask ourselves whether the notation actually improves our ambition to “process enable” companies and organisations for higher employee motivation, better productivity and higher quality and compliance.
Processes can make the business goals clearer which can lead to better understanding of the work to be done. Understanding the purpose of what we are set out to do is critical for employee motivation. Once we understand why, the work is often done faster with fewer problems. This is my interpretation of Daniel Pink’s bestseller on motivation, Drive. I fear this will lead to lower employee motivation, which most likely will lead to lower productivity and lower overall quality. Probably not the path to take forward.
IBM talks a lot about “straight-through processes”, which basically means automating the process completely. While this certainly is valuable from an efficiency perspective, it might not be the right direction if aiming at customer intimacy or innovation. But is automation really the main aim for Business Process Management? I think most people agree that nearly all work is complex and hard to be broken down into sub-tasks.
Despite our effort to make clearer goals before we start off the work, we often end up in situations where goals need to be adjusted as we proceed. Similar to our GPS , we need a business process model which can re-calculate the best approach forward as goals and directions, and even instructions, change as we go.
The BPMN notation leverages the well-known flow chart model as its basis, because it is something people understand. But is this really true? Flow charts might explain how we assemble our newest IKEA purchase, but can we really break down complex work into well-defined steps and conditions? And even if we could, is a flow chart the best starting point when trying to understand and agree on how we collaborate as an organisation together with customers and partners?
Flow charts explain how we are going to do the work, and leaves out the reasons and backgrounds – the whys! As the reason is important from a motivation perspective we risk that employees loose the understanding and goal, and end up performing the tasks as mechanical steps. Anyone who has talked with a customer services center has probably experienced the flow chart questionnaire approach rather than listening to what the customer actually says and provide of background. You simply have to fit into a flow chart to get an answer. The aim is efficiency; let’s end this call as efficiently as possible. In my experience I tend not to call customer services anymore – as they are certainly efficient, but seldom solve my problem. Like at online shoe giant Zappos.com, the purpose of customer service needs to be customer happiness. But can flow chart questionnaires really help the Zappos.com customer service representatives?
Flow charts are considered harmful, simply because they leave out the background, reason and whys, and merely explain how to do the work. It simplifies complex work processes into simple furniture assembly instructions. This leads to lowered employee motivation, lower productivity and lower overall quality. Probably not the path to forward!
As flow charts leaves out the whys, the business rules, neither people nor machines will understand them.
So – what do we do instead?
Business Process Management is important as streamlining our businesses for higher productivity, employee motivation, and customer satisfaction is a constant challenge where we need to improve.
BPM enables us to communicate about the work we participate in, which can facilitate coordination and collaboration among co-workers, and can even be extended to customers and partners.
As a first step we need to start agreeing on how to name our processes. Terminology is critical and different words can lead to misunderstanding. Identifying and naming the business processes is probably the most difficult step in the process. Leveraging social media and activity streams can help us in these processes, as people involved in the process can give feedback to the terminology as understanding evolves.
In the second step we often break down the processes into commonly agreed phases or milestones. In complex solution sales, a sales funnel is often in place with some milestones. In project management, whether building power plants, bridges or delivering IT projects, similar phases or milestones are found. It is my experience that it is surprisingly easy to get coworkers to agree on these phases or milestones, as long as we focus only on naming them. Once we start the discussion “how do I get from one phase to another” the problem starts. Simply put – people do not agree. Viewing the phases as a flow chart tends to lead people into the discussion on how to go from one phase to another, rather than the important information which has already been found, namely breaking the processes into manageable phases. The purpose of the phases is to make it easier for coworkers to coordinate their work. One sales person might have one approach whereas another sales person uses another approach.
Their knowledge and experience tells them how to do their work, and breaking down this work into small well defined “atoms” of work is seldom possible. Work is a complex matter, which to some extend can be broken down – like the IKEA assembly instruction – but many of the elements are simply intangible, unknown or not well understood. In these situations employees use their knowledge and experience as well as coworker input to navigate.
In the third step you ask the team to identify the roles of coworkers, partners and employees involved in the process. This often result in swim-lane type of diagrams where we visualise the overall understanding of where people are involved without going into a level of details which often causes unproductive discussions.
Knowing the process, phases and team, the next step is to identify the various work-tasks done in the process and associate responsibility with each task. You’ll most likely not get them all in there as a start, so the ability to add ad hoc work tasks, preferably based on common process fragments is critical. The ability to process mine what people actually do will be a good basis for process modifications.
The next step is identifying the data involved in the process. What data do we know, when do we collect it, when is it required for us to proceed etc. Most project management solutions prompt the end-user for all data when creating new projects despite the obvious fact that all data is not yet known to the person. He simply doesn’t know. Projects often start as ideas and evolve as you proceed. So, who should be involved? How do we find the right team? Asking these questions at project creation is meaningless and often leads to people entering dummy data initially in order to proceed. The ability to associate attributes of the business process to the overall phase simplifies the work as only relevant information is presented at a point in time.
DCR: Rules and response
Once work-tasks and data are in place you can start looking at the rules. We analyse the overall phases and identify the conditions for each phase. What needs to be done before we can enter into the next phase? We also analyse each phase for the work tasks defined, and again find conditions. This somehow leads to a sequence of work tasks, but the tasks are loosely coupled with only strict constraints against them. Then we look into response, e.g. what needs to be done as a response for each work task. As an example, once a loan has been approved the loan document must be signed. If we, for some reason, change the loan amount and re-approves, we also need to re-sign the loan document as it is a required response of the approval.
This solves one of the critical issues with flow charts and happy paths, as the logic has no problem going back to a previous stage. If a loan application is rejected, all work tasks is simply excluded from the workflow. If the application is later on re-evaluated and then approved, the works tasks are simply included into the process again. Guards can control each work tasks, and provide an expression which must be true for the work tasks to be applicable at all. As an example, if the loan amount is more than $1 million, a guard controls an approval which is only applicable if the amount succeeds $1 million. The rules follow the Dynamic Condition Response logic developed by IT University of Copenhagen by Thomas Hildebrandt et.al.
As a final step, we might look into the statistics and analytics needed. Do we need to provide statistics for average and mean processing time, broken down by each phase? Doing so can enable us to identify bottlenecks in the process portfolio.
Exformatics uses a methodology leveraging the steps mentioned above when helping our clients defining and documenting their business processes. It is not based on flow charts and happy path, but focus on the elements of the processes most people can agree on fast, which ensures fast adopting and less discussions about the processes. The main challenge moving forward is probably related to ensuring employees joins the first step – starting to identify processes by name.
As a curiosity the process engine is delivered as a cloud service away from the Adaptive Case Management system which holds the work tasks, documents, processes etc. Every step in the process is executed by the engine sitting in the cloud with data and information fully anonymised. Once the process sits in the cloud it is easy to interact with customers and business partners in the process.
By Morten Marquard, CTO of Exformatics
ECM-blog 