Mining Your Business

Combining Process Mining with Process Modelling with Alec Sharp, Clariteq

April 13, 2022 Mining Your Business Episode 33
Mining Your Business
Combining Process Mining with Process Modelling with Alec Sharp, Clariteq
Show Notes Transcript

Alec Sharp, founder of Clariteq, is one of the most accomplished process modelling and data consultants on the market. Author of book Workflow Modeling, speaker on many events and webinars and now a guest on Mining Your Business podcast shares with us how to discover, establish, understand, and design a process, regardless of whether it is a business process at large enterprise or smaller process admission process at public university. Goal? Model As-is reality – who does what, when, and how.

Learn more at the Processand website!

Follow us on our LinkedIn page here: LinkedIn
Learn more about what we do at Processand here: Processand

00:00

Patrick:

Welcome back to the Mining Your Business podcast, a show all about process mining, data science and advanced business analytics. My name is Patrick and with me, as always, my colleague Jakub.

 

00:09

Jakub:

Hello, Patrick.

 

00:11

Patrick:

Joining us today is Alec Sharp from Clariteq. He is going to tell us all about his tried and true methods of helping organizations get their processes in order. Let's get into it.

 

00:31

Jakub:

Another episode of Mining Your Business podcast. Another brilliant guest lined up to share his wisdom with us. I'll be honest, one of the best things about doing the podcast is extracting the knowledge of people who have been in the field for way, way longer than we have. Our today's Guest of honor is Alec Sharp, a lifelong consultant in Clariteq Systems Consulting, an author of the book Workflow Modeling Tools for Process Improvement and Application Development. Alec, welcome to our podcast.

 

01:00

Alec Sharp:

Thank you. I am very excited to be here. I've listened to some of your previous episodes and I I think this will be mutually beneficial. Thank you for having me.

 

01:13

Jakub:

It's our pleasure. I mean, we love broadening our horizons. And as we mentioned, a couple of times before, when we started doing the job, we thought that there is just process mining. And then soon thereafter we found out, Oh, wait, there's more than doing process mining. So having people such as yourself telling us about those horizons that are up there, it's insane. But the first question I would really have for you: is there is still something in the world of business processes and management that still keeps surprising you today?

 

01:48

Alec Sharp:

Well, let me see, no. I'm an old man, I've been doing this, I've had my consulting business for 40 years. The first ten years were largely doing data work and the last 30 years my focus has been on business processes, although now my data business is taking over again as well. So honestly, I don't think I get surprised very often anymore. I, as an example, I do a lot of work that I call Project Recovery. So a team, whether it's application development or process improvement, a large project or program is stalled. And I get asked to come in and get things moving again. And there are some very common patterns. So I'm not a slave to those patterns. But if you'd like, I'll share them with you.

 

02:57

Patrick:

Yes, absolutely.

 

02:58

Jakub:

Please, go ahead.

 

02:59

Alec Sharp:

Okay. So the number one problem I see is failure to identify the true end to end process. Even if your scope of authority is only a piece of it, you really need to understand from the initial trigger to the final result, what is the scope of the process and what is involved in it. And I believe that is very true in process mining. We will talk about that a little bit more. Second common problem, premature diagnosis of the problem. So if you jump right in and you don't really know the end to end context, then you can easily think, oh, well, we know where the problem is. Let's solve it. A very quick example. An insurance company brought me in because they had determined the problem was in the testing of new applications before they went into production. And so all of the fingers were pointing at the testing group, and they built a problem statement which gave me a barrier to overcome. And then the actual problem was they weren't looking end to end at initiation, development, testing, and implementation. When we showed them the true end to end process, they realized actually testing was not the problem. It was elsewhere. So that's the second common problem. Premature diagnosis of the solution or the problem. And the third one is a rapid descent into unhelpful detail.

 

04:46

Jakub:

Yeah, we see that very often.

 

04:47

Alec Sharp:

Very too quickly into detail flow modelling without having established a high level scope model.

 

04:54

Patrick:

Oh that's great. So in terms of project, so that's one thing that's project recovery. But can you tell us a little bit about or people that aren't familiar with your work? What else do you do?

 

05:06

