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