My Week in BPM

The last couple of weeks I’ve shared my thoughts and ideas around some of the aspects of a BPM Center of Excellence, being the position in the organization, the mandate it should have and the structure and role a CoE can have. In this week’s episode (and the last one on the CoE) I look into the types of services you should be able to expect from this CoE. One thing I can already disclose: it goes way beyond documenting business processes.

Allow e start with repeating myself (again, I know) in stating that process documentation is a very important part of any BPM journey in an organization, but it is not the only part. It’s a fundamental activity that needs to take place in order to unlock all of the value-adding additional services a BPM CoE can deliver. In short, BPM is much more than just process modeling. Now that we got that out of the way, let’s take a look at these services that I am mentioning above.

First of all, I identify 4 major services a BPM CoE can/should deliver:

1. BPM Definition and Governance
2. BPM Content Management
3. BPM Enablement
4. BPM Supporting Activities

Let’s take a look at each one of them separately.

BPM Definition and Governance

This service is the first service to be set up in case BPM actually is going to be organized into a CoE. Very often the second service (BPM Content Management) might be already up and running. In this service, the CoE needs to come up with a definition of the process architecture (or hierarchy), the process governance, the BPM KPI framework and the corresponding business rules on how to deal with BPM. A lot of this can be seen as relatively one-off activities that lay the foundation upon which the actual content can be build. Without this fundamental work, it is not hard to understand why BPM initiatives that start right away with creating content, struggle later on to anchor the labor of their work in the standing organization.

BPM Content Management

As mentioned earlier this category of BPM services is typically the first one to be deployed and implemented, and in and by itself that is absolutely fine as long as the organization understands that it is the first category of services that need to be taken care of properly before BPM can grow and become sustainable. As for the sub-services in this category, think about defining and managing the modeling methods and conventions, the process model repository and the management of reference models/frameworks. Especially this last one is becoming more and more popular I would say and maybe not for obvious reasons. Yes, frameworks like APQC, Deloitte’s Industry Print and some more were already quite popular back in the mid 90’s early 00’s, but the type of reference frameworks that have joined this list are the regulatory frameworks. Think about the ISO / NEN / BS etc norms that organizations need to comply to. Why not add them to your process repository and connect them directly to those processes that play a role in complying to these frameworks. This brings substantial clarity to organizations when it comes to understanding how a certain regulatory framework impacts the way they operate (I might dedicate a special blog to this topic).

BPM Enablement

This is one of the most important services a BPM CoE should deliver: making sure that the rest of the organization warms up to the concept of business process management (just to re-iterate: this is much more than just some process mapping exercises). When this is done right, the BPM CoE can continue to be relatively small group with a disproportional high positive impact on the rest of the organization. In this service you will find things like finding the right internal champions and ambassadors to promote and stimulate BPM, having one or two experiences facilitators / change agents to support the mental transition process for senior managers from silo and kingdom thinking to collaborative end-to-end thinking. If I look at all of the consulting I do with our prospects and customers, the majority of my time goes right into this category, helping them understand how to inspire the rest of the organization for BPM.

BPM Support Activities

Finally, the fourth category of activities deals with all kinds of support activities for related but slightly distinct topics. Think about the support for process and task mining, enterprise risk management, automation projects or the general support BPM can bring to Continuous Improvement programs. This range of activities can become very extensive (depending on the success BPM has within the organization) and one typical pitfall to avoid is that the time claim based on these activities can become very high very quickly and you would become the victim of your own success. The key deliverables for a BPM CoE are in the other 3 categories first. Don’t get me wrong, the activities in this category are important but from a resource management point of view, first you make sure you can deliver on your core services and if time permits the support activities can be picked up. If you then find out that you’re structurally running out of time, you might need to expand your CoE of course (even if it is temporary).

In short, a BPM CoE is much more than just a process mapping factory and they can and will deliver added value to the organization if they succeed in inspiring this organization for the wonderful concept that is called BPM.

That’s it for this series of blogs on the BPM CoE. Next week I’ll start a new series on the topic of compliance management.

Ciao, Caspar

In the previous two blogs I shared my thoughts on the mandate and the position in the organization of the BPM CoE and this week I will add the various roles that play a part here. A center of excellence can only function properly (like any organizational entity in fact) when the right people are assigned to the proper roles. This means that I will touch upon two aspects in this week’s blog: (1) what roles would that be, and (2) what type of person would you like to see in this role.