Alec Sharp:

I do a lot of data modelling and data management work, so I help organizations understand the data they need in order to operate. And that's more on the operational side than the analytic side. So I do a lot of work both consulting in and teaching and speaking on business friendly concept modeling or conceptual data modelling. Obviously, I do a lot of work in process improvement, and my focus is at the front end. What is the actual process? What are the real issues what are the goals? And I have an interesting feature-based approach to the design of new processes. And I also do a lot of work in application requirements. So use cases, user stories, service specifications or microservices, if you want. And business is booming. And I think one reason business is booming is, I'm not sure how to word it, but in a way I cover the full stack, process, application, data, consulting, and teaching. And that turns out to be surprisingly quite a unique combination. And I'll just go on for another 30 seconds. Especially helping organizations see end to end and what the root cause of some of their dysfunction is. My clients have pulled me into the organizational change area, so I had many clients beginning five or six years ago, tell me you're not our data guy or our process guy, you're just our change guy. So I help the change and of course, I mentioned project recovery, helping stumbling efforts.

 

07:09

Jakub:

This is great because change is also very much the focus or the goal of what we are trying to do through our process mining projects. However, you mentioned word or let's say two words that haven't really been in the podcast yet, and this is a process modeling. Could you tell us a bit about what process modeling is so that also our listeners are well, including myself, are a bit up to date.

 

07:34

Alec Sharp:

So process modelling to me is engaging business people in the act of identifying and then depicting or representing their business processes. And so process modelling might initially begin with simply saying we believe we have a dispute resolution process, then we would build a visual model. And I will provide for your listeners some graphic examples. Real life examples of what I mean. But a process scope model would be a simple one-page depiction of the process in terms of a framework that one of my students named TRAC (T R A C), which stands for trigger, results, activities, cases or variations. So we build a very simple diagram that says at one end here is the triggering event at the other end, here are the results received by the significant stakeholders in the process. What does the customer get? What do we get? What does the sales rep get? In between the A is for activity and we only ever identify five to seven major activities. So this is not a flow model, it's a high level depiction. And then finally, what are the cases or variations? So we fill a new order, we fill a standing order, we fill a replenishment order. And this is something that first stage of modelling is something I do on 100% of my project recovery jobs, because people have always gone into too much detail without really comprehending the end-to-end flow.

 

09:38

Patrick:

So when I hear cases and activities and variations, my process mining senses start to tingle here. But just so we're not talking about the same cases and activities that we would in process mining. And if you could, how would you go about finding these cases, these activities with the client? How do you go about doing that today?

 

10:00

Alec Sharp:

Okay. Well, and I am going to circle back to mining, but let me answer that. One of the extremely simple guidelines, it's part of my teaching, it's what I'm known for. One thing I'm known for in the business process conference circuit. Certainly an important part of my consulting is simply properly naming the process. So somebody says, we have an onboarding process and I want to slap them and say no, onboard is a verb. So a process should always have an active verb and a noun. So let's say that we're at a university and the process is to admit a student, a verb, an active verb and a noun, not a mushy verb like manage process, handle or do, but an act of verb, like admit, evaluate, assess. And then I ask them what are the qualifiers that go between the verb and the noun, is there some? Because as you know, in the process mining, there is always some object going through the process. And I will call that a token. Now, is there some characteristic of the token like student that is going through the process? That changes the path it takes? And as an example, I've done a lot of work in higher education in the United States, in particular, on the recruit, admit, and onboard student processes. And so what is the qualifier that goes on student? Well, it's pretty easy in most universities, they say, well, there is an in-state undergraduate student, there is an out-of-state undergraduate student, there is an international, you know, graduate student. There is a returning mature student. Usually there are three to five major cases. But I was at a global air logistics company and we identified 22 cases, which turned out to be their problem. So each case is a variant on the base process. And it's, oh, gosh, I'd better stop. But it's incredibly important to simplify your world if you try and and build models. So I'm going to get back to modeling. If you try to build a model, especially a flow model that covers in one diagram, all the cases of a process. Nobody on Earth will be able to understand that model.

 

12:49

Jakub:

