Aligning Process Management with Enterprise Excellence

I’m guessing that, given you’ve taken the time out of your day to read a blog on process management, you understand the importance of having clear and current documented processes. What we all need to remember though is that while process documentation is a necessity, it will do nothing on its own. This is why so many process management initiatives fizzle out – organisations create hundreds of process maps, but having these process maps in isolation doesn’t tangibly benefit the business, so the business loses interest, stops mapping and updating the maps, and the initiative is over.  

Whenever I kick-off a new project, one of the first questions that I ask my client is What does Enterprise Excellence/ Operational Excellence mean to you? And the answers that I get are generally revolve around:   

  • Having a process driven culture  
  • Having one way of working  
  • Ensuring that everyone knows how they should be doing their job  

To me this is the problem. Too often we confuse Enterprise Excellence with Process Management. The reality is that Process Management is a part of Enterprise Excellence, they’re not the same. With that in mind, we need to remind ourselves that our focus needs to be on achieving (or moving towards) Enterprise Excellence and therefore, our process management activities need to be performed in support of this cause.  

This of course raises the question, what is Enterprise Excellence?  

Enterprise Excellence

This is SA Partner’s Enterprise Excellence model and is made up of three core components, Purpose, Process, and People all in support of delivering Customer Results.   

Purpose: This is why your organisation exists and the strategy that you have developed to achieve your purpose. 

Process: This is the work that you do. It should be standardised and visible so that at any given point in time everyone should know exactly what they should be doing and how they should be doing it.  

People: You need to ensure that you have the right people in place with the capability, capacity, and mindset to perform our processes.    


When we happy map, what happens is that the Process component becomes disconnected from Enterprise Excellence. This causes us to end up with process documentation and assign process management work in isolation which fails to deliver customer results.   

Happy Mapping

As a result, what we need to do is ensure that our process management activities are tightly aligned to our Enterprise Excellence efforts. To do this, what we’ve found is that the connectors between Purpose, Process, and People are of vital importance.  



Once we’ve determined our purpose and developed a strategy to achieve our purpose, we now need to ensure that our processes are aligned. This helps ensure that everyone is working on the right things and solves the problem of being busy, but rather than doing ‘busy work’ that doesn’t move the needle. As such, as part of our process management activities, we need to question if our as-is processes are aligned with our strategy and contribute to us achieving our purpose and, where they don’t, decide if the process needs to be changed or eliminated. Additionally, while our purpose will typically stay the same over time, our strategy will evolve. As our strategy evolves our process management activities needs to involve reviewing our existing processes and determining how they need to change in-order to remain aligned to our revised strategy. Once we’ve determined our purpose and developed a strategy to achieve our purpose, we now need to ensure that our processes are aligned. This helps ensure that everyone is working on the right things and solves the problem of being busy, but rather than doing ‘busy work’ that doesn’t move the needle. As such, as part of our process management activities, we need to question if our as-is processes are aligned with our strategy and contribute to us achieving our purpose and, where they don’t, decide if the process needs to be changed or eliminated. Additionally, while our purpose will typically stay the same over time, our strategy will evolve. As our strategy evolves our process management activities needs to involve reviewing our existing processes and determining how they need to change in-order to remain aligned to our revised strategy.



We need to start by capturing our As-Is processes. Not everyone will like it, but it has to be done. As-Is process capture is however just the starting point. Once we’ve captured our As-Is processes we need to look at them and question if they are fit for purpose? Particularly if you are starting with a culture that doesn’t appreciate process many of these processes won’t be followed so you need to invest energy in standardising them to make sure that the lived process aligns with the documented process. Also, these as-is processes will likely have waste, so you should also be thinking about how you can make them more efficient. Finally, as the environment in which these processes evolve, so too must your processes, so you need to ensure that your processes are continuously improved.   

None of this improvement work will just happen though. As the model indicates, improvement isn’t just related to Process but also People. Your people need to have the capability (e.g. Problem Solving and Lean Improvement skills) to participate in process improvement as well as have time allocated away from working in the business to working on the business.  