So, let’s get started with the roles and to make things easier I’ve added a simple visual. First of all, let’s explain the coloring a bit. The green box is either the group the BPM CoE reports into or is part of (this very often is a Transformation Office nowadays) or the Executive Leadership position the BPM CoE reports into. The purple boxes indicate the core roles in the BPM CoE. The red one (the communications professional in my picture) is a role that is often contracted to be part of the CoE on a temporary or part-time basis. The dark grey boxes (Business Process Architects) can best be described as some form of luxury. If you do have the budget to include these roles in to the CoE, be sure to add them. if not, these roles will most probably then exist in the business itself. The light grey boxes indicate the Process Owners group throughout the business.

Now, let’s take a look at the roles themselves. Just to make sure we’re on the same page not all of these roles are full time roles. It depends on the scope, size and maturity of the organization and this is always a bespoke configuration.

Head of BPM: this is the major champion in the organization for the BPM topic. Preferably a seasoned professional who has done this before in another company or industry. Somebody who understands that implementing BPM will be made or broken by the commitment the Head of BPM can secure from the executive sponsors. This role does have a rather large portion of salesmanship as, unfortunately, it does require a lot of internal selling due to the simple fact that a lot of business line professionals are not able or don’t want to see the bigger picture on BPM (it first takes effort before you reap the benefits, then again, this is a not a strange concept in business, is it?). Summarizing: a seasoned professional who can sell a Alfa Romeo 8C to Valteri Bottas or think about Leonardo di Caprio in movies like Catch me if you can or the Wolf of Wallstreet.

Methodology Expert: This is a person with actual modeling and documentation experience and understands what is needed to support the organization with a set of decisions and agreements on how  to document the business processes to such an extent that it is both rich enough to capture the complexity of the business processes as well as not to complicated to get lost in the forest of rules and regulations for modeling a process. The balance between simple and capable of capturing complexity is the main challenge for this role. This expertise could be (and often is) contracted from the supplier that delivers the BPM platform or from an external consultant with experience. Once the method, conventions and filters are defined this role is often combined with the System Administrator.

Trainer: As the name kind of gives it away, this role makes sure that there are sufficient people in the organization that are trained in making valuable contributions to the process repository. I am not talking about the end users consuming the information as most BPM platforms are so intuitively easy to use nowadays, you can suffice with self-paced, video-lead explanations for those type of users. No, I am talking about the modelers and this also touches a fundamental discussion you will have at one point sooner or later: will we stick with a limited number of expert modelers or will we try to train as much modelers throughout the company as we can. Again, here the most cutting edge BPM platforms help you make that judgement call. Nowadays, these platforms distinguish between different type of modelers: the real modelers who can document a process from scratch (you only need a few of those), the subject matter experts who are able to make simple edits to processes (you probably have a few more of them) or the contributors that basically only make textual additions, corrections or removals based on their experiences (and there’s plenty of those). In the end of the day, you need a trainer to either train modelers, or create self-paced training content for editors and contributors.

System Administrator: this is a crucial role to be honest because this is the role that keeps your BPM platform in optima forma. Even in the era of cloud platforms, you still need to be on top of the content and the configuration of your BPM toolbox. One of the major benefits of a BPM platform over documenting your processes in PowerPoint or Visio is the re-usability of objects (such as activities, roles, applications, risks etc). However, in due time and because of the sheer size of the process repository, you will have duplicates of objects in your database. If you want to keep things as easy as possible for the end-users (meaning: if they are modeling or editing and they want to add an application that’s already present in the repository, you want them to have only one choice in the pop-up screen and not 2,3 or even more). So, keeping the repository lean and mean is the name of the game for the system admin. This role typically also deals with new custom made reports, queries or other analyses to be set up in the BPM platform. This is also the reason why the Methodology Expert role is often combined with this role. Here, you’re looking basically for McGiver (a jack of all trades) with a lot of patience.

Management Assistant:  last, but certainly not least the management assistant or PA to the Head of BPM. As we already established, the Head of BPM ideally is a salesman and we all know (and I know from personal experience) that sales people do not like administration and can come across a slightly chaotic from time to time. Implementing BPM however is a hefty program for which you need somebody who can make sure that progress is continually being made in supporting the CoE with structure and stability.

There you have it, the BPM CoE dreamteam! Seriously, the point I’m trying to get across is that there are several different roles that all play a crucial part and that you need to make sure that you put the right person in the right place for it to be successful. Next week, in the last blog on the BPM CoE I’ll zoom in a bit more on the most common things a CoE does on an average day/week/month.

Ciao, Caspar

In the previous and first episode on the BPM Center of Excellence I shared my insights on the formation and positioning of this CoE and briefly touched upon the mission it could or should pursue. One of the most important requirements for a BPM CoE is the fact that it reports sufficiently high into the organization it is supporting. This means that if the CoE aims to support the entire organization, it should report into C- or C-1 level.

