My Week in BPM

I don't know how, but somehow I managed to get through this week, not because it was overly busy (it’s almost Christmas) but because I ran into a situation in which I almost did not know what to say anymore and for people that know me a little bit, this is quite rare.

Every once in a while you end up in a conversation where you are thoroughly confronted with the fact that you (and I mean everybody individually) assumes a lot things, you take a lot of things for granted while you have your conversations. You find yourself having a discussion with somebody (a client or a prospect or a friend) and based on one remark you suddenly realize that your assumptions going into the discussion where out of sync with reality.

The topic with which I had exactly this experience was #processmining and in and by itself this not amazing because I spend more than 50% of time talking about process mining. The way I normally build up this conversation is by explaining what I call the big picture (blog #5) where an organization’s strategy and operating model form the basis on which a process and system landscape is being defined and build. Then, once you have translated your processes into work instructions (or SOP’s) you arrive at the EXECUTION level (where it all has to happen).

Only then you can start to think about implementing more tools to either improve your execution capabilities (think about RPA or workflow automation) or to improve your understanding of the level of execution (task mining, IoT or process mining). And yes, all of these mentioned tools can be implemented in a stand-alone fashion, but to my opinion, this will leave you with stand-alone results. When looking for more structural or sustainable results (and thus also ROI), one would do good to consider embedding these tools into a wider process management practice.

So, there I was discussing this topic and all of sudden (I don’t even remember what triggered it) the bomb is dropped: “we don’t document our processes and don’t see the need to do it either”. Fortunately, the addition “but we could be wrong about that” was added rather quickly. My jaw just missed the edge of my desk and by the time I gathered my thoughts again, I decided that I would need to tackle that discussion in a different way. It started asking questions about how they dealt with improvement projects and more specifically the starting point for these projects and the efforts they deployed to make the improvement sustainable.

Soon, it became clear that one the main benefits of working according to process management principles is to reduce the number of time you have to re-invent the wheel!

Without process management (BPM) you often reinvent the wheel on…

• value stream mapping when starting a LSS DMAIC process
• finding out who needs to approve this change to our way of working
• what do we need to train/teach our new employees on?
• what activities are going to be audited because of ISO27K?
• how did we do on our first time right KPI this month?
• why are our business lines all executing this standard process differently?
• why did our RPA bot stop working (it worked last week….before we implemented this new feature on our ERP)?

And the list of course can go on and on. 

I am a true believer of the BPM approach, and even if you would be skeptical I still believe there is so much published evidence why a process centric way of working is beneficial for your organization.

So, if you want to implement process mining without doing process management, please go ahead, but don’t be surprised if your results are not sustainable in the long run because you are lacking the foundation on which to embed your mined results. 

Having said that… no more blogs for the next 2 weeks…I’ll be enjoying my Christmas holidays and will try not to open up my company laptop ;-)

Happy Holidays and see you in 2021!

Ciao, Caspar

“A beaten path does not mean it should not be followed”.

It goes without saying that the beaten path might not give you surprising results, but I would argue that implementing a business process management practice (or BPM practice) needs to be surprising. In fact, if done properly the rest of the organization basically should not even know that they have walked down the path of #BPM in the first place. This week I had some interesting conversations around the topic of executive sponsorship and BPM.

If we take a little trip down memory lane we come to the conclusion that traditionally BPM implementation very often started in cupboard underneath the stairs of the IT department, piggybacking on an ERP implementation project. Sometimes, the BPM practice survives the go live and aftermath of this ERP project and manages to build up its own right for existence. It started venturing out to other functional areas with the company, however still “only” focused on process documentation.

At a certain point, the BPM group has rooted in the organization and starts to grow in a upward direction and this of course attracts the attention of management (starting with middle management and senior management) and this attention is not always positive. When done right, BPM provides a level of transparency that is welcomed by continuous improvement teams and process owners that want to improve their process performance, but disliked by more traditional managers that apply the divide and conquer technique above anything else.

Another initiative that is often deployed (or tried) by BPM groups is to also go beyond just process documentation or process modeling (which I can only stimulate). Applications, risks, roles and regulatory frameworks are artifacts that are typically high on the list of being added to the already documented business process. The advantages of this are obvious to BPM enthusiasts, but less so to the business process owners that often speak a whole different language. Unfortunately we do not always R2D2 at our disposal to provide translations.

And this is where something undefined hits the fan. Sometimes, managers in those functional expertise domains (like risk management, IT, Auditing) are not necessarily thrilled by the prospect of having to change their way of working, because that is the underlying root cause of misery. People resist change if they can’t see passed their own internal hurdles. So, in order to win these people over, workshops are organized to explain what it would mean to switch from maintaining an excel file on SharePoint to maintaining your risk library (or application library, or regulatory framework library) in a BPM platform (let’s use ARIS10 as an example here).

If that doesn’t do the trick, a pilot is being conducted to bring some of the content over into the BPM platform so it does not remain hypothetical, but these experts can actually see how it would look like and what kind of activities are needed to maintain it (and all of the other wonderful benefits of maintaining this kind of information centrally and connected to the other enterprise artifacts such as processes, roles, applications etc).