Having a purpose and strategy defined and understood by your Executive team is important, but for it to mean anything it needs to be understood and believed by your entire workforce. Part of your strategy should be Enterprise Excellence, the idea that the way that you work matters, not just the work that you do. And this needs to be communicated, understood, and believed by everyone in your organisation. They need to understand why we are doing this and be willing participants.  


To summerise then, if you want your process management activities to deliver customer results, you can’t just be a happy mapper and create process documentation. You need to ensure that your process management activities are part of an Enterprise Excellence strategy which is done by aligning your processes with your purpose, building an improvement framework and creating capability and capacity in your people, and finally engaging your people with the role that Enterprise Excellence has in achieving your purpose.  


Please contact me on with any questions.


Managing Regional Process Variation

Many of the clients that I work with operate out of multiple national and global sites. This then naturally gives rise to the question ‘how do we deal with these geographic variations?’

I doubt I need to explain in too much detail why organisations want to get rid of their variations, there can’t be two best ways of doing something, but at the same time, we need to appreciate that variations are not always evil. There are valid reasons for variations, different regions have different rules and regulations governing how processes need to be performed, sites are set up in different ways, or customers may have different requirements just to name a few. As a result, my advice on how to deal with variations is typically three-phased:

  1. Capture the as-is and understand how your process vary
  2. Decide what you’re going to do with these variations
  3. Use change management best practises to standardise where appropriate.


Step 1: Capture your variations

As an example, imagine that I want to capture the process of how our staff catches taxis around the world. I’ll start by picking one country (often the head office), and map out how the process works there. In this case, let’s start by mapping how we catch taxis in the UK.


Capture the process

What we would do next is share this process with SMEs in our different offices and ask them if it aligns with the way they perform the process. Hopefully, their response is ‘yes, it’s identical’, however, this is rarely the case. Where we identify variation, we can’t just pretend like it doesn’t exist or simply jump straight to standardisation, we need to capture this variation so we can properly understand and assess it.

In our example, let’s say that we find that our American office said their process is the same, but our Australian office said that they perform it differently. If that’s the case, let’s apply and capture the variation.


Create process variations


What I’ve done here is specified that the process that I have already mapped is our ‘Rest of the World’ process and have now added a new variation for Australia. We have also introduced a new layer of governance. Our process has a Global Process Owner and Global Process Expert who are ultimately responsible for the performance of the process across all geographies, but now we have also introduced ‘Variation experts’ who are SMEs at the variation level.

The next part is to document the As-Is Australian process, capturing exactly how it varies from the ROW. If the Australian process is completely different from the ROW, you could build it from scratch, however in practise what we often find is that processes are similar to a point. Rather than starting from scratch then, using Nintex Process Manager, I would compare the Australian variation with the ROW and select the common elements:


Build process variations


In this case, I might start by importing all of the process items from ROW to my Australian process and then tweak them. Specifically, I am going to capture the variation that, unlike the ROW who catch Taxis, in Australia Ubers are caught (when I make the changes, the differences are clearly highlighted in Nintex Process Manager as shown below). Additionally, I’ve also added two new activities to the end to show that in Australia, once the ride has been completed, they must rate the driver and then submit an expense report.



Compare variations



Compare variations


Step 2: Understand and assess your variations

If I then toggle back to the ROW variation, you will notice that this variation hasn’t changed.


Understand and assess variations



This is important, just because the Australian process is updated shouldn’t mean that the ROW process should be updated too. This comes down to the Variation Expert of ROW (in this case me) to assess how Australia performs its process differently from the ROW and then decide if ROW needs to maintain its variations or if we should standardise.

You may notice that next to the title of the ROW process it says ‘Shared activity update’ which is telling me that one of the shared activities has been updated in another variation (as the Variation Expert I would also have received a dashboard notification).

When I edit the ROW variation, I am clearly shown what changes have been made and then I have the ability to either reject or accept them.


Accept or reject variations