Another important aspect of the center of excellence is the mandate it is tasked with fulfilling and generally speaking a BPM CoE will have the request to implement the philosophy of process management throughout the organization, with all of its facets included, such as process governance, maintenance, optimization and documentation. The consequence of such a wide mandate is that the impact of the actions of the CoE potentially need to be experienced in all the nooks and crannies of the organization. This also means that the required expertise that needs to be available in the CoE needs to be sufficient to be able to make this impact a reality.

In some cases, organizations understand these implications and embed the BPM CoE into a larger group, very often called the Transformation Office. The reason for this being that one of the key ingredients of a successful transformation is the adoption of the new way of working throughout the organization and this adoption is very much depending on the accessibility and consumability of the documented way of working (be it in the form of process maps, work instructions, strategy descriptions, customer journey maps or anything else related to the way the workforce executes its tasks). Other specialties in the Transformation Office, besides BPM, typically are PMO (project management), EA (Enterprise Architecture) and Change Management. Together they form a very strong capability that is able to define, support, implement and embed any kind of transformation.

From this point of view, it’s not a stretch to understand that a group with such far-reaching responsibilities and consequences also needs a hefty mandate in order to be able to execute on it. The last thing you want is that this Transformation Office has to go to the C-level executives for every little decision they need to take.

Although this blog is a rather short one this time around, the message I try to bring across is equally short: if you’re serious about implementing BPM, make sure you give the BPM CoE the corresponding and required mandate for it!

More on the BPM CoE next week.

Ciao, Caspar

The last couple of weeks I delved into the wonderful topic of Management of Change and how organization can look at that. One of the things I described is that there needs to be sufficient mandate for the entity within the organization that is working on this process (you can find this here) and this brings me to the topic I will be focusing on this month: the BPM Center of Excellence. Although this group can bear many names, for example: BPM, Process Management group or Process Excellence group. It can also be part of a larger group that focuses more on business transformation. In this first episode of this months series I will focus on the position of this group. 

Due to the nature of the business process being the central vehicle to connect virtually all business artefacts such as applications, risks, activities, roles and other input-output converting aspects, it can be deduced without too much effort that any group that seeks to manage this jungle of dependencies should also be located in a central position. Allow me to explain this. 

If we look back into the history of managing business processes and business applications, we have seen a trend that both topics predominantly had their own lives and developments through the organization. The business application side pretty much started in the CIO function and stayed there and in most cases still resides there to be honest. The business process side has had a bit more rocky route, that very often also started in the IT function, very often as a supporting act for ERP implementations, and in many cases transferred to Quality Management in the time that the ISO 9001 norm became widely popular and later also started to be embraced by the likes of risk and audit management and finally as a separate group anywhere in the organization. 

For many organizations it has been quite a challenge to position the BPM activities in the best possible spot, first and foremost because most organization do not have the slightest idea of what the best possible spot actually is. A paragraph or two above I already dropped a major hint on where I believe a BPM group should reside within an organization: as a central group, reporting into C- or C-1 level. It does not need to be a separate group, it can be part of a larger group (for example a Transformation Office as we have seen with a number of our customers) as long as it is centrally located and reporting sufficiently high into the executive management. Let's pick apart some of these aspects and explain a bit why I define them the way I do. 

However, before I go there, I need to clarify one thing. When I speak about the best possible spot, I do mean the ultimate location where the BPM group should reside once the BPM mindset has been adopted within the organization. This does not mean that when you form such a group for the first time, it should be directly in that organizational location. There is no problem whatsoever if this group starts somewhere else (typically a couple of reporting steps down the ladder, reporting into either IT or Finance or business operations) and slowly works its way into the ideal location. Nevertheless, at the moment that you have reached a certain maturity with BPM, you better be in the right spot, if you want to make it sustainable. Got it? Good, now let's continue...

Let's start by looking at the central aspect. BPM, by nature, is a management discipline that covers all functional domains within an organization. It spans the entire organization from a process point of view, and therefore does not lend itself well to be "owned" by any one functional domain. The same applies to domains like HR, Legal and Auditing, these are independant from the core business and related functional domains and are often (part of) a corporate department. Back in the glory days of BPM in my previous company, the BPM group (known as Process & Advisory Services) belonged to the so-called Expert Center (also containing Legal, IP and Large Capital Projects) and this was exactly the right place to be. Later, this department was dismantled and the BPM group moved to the Global Business Services (read: shared services and IT) and to be frank, that was the beginning of the end. So, in short, it is vital for a BPM group to be located in a central type of department, detached from the day-to-day business. At least, if you expect it to thrive. 