Alec, when we were discussing the details of the episode and what we would like to be really talking about when I mentioned that we are doing process mining. What you wrote me was that the process mining achieves its true power when it is combined with other aspects of process modelling and analysis, including helping businesspeople identify their true end to end process and why they need to change them. This is a lovely sentence Could you please elaborate a bit more on that, because this is basically, let's say, the position where process mining meets process modelling. And I think this is very intriguing also for us and for our listeners.

 

13:32

Alec Sharp:

Okay. Well, now that that's, that is a big topic. And if you'll permit me, let me just go back for a minute to the modelling question. Because when I go into an organization that is struggling, whether they use process mining or whether they are just going in by hand and building workflow models or swim lane diagrams, they have usually gone into far too much detail too quickly and without really any guardrails. So I mentioned doing a process scope model, that's the starting point. What is the trigger? The result, the major activities, the cases, or variations? Then we will move into the conceptual modelling stage, you know, any kind of model, data model, use case model, service model goes through three levels of detail that are well understood in the enterprise architecture and business architecture fields. And those are scope, concept, detail. And most of us with a computer science background go too quickly to the detail level without understanding the first two. So the scope tells me what is the process? The initial business friendly concept level workflow, which is nothing but boxes and lines, not all those BPMN symbols. A very simple diagram to help businesspeople help you identify all of the participants in the process, and therefore we can identify all the systems that are actually being used. And then eventually we'll get into the detailed level, which is, you know, all of your alternate flows, your gateways, that's your detailed BPMN model. But if you, if you start there, you will mess things up. So back to your question.

 

15:38

Jakub:

I love the way you're answering those, it's brilliant.

 

15:41

Alec Sharp:

Those models in mind, I would say that what I do in the process change field and how it would work synergistically with process mining is first, we would engage the business in helping comprehend their true end to end process. Okay. And a real quick example, I was consulting for a telecom company recently. They were sure they had three main processes sell a service, implement a service, collect bill for a service. And I showed them that helped them see that all their problems were because that was really just one process from the perspective of the customer we have gone from need is the trigger through to implemented and collected which are the results and that helped them understand all the conflict and it also, now here's the key point, simply doing that allows us to identify all of the actors in the process, the functional organizations and the actors and then we could identify the tools and data sources that were at work. And this is where I think this is extremely helpful. And then and then when we get into that initial business friendly flow modelling, we will discover additional actors that we didn't consider. We will discover that they are using other systems. And now we have a richer, a more complete view of the data that is underlying the current process. And now in terms of what you fellows do, now you have, you know, oh, it's not all in SAP. I've got this stuff that is up there in force.com And then this group is unbelievably using Lotus Notes. These people are doing stuff on Excel there's all these shadow systems and now we know that collections is part of the process and that's in Oracle financials for some weird reason. So we get a richer understanding of who is involved in the process, what do they do and how do they do it?

 

18:16

Patrick:

Yeah, that's a really interesting point because in a way, we have a lot of clients, let's see, or their organization or their, their domain or wherever their work. They see this tool, they see I can solve a lot of your problems in the finance department and they go and they want to implement it. But from what it sounds like that in your mind, this can be a little bit of a hindrance rather than instead of going from the top down, looking at the bigger picture and identifying all these actors and then and only then once you have the full internal process can you actually start with this type of tool. Is that right?

 

18:50

Alec Sharp:

That is perfectly said. And it would take me 5 minutes to say that, but you did it in 15 seconds, so well done.

 

19:01

Patrick:

Okay. So is that the phase where a process mining project should start? Like once the foundations of your approach have been, have been implemented, that's when the process mining part can go.

 

19:11

Alec Sharp:

I absolutely believe that and then the, the power of process mining is when people get to see the reality, like why do 17% of our instances of this process, why do they stop there in internal audit? And then we go in and then the other thing I would like to talk about is the concept of the enablers. But the process mining will reveal the reality, which is, as you know, it's always surprising when people see the actual path that some instances of their process takes. And then I mentioned the concept of enablers. Mm hmm. Well, I'll make sure we're finished with the current topic before I move on to that. So anyway, I think, yes, we do some scope level modelling to help everybody see the big picture, business friendly flow modelling to help uncover obvious problems and also to help uncover additional actors etc. And then now we can go in and use process mining to show the reality, like what is actually happening.

 