In this case, I might decide that due to our UK and American insurance policies, staff are not covered if they catch an Uber, so I’m going to reject that change and maintain the variation. Equally, as we are not catching Ubers, I don’t need to rate the driver but I think submitting an expense report is a good idea, so I’ll bring that new activity over to my ROW process.



Step 3: Drive Change

Now that I’ve made the change, as the Variation Expert, it’s up to me to ensure that this new process is performed (i.e. that staff in non-Australian locations now also submit an expense report). This will be helped by Nintex Process Manager itself – as soon as I publish the change all stakeholders will receive notifications explaining the change which they need to acknowledge, but it is also up to me to monitor the situation and ensure that the lived process moves to the new version of the documented process and take corrective action where it does not.


In this case, we’ve understood our variations, standardised as much of the process as we could, but ultimately decided that we can’t standardise the entire process and some level of variation is required. This may change over time, perhaps in the future we’ll get a new insurance provider who covers Uber rides, at which point we will archive the variations and just have one ‘Catch a taxi’ process.


To summarise:

  • Don’t just jump to trying to create one variation-free process, at best this will result in a process document that is ignored, at worst it will result in processes no longer being compliant with local rules, regulations, and/ or customer expectations
  • Consider variation ownership – each variation needs to have an expert who can assess a variation and make a decision to standardise or not
  • Don’t just change your process documentation and hope that you achieve standardisation, ensure that everyone is aware that their process has changed, monitor what is happening in the real world, and take corrective action as needed
  • Appreciate that this is a moving target, as the landscape changes you may need to add/ remove variations


Taking this approach will allow you to find the balance between flexing to meet market conditions while standardising to drive efficiencies and share best practises.


In this post, I have used Nintex Process Manager as the process management tool. For more information on how it can be used to simplify variation management (or process management in general) please let me know.

Ishan Sellahewa

Digital  Transformation Business Manager   

Does Process Management Hinder Creativity?

Often, when I talk about process management and explain the benefits of having clear processes with detailed work instructions, I’ll get pushback like ‘we hire professionals to do a job, we don’t want to tell them exactly how to do it’.  

In short, the push back is on how much detail the process needs. The concern is we run the risk of turning competent professionals into robots and in doing so kill creativity.  

Process vs Creativity 

So, does process kill creativity? Potentially yes. This is something that we need to consider and, depending on the process, find balance between giving our teams discretion to bring their own flavour and personality to the way that they work on the one hand, and following standard and best practice on the other.  

As a real example, at SA Partners we are forging ahead with Digital Transformation and cross training our global consulting team to deliver these new services. As we expand, I’m asking myself how much guidance should I provide? When documenting our delivery processes, I could include scripts and recordings of how I would run a session, but doing so means that we run the risk of consultants mechanically running sessions which are not engaging or effective. But we could go too far in the other direction. The methodologies that I use have been polished over the years by myself and my predecessors with a focus on delivering the most impact to clients in the shortest amount of time – why would we not want our wider consulting team to benefit from these years of experience?   

How to make the decision 

Let’s take an example:  

Process mapped in Nintex Process Manager

This process has been kept very high level.  In Activity 3 task a, the Director of Legal is asked to ‘review and approve the contract’ without any further details provided on what this review involves and what good looks like.  

In this case, the argument can be made that as the Director of Legal, this person will have sufficient experience to complete a contract review using their professional discretion and further details are not required.  


Compare that approach with a small tweak as follows:  

Process mapped in Nintex Process Manager In this example, attached to Activity 3 task a, a work instruction has been attached explaining exactly how the contract needs to be assessed.  

There are a few benefits of this approach, specifically:  

  • Because we are leaving less to professional discretion, we can reduce risk by formalising exactly how the process is performed  
  • By making this process more mechanical we may be able to reassign the review from an experienced Director to an early-stage Associate and reduce the cost of the process while maintaining quality  
  • By formalising what good looks like, it will be easier to explain to the Sales Executive what is required for the contract to be approved, and thus reduce rework  


