The previous main step of the BPM life cycle was about Business Process Design and Redesign. However revolutionary process design may be, it is nothing worth as long as the process is not implemented. It’s like a dream which is not (yet) realised.
From design to reality
Simply stated, business process implementation is putting the (re)designed process into practice – or making it real -, so it can be executed. The more detailed you designed and thought of the future business process, the easier it should be to implement it.
Let us review which main aspects are involved in a process implementation:
1. People
Unless you will be able to implement a 100% straight-through process, say a full-automated one, then you will need to pay attention to all process actors. If your process diagram is based on so called (swim) lanes, then you already have determined in your design who will execute each process step. But it does not stop here…
Assignment of tasks
In such a process model, you usually assigned activities to roles, e.g. a klerk or a credit analyst. In many cases you will also need to assign persons to the roles, depending on the required skills. So you may have a klerk who needs to master a specific language, for instance French if s/he will manage French speaking customers.
On top of the actors mentioned in the swim lanes, you should ideally also assign a Process Owner, who takes the responsibility of well-functioning and continuous improvement for the overall process.
Ensure the skills
Process changes, as a result of process (re)design most often induce people change. Practically, this means training people who need new skills ; or even recruiting new staff. Remind the competency matrix showed in the blog on Process (re)design, which will help you to identify gaps in the skills needed for your new process.
As training – let alone hiring – people does not happen overnight, you undoubtedly understand the importance of considering this at a detailed level already during the (re)design phase, and to well estimate the time needed to obtain the skills required. And also the importance of involving process actors during the (re)design phase as well.
(Re)Consider the organisational structure
Process re-design might be a good opportunity to review the organisational structure. So, if you already pondered about self-managing teams, have a look if the (re)new(ed) processes enable this kind of organisational transformation. For more on this topic, have a look at this blog.
Communicate the changes
Make also sure that all persons involved in the (re)designed process know every change that is relevant to them. Including all aspects which are described further in this blog. I even ever made the mistake myself by (unconsciously) neglecting to inform some people about process changes. You may imagine the consequences…
Therefore, identify all possible persons who may be impacted and explain them what’s in it for them ; obviously before going live with the new process. Better too many people than to few.
Thus not only the process actors, though any possible stakeholder, including external customers, should be informed; certainly also all internal customers. This means all persons active in downstream processes as well ; or at least the process owners of those – who then can decide whom within his/her process should be informed.
2. Systems & tools
Another main element contributing to the right execution of business processes are the systems and tools. Not only the ‘hard’ or physical ones like machines, robots or more simple equipment ; but also the ‘soft’ ones, e.g. information systems, means of communication, etc.
Machines & equipment
Processes which transform physical – say material, tangible – objects, usually need machines or equipment to transform or to transport them.
Comparably to People, you will also need to assess and to fill the gaps between existing capabilities and the newly required ones, resulting from the (re)design. For newly designed processes, you will probably still have to acquire those, while for redesigned processes, some adaptations to existing machinery or equipment might be sufficient.
When these machines also need maintenance (which is most often the case), you better foresee these supporting activities as well; e.g. planning them in an overall maintenance plan.
Information systems
Similarly, you will need to review the need for capabilities – i.e. functionalities – of information systems. Here as well, it might be sufficient to adapt existing software, or there can be a need to acquire or to develop totally new ones.
And again, you better also foresee the supporting activities which will assure the reliability and the optimal use of these systems, e.g. helpdesk support, bug fixing, change requests, etc.
An overview of recent information technology, enabling a rather fast process implementation based on process models, like RPA (Robotic Process Automation), Process Engines, etc. will follow in a future blog, as this is a topic on its own. You will then also read which type of technology to use, depending on the nature of processes.
Information & Data
Most activities within a process need information or data to enable its execution. How could you process a sales order correctly without knowing which products, quantity, etc. a customer ordered? Particularly when you did not take the order yourself.
Indeed, next to the workflow, processes most often also include an information flow.
If you did not yet identify for each task the information / data needs, then you will really need to do it during the implementation, making sure that these data will be available at runtime. For each task, you should assess
- which data is needed as input, to enable its execution ; e.g. products and quantities for a sales order
- how the task will (possibly) transform the data or its attributes ; e.g. invoicing calculates the amount to be paid, based on data of the sales order.
- what data will result as an output, possibly needed for later tasks or even for another process ; e.g. the expected delivery date (as output) on a sales order is needed for the warehouse manager to know when to pick and to deliver the goods.
3. Process interfaces
A business process is not an isolated thing. Hence, after a process redesign you should be careful and make sure that upstream and downstream processes stay in-line with the redesigned one. Let alone the possibility that also these up- and downstream processes might be redesigned themselves, and thus could be subject to change as well.
Upstream interface – assure the input quality
The general rule in process land is that the downstream process (the one receiving the output of the upstream one) is considered as the client. Which means that it is up to the responsible (manager) for the downstream process to clearly communicate the expected quality criteria of the output to the one of the upstream process.
Hence, you should have explicitly communicated in details about the input(s) which your new process will need to function as designed. Thus about the expected outputs from upstream process(es). Even not only the quality criteria, but also delivery times (possibly takt times), the way of handing-over, etc.
Ideally, you may have written SLA’s during the (re)design phase. Also a topic that will be explained in a future blog.
Downstream interface – assure the output quality
From this perspective, your new process is “supplying” to the downstream process(es). Therefore, you should put anything in place to satisfy your direct client, which is the downstream process – or the final customer if your process is at the end of your organisation’s value chain.
Sorry to insist again… you should have involved your ‘customer’ in the process (re)design phase and you should have obtained the output expectations, i.e. the quality criteria. Because these contribute to your process (re)design, indeed.
You should also put the checks & balances in place to detect non-conformities as soon as possible within the process, to avoid any defect flowing downstream to your customer(s).
4. Procedures & business rules
Activities describe what should be done ; though for some activities, you may need to describe more in details how these activities should be executed, e.g. though procedures. Some tasks may even include specific business rules.
For new customers, for example, you may need to check their solvency before accepting or confirming the order, and so request risky customers to pay in advance. This is clearly a business rule (defined by your organisation’s policy).
Though you might also describe how to assess a new customers’ solvency, through a method or procedure to be followed. E.g. by analysing their balance sheet, or by contacting a credit rating agency, etc.
5. Test, simulate or validate the process before ‘go live’
The better you test – or simulate – the process before putting it into production, the lower the probability of meeting (negative) surprises. Even small process changes can bring critical business processes to a standstill, indeed.
In some industries – e.g. pharma – you really cannot use a process that has not be validated. Of course, other industries do not demand this level of safety, and applying such strict measures would then be a ‘waste’ ; though a minimum of testing will often save you money later on, by preventing costly surprises. When the process relies on information systems – which is most often the case these days -, you should at least test whether these work as required.
You may even involve an external customer while testing ; namely to assess whether the process outputs are as expected.
Critical success factors
Let’s now consider some critical factors which may impact the success of your process implementation.
Top level management involvement
Particularly for business processes crossing many organisational units, involvement by the top management is key. This is even more important in a hierarchical organisation, where many managers are responsible for only a part of the overall process.
The obvious reason is that the stake of the whole process must transcend the (narrower) stakes of smaller functional units. And therefore, the authority of the top management is then required to get the several managers’ noses pointing in the same direction.
Change management
With regards to the mental aspect of change, and referring to change management frameworks – like Kotter’s 8 steps model for change, or the ADKAR model, Rick Maurer’s tools, etc. – people will more easily accept to change when
- they understand the (urgency and importance of the) need for change
- what the impact will be on their own situation
- they are sure that they will be supported, e.g. being trained or coached, and will acquire the abilities to contribute to the required change.
Needless to stress the importance on the right communication to obtain the acceptance.
This also means that – even when they have mentally accepted the changes – people will obviously need support to change. So, if a machine or a software application will be used differently, people using those will need to be trained and possibly coached.
A lack of adequate training can severely jeopardise the change, even when people accepted the principle of changing the process and their individual way of working.
Alignment with the organisation’s vision & strategy
This is not only important for the fact that processes are an enabler – say the bridge – to realise an organisation’s vision and strategy.
Indeed, one of the strongest intrinsic motivators is giving sense to people’s work, by making their individual goals clear and how their personal goals are related to the organisation’s overall objectives.
Hence, by making the relations between individual and common goals explicit, you will certainly get even more buy-in and commitment for the (re)designed process. You will find more on how to do so in this blog.
To conclude
Mind that among above critical success factors you did not see “technology”. The main success of process (re)design and the corresponding implementation will very seldom be technology, indeed.
The most challenging to assure a successful (i.e. a swift and sustainable) process implementation is alignment ; thus to get all stakeholders on the same page, so to earn their acceptance. And this is something you better do before the implementation, i.e. during the (re)design.
Other said, process models resulting from the (re)design should
never be “just diagrams”. They should rather be the result of agreement – or at least acceptance – by the many stakeholders. You may call it common envisioning, as it is about mentally picturing a commonly accepted vision on how everyone should work to achieve objectives. And this sometimes requires lots of patience…
Do you have any question or wish to share your experience or opinion about business process implementation – or about any other BPM-related topic? Then please post them in below “Comment” box. Or take contact through this contact form.
P.S.: Please share this information with your Facebook friends and fans, LinkedIn contacts, Twitter followers and Google+ circles, through the share buttons below. Thank you!