20:44

Patrick:

So it's more about uncovering on the details level that you spoke about before on that type of granular level is where process mining really starts to shine.

 

20:53

Alec Sharp:

Yeah, I and if I can add, like I always tell people, like we modeled the process initially, typically in a room with a whiteboard, you know, I don't actually go out onto the shop floor initially. I'll work in a facilitated session. Unfortunately, these days it's on Zoom, but we'll work in a facilitated session to help understand the assumed overall structure of the process. And then I always say walk the flow. So actually go out into the physical workplace and see if you see anything unusual. For example, I had one job where I saw people who were doing a kind of evaluation and some people had a huge backlog, a huge stack of work to be done, and others had almost nothing. Okay. Well, that's a little strange. But the other example of walking the flow is using process mining, because then you are literally you're helping the machine the machine is helping you walk the flow, which is pretty cool.

 

22:08

Jakub:

Alec, you have this very interesting frame when you are about discovering your organization processes where you essentially divide it into three steps with first one being establishing process scope and objectives. I guess this is the high level of the process. Second one would be to understand the as-is process, and the third one is to design the to-be process. And what I would like to now do is basically dive deeper into these three topics. And I would also love to hear your take on when and how does it even make sense to even establish any process mining initiative in these things and whether it even makes sense because as you are mentioning, sometimes it's just too detailed to even address problems that you're trying to solve with such a granular overview of your problems or as-is processes.

 

23:02

Alec Sharp:

Okay, do you have an easier question for me? I was thinking, in the overview you gave us Jakub, I might add one additional step. So number one, identify the processes and what they are expected to achieve. Number two would be do a stakeholder-based assessment of the as-is, understand the pain points felt by all of the participants and the stakeholders. Then we understand the as-is and then we design the to-be, we understand the as-is, we assess it by enabler and then design the to-be. Now, sometimes when we do those first two stages, identify the process and then we do what I call building a case for action. So what are the problems perceived in the as-is process? Why did they appear at this point in time, and what would we like to see in an improved process? Sometimes at that point, the problems are so obvious, they're so large. It's almost premature to go into detailed analysis of the process because our problem is our organisational structure was effective 20 years ago. But we're in a different world. We have conflicting data sources. In private enterprise the main problems, believe it or not, are poorly thought put performance measures. So I guess what I'm saying is sometimes you don't need to get into the details. The problems are so large and egregious. They're so large that you can and you should attack them very quickly. People hear the word process and they think, oh, my God, you know, years of process analysis and modelling. But I've actually been told that the approach I take is very agile. It's feature based. We can accomplish significant change in days or weeks, not months or years. And sometimes you just have to improve the current situation, like get it out of the basement. And then perhaps looking at process mining would be more appropriate.

 

25:57

Patrick:

So when you go into an organization and you talked about how a lot of these functional organizations aren't aware of the whole end to end process and making them aware can make them see a lot of the problems. I feel like that is a little bit analogous to what you just said. Do you ever just go into an organization and instead of thinking, hey, this is a process problem, realized very quickly that this is so far beyond a process problem that it's a more organization problem or any of the problems that you face. And my question, I guess, would be what do you then do in those cases?

 

26:32

Alec Sharp:

Well, I think what I would say, I would express it a little bit differently. Not every problem is a process problem. When I am brought into an organization, and they feel that something isn't working right. You know, I use my experience in some frameworks and I make an initial decision, maybe this is a process problem, maybe it is a data or information problem, maybe it is an organizational dysfunction problem. But let's say I think it's a process problem or even an organizational dysfunction problem. I'm still going to do that initial scope modelling and the stakeholder-based assessment. The beautiful thing about a process is when I'm trying to demonstrate this idea, if I was teaching in person, you would see me do these sort of hand motions about what is a process, triggering event, final results, major activities, cases or variations. And the key thing is a process cuts horizontally across the various functional areas in the enterprise. And that is, in my experience, the most powerful lens for understanding organizational dysfunction. And at that telecom company I mentioned, once they saw that the end-to-end process included sales, engineering and implementation, and finance, then they could see where all the conflict was coming from, the organizational dysfunction. That's why my clients started telling me several years ago that I wasn't really their process guy, I was their change guy. So this is a great lens for understanding the reality of organizational, well, how the organization behaves and then we can talk in a minute about how we get into understanding the root cause of that behaviour.

 