The other aspect is the reporting level of such a group. I stated that it should report in to C-level or C-1 level and the reason for that is also quite simple. BPM facilitates and generates such a level of transparency that not all business leaders know exactly how to appreciate and as a result will try to rebel against it. If you BPM group is reporting into C-4, there simply is not enough support to stand up to a C-1 or C-2 business leader that has it out for BPM, for whatever reason. If you remember one of my previous blogs on Management of Change, this exact same phenomenon was discussed and it applies here as well. There will be turmoil and you need a corporate heavy-weight to have your back, because most of the added value from BPM is indirect in nature and thus sometimes difficult to grasp for business leaders that, logically, often have a short term focus (next quarter, next 2 quarters but not longer). 

Alright, we established that a BPM group can be separate or part of larger Transformation Office and it should be on a corporate (central) level and report into C- or C-1 level. That's not too difficult, is it? Oh yes, before I forget, a BPM group should (in the end) never belong to IT! Trust me, I have nothing against IT (they have a very tough job to do as it is) but the focus of IT is simply too narrow for BPM to prosper in. We have seen this time and time again at our customers. If you expect a BPM group to be successful, make sure it is a independent group, or have it report into the CFO or COO column. 

That's it for this week, next week I'll be looking at the roles that you need to form a BPM group in the first place. 

Ciao, Caspar
 

In my last three episodes I shared my thoughts on the topic of Management of Change, or MoC in short and I argued that this is one of the most underrated business processes out there. It’s almost regarded as necessary evil, while in fact, it is one of those processes that actually enhances your business agility. Do you want to effectively implement a new business model / product / service? You can rest assured that changes will be needed to your processes, applications and more. If your MoC process then takes very long and is not first time right, you’ll loose valuable time to market for your new business model / product / service. It’s that simple.

Anyway, the MoC process is not a stand alone process, it is the central hub in an ecosystem that has links to many aspects of any organization. Let’s see what we explore together!

First of all, there is a link to the Incident Management process and supporting application. Every organization experiences hick ups and incidents. Failed security patch updates, missing implementations for new mandatory legal requirements, spooky application behavior, we’ve all seen it happen. These events often trigger an incident management process (often supported by tools such as Remedy, Jira or ServiceNow) and this process is also often run by the IT department. You can imagine that at the moment such an incident is being handled it is likely that there will be consequences in more ways than just the application that is acting up and the proposed solution to the incident may have an impact on the related procedures, processes or even on other applications. This interdependency between the various components of your organization, in the event of a change (the solution to an incident can come in the form and shape of a change request), can cause some havoc if not handled appropriately.

Another example I particularly like is the act of setting up a shared service center. This should always go hand in hand with some rigorous standardization, harmonization and, centralization. New roles will be created, new business processes are developed, other existing ones are discontinued and all of this is having a profound impact on the documented business processes. A new role means new authorization profiles, new SOP’s or work instructions, new interaction with other roles and much more. All of this has to be integrated with your existing process documentation to make sure that whatever technically needs to happen to set up your shared service department is in line with the way of working as described above.

A third and final example for this week is the link between the MoC process and the so-called development groups in the organization (the ones that make the application changes, DevOps, development streets, whatever you want to call them). During the MoC process, after you have successfully managed the impact analysis, high level design and approval for it, there will come a moment that the detailed solution design will have to be actually built. This typically is a handover moment between a process oriented group and the IT application experts group. Now imagine that this development group is located somewhere far away (let’s say India, just randomly). This physical separation leads to the consequence that the specification of the solution design (as fabricated during the MoC process) needs to be first time right and unambiguous. This also is the reason why the different levels of testing in the MoC process (unit testing, integration testing and user acceptance testing) is really, really important.

Summarizing, I can argue that the MoC process is the glue to connects the business world (with ever changing environments and requirements), the IT world (with the continuous stream of incidents, changes and patches) and the process management world (trying to consolidate it all) and if this process is not functioning optimally, you will pay the proverbial penalty in a reduction of business agility.

So much on the MoC process for now (I can talk about this for days if needed), as of next week I will sharing my thoughts on business continuity management and it’s link to BPM.

Ciao, Caspar

Last week I shared my thoughts on why consolidation of the various management of change processes in your company (check here if you missed it) is a necessary step for success in MoC and as the scope of this process increases also the pressure and the number of attempts to influence or by-pass it will increase. Let’s elaborate on that for a little bit, shall we?