In making this decision, it’s no one size fits all approach. If this organisation works on a few complex seven figure contracts at any given time, it may be impossible to codify what a review involves. A highly experienced legal practitioner would use their decades of experience to perform an analysis. Conversely, if this organisation is more transactional, reviewing hundreds of low value standardised contracts, relying on expensive, experienced legal practitioners will make the process untenable. As a result, tightly defining how it’s run, and allowing it to be run by cheaper resources, is more appropriate.  


Your decision-making should include several factors:  

  • How complicated is the process? Is there significant variance between cycles?   
  • Is there a risk if the processes are not performed in a defined way? 
  • Is creativity or standardisation more important for this process?  
  • Is there a requirement (e.g., regulation) that the process must be performed by someone with certain credentials and/ or experience?  
  • Is there a cost pressure on this process for it to be tenable?  


Personally, I prefer more detail. When mapping our internal processes I will likely include recordings, instructor guides, and talking points. That way, if a consultant in Australia needs urgent support while I’m asleep, they’ll be able to easily go into our single source of truth (Nintex Process Manager) and self-serve. However, I would also pair this with a culture that encourages consultants to use their own judgement to deviate from the guidance where they feel it’s appropriate and, in doing so, hopefully achieve the best of both worlds.     


Finding this balance can be difficult so I’m happy to offer a free one-hour process conversion workshop. All you need to do is come with a process in mind and we’ll work together to create meaningful process documentation that has just the right amount of detail based on the flexibility that you require. Drop me an email at the details below and we can get something scheduled.  



Ishan Sellahewa

Digital Transformation Business Manager

+44 (0) 79263 89523


Process Management and Agile

Periodically when talking about process management, I’ll be told ’process management isn’t for us, we’re agile’.  Is agile a fair excuse to avoid process management? Short answer, in my opinion, absolutely not; in fact an agile environment makes process management more important if anything.

Here’s why.


Agile and the Agile Trap

First, let’s start by defining agile. Whilst agile originated from software development, it’s since become synonymous with continuous improvement following the Japanese concept of Kaizen, which means to make small incremental improvements continuously. The idea is that we should always be looking at the way that we work and seeking to improve rather than blindly performing old, ingrained processes.

It is easy to see why people categorize agile and process management as two competing ideologies, with the former focusing on change and growth, whilst the latter prioritises stability.

Let’s consider the SA Partners Improvement Journey:



SA Partners Improvement Journey


When you are in the reactive phase, you’re likely to be experiencing:

  • Inconsistency in the way that work is performed, depending on who is doing the work and/ or when the work is being done
  • Inconsistency in the outputs that are produced by your processes, resulting in a highly variable customer experience
  • Significant management time spent responding to, and resolving problems

And this can be the agile trap – if you adopt an uncontrolled, ungoverned approach to continuous improvement you run the risk of trapping yourself in the reactive phase with process participants given license to perform their work differently every time they do it and call it agile.

Process Management

How then does process management come in to save the day? Simply put, it means that we are fostering an environment of continuous improvement, however tying governance around it.

This starts with standardisation. Whilst it may seem counter-intuitive, for us to improve we need to start from a platform of stability so that we are all trying to improve the same process (see my earlier post where I explore the idea of standardisation in more detail).  Once we’ve achieved stability, we’re ready to start thinking about improvement. While yes, we want everyone in the organisation to be empowered to drive change, it’s critical that processes have clearly defined ownership so that whilst anyone can suggest a change, it is the process owner who makes the decision to adopt the change and deviate from the agreed, ‘stablised’ process.

To make this happen, every process needs to have a clear process owner and expert as can be seen in the screenshot below where the process has been captured in Nintex Process Manager and Julien and Madlyn have been named as the Process Owner and Expert.



Process Ownership


Once this ownership has been defined, anyone should be able to leave feedback on the process to suggest a change, but this feedback needs to be funneled to our process owner and expert to assess the feedback and decide what action, if any, will be taken. An example of this can be seen below in the screenshot where I’ve left feedback on the process which has gone to Julien who has provided his response.


Process feedback