29:00

Jakub:

Yeah, we've actually had a guest on our show before who said that he finds out how the organization works in terms of processes when he asks whether they are differentiating between purchase to pay process and accounts payable process, which is basically two ends of the same process, and that really rang a bell and yeah, it was exactly the problem that they are looking at the processes from their, as you said, horizontal.

 

29:30

Alec Sharp:

Exactly, and in fact, we have a graphic that I'll share with your listeners after the podcast with some examples. For instance, at a large and very famous international technology company, they thought their processes literally were sales, manufacturing, planning, manufacturing, logistics, and finance. And that was the root of their problem. They simply did not recognize that those were all participants in a single process. Which was to fill an order. And so simply building that initial scope model, there were some real surprises in there. Some people in the organization said, oh, I didn't expect to see manufacturing as part of order fulfilment. I thought we went to the warehouse, and we fulfilled out of inventory. Well, no, this company had shifted to a build to order philosophy, and other people said, I'm surprised to see collections as part of this process. Well, it used to be a separate process because we would do it once a month and collect for multiple orders. But we've realized life is better when we collect order by order. So simply expressing the true end to end process is a huge contributor to people's willingness to engage in change because everybody has always seen their functional perspective. And once they see that their function is part of something bigger, it has an incredible psychological impact. And we have to take them through that impact to prepare them for what is coming.

 

31:33

Jakub:

And what is coming?

 

31:35

Alec Sharp:

What is coming is a closer look at the reality then of how this end-to-end process behaves. What are, for instance, what are some of the policies that pit one function against another? Well, I mentioned in private enterprise, the big problem is very often poorly thought out performance measures and rewards. We are very frequently, I worked in a large European justice system that was trying to understand why does it take us so long to get through the process of a trial. And it turned out how they paid lawyers was entirely based on lawyers delaying the case. So the lawyers were literally paid for every document they filed. So they would file a document for an adjournment they, would file for a continuance, they would file for another discovery session. The only way they got paid was on a per filing basis. So my program manager in that environment referred to these as perverse incentives and frankly, no amount of process mining is going to help you when the big picture is people are being paid to disrupt the process. And then in what I call the mission driven fields, health care, higher education, social services, the problem there is poorly thought-out policies. Very frequently policies and rules are created by people who have no awareness of on the ground reality. So you have these policies that effectively put people in the process in handcuffs or at the same time a major EU agency said, our corporate legal people believe better safe than sorry so we have created all these internal policies that require so many unnecessary checks and approvals and notifications that totally slowed the process down. Now Process mining would probably help you see that, but maybe you don't need to go that far. Yeah. So I have this concept of the enablers of a process six factors that we need to study.

 

34:29

Jakub:

Yeah, we will get to that in a second. It's one of my future questions and I know we will neglect here some of the process discovery phase and you know, understanding the process as-is, unfortunately we always only have, you know, about 60 minutes for these discussions. What is really interesting also for us because in my opinion, it doesn't matter whether you are working in details or in this higher level of scope or concept levels of your processes, you always at some point have to design a new to-be processes, either in the very small nuances as it's in the I.T. systems that we work with in process mining or in the higher organizational level. And so my question would be, how do you go about designing a new to-be process, especially in the time and, you know, when it's just so difficult for some organizations to change in the first place?

 

35:32

Alec Sharp:

Okay. The design of the new process begins, in my overall methodology there is the phase where we understand the as-is process. So the first two phases we scope out the process. Second, we do an assessment by stakeholder, then we understand the as-is process and that is, you know, progressive levels of modelling, typically workflow modelling. And that could very much include process mining and then there is this overlap, there is this stage that I refer to as assess the as-is process by enabler. Don't worry, Jakub, I am going to answer your question. So the framework that I use, which is very similar to the framework my colleague Roger Burlton uses, he has the famous Burlton Hexagon and I have my enabler concept. And back in the late 1990s when we were both speaking at the very first enterprise architecture conference, we saw each other's presentations and we each thought the other had stolen from us because his hexagon and my enablers basically touch the same point. So here it is, I think that the performance of a process is dictated by six primary factors. There are many more, but as analysts, this is a reasonable number. The first is the actual design of the process. Who does what, when? What is included? So we will learn about that from our process scope model and our flow modelling. Number two, the application of systems, data, and technology. So what information systems are we using? What data sources, how integrated are disintegrated are they? And increasingly, we're looking at devices like drones, so other kinds of technology. Those two are what I call the usual suspects. That's what everybody focuses on. The ones that really matter in my experience are the next three. Next we get into motivation and measurement. How do we motivate performance? What are we measuring and what are the associated rewards and punishments? Simple example, a big tech company I was at gave sales people a bonus for any order in the last two weeks of the fiscal quarter. So of course, they held all the orders until the last two weeks. So that's motivation and measurement. Big problem in private enterprise. Then we have human resources and organization. Basically, how are roles or jobs defined and how are organizations structured? That can be a problem in any kind of organization. So we often see cases where what is logically one task has been arbitrarily split across three different roles because of how the roles are defined. And then the third of the big three is what I call policies and rules. So what are our internal policies and rules? Do they make any sense? Usually, they haven't been updated in many years and they are conflicting or overlapping. The other big thing here is how have we interpreted external regulations and our friends in corporate legal typically like to interpret them far too stringently. And then the sixth enabler historically for me that was facilities, the actual design of the physical workspace. But now that so much is happening in the digital space, now many of my clients generalize that and they just they look at data, information, and knowledge as a sixth enabler. Others look at their communications systems. So it's just a framework. And to me, the whole reason we do as-is modelling is to see weird behaviours and then say, can I explain that with these enablers? Or simply ask people what is right or wrong with performance measurement in this process? What is right or wrong with role or job definition in this process? And then you end up with a lot of very specific problems and now we can take that and very directly turn it into the features we want in the new process. So, for instance, if the problem is all the orders come in in the last two weeks of the quarter, and that places a huge burden on production, well, then in the future, we would like to see a level flow of orders and then how we can achieve it. So that's a feature that we want. And then we go back and say, how can we make this feature work? And again, that involves looking at the enablers. What do we change in the workflow? What do we change in systems? What do we change in performance measurement? And I typically even among the largest redesign projects typically identify somewhere between five and ten critical features of the new process. Understand all those enablers. What will it take to make each feature work? I'll just say one more thing. I didn't realize it until a client pointed it out, but I was working on a procurement process and this amazing woman in the session said, this is amazing. This means we do not need to implement the new process as a big bang. We can implement it feature by feature. So this is actually an agile process change methodology. And I was like, Oh my God, I was so amazed. I hadn't realized that, but now it's very important. So, Jakub, I probably gave you much longer answer than you wanted.

 

42:30

Jakub:

I love it, I love it, Alec.

 

42:32

Patrick:

I had a question when you were mentioning the performance measurements. Talking about these enablers, how important is it in this case to have, if I'm thinking about salespeople, and, for example, the accounts receivable people, their goals and their motivations and their overall performance is measured completely differently. So how is it important from like an end-to-end perspective that these goals are aligned on the central process? And how do you go about these individual goals in comparison to salespeople and, for example, accounts receivable people?

 

43:04

Alec Sharp:

And that's a great question, Patrick, and that's why it is so important for people to see the entire end to end, because then without judgment, I'm often told by clients that my approach is blame free. So we're not saying, hey, you know, accounts receivable, you're idiots because of this or sales, you're ruining the company. We just say, okay, management, senior management has set these performance targets when they were only considering functional organizations. When we look end to end, you tell me and I have the people in the room, tell me, what do you think are the likely consequences of this measure? You know, the fact that we are dealing with an offshore payables group who will not accept variations of even one penny, but because of some other bizarre rules, you know what? What are the consequences? Well, people become much more open to change. And I think that, like your question is brilliant. Almost the key element of process change is helping all of the involved functional areas and the individual roles see that there is some overarching objective. There's also the concept of the differentiator. What do we really need to be great at? You can't have, you know, sales being great at customer intimacy and manufacturing being great at product leadership and finance and being great at operational excellence or everybody will be in conflict. So it's making it visible. And then I let the people help to craft new. Well, no, I take that back. You usually take this up to senior leadership and explain, you've got your people pulling in different directions and the performance measures are actually impeding the process. And I work at that level too. To come up with new measures and a new overarching sense of direction.

 

