One of the biggest debates in the world of digital transformation and ERP implementation is when do we do business process management? Do we let the software determine how our processes are going to look? Or do we ensure that our business processes drive how the software functions? Part of the reason why this is such a struggle for organizations is because they don't want to reinvent the wheel if they don't have to and is they don't want to have to customize the software if they don't have to.
So, before we dive into the how we do business process management, and answer some of these philosophical questions I just mentioned, let's talk about when we do business process management, there's a couple of different ways this could work. It all depends on the type of situation you're in… but I'm going to sketch out a couple of ideas or a couple of options for you. So, in a perfect world, you have, it is really three major phases of any project:
Now in a perfect world, we would spend a fair amount of time defining what our business processes are going to look like and what we want our future state to be in the software evaluation stage of a project. Now, the reason for this is because the clearer vision we have for what we want this business transformation to achieve, the greater power we have to manifest the desired outcome. The more aligned we are around what those answers are as an organization, the better results we will achieve during the software evaluation phase. Now, the unfortunate reality for a lot of organizations, whether that's good or bad is that they don't necessarily have the budget or the time or the resources to spend, redefining what their business processes are going to look like as part of a software evaluation.
Some organizations miss this pivotal step because they don't necessarily have the time or money to invest in the business process mapping. There's a huge amount of value in defining your business processes upfront. Now, I'm not suggesting that you define all of your business processes in a great amount of detail but, in general, let's just get that out of the way conceptually, when we're talking about where and when we focus on business processes. Ideally, it's here but, for a lot of organizations, it ends up being here in the design stage.
So, this brings up the question of how do we define business processes and when? We are not going to have the same answer of how we handle business process management for every portion of our business, we're going to base it on the prioritization of our different business processes. And again, this is operating with the assumption that time and money and resources are not unlimited, and we have to really focus our efforts to make sure we get the highest value out of any sort of effort we put into this. So, it's helpful to first of all break our business processes into two buckets.
These are the differentiators that really make us who we are as an organization. This is why we win against competition; this is what we do really well. And we want to continue doing really well. It's our secret sauce! Core competencies are functions that we want to do differently, we want to continue to preserve these core competencies. If you think about it, we don't want every ERP system out there to be able to address these things because if they did, then they wouldn't be core competencies, every other competitor in the industry would also have the same processes, and we would lose our advantage. These functions will likely need to be customized.
These are important – BUT they're not as important in the grand scheme of things as our core competencies. And they're not a secret, it's not something that we want to necessarily do differently than other organizations. core competency is going to be oftentimes things that are customer-facing. Some of the examples here would be your GL, or how you handle accounts payable, your purchase order or processing, things that you have to absolutely do as an organization. Typically, most software systems in the marketplace probably are able to deliver these types of functions.
Now, the second way that we look at the breakout business processes, is to think about this in sort of a hierarchy. One through five levels of business process mapping will resonate with you. Probably the simplest way to explain this is you start off with your macro processes at a high level, which would be level zero, and then you're working your way down to level five.
For example, let’s take the 20 major steps that happen in the organization from order to cash. The reality is there are hundreds of sub-steps within that. But we're just giving the high-level macro view here. So, to understand how we treat these two buckets differently, we have to look at what level of the business process we're talking about. Here we're talking about level zero to one. And then for each layer down, we're breaking out each of these boxes into more and more detail as we move our way down to level five. So, by the time we're down to level five, this is transactional: this is what buttons we press, what fields we populate, what approvals we have outside the system, etc.
Circling back to the original point of where do we the business processes fit in? Let's start with the easy answer. The easiest part to answer is when we get to the point at which technology matters, it matters which technology you're using.
Let's call this the tech-specific processes. From this point down, where we need to know what technology we're using, we're not going to get to that level of detail here in software evaluation. We're going to wait to do that here in Design because we need to know what software we're implementing before we get to that point. We don't want to get to that level of detail for really any of our business processes until we get to the design stage.
When it comes to core competencies, especially if we're here in the software evaluation stage, trying to define what the business process improvements are, we're going to take these prioritize these high-value areas. We might go a little bit deeper here and bump up against this dotted line to where we define what we want our processes to look like in a technology-agnostic way. So, whether we're using SAP / Oracle / Microsoft, or whether we're using a pen and paper and Excel spreadsheets - it doesn't really matter, doesn't change the fundamental aspect of what we do.
This is the easiest way to think about how do we prioritize our business processes? How do we define what level of detail we get into? And ultimately, at what point in the project do we do that? So that all brings up the question of how do we facilitate business process mapping? How do we do it if we're not using the software to drive what the business processes are, or to define what the business processes are? One of the most powerful tools that we've seen and use at Third Stage is a company called HP QC. Visit HPQC.org, and learn more about that organization.
This whole exercise isn't just about business process management, it's also about organizational change management to as we look to these future state business processes all along the way we're defining how the organization is going to change, and more importantly, to individual employees we're defining how individual jobs will evolve and the impact to culture. We have identified some change impacts and we can start working on the organizational change strategy to address those change impacts. This another reason why moving as much as business processes work upfront as you can, is so valuable from a change management perspective.
When you're thinking about business process mapping is important not just to think about the processes and the design of the software, but also the human component and how we enable those changes with people.
For more information on this same topic, I encourage you to download our 2021 Digital Transformation Report which contains best practices around ERP implementations, and a lot of other information related to business process mapping and organizational change management. I am also always available to be a resource through your digital transformation process. Please feel free to reach out to me directly with any questions.