The benefits of tying governance around improvement are:

  • Process owners are in a position where they can see the bigger picture; while something may appear to be an obvious improvement to us as process participants, it may cause issues down and up stream.
  • There is control over the path forward, are we okay to go ahead and implement the idea? Do we need to pilot the idea in a controlled environment? Does the idea need to be parked for now?
  • While a process participant may make a suggestion, it could be a band-aid fix. The value of the suggestion is often not the proposed fix itself, rather a flag to the process owner that there is a problem that requires root cause analysis.
  • If we, the process participant, do indeed have a valuable improvement suggestion, this approach will mean that it’s more likely to stick – it shouldn’t just be us that changes the way we work, everyone should adopt the new and improved process (which should then become the starting point for future improvement)

In summary then, process management and agile shouldn’t be seen as competing ideologies rather process management will help you to be agile and drive effective, meaningful change.

Ishan Sellahewa

Digital  Transformation Business Manager   


Process Standardisation and Stabilisation

When embarking on an improvement journey, organisations too often give into temptation and jump directly to process improvement, either by designing a new, optimised, Lean process, or attempting to immediately create a digitised, automated version of their existing manual process.  

While this approach of skipping ahead to your desired future state may seem like the best way to fast-track your improvement journey, more often than not it will result in the delivery of solutions that either miss the mark entirely or even exponentially increase your existing process problems.  

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”- Bill Gates 


SA Partners Improvement Journey


Using the SA Partners Improvement Journey pictured above, if you find yourself in the ‘Reactive’ phase, you are likely to be experiencing:

  • Inconsistency in the way that work is performed, depending on who is doing the work and/ or when the work is being done
  • Inconsistency in the outputs that are produced by your processes, resulting in a highly variable customer experience
  • Significant management time spent responding to and resolving problems
  • High rates of turnover with employees feeling like they are unable to achieve their assigned KPIs, and having no internal growth and learning opportunities

At this stage of your improvement journey, your focus should not be on improvement itself, but rather on achieving a state of stability where work is done in a standardised way regardless of when, where, or by whom the work is performed.

Achieving this level of standardisation will not only ensure that your processes produce consistent outputs, but will also lay the foundations for you to do proper root-cause analysis of process problems, and therefore ensure that future optimisation and automation projects deliver meaningful results.

The question then becomes, how can we get out of the red ‘squiggly’ line and achieve stability?


  1. Identify your processes

Step one is to simply identify your processes. Another common mistake I see organisations make is to jump straight into talking about the details of how their processes operate without giving enough consideration to what their processes are to begin with. An example here might be a sales team talking through their processes starting with how they qualify leads provided to them by marketing. Separately the marketing team may discuss their process ending with how they qualify leads before passing them over to sales. All of a sudden leads are qualified twice which is not only waste but also a cause of frustration to your prospective clients.

Before getting into the details then, you should run a scoping exercise where you identify your process groups, the boundaries of these process groups, and finally the processes inside these groups along with their boundaries. If we consider a process hierarchy, at this stage we are trying to define levels zero, one and two.


Process Hierarchy



2. Capture your As-Is processes

Now that we know what our processes are, we are ready to capture the As-Is (levels three, four, and five). The process capture sessions shouldn’t be performed by a process owner in isolation, rather a workshop should be held with a collection of SMEs so that what is captured represents what takes place in the real world, not what the manager thinks takes place. Determining who should attend this workshop is a critical decision, on the one hand, you don’t want to get into a position where you are stuck because no one in the room knows what happens next, but at the same time if you invite every man and his dog you’re going to go round and round in circles trying to come to an agreement. The approach that I take is inventing the absolute minimum number of people that will allow us to get something done and out the door.


When running these workshops there should be a number of ‘house rules’ – the following are the rules that I like to enforce:

  1. Spelling doesn’t matter
  2. All must contribute & be present
  3. No hierarchy + Vegas rules
  4. Start with the As-Is
  5. Stay on topic and use the parking lot
  6. Progress, not perfection. ELMO! (Enough, let’s move on)