Nevertheless, it often happens that some departments still continue to refuse the incorporation of their way of working into a process management practice and that is the moment where an executive sponsor proves very useful. By now, I realize this was quite a lengthy introduction to our executive sponsor, sorry for that.

Every major company-wide initiative or program has an executive sponsor, typically a managing board member or a member from the executive committee (that mostly also contains senior executives from different parts of the organization). However, BPM initiatives, because the typical way how they originate, do not have that luxury from the start. This means that an executive sponsor needs to be found and cultivated (unless you can find a true believer) and one of the main responsibilities of this executive sponsor is to make sure that senior management is aligned on the why and what of the BPM implementation.

Now, even though I am not a fan of pure top-down change management, I do realize that it is something that is of vital importance to any company wide initiative and BPM implementations are exactly that, a company wide program that finds its way into each and every tiny blood vessel of the organization in order to help them be more effective and efficient. Your executive sponsor is the pituitary gland that controls the hormone levels in his or her organization around the BPM topic.

So, in short:

• Can you start implementing BPM without an executive sponsor? Yes, you can
• Do you need an executive sponsor in order to reach BPM maturity? Yes, you do

Having said that, please do enjoy your weekends and see you next week..

Ciao, Caspar

The first milestone, number episode 10 is already here and this weeks topics evolves around the difficult question whether an organization needs to change it processes or organization to suit the application(s) or the other way around. Buckle up, because this will be a bumpy road….

My earliest memories to this dilemma dates back to my university days. I was making my way through my masters degree on Industrial Engineering & Management Science at the University of Technology in Eindhoven (NL) and we had this course called Goederenstroombeheersing in Dutch (materials movement control in English) and during this course we had to draft and calculate MRP (material requirements planning) tables by hand just to learn the complexities that are involved in planning and streamlining material movements (mostly found in manufacturing environments). Needless to say that this course was one tough cookie. 

A part of this course was a guest lecture by a guy from SAP (we all know SAP, right?) and his central theory was that organizations needed to align the way they worked with the way SAP was configured. My instinct reaction then (1998 to be precise and for cultural reference) was: nonsense, you never ever adapt your organization to your application. That’s entirely the wrong way around. What are they thinking, etc etc.. you probably understand my emotion at that time. 

Fast forward 10 years, and I find myself working at a large Dutch manufacturer and in the middle of auditing SAP implementation projects at our business groups. It was during these audits that I had many conversations with consultants, subject matter experts and managers in which this very topic would pop up time and time again. The level of customization in SAP reached such high levels that it was hardly maintainable anymore and the reason for this customization was the belief that the application should fit the process/organization. This also meant that I had to start re-evaluating my own position on this and came to the conclusion that in many cases SAP had already thought long and hard about the way some processes should be executed and used that to configure their standard SAP system. In other words, it didn’t seem like a stupid idea anymore to change the way you work to suit the use of a standardized application. 

Fast forward another 10 years and here I am now working with a lot of different organizations on the wonderful subject of business process management and one of the questions I very often discuss with my customers or prospects is: are all processes equal? Surprise, surprise but the answer is: NO, they are not. First of all, the most often used differentiator for process classification is: management, core and support processes. Management processes deal with the strategic part of being in business (why are we here, what battles do we want to win in the marketplace, how will we organize ourselves to reach out strategic objectives) and to be frank, are pretty much the same for most of the companies out there. Yes, there are of course subtle differences between industries and start up by default think they are different, but in the big picture management processes are quite standard. Core processes are a more difficult category since this is much more hybrid in nature. The real core processes (sometimes called differentiating processes) are very specific to the different type of business that you are, think about your R&D, Product Innovation, Manufacturing or Service Delivery. Nevertheless, there are a group of processes that are often positioned as core processes but a much more generic in nature. You can think about order to cash and plant maintenance to name two. Take for example Plant Maintenance, yes, specific pieces of equipment have very specific ways to be maintained properly, but the process of identifying, scheduling and administrating this process is the very same for all pieces of equipment in your production facility. At least, there is no reason why it shouldn't be the same. That's what I mean with a hybrid model. Finally, the Support processes are those processes you need to do, but will give you no competitive advantage what so ever. You need to do legal, HR, finance, indirect procurement and IT but it will very unlikely that any of these processes have a significant impact on your competitive proposition. 

Now, bringing this back to the main question of whether you need to adjust your way of working to your supporting application or the other way around. You can imagine that this is closely linked to the topic of process classification. For management and support processes (and very strongly for this latter category) my personal opinion is to stick to standards and standard applications. Take it from me, your indirect procurement processes, your finance and control processes are not different compared to pretty much anybody else's so why waste time and money on customizing a standard product and run into problems with the very first upgrade or significant process and/or application change. For the core processes (the differentiating ones) the situation is much more subtle. Given the nature of these processes a thorough investigation whether standard application would match with the way these departments want to do their work could be very well warranted, but also here I would still argue that it would pay to push such departments as hard as possible to at least consider the situation to change the way of working to match an application that is intended to be used instead of blindly customize the application. 

There you have it... now let the commenting start so we can have some good conversations...

Needless to say, that if you want to manage your business processes properly, a decent #BPM platform certainly helps, also with keeping track of your application portfolio...

Enjoy your weekends!

Ciao, Caspar