The end of the month is drawing near and so does my monthly blog series on the topic of implementing #BPM. I’ve already shared my thoughts around the scoping, planning and communication challenges of BPM projects and this week I will close down this month’s topic by discussing one of the biggest challenges: the embedding of BPM in the organization.

Imagine, you have been working really hard for the past period of time, implementing the various aspects of the BPM philosophy. You have installed your BPM platform, have been loading it up with relevant content (processes, applications, risks, policies, work instructions etc), training people, figuring out what kind of reporting everybody wants to look at and you’re approaching the point in the project where you are getting your first glimpse of what could be described as the finish line. I’m being very careful in my wording, since a true BPM implementation never finishes, really.

Nevertheless, you will need to prepare for the hand over of the project related activities into a more structural anchoring in the organization. In other words, how do you embed BPM in your organization and to be very clear, this is not something you should start to think about at the moment that you think the project is nearly done. Au contrair, the French would say, this topic already needs to be top of mind from the very start because everything that you do during the project, is going to be geared towards embedding it in the organization. Maybe not as dense as this mesh wiring in the picture below, but something similar…

Your process governance? Yes, you need to establish that early on in the project and yes, the people making up the governance body might not be the same in the final anchoring, but you do need to think about the formation of the governance group at the start to ensure that a transition into a more sustainable set up is at least possible and you don’t have to start all over again in finding the right owners for your processes.

Your process documentation? During the first phases of the BPM implementation this is very often focused on creating as much as content as you can, documenting every little step and activity and structuring it along side the lines of the implementation project. However, come the time that pretty much all of your content is in and the project team is almost discharged, and you still need to start thinking about how to keep the content relevant and up to date, then I can assure you that you are a tat bit late with that. Preparing the management of change of the content in your BPM platform should begin right after the technical installation of the platform. From the first moment that you start to add content, you need to have a management of change process in place. Yes, the responsibility for the execution of this process might be with the project team at first, this will have to transfer into the business after go-live. I can’t stress this enough, the management of change process is your life-line for embedding BPM into the running organization.

Based on our @SoftwareAG collective experience of implementing BPM  (and also my personal hands-on experience) there are 3 main lessons to be learned:

1.  For a BPM group to be most effective, they need to report directly into the executive level (C or C-1)
2. This group needs a diverse set of skills (not just BPM related, but also project management, Enterprise Architecture, business analytics)
3. Connect and integrate BPM practices into the daily, weekly, monthly, quarterly or annual management review activities

I will not go into details on these lessons as most of them should be very straight-forward as to why they are on the list. Should you, however, want to discuss these (and more) anyway, feel free to reach out to me. 

Having said that, enjoy your weekends!

Ciao, Caspar