During these capture sessions, it’s easy to get caught in the weeds and go round and round in circles trying to agree on exactly how a process is exactly performed or chasing each other down rabbit holes.  When facilitating these workshops I always focus on getting things done and set the bar as ‘Can we all live with this’ rather than ‘Is this right?’ with an understanding that we are just mapping version 1, which will be iterated over time.

Consideration should also be given to how you run these workshops and a consistent approach should be taken (i.e., every workshop should be run in the same way every time using the same templates). I prefer Miro, where I’ve developed the following capture template:


Process Mapping Template


I find that this template allows me to capture all the information that’s needed, and do so in a way where I can keep the group focused.

Importantly, during this workshop process ownership needs to be assigned. Who is going to be the Process Owner? Who is going to be the Process Expert? It will be these two people that will be responsible for making sure that the documented process becomes the lived process, as well as maintaining and updating the process moving forward. This decision is often the difference between process management being a theoretical exercise and getting us out of the red squiggly line.


3. Map and Share your As-Is Process

Whatever tool you decide to use for your process capture workshop is simply that, a tool for the process capture workshop. You need to quickly take the output of these workshops and document your processes in a proper process management solution.

SA Partners have been involved in Process Management projects since our inception 30 years ago, and over that time we’ve used almost every major process mapping tool in the market. After extensive research and experience, we’ve identified Nintex’s Process Management tool as our tool of choice, and is what we recommend to our clients.


Process Manager Process


Once your process has been documented in your process management solution, it should be shared with the workshop attendees and other key SMEs. This is something that I like to be timebound, I will say ‘here is a link to the process that we captured during our workshop, please review and leave any feedback by next Friday (March 24th) at which point I will submit it for approval’. This approach allows everyone to have a say without slowing us down if people get lazy.

This process is made very easy with Nintex Process Manager where a shareable link can be created allowing SMEs to interact with the process and leave feedback if needed (have a go yourself here).


4. Approve and Publish your Process

Once the relevant SMEs have provided their feedback (or have not raised any objections) it’s time to get the process out the door. While this stage might seem obvious, I find clients often struggle. Once they have captured something they want to hold onto the process and keep polishing it until it’s perfect before they release it. The problem is that the only way that you will achieve standardisation is if your process participants are actually given the process that you want them to follow; as such my recommendation is to get the process published ASAP.

There should, of course, be checks and balances, again if you use Nintex Process Manager this is all automated where the required process approvers will have to formally approve the new or changed process (all captured in the change log) and then have it published by an administrator.



5. Standardise and Stabalise

All we’ve done so far is come to an agreement on the current state process which we now need to operationalise. This starts with letting our process participants know that there is a new or changed process that’s relevant to them. Again Nintex Process Manager will automate this by issuing notifications to all relevant stakeholders:


Change Notification


If it is an existing process that is changed, we also need to make sure that process stakeholders are crystal clear on what specifically has changed. In the example below, by comparing the new version with the previously published version, I can see that the Manager no longer needs to reply to the applicant as this is now automated by the Workday system:


Change Description



Once our SMEs know that a change has taken place, and what specifically has changed, they should acknowledge the change to commit to changing the way that they work:


Change acknowledgement



6. Monitor and Enforce

Shortly after a new or changed process is published (appx two weeks) process owners should review reports to see who has/ has not acknowledged the change, and for those who have not, reach out to them to make sure that it gets done and they are fully committed to performing the process as it has been documented.


Change Report



It is also the responsibility of process owners and experts to monitor what is happening in the real world and ensure that the lived process is the documented process. Where there is a discrepancy it’s up to them to bring alignment which may involve using change management to bring process participants to the documented process, or updating and iterating the documented process so that it aligns with what is happening in the real world (prior to considering any desired future state).

My key message here is to not ignore the importance of standardisation and stabilisation. Not only will this provide the platform to make a meaningful improvement in the future, just the simple act of achieving standardisation and stability will deliver substantial benefits in and of itself.


Ishan Sellahewa

Digital Transformation Business Manager