Let’s assume that you have successfully consolidated the MoC processes for process and application changes (let’s not get over-ambitious) and we have gradually extended the scope of the organizational entities of our company. In others words, we’re now responsible for the execution of changes on processes and applications for pretty much the entire company. If the size of company is significant, you can also rest assured that the number of change request will be significant. The more people that work with processes and applications and the more countries you’re active in, the more requirements for change will be created. That is not rocket science, but simply a fact of life. Another undeniable fact is that human beings always think that their change request is more important that those submitted by the colleagues. There is always a very pressing reason or compelling event that makes them think that the execution of their change request deserves priority over others, and truth be told sometimes they are right, but mostly they're not. From time to time there will be a change request that is so important or urgent that it does need to be prioritized over already existing change requests. This could be because of a legislative nature (you need to comply to the requirements of SOX-xx (I lost track of count on that financial framework) before the end of the year, or to the requirements of the Corporate Reform in the UK early 2022, just to name two. 

You could plot the importance / priority of a change request easily on a normal distribution graph, the vast majority is all the same (let's say everything between plus or minus 3 standard deviations, but some of them (outside the plus 3 standard deviations) just mess up your change request processing schedule because of legitimate reasons. The major challenge with the MoC process is to be able to distinguish between the legitimate priorities and the wishfull thinking priorities, and in order to do this you either need to be quite seasoned and steadfast or you need to have a senior executive overseeing the MoC process and decide on these priority requests. No matter how you look at it, your capabilities to judge, decide and withstand these requests will make or break your MoC process. 

In order to be able to withstand these numerous requests there is one thing that needs to be firmly in place: a sturdy and just governance framework for your management of change process. This framework consists out of a number of components, but two of the most important ones are:
1. The mandate
2. The RACI on the MoC process

To start with the first one, the mandate. At the moment that you decide to implement a more central MoC process, the first thing that needs to be taken care of is a definition of the MoC mandate and this mandate puts the responsibility and accountability in the hands of the group of people executing the MoC process, including a senior executive that has the ultimate ownership of this process. Let's assume that your organization has a central process management group (sometimes called a BPM CoE or process excellence group) that executes the MoC process. The leader of this group has the over-all R(esponsibility) for the MoC process, and his/her manager would have the over-all A(ccountability) for this process. The "A" needs to be sufficiently ranked with the organization in order to have sometimes difficult discussions with business line/unit leaders in case of escalations. This "A" needs to have the mandate to accept or reject the prioritization requests coming from the business executives. If this is not the case, the MoC group will become nothing more than an execution group with increasingly faster changing priorities, driving them barking mad and virtually no change requests will be fininshed and delivered on time. This is of course not something you wish to see. 

If you look at the picture below you will see why the mandate matters. In traditional set ups very often the MoC responsibility is tucked away deep in the CIO column. At the moment that a business unit wants to dispute the priorities or a change request coming from another BU or even Corporate departement, they will escalate ultimately and the level of escalation (I always look at two levels up in the org chart) simply is not an equal match in that case. A BU Director is much more powerful compare to for example a Head of IT Delivery. At the moment that the MoC process is part of a Corporate BPM group, this escalation game becomes much more of a level playing field, increasing the likelihood that the MoC process is constantly overruled. 

So, summarizing for this week, if you want to engage in centralizing your MoC process (over the different types of changes and/or over the organizational axis) please be sure to anchor it at a sufficiently high level in the organization and give the MoC group the mandate they need to do their work. That way they can make sure that all submitted change requests will be executed in the proper order, at the proper time and without the unexpected consequences that are unfortunately characteristic for large organizations. 

Ciao, Caspar

First of all, welcome back from the holiday season. As you may have noticed I too took a little break from work (and also from blogging) to recharge not just the batteries of my EV, but also of myself and last week marked the restart of my professional activities, much to my delight. In my last blog (and the first one on Management of Change) I mentioned once or twice that the MoC process perhaps is the most underrated process in organizations. Everyone knows it’s important, nobody wants to put a lot of effort into it and we all know by now that this is a recipe for failure.

This week I would like to make an argument for consolidation in the MoC landscape and that this consolidation will unleash unparalleled levels of business agility. This may sound a little bit over the top, but in essence I believe it does.

First of all, what kind of consolidation are we talking about? Many companies around the world (I could even say: the majority) are executing parallel management of change processes: one for their IT application changes, one or more for the process changes, another for the corporate requirements changes and yet another one for legal or compliance changes. As you can imagine, when you start making changes to for example applications, there is quite a high likelihood that these changes also have an impact on business processes, just to name one, and vice versa. This is, of course, not always the case. You can think of numerous changes that you can make to applications that have no effect on anything else, right?

Read that last sentence again a little bit slower…. if a change has no effect whatsoever on anything else…. why are you changing it then? Nowadays, organizations are so heavily intertwined from an IT and way of working point of view, that virtually everything is connected to everything else. Let’s put that to the test, shall we?

Have you ever been involved in or heard of a situation where a company made changes to one part of their ERP system and right after the go live of that change, all of a sudden other people start complaining about things not working anymore? [prediction mode on] you’re now going like: hmmm, right, yes, how could I have forgotten that [prediction mode off]…

Seriously, business processes, applications, compliance requirements and risks are becoming more and more intertwined and interdependent and this results in a requirement for the management of change process to become more consolidated and more central. No, this does not mean that the execution of the various changes need to be consolidated too, but it does mean that before you start developing the solutions to the change requests, you need to perform a consolidated / central impact analysis on all of the various parts that make up your organization.

I’ve had the pleasure of restructuring and optimizing the MoC process of the company I worked for about 5-6 years ago. The IT changes were done by Corporate ICT, the process changes were done all over the place (but later in a centralized BPM team) and the average time it took from inception to production was about 9 months, which is a long time and does not help your ability to respond to external changes quickly (and this happens to be a core part of the definition of agility). One of the first things we did was to draft a MoC process that would treat all types of changes the same, it didn’t matter if it was an IT change (with an emphasis on SAP changes at first) or a process related change. At the moment the change request was delivered in the ticketing system we already used for that, the change was categorized and assigned to the proper central subject matter expert (SME). This SME subsequently had 48 hours to get together a cross-functional team to perform an  Impact Analysis. In this cross functional team you would always find at least the following roles:

• The Change requester
• The Relevant SME
• A Finance SME (almost everything you do in a business process results in a financial transaction in some shape or form)
• A risk & control SME
• The relevant application SME

This way, during the impact analysis, the change request was assessed based on all the possible angles and requirements and if it was approved, we were reasonable certain that the further design, build, test and deliver to production would not result in any unexpected effects. This was also, by far, the most difficult step to implement, after all, the build, test & deliver steps were already in place from some time in the various departments. 

This new way of working resulted in less interruptions and more effective roll outs of changes. It also reduced the cycle time for a change request but not yet spectacularly, however, based on the new normal for the MoC process the organization grew more confident and after about 8-12 months it was decided to switch from a fixed interval of change delivery to the SAP systems to continuous delivery. The change could not have been done with the central and consolidated start of the MoC process, the main reason being that we were now able to gauge the change requests on their potential cross-functional impact before we started developing. The result in the end was that our average cycle time for processing a change request dropped from 9 months to 3 weeks. 

The food for thought I would like to leave you with for this week is to evaluate the way your process change requests for business processes, applications, requirements etc and try to consolidate at least the first steps of the MoC process into a single way of working. Your business stakeholders will thank you for that. 

Talk to you all next week.

Ciao, Caspar

The last couple of weeks and months I have been sharing my thoughts on various topics, such as risk management, process mining, process documentation (or modeling if you insist) and during the summer I will spend some time on perhaps the most underrated processes of all: management of change. To make sure that we are all aligned on the jargon before I go into any kind of details. There’s Change Management and Management of Change. The first one is often used to define the human side of change (or sometimes called the “soft" side of change, remarkably enough getting people to change is much harder than changing a system, but anyway) while Management of Change (or in short MoC) deals predominantly with executing changes in processes and application. Just to be perfectly clear on this: YOU NEED BOTH. They are the Yin and the Yang of organizational change as a whole. Two sides of the same coin, two birds of a feather… I think you get my point…

Now, why is it that I believe the MoC process is perhaps the most underrated process? Well, human beings are typically easily motivated by new things: a new piece of machinery, a new project, a new journey etc. Maintaining what’s already there is much less exciting and hence we tend to get bored with it really quick. Fortunately there are people in the world who actually like that, who take pride in making sure that your process repository and application landscape remains in the best possible shape. One of the reason why they do, is that these people understand that if you do not upkeep your process and application repository, it simply will be outdated again in about 6 months and considerable effort has to be invested (again) in updating your processes and application documentation.

Another topic that might warrant a few words is that you will always see and hear me talk about process AND application changes and I do that for a very specific reason. Besides that fact that it is recommendable to have and execute a MoC process, it's also recommendable that you always include both the process view as well as the application view for each change, not matter how trivial the change might look like. This way you can secure two of the most important goals for a successful BPM implementation:

1. Keeping everything up to date
2. Keeping everything aligned

I believe the first goal is quite self-explanatory. Whenever you document something you can't expect that this will remain up to date until the end of days. The world changes constantly and this applies also to also to your processes and your applications. Fiscal, legal or functional changes, security updates, end of life replacement of applications, this all plays a role in the required effort to keep you processes and applications up to date. 

The second goal, keeping everything aligned perhaps is even more important. You can imagine that in larger organization the number of implemented processes and the number of implemented application can be dauntingly high and that there exist a vast amount of interdependencies between the information captured in the processes and the capabilities that are provided via the applications. At the moment that you are looking into a requested change, it then becomes vital to consider not just the directly impacted process, but also the rest of the process and application collection. Should you ignore this, the likelihood of unintended consequences increases exponentially. If you ever have been part of a large ERP implementation project, you immediately know what I mean. Changing something in one module (without looking at the dependencies) can result in unexpected system behavior in an entirely different module. 

So, knowing this, I would argue that a consolidated MoC process helps organizations to remain aligned, up to date and in control of the everchanging environment that is called: business. More about this process in the couple of weeks. As I will be enjoying some vacation in the meanwhile this series might run a little longer than normal, but I am not sorry at all for that. 

Enjoy your summer holidays!

Ciao, Caspar

In the last three episodes of my BPM blog I shared my thoughts around the noble activity called process documentation, or sometimes referred to as process modeling. And as I mentioned earlier, this is specific activity is suffering from a bad reputation as being outdated, unnecessary and more. I hope that with the previous three and today’s blog I have swayed your mind a bit to not just understanding that process documentation is important (it’s critical, if you ask me) but also that it can bring much more added value to an organization (think about the transparency and connectedness of all documented organizational artifacts). 

In this last episode around process documentation I would like to visit the topic of organizing the governance. Who is responsible for what and why? Of course, this relates to the way that you have organized your modeling efforts (see episode 34 - organizing your modeling), but let’s assume that you have picked the hybrid form of documenting processes with a limited number of central modelers and a larger number of local modelers, but these local modelers only draft the outline of the process, reuse as much objects as possible and the central modelers safeguard the compliance to the method and conventions (and maybe some aesthetic finetuning). This variant defines who is doing what, but it does not define who is approving and reviewing what, does it?

This is, I think, the core essence of governance. Besides the way of working that ensures that things actually get done, you also need a parallel universe that looks over their shoulders (not during the activities of course, I hate micro-management, it’s the death trap for creativity) at the moment that important steps are done so the result can be validated, reviewed and if necessary, approved (or not). My son is a huge fan of rollercoasters and there is a nice analogy to be found. Imagine you’re about to embark on a rollercoaster, the train comes into the station, the people that just completed the ride get out of the trains and your gate opens up. You scurry into your seat in the train, make yourself as less uncomfortable as you can and you apply all the available safety measures (straps, bars, whatever). Before you can go, two things will always (at least I hope) happen. First of all, there will be parc staff to physically check if you applied the safety measures properly (is everything secured and all) and subsequently a second person (typically sitting up high in a booth and controlling the rollercoaster) is looking for confirmation from the parc staff who performed the physical check and if received, will set the train in motion. Off you go!

Now, where is the analogy to process documentation and governance then?

First of all, the person getting on the train, strapping themselves in is the local process modeler documenting a process (either from scratch, or importing it or even discovering it via process mining) and adding all relevant and available information to it. Sometimes this goes very smooth, sometimes it’s a bit of mess (sometimes strapping in goes first time right, sometimes you can’t seem to get the bloody strap connected). 

Next, the parc staff performing the physical safety check can be compared to the central modelers going over your modeling efforts to check whether or not you sticked to the rules (did you apply the method, conventions etc all properly). The so-called semantic check is something that is always done here (sometimes the local modelers also do a semantic check, but this typically only happens when the local modelers are a bit more mature). 

Finally, the controller of the rollercoaster is your process owner. Ultimately, it is in his/her interest that the processes, for which (s)he is responsible, are documented properly and complying to the standards. So the process owner is the one who set the train in motion by approving the process model and therefore making it public. Again, the process owner needs both other roles (the local modelers for the subject matter expertise and the central modelers for the conformance to the defined standards and conventions). 

In short, when engaging in process documentation, make sure that you’ve put some thought into the topic of governance. What is the RACI table looking like for your organization when it comes process documentation? Who is ultimately responsible for the content of a process model? Hint, it’s never the BPM group (they are responsible for making sure people are capable of documenting a process and that it happens in a consistent manner)…

Having said that, I hope you enjoyed the process documentation topic. The coming month (July) is going to be all about task mining (or process discovery) and the link it has to BPM. 

Ciao, Caspar

Last week (it was last Monday actually) I shared my thoughts around the dichotomy of process documentation, which in short means that all of the content that you document around your business processes can have two purposes (it doesn’t necessarily means it always does, but it can and will at times); one to capture (and create) the content and two to be consumed by the end-users. If you extend that line of thought you automatically end up with the question: who will be doing the modeling and who will own the content once it’s modeled? In other words, how do you organize the process documentation in your company?

Before I get into this, please allow me to re-iterate the purpose of process documentation and also specifically what it is not. The purpose of process documentation is to create transparency around the way of working over all of the business processes that you execute within an organization. This transparency includes the specification of the activities, the roles, the applications, risks and so on AND the connection these activities et al have to other activities within your organization. Processes are hardly ever completely stand-alone, for example your purchase to pay process has connections to your finance processes, to your raw material replenishment processes (MRP, in case you’re into manufacturing), your supply chain management processes and even your auditing processes and you want to make sure that you capture this connectedness properly to ensure that you can perform an impact analysis that actually makes sense and supports your management of change process (just to name one, and yes, this is my favorite underrated process).

The purpose of process documentation is definitely NOT to make process drawings for the sake of having a process model. I purposefully refer to them as process drawings because if you are using tools like Visio, Excel, PowerPoint etc. you’re not even creating a process model, your creating a process drawing (you can compare this drawing to an architectural sketch of your new house, while a true process model is much more like the construction drawing (yes, awkward timing to use this word) that contractors need to actually build your house). Anyway, the goal of process modeling is not to model, but to create transparency and connectedness.

Now that we’ve got that out of the way, let’s dive into the topic at hand: how to organize process modeling? I believe that there are a couple of components to this question:

1. Modeling consistency
2. Modeling roles
3. Modeling governance

On all three you can right a book and still be done about it, but I’ll give it a go anyway in this blog. Let’s start with modeling consistency. It’s very tempting to give your organization as much freedom as you can in the way that they want to capture their business processes. After all, every process is different and unique, right?….. WRONG!……very, very wrong. Despite the fact that the content of each business process is kind of unique, the way that you can document a business process is far from unique and some consideration on standardizing the modeling of these processes is in order. Imagine the situation that you have documented all of your relevant business processes and you are leisurely browsing through these processes, would it reduce the readability if every process was modeled with their own set of conventions (on color schemes, iconography and connections)? A Business Process Owner (typically covering a wide span of processes) would go nutty and would lose valuable insight and transparency because of it. You immediately now notice that points 1 and 2 are very closely connected (and let me spoil the fun here, so is point 3). 

Good, so we established that it is good to think about the consistency of your process documentation before you actually start modeling. Then the next question will be: who is going to do the modeling? The good news is that there are basically only three options here, the bad news is: how do you pick the right one?

Let’s first examine the three options, which are:

1. Fully centralized modeling
2. Fully decentralized modeling
3. Hybrid modeling

Even though I think these options do not even need further explanation, I’ll do it anyway (it’s all about alignment after all). In a fully centralized modeling concept there is a group of people somewhere in the organization where all of the modeling work is done (as a central team, hence the name for this option). The upside of this is that these people will be very experienced modelers in no time, the downside is that these people do not necessarily have sufficient knowledge on the business process context and thus have to do a couple of iterations with subject matter experts before the model is good enough to publish. Next, the fully decentralized concept in which the modeling responsibility is basically placed on top of the responsibilities of the people executing or managing the processes and as you can imagine, the upside is that these people know their own process inside-out, the downside (and this is a huge downside) is that they do not model frequently enough to go fully thru the learning curve and become great modelers.

In the middle there is the hybrid model where the flexibility and agility lives. In all case, I believe there is a lot of merit in having a few (to start with 1 or 2, later to be expanded) people who define the modeling conventions, do most of the initial modeling and are able to train other modelers later on. Besides these centralized resources, you can consider to identify 1 or 2 people per business line (most typical role for this is that of the Subject Matter Expert (SME)) and train them to become modelers too. SME very often work with business processes all day and every day and it will provide them with some great tooling to better help their internal customers. You could even go a step further and consider the following situation: you engage with a BPM platform that allows for smart modeling (for example by being able to import tables that contain the process relevant information and turn this into a process model) so that virtually everybody could create the first high level draft of a process model. This draft could then be further professionalized by either the experienced SME modeler or even the central modeler. This way you can capture the essence of a process model, while at the same time not burdening the process executioners with the administrative tasks of completing the model and bringing it in line with the modeling conventions.

One recommendation that I always give to my clients and prospects is: never just add the full process modeling activities to the process executioner’s workload, that will never ever work. They will almost never be fully engaged with these additional responsibilities and the quality of the output will reflect this, which in turn will not help the organization to achieve the transparency and connectedness that is the main purpose of process documentation in the first place. 

Finally, there is not one solution that works best in every situation but understanding that you have options (with pro’s and cons and consequences) is good to know. It will enable you to make a more conscious decision about it. By the way, as a little disclaimer, the pro's and cons I've mentioned in this blog are not the only ones, but the most obvious ones. So, rest assured, there is more....

From a very hot Netherlands, speak to you next week…

Ciao, Caspar