45:36

Jakub:

Now, I would like you to give me actually advice. So imagine that we are these data engineers, data guys that are working on this details level. So we are working with the information from the systems, but going for us from that little process that we are visualizing in our process mining tool is great, but we would like to take the next step. What kind of recommendation for us would you have? So that we don't get stuck in trenches on these, I don't want to say little problems, they are still problems, no matter how you put it, but thinking in a bigger perspective. Okay, I think I can answer that. So I've mentioned many times the process scope model. Trigger result activities, cases, and then I usually add to that a simplified scope model. I produced what I call a process summary chart and it may not even show the trigger in results. It may or may not, but it will show, here is the process, here are the five to seven major phases in the process and then we superimpose that on here are the functional areas that are involved in the process. And this is usually a real surprise to senior management. I was at a America's largest pipeline operator and oil refiner and I was going through this and the president of the company, suddenly he just faced palmed. He went, Oh my God, now I see why our process improvement efforts never go anywhere. And I said, Okay, Ron, that's great. Why? And he said, we’ve been doing functional improvement. Not process improvement. I said, You're a smart guy. That's why you're the president. And then what we can do in terms of adding value, we can then, for instance, under each functional area we can list, here are all the different systems each function is using or under each major activity.

 

48:02

Alec Sharp:

I also use this framework to show the primary performance measures for each function and, therefore, how they conflict with the process. So my advice, always get up to that process scope level and use that as a framework to put other information in context. So that's unfortunately that's only one. The other thing I like to do is build concept models, conceptual data models. So that's getting up to a business-friendly overview level. Where to put it simply, every entity in the data model is a thing that businesspeople discuss on a daily basis. So we're not talking fifth normal form granular tables. We're talking, you know, we've got customers, site, product, order, channel, and so on. And what I like to do is show that different parts of the organization are operating under different concepts, and that's why they're at loggerheads. In fact, one of the world's largest technology companies asked me a while ago, could you build for us a data modelling for data scientists class? And I said, Well, that's interesting. Why? And the answer was, Well, our data scientists do not seem to understand and that the word customer means something different to marketing. It's different in sales, it's different in logistics. It's different in operations, it's different in finance. And now and I had another case where somebody in a workshop in the Netherlands sort of faced palmed and said, Oh my God, I see now we've been building a data swamp, not a data lake. So in my data modelling classes, all the people coming now are agile developers who realize they need that underlying conceptual model platform, business intelligence people who need to understand operational data better Internet of Things, people, data scientists, not only SQL people, data lake people. Yeah, we all need that conceptual underpinning. Sorry, Jakub, it was a long answer, but I think there are very specific things we can do and we don't have to beat management over the head. We just have to say, Hey, we have something interesting to share with you.

 

50:43

Patrick:

That's great. So when we talk about changing the as-is process to the to-be process, there often tends to be a I guess sentiment of changing technologies is easier than changing the behavior of the people. And so a lot of improvements that are suggested is automating things with RPA or any other tool that you can think of. And so in your experience, how much is that like, what's the expression I'm looking for, overdoing the automation to a certain degree and kind of missing the point of the problem.

 

51:18

Alec Sharp:

Yes. Well, thank you. This is what keeps me in business because everybody, it's like we're in Star Wars, we're on a tractor beam and we're getting pulled into the world of of technical change, which may not actually really make a big difference. And so you have to understand then that people are scared about the resistance to change. So we get oh, it's hard to change people's behaviour. Yeah, it's hard to change people's behaviour if they are trapped in a poorly defined job and they are struggling to achieve process measures that are, well, I won't say stupid, but people do not blindly resist change to the status quo. An article that was written in the year I was born, like 69 years ago, there was an article in Harvard Business Review, the title was People do not resist technical change, they resist social change. And it was my first exposure to the idea that when we make change, if it impacts the equilibrium that a person is in, they know who they work with, they know who they take work from, where it goes to, they know the constraints from above, they know the support. They just have this comfortable spot. And that's why it is so important to have the people. My whole approach is based on simplicity and accessibility and the engagement of the people who do the work, the people who are actually going to have to change. And that's why we need to see that they are if we make a particular change, boy, I had a good example from a European Central Bank where you know, there was a change people wanted to make, but we could see it was negatively going to affect the measured performance of the people who we wanted to change. So this is why we have to take a holistic look. That's what the whole concept of the enablers is, a holistic look at all of the factors that impact a process. So when we use the term process, I do not think of the process as just a series of steps. I think of it as a machine that includes job and organizational design, performance measures, the layout of facilities. So people are much more accepting of change. Quick story, I had a client at a large US university who asked me, Alec, do you have a degree in organizational psychology or organizational change? I said, No, not at all. Why? And she said, Well, what we've noticed is when we follow your methodology slavishly, was the word she said, when we follow it to the letter, when we go through every step, what we're seeing is that the resistance to change that we always saw in the past, it simply doesn't materialize. And I said, Thank you. That's why it took me 25 years to figure out this methodology. But it was all about, you know, I would encounter a barrier and say, okay, what are these people resistant and then I would realize, oh, it's like that. I came up with the top three problems in process projects, and one of them is premature diagnosis of the situation. Well, people were resisting getting involved because they thought we already figured out what the problem was and what the solution was and it was going to be to eliminate their jobs. So, you know, it's a very holistic undertaking. As a CIO once told me, he wanted me to come in and just share best practices. And I said, sorry, it won't work. He said, well, why not? I said, because your people won't trust it. They got to go through all of this. And he had a beautiful line. He said, Oh, I get it, you can't skip the therapy. And a well-handled process change project really is therapy.

 

56:15

Jakub:

Alec, should people know more about your therapy and about the way that you are addressing these issues? I know that you've been active and you have not only the book, but also other channels and other sources where people can go and find out more about how you are helping in these process related questions? Where would you go and point them to?

 

56:40

Alec Sharp:

Absolutely. The first place to go would be I would start with the webinar that I did for Lucid Chart. So Lucid Chart Diagramming software for the web. They had me do a 45 minute webinar on just the fundamental concepts you need to know about business processes. And then after that they contracted with me to produce webisodes. So each, webisode we did eight webisodes, each of them is 12 to 15 minutes on one important concept in the approach I take. So there is a webisode that explains my overall methodology, there's a webisode on how do you actually engage people Bottom-Up in discovering processes, how do you design a new process? So those are my wife tells me I gave too much away. There's a lot of resource, free, just like what you guys are doing.

 

57:51

Jakub:

And you, dear listeners, will find a link to these resources in the description of our podcast episode. So if you are interested in more what Alec is doing, you will be able to find it easily. For the rest of us, this has been a lovely episode. So Alec, thank you very much for accepting the invitation to Mining Your Business podcast. As I said at the beginning, I love looking at the areas that we might be somehow missing just by the pure effect of what kind of job and what kind of tasks we are doing. So thank you for enlightening us.

 

58:29

Alec Sharp:

Oh, well, thank you so much for asking me, you know, I learned a lot as well. Thank you for your well-considered questions. I really enjoyed this. Maybe we can do it again sometime.

 

58:43

Jakub:

Let's do it then.

 

58:46

Alec Sharp:

Okay!

 

58:47

Jakub:

Yeah. So for the rest of you, thank you for listening. As usual, we ask you if you if you like us, just rate us on Spotify, on Apple Podcasts. If you have any questions, you can find us on LinkedIn. Also, you can drop us an email on miningyourbusinesspodcast@gmail.com It will be lovely to hear back from you and, you know, telling us how you are enjoying our podcast. So thank you very much thank you, Patrick. Thank you, Alec. Talk to you next episode. Bye bye.

 

00;59;17;17 - 00;59;19;02

Alec Sharp:

Okay. Thank you very much.