Process mining, the hipster child of the process industry with Roland Woldt, author of What's your Baseline Podcast

00:00

Patrick:

You know what time it is. It's time for another episode of the Mining Your Business podcast. The show all about process mining, data science, and advanced business analytics. I am still Patrick and with me still is my colleague Jakub, hi there.

00:14

Jakub:

Hello, Patrick.

00:15

Patrick:

Joining us today is Roland Woldt, Business Transformation Architect at Software AG and Podcast host of the What's Your Baseline podcast and blog. We will be talking about the ins and outs of business process management, the steps of a process life cycle and the hipster child of BPM. Let's get into it.

00:39

Jakub:

We are biased. We do process mining and sometimes it feels as if we had this narrow vision and did not see and accept that there is a whole world of business process management, so-called BPM out there. To tell us whether we are guilty or blessed by the fact that we most of the time focused solely on process mining. We have invited today's guest, Roland Woldt, Business Transformation Architect at Software AG and co-host of the podcast What's your Baseline., Roland, welcome to our podcast. How does it feel to be on the other side of the mic?

01:12

Roland Woldt:

Thanks guys for having me. I feel honored and blessed to be on your show.

01:16

Jakub:

It's great to hear. We feel honored and blessed to have you on our show as well. And Roland, first question that comes into my mind is, you know, when checking your LinkedIn profile and digging into your history and past, how does an Army guy end up in business process management?

01:37

Roland Woldt:

That's definitely an interesting story because I think there's no relationship there. But maybe, maybe I talk a little bit about it so get the idea. So in the tender age of 19, I got drafted into the German armed forces that was back in 86, which just tells you if you do the math, how old I am. And as part of that I looked at, Hey, what am I going to do after my military service? And one of the options was, Hey, why don't I stay longer and become an officer, which I actually did at that point in time, and that stayed almost 11 years, too long of a story. But I was twice a platoon leader of a tank platoon, and my last gig was being the head of a department in a tank battalion staff and all these type of things that you do. And then at the tender age of 29 I retired and I went into consulting. So I spent six and a half years with Accenture working in their change management competency CMS Change Management Services, I know that's appropriate to say, chicks making slides. That's how they called it back in the late 90s. And Accenture made a switch roughly this year when I was in From the Competencies to Industries, and I worked in the telco industry. So with clients like Deutsche Telekom and T-Online, T-Mobile, and that is where the process topic basically came up and we wrote processing manuals and all those wonderful things that nowadays nobody does anymore. And in 2003, I switched jobs and I went to a company called Ideas Shear, which was at that point in time, the third largest I.T company in Germany. And as you might or might not know, Odysseus, the developer of the errors tool and the Errors methods and we were using that at the German Armed Forces where I spent another five years as a consultant and as a reserve officer. So I did one reserve training in the Ministry of Defense where they had a very nice office and it says Captain Woldt, and all those wonderful things on the door signs. Nicely done. I appreciate that. And yeah, we had them with implementing SAP and I was a project lead for the solution design. You know, the process mapping and all those type of things that happened there. And then back in 2009 and in all reality in 2011 Software AG bought Ideas Shared and in between I moved to the US at the end of 2007 and my last gig with software AG at that point in time was being the head of their enterprise architecture services in their global consulting organization.

04:18

Jakub:

Roland, before we proceed, let me just get this straight. The German Army uses SAP?

04:26

Roland Woldt:

Yes.

04:29

Jakub:

That is interesting. I never knew that. Yeah, maybe we should.

04:33

Roland Woldt:

Yeah. That program was called Standard Application Products Software Families, which in German is one word - Standardanwendungssoftwareproduktfamilien. Patrick will appreciate that. Yes, and one big part of it was SAP's ERP system and that. But that had other tools around it.

04:54

Jakub:

Yeah. For our listeners, in case you ever wonder it, where do those strange names in SAP come from, well, it's the German language, so get over that. However, Roland, I have a question for you. So right now, what you do, you are in Software AG. You work as a business transformation architect. What does this even mean?

05:17

Roland Woldt:

That is a very good question. And I think you don't find a job description for that. So the role that I have is and maybe just to wrap up my history, I spent seven years with KPMG here in the US running their enterprise architecture offering out of the business now. But the business transformation architect, I'm working in a group here which is located in our sales organization. And what we do here at Software AG, we have two tools that we sell. One is Aris for the more business oriented people and the other one is Alphabet for the more I.T oriented people. And we call those our business transformation suite. So the role that I currently have is the mix of, I would say high level consulting, doing business cases with clients and help them in general, but also pre-sales and also evangelism. And this is how my wonderful blogging podcast came about.

06:14

Patrick:

So essentially what you do at Software AG is you, let's see if I'm getting this right, you would talk to clients and see out of these two suites, like what you can offer them and what they kind of require for them to transform their business. Is that right?

06:28

Roland Woldt:

Yes, basically, yeah. Get their requirements, see where they want to go, see how we can support them. Either with software or with the services that the firm provides.

06:39

Patrick:

Now, is there some sort of overlap between being a tank commander and battalion leader of a of a tank platoon, which is focused on, you know, destroying things with tanks up to now, building things as an architect in businesses? Is there some sort of overlap here?

06:55

Roland Woldt:

I've never seen it that way. But I can tell you one thing that you learn when you're an Army officer is you learn how to make decisions without knowing everything. So there's no CIA or other things that you would like to see in corporate America or in every corporation. But you're just saying, OK, this is the right thing to do and to wrap it up on this is one of the things that you learn because you obviously get trained to be a leader. Is a simple statement to say, OK, you rather make a wrong decision, then? No decision. And I think that's an attitude that I took over into the job afterwards what I'm doing now for 25 years.

07:39

Jakub:

Mm hmm. I will not go into asking how many wrong decisions have you done since then, because we all make those. What I want to discuss now as a first part of our interview here is you mentioned a word evangelist, when it comes to spreading the ideas of business process management and what you've been doing and what's clearly a passion of yours is spreading the word through your platform, podcast, and also a blog and generally a website - What's your baseline? So what is that? What is What's Your Baseline?

08:17

Roland Woldt:

whatsyourbaseline.com is obviously a website, right? And the idea that I had for that was actually born back in 2005 2007. So much about wrong decisions that I didn't start earlier. I burned through two domains that I never used but paid for. And then last year I actually said, OK, it's time. You're not getting younger anymore. So now you go and start the stuff, right? And I'm using this as a creative outlet, obviously, I learned a lot about podcasting and technology and marketing and all those things that I haven't done before. But I also use this as sharing knowledge. So I go and write articles, and the majority of those articles, they are, I would say basic things that I also could use in my day to day job, you know, because the questions of clients who get started with these topics are always the same, you know, how do I implement things? How do I structure things, how do I do this and that and that? And I just say, Oh, I've written an article about this, and then I share the link with those guys. And that saves me a lot of talking, obviously.

09:26

Patrick:

So what's the motivation now that it's been going for some time? Where do you foresee it going? Do you have some sort of goal that you want to get to?

09:36

Roland Woldt:

Not a goal in whatever, something that's countable, you know, money or followers or whatever you want to put in there. So I think it's the satisfaction of sharing knowledge and having interesting conversations with guys like you, you know, because we didn't know each other until I reached out to you, you know, so that's more of the thing. And then on the other side is obviously things like building a personal brand, you know, and having people reach out to me. And maybe an interesting job comes along that I wouldn't have the opportunity to get without this.

10:1

Jakub:

You mentioned that there are a lot of questions that people are asking. Is there some general way or general one that would keep repeating itself and that you think is vital and that you already provided guidance through your podcast and through your work on?

10:30

Roland Woldt:

Yes, and maybe take a step back and think about who's the audience for our website and our podcast. Right. So we're aiming strictly not strictly. We're aiming at the people who are the practitioners, people who run an architectural practice or a process management practice, and they just get the question of like, oh, damn, how do I do this, right? We're also aiming at their bosses, you know, the people holding the purse, because obviously you need to justify why do you want to do this and that and that, and why do you want to spend whatever $50,000 or $100,000 on process mining? And you better have a good answer. And the one question that comes up, and this is based on my experience being in charge for the EAA, offering itself edgy, but also the EAA offering at KPMG. I think architecture as a discipline is completely underrated, not professionalized. I don't know how to say this, you know, even though these are decades old, you know, Zackman was in the eighties, if you will, but there's still no consensus about, OK, what does an architect actually mean? And I find it interesting listening to your latest episode, which is obviously months ago when this airs, you were talking about a process mining architect. And I was just thinking while I was driving, oh, that's an interesting question to ask the guys how they find the word architect, but anyways, I digress. So it's getting those questions. That's why should I do EA, why should I do process management in general? And the beauty of it is when you look at our audience, there's always new people, right? Everybody starts at some point in time and they all ask the same questions.

12:12

Patrick:

Now, since starting, what has been the most surprising thing that you found out while doing the podcast and the blog?

12:21

Roland Woldt:

The most surprising thing is that I don't know about 30 people per day read my ramblings on the website and it's two hundred people a week listening to our shenanigans on the podcast, which I find very humbling and very exciting.

12:37

Patrick:

Absolutely. So are you enjoying doing it?

12:40

Roland Woldt:

Oh, yeah. Yeah, yeah. And I'm sure you've listened to our show. So J-M, my co-host and I, we have a good chemistry and we're having fun just preparing all the stuff that we do and then talking to guests and getting their perspective on things. So when I think about our current season where we're looking at three major topics basically, and each of our seasons, 12, 13 episodes, right? It's half a year, and then we take a break in summer and over the holidays, the three things that we look at in this season is obviously topics around how do I run my practice? It's EA and business process management topics so content and it is what's the new hot stuff that's out there? So again, we will talk about process mining and task mining and all those things because that seems to be the hot stuff.

13:32

Jakub:

So I have another question. Maybe if our listeners don't know your show yet, is there maybe an episode that you would, I know that you are proud of all of them, obviously, such as we are, but if there is one episode that you would recommend our listeners to just go and listen to, to get acquainted in the topic from a broader perspective.

13:57

Roland Woldt:

Yeah. Besides the fact that we will have an episode in summer where we have some guy from the Czech Republic on our show, I don't know who that is, which, which will spike our statistics immensely. I think I would recommend people to listen to episode two, which is "Why Architecture and Process Management?" episode, which is actually also the one that most people have listened to. And then from there, I think you get a good idea of how do all those other topics and as the title of this recording, we have published 16 episodes so far, how do all those other topics relate to it?

14:33

Jakub:

So sounds great. And one last question about your blog and podcast. What does the baseline really stand for? I was always wondering.

14:43

Roland Woldt:

Oh, you don't know that? Well, so little history or look at project management. Typically when you do your planning, you make a cut of your planning. That's called the baseline. And then each additional iteration on your plan is then compared to the baseline plan. So that's one idea because the initial idea of the whole blog was about how do I manage these type of projects? The second thing, and I think that becomes more important by now is, well, if you do improvements, you need a baseline that you measure your improvements against. You know, what is your as is and process mining is good technology for that to get that understanding where we are. But the more interesting thing for business is obviously how do we improve and to which degree do we improve. So that's my question. What's your baseline?

15:37

Jakub:

Well, thank you for clarifying I will keep that in mind next time I see this word. Anyhow, let us move on a bit into the main topic of today's episode, which is, you know you were a host of a podcast before where you called Process Mining, a hipster child of BPM. And well, the good thing about having a process mining show is that we no longer need to explain what process mining is.

16:04

Jakub:

So we can skip a lot of explaining here however, as I said, the main focus should be whether us, process mining architects, let me use the word architect again. Are maybe unjustifiably stealing the thunder from you guys, from the BPM architects. And if you could elaborate a bit more on that and why did you even use these words, like a hipster chart of BPM? It's very interesting to me.

16:37

Roland Woldt:

So that's a little play on that obviously process mining is the hot thing nowadays, you know, so that there's no deeper meaning. Obviously I'm super jealous about, about your hairdo, Jakub, because that's way past my prime, but there's no whatever derogative meaning on this. It was just a wordplay but to your question underneath this, I don't think that there is a them or us, but I don't think that it's process mining or BPM, BPM or architecture. If you think about it in the even bigger topic, I just part of the same thing they have different functions that they do. There might be different methods how you get stuff. But when you look at process mining, to me the first and foremost objective of process mining is to getting a realistic data driven perspective on the as is process, you know, what do people actually do, right? What are the frequencies, the times, all those things that you guys have way more experience with than I have. But that's not the end of the story. It's not a purpose in itself. The question to me is what do I do with those data points? How do I transform them into information and how do I transform the information into insights that I then can use to think about, Oh, how do I improve the situation?

18:04

Patrick:

So you think that the business process management in and of itself is kind of like a bigger picture vision of a business processes and does a BPM kind of initiative need to require process mining, or is it just a nice to have but not necessary?

18:23

Roland Woldt:

So, wholeheartedly yes to your first statement, I think it's part of BPM. It is a method, like I said, to get an as is. There are other process improvement methods out there and depending on when we would have recorded this episode in the 90s or the early 2000s or whenever you would have received a different answer because there's always something new that goes through the community. You know, think about the value stream revolution by hammer in the 90's or think about the Japanese Kaizen attitude of improvement, or think about the Lean and Six Sigma folks where tons of money was made, Those are all methods of BPM that all have their place somewhere in it. And that's the same with process mining. It has its place in the bigger picture of BPM.

19:14

Jakub:

Mm hmm. Why do you think that people are now so excited about this technology? And you mentioned it also on your podcast that it feels kind of that suddenly young generation starts caring about business processes in the first place. While this wasn't the case, merely even ten years ago.

19:34

Roland Woldt:

Well, now you hear the old guy talking because there's money to be made. All right. It's always when you think about the Gartner hype cycle I don't know if you've seen those concepts, you know, where you have basically a curve where you go through and at the beginning you have those expectations that just cannot be reached and I think process mining is at that place right now. It's a new, exciting technology. Nobody knows really what it is. And just to give you an example, a few weeks ago, I gave a talk at the Apex Conference in Miami, and I started my talk with a show of hands and I said, Hey, of those 40, 50 people who are in the room how many of you already have a process mining initiative going on? No hands raised. How many people of you are thinking about it? And about a quarter of the hands went up. So that just tells me it's super early. People need to understand the value prop of process mining, you know, the speedometer of how you do your business, how fast you're driving to steal a quote from James Denning and figuring out how do we implement that technology? And because we're at that upward trajectory before the Valley of Despair comes in that hype curve, people are super excited about, and that's why they want to have that new technology.

20:56

Patrick:

Now in order to get over this valley of despair, does process mining need to be implemented inside of a BPM initiative itself to kind of give it more context? Or is process mining fine on its own as a standalone type of initiative?

21:11

Roland Woldt:

And let me ask you a different question. If you have a car, is it sufficient to drive your car? The answer might be yes, because you have that wonderful new whatever golf GTI that you want to drive on the Autobahn, right? That might be a value in itself. Is it better embedded if you have a plan to bring a box of chocolate to your grandmother and using your golf GTI to drive to her? Maybe, you know, so I would say obviously it should be embedded into a larger perspective. But most clients obviously start with a POC or a smaller project just to get their feet wet.

21:50

Patrick:

Are these types of projects doomed to fail in in your opinion?

21:53

Roland Woldt:

Not necessarily. It's more about the maturity of the people who do this and this is one of the things where I think if you pitch it to I.T. Departments, you know, we're all geeks. Everybody is super excited about new stuff that they can play with. Then it might fail. If you are able to bring the business people in and to show them the value of what you're doing and make it tangible what the advantages are and what the improvements will be and how you ensure that you will reach those targets compared to your baseline that you discover with process mining, I think then you will be successful. But it's more a matter of how do you not change the culture but pick up on the culture. If an organization becomes architecture oriented, process oriented, if you will.

22:41

Jakub:

Now, what is happening in process mining world last couple of years is that it's shifting heavily towards this pro action based process mining. So it's not only about discovering and exploring your processes anymore, it's also about, you know, creating an actual tangible value out of it. It's very exciting because some of these vendors obviously come up with very cool suits that you can just use to create automations reporting and auditing systems and so forth. But do you think in terms of the bigger picture that this is the right way to go, considering that you mentioned it yourselves, that that process mining should be ideally integrated into this BPM and overall architecture model rather than to use process mining as this tool to fix two or three of your problems without any regards to what is happening elsewhere.

23:38

Roland Woldt:

I think that's a very obvious question or very obvious answer that you will get. But just to have it said, we saw FMG will bring those notification alerting action capabilities with our next release of our process mining tool as well. So that's definitely a trend and I agree with you Jakub, a trend that goes to hey, how do I get into the execution space, how do I get into the runtime systems? This opens obviously an open flank because you have tons of other systems in an organization already. You know, an SAP service, now a Salesforce, whatever pick your choice. They all have those workflows capabilities. So the question is where do you draw the line? And I think it's important to not lose the big picture, right? What is process mining actually meant for? And it's meant for two getting that as is driven by data and what do you do with it are things that you do in your process or solution lifecycle, if you will.

24:45

Jakub:

Ok, so maybe my next question would be like, when do you know that doing just process mining is not enough anymore and you should consider other options really? Or as you mentioned, looking at the bigger picture and assessing the whole process lifecycle.

25:05

Roland Woldt:

I think it's not a digital question, right? I think it's a gradual maturity curve that you go through with the people. You know, like I said before, if you have somebody who's excited about the technology and who has the budget, by all means go for it. Right? At some point you will come to the question, now what? What do I do with that result? You know, I did all those exercises. I captured the data from obscure systems, I did the transformations, I built the dashboards. I whatever you did all those things. And then, what do you do next? And I think you need to have an answer for that question. And then the natural way is going into process management, right? And think about, OK, how do I improve it? How do I measure my improvement? How do I transform my organization? So it's more similar to the question like, hey, Jakub, I have that new hammer for you. When do you start building something?

26:08

Jakub:

I'll think about it. Let me first try to figure out where I can make some action with it and, you know, get some interesting insights.

26:16

Roland Woldt:

Take the hammer and hit your thumb and see if it turns blue. Now, be my guest.

26:23

Patrick:

If we look at the as is process, that process mining can provide is the BPM, then the parts where you go from the as is and you shift over to your to be process where you look at the inefficiencies and you start really changing the way your business works. I'm imagining that a lot of clients will say that a whole BPM initiative will take a lot more time and the whole life cycle of this BPM initiative will be longer than just simply implementing a process mining implementation.

26:56

Roland Woldt:

It will be a little bit longer, of course, because you do different things, you do more things. But I think it's important to put things into a context so that you get the higher level of value out of your initiative. The way how I typically pitch it is to say you must have something like a process lifecycle. And the big challenge that I see in organizations is they don't know in the beginning what runs. You know, they have no documentation or it's distributed or it's documented in word on a SharePoint listed alphabetically by project and by year. And we all know six weeks after you store that document, it's outdated and you will never find that information again. So that's the first challenge. How do I get this enterprise baseline? Right? That's obviously tools for this. We, Software AG by coincidence produce one for over 30 years but this since I heard you also an Equal Opportunity podcast. There's obviously other vendors as well. We have similar things or when you talk to the agile folks, the scaled agile folks, they would call that a solution intent repository, which is quite a mouthful. But at the end of the day, what you want is you want to have a database where you have a different architecture of use, your processes, your apps, your orgs, your data being related to each other in a current state. And then you take this as the first step of the solution lifecycle or process lifecycle. You do an analysis on it, right? And you say, OK, where are the areas that I want to improve upon? And once you figure that out, you come up with a plan, you know, a high level plan. Transition states, if you want to have some architect lingo in here, you know, where do I want to be in six to eight months from now? And once you have that as part of the as is the analysis as well as the plan as your baseline, well, guess what? Then you go into your solution design. And in your solution design, you take exactly one transition stage and say, OK, I don't care what happens in 12 or 18 months, how do I improve this thing within the given timeframe? And you come up with a design that then goes inevitably into some form of implementation, which could be a system implementation or a org change or whatever you come up with, a process change, whatever you determine as part of your analysis, as part of your solution design to be the right thing to go forward. The challenge that you see is you might have a difference between what was designed and what was implemented, because at some point in time you go live. So that's one thing that your tool should support to make sure that this is the right thing because what was implemented will become your new what runs in your enterprise baseline on the go live date.

29:47

Jakub:

And so this what you just explained would in essence be this process lifecycle that you call.

29:55

Roland Woldt:

There's a bit more to it. There's two more phases. So I described three by now, you know, the enterprise baseline, the high level strategy and roadmap and that stuff, the solution design and the implementation. Once it went live, you obviously do your processes. You're in the execution phase. All right. So now if you think about you would be a manufacturing organization to make that very visible, right? You see a conveyor belt, you want to know, do I produce the right amount of widgets in the right amount of time, in the right amount of quality? And that is your focused day in, day out. So you want to have dashboards and all those things that will give you the insights, so that you can react immediately. And then the last phase of it is when you take a step back and this is where process mining kicks in, where task mining kicks in. This is where you want to go and see, do I see patterns? It's not the day to day hustle, but on the longer term, do I see patterns evolving? Do my users actually do what they're supposed to do? Good process mining tools like ours allow you to upload a BPMN process, which is your solution design into process mining. And then process mining will compare this to the data set and will tell you exactly where you deviate and will give you a punch list to say, Oh, this is what you should improve first. So five circles, high level strategy, solution design, implementation, execution, and then measurement and analysis.

31:30

Jakub:

You mentioned a manufacturing process. Do you think that you could now take this analogy of process lifecycle of these five steps and use it for this specific example? How would it look like, in your opinion, in your eyes, to have a properly executed process lifecycle for, let's say, manufacturing? But if you want to use our favourite example with like purchase to pay or something, be our guest.

31:54

Roland Woldt:

Well, it's the same logic behind it, right? You want to know how many, if we stick with a procure to pay, how many orders do I have that come in time at our warehouse, how many touchless orders do I have? You know, so these type of things that's the same scenario, like with a conveyor belt, you know, you might have some SLAs for it and you say, oh, it must not take longer than this. And you just measure it with the reality that your process mining tool will give you.

23:29

Jakub:

How do you know if an organization is doing a good job and actually a bad job on this process lifecycle approach.

32:43

Roland Woldt:

You see me pausing for a moment here, because you run into the situation that a lot of clients being excited about the technology, you know might not have had those thoughts. They don't know what they measure against what, their baseline is, what good looks like. And that obviously is a hard thing then to sell your results because it could come to a point where they say, meh we already knew this. Or new eye opening things, like, oh, this is what we're doing? Or you get a super big spaghetti diagram in your explorer. And they say, What is this? This is not us. So it's it's a full bandwidth of reactions that you might see but I think the important thing is that you frame the conversation correctly, and this is why I said the lifecycle is so important because it puts things in a bigger picture and process mining gives you the baseline to say, ok, where do we want to improve?

33:45

Patrick:

Now, the focus of the lifecycle being or I guess in my view is the cycle part, right? Because you want to evaluate your processes in some intervals, right? So in your experience, how do you go about saying, OK, we have implemented this now in six months we're going to evaluate and change it and do something different again. How does that translate to the process mining aspect and also the overall general BPM initiative?

34:16

Roland Woldt:

There are two answers to this. The purist of me would obviously say, Oh, you must have a schedule, you must have those regularly scheduled touch points and see where we are. And then there might be the reality of where you hook up your process mining to a runtime system. So not just a CSV upload off a static data set, but something that's live, right? Which is obviously more interesting, but also the more complex thing to do. And it might be a little bit finicky, you know, and it might break. So that's an added complexity that you obviously don't want to have in a POC for example. But I think a mental change has to take place where people say, OK, I want to know how I am doing, not every three months or every six months. I want to know how I'm doing now. So to stick with that analogy, you know, if Patrick, if you hop in your golf GTI I drive to your grandmother, you want to know how fast you're driving. And that's obviously the point that you can ask your passenger and your passenger takes a while to guess or you turn your head and look out of the window and look for the trees and take a wild guess. Or you just look at your speedometer in your dashboard and it tells you exactly that you're driving 160 miles an hour over the Autobahn. This might be a little bit too fast, you know, but that is, I think, the mental change that needs to happen, that people, organizations get used to have a speedometer, which they didn't have in the past, because in the past it was all reports. Been there many many times where you have some young person on the project whose only job is to take data from their ERP systems and assemble a power point "dashboard" You see me doing inverted commas, right? And that will then be submitted on a silver platter to the project leader who then proudly takes it to the status meeting. This is just a waste of time. So I think if you have something like process mining in place, you just see how you're doing and how fast you driving right now. And that is the qualitative change that we see today.

36:30

Jakub:

I would actually like to still stop and revolve around those steps in your life cycle a bit more, as I saw your presentation as a part of preparation for that. And you basically already mentioned it. You divided it into five steps, measure and analyze high level design and program road roadmap, solution design, implementation and process execution. So basically they are divided into two categories in a design and execution. And what I would like to understand a bit more thorough is like, what do you do in each of these phases in an actual project and what kind of tools you might be using to execute this. First one being the measure and analyze, and I think we already talked about it quite a lot. That's the, that's basically the, the phase where you use the process mining as your ongoing continuous measurement of your process. Is that right?

37:24

Roland Woldt:

That is one part of it. You obviously might use task mining or project robotics process discovery technology, you know, where you have little bots installed on users desktops that do screen scraping and all those type of things. You might use that technology if you see, for example, a big spike in your process mining analysis and you're just wondering what the heck is going on there. In an ideal state, I would throw our root cause miner first on that spike to say show me does that happen just in a location or is that a certain vendor or whatever the reason is, but that might not be granular enough So for example, if you have an activity that takes forever, see my eyeballs, like a teenage California girl, it takes forever. You might think about, hmm, maybe I look at test mining and see what those users do because you might have different outcomes, but it could be the user just don't know what to do. You know, the UI is so bad that they don't know where to click, right? So the mitigation of that would be more training or change of the gooey right it could be that they are waiting for information. Oh, that damn vendor never sends the PO number, right? So I have to pick up the phone, call them, you're on hold. You never get the answer. So it just stalls. Or it could be that a technical interface does not work. You know, a system A does not send data to system B and the users are the swivel chair in our face. Right? They type in the information by hand, which obviously has the risk of being error prone and all those type of things. And task mining can give you those insights. All right. And the other use case for task mining would be if you have a process that does not have an event log, you know, there's a step in your process where people do calculations in Excel, for example. Right. And task mining can give you the information on that step. But don't look just on those two things to your question, Jakub, there's more you can do. But look at the compound folks. Just go to the place where it happens and do an observation, talk with people. What a strange idea in the 21st century. Talk to people and ask them where they see the problems. You know, so that's the quote on quote, traditional process improvement methods, which I think are still valid and should be part of every business analyst or business architect's toolkit.

39:53

Jakub:

Mm hmm. And then let's move to the other dimension. So let's say that we figure out where the problems are. We measure, we analyze, we discover our processes, but not only those processes discover what's going on in our own organization, and we can actually put a label on the things that are happening and quantify it, measure them and so on. And then we go into the high level design and program roadmap. So we take these findings. And my understanding of this step is that we, you know, meet with the people responsible for the process, you know, process owners and so. And we discuss with them how the process should actually look like. Is that correct?

40:36

Roland Woldt:

You're a little bit too fast. I think there's this two steps in between. So that the first assumption is only what you brought down to paper is something you can look at and you can discuss. But I think we all agree on this. So since in the design phase, you use a different tool than your process mining tool, you use one of those architectural repositories. Your process mining tool, like ours, should have a very boring button that says transfer discovered process model to errors and it shoots over and it creates a BPMN diagram in the repository. And in the repository you then can create those connections, you know, which applications support, which step. You literally draw a blueprint, right? Because the applications might come from your seem to be your risks might come from your GC tool, you know, an arch or a metric stream. Your org might come from your ERP system, you know, your roads and all that type of stuff. So what you want to build in that high level design is that network of information, the different architecture views and show how things are related to each other, because that allows you to do an impact analysis. If Patrick has that idea, oh, that's great, let's just kick out this whole step there, or let's just implement another tool that supports this step that gives us some heartache. Yeah, well, guess what you want to know? Well, what does that mean for my twenty five other systems that are already half doing that task? And wouldn't it be a better idea to standardize on one system instead of having 25 different systems supporting this step?

42:12

Patrick:

So it's more about giving additional context of your process steps with the tools and all these things to measure the impact of what these things have. Is that right?

42:24

Roland Woldt:

Yeah, it's called architecting, This is why I find the architect name so, so interesting because there's no hard rule what it means. You also want to map everything to your strategy. So you should have strategy models, you should have your KPIs being defined, you should have the requirements somehow captured to put that into perspective and then being able to have the full visibility and being able to determine the impact of a potential change when you have an idea because everybody of us can have a great idea. But it's the interesting task of an architect to analyze this and then say, yeah, that makes sense. Or maybe the other idea is better because then we're talking about timelines and cost and impact on running projects and programs and whatnot. You know, that the reality in organizations is messy.

43:18

Patrick:

And so it sounds like this is a very crucial step. And is the somehow achievable through process mining process.

43:25

Roland Woldt:

Mining is a good input. I don't think that process model and this is why I don't buy into the story that our competitors tell us, you know, to say, oh yeah, you just need process mining and you can do a simulation. And Jakub knows my feeling about what's the relation in this context. In in our process mining tool and you just need to change these things. But I think they fall short because, A, they don't have that context that I just described that you would have in an enterprise baseline in your repository that other people have access to. That's also a cost issue. How many people do you give access to your process mining tool versus the repository, which are significantly cheaper.

44:05

Jakub:

So as a next step in your process lifecycle, you have the solution design. And this is basically where you take all your findings that the high level design and program roadmap and you kind of put it into motion, is that right? To finally have the overview of all your systems and you try to create a unique ecosystem, an environment where they all function together.

44:32

Roland Woldt:

Mm hmm. Yeah. Let me give you an example. So as part of your high level design, your roadmap development, you have the idea that the town where you live, in fact, you need another hotel, right? That's a need. You know, people need accommodation. A hotel is the solution that you're aiming for. So would be your next step to go to your home improvement store and buy two by fours and nails and hammers and start hammering? No, you wouldn't. You would go to, quote on quote, a real architect. And they would do their magic. They would do drawings, they would do load calculations. They would think about permitting with a city and all those things that you need to do a proper design. And that's basically the solution design step in the lifecycle, right? So I'm not a big fan, and that's always the conflict with people who say we're agile. We don't document anymore. Well, what I say, that's just bs. You still need to do this, because at the end of the day, you wouldn't build a hotel without having a professional giving you the OK that what you plan to do will be actually strong enough to stand on its own. It will not be a danger for society or the guests or whoever.

45:44

Jakub:

Well, maybe Jakub would with a hammer, haha.

45:50

Roland Woldt:

Haha, many IT organizations run that way. You know, hop in your pickup truck, drive to the home improvement store and buy two by fours. Don't get me started on that, but I think you should take that step back, you know, and have a pause and make clear what will you build in which time frame? What are the features, which requirements do you accomplish and what are the processes? What are the application landscapes? What are the changes to the organization? You have those nifty org change management people, you know like me 30 years ago, that asked silly questions like what has changed, you know? And the typical answer back in the day was, I don't know, we're just implementing the new system, you know, and that is not satisfactory for your end users. So the solution design phase is coming up with that detailed architecture drawings, that business and technical blueprint as SAP called it many, many years ago for one transition stage.

46:51

Patrick:

So my question is, who is involved in this solution design? In your analogy of the architect, it sounds like there's one person that is kind of responsible for helping design this, but how many people need to give input and who are you in this solution design?

47:08

Roland Woldt:

So that opens a can of worms, of questions. And I point you happily to some blog post that I wrote about this, but in general, what I see is you have different roles in an architecture program. You have your specialists, your whatever business architects, your application architects, your tool specialist, you know that you identified that you want to bring in. Those guys, bring a part of the puzzle to the table. They just know what they know, right? So what you need is another role, a solution architect who makes sense out of all those individual contributions that you see so that you can say, OK, we're going to implement this and that and that, and this is how it fits into the bigger picture. And these are the benefits that you would get from it. When you think about larger organizations, you might have a level above, you know, somebody like a solution portfolio manager, if you will, who coordinates the different things that the solution architects do. But at the end of the day, it's always the same question. What are we going to build? How does it fit in? What do we want to accomplish? And what are the changes that we have to do without breaking things and without doing redundant things?

48:22

Jakub:

Ok, and then you move to the execution phase, and there you are actually divided into two categories. First, the implementation and then the process execution. I assume that the implementation is ok, so our purchase to pay process we had there problems with our scanning system of orders or something. So we need to replace it and then we need to implement a new monitoring system to make sure that is actually running well. Is that right? So basically, you are then focused on the technical implementation of the new systems that you want to incorporate into your process.

48:58

Roland Woldt:

It's three things that I typically say that an architecture program should have. It's the content, its governance and its adoption, and it's similar to your implementation project. Of course, you will implement your new system, but there will be techies that will be some wrenching going on. There will be testing and all those things that you typically do there. But you also need to have for that program that implements it. You have to have some governance defined like who's doing what you know and what does the individual have to bring to the table and who approves. But you also need to bring in and that's my topic, you need to bring the people with you. So that's the whole adoption stuff. Where you have your change management and org management people doing communication and training and org design and all those things that J-M and I chatted about in episode 17 of our wonderful podcast. If you're interested in our thoughts on org design, but then you obviously focus on your tech implementation because that's the whole purpose, right? Just keep in mind, when you do those tech implementations, they have that nasty thing called timeline in the back of their mind. You know, they have a launch date and everybody's working towards that launch date. So what happens now if you start coding, if you start doing more detailed designs or whatever you have to do, you have some poor guy who needs a decision and those guys might not get the stakeholder in time. So they make assumptions and those assumptions might be different than what you have designed in your solution design. So this is why I said earlier, there's a difference between what was designed and what was implemented. And you need to make sure that obviously your design would be updated with what was implemented because it becomes the new what runs in the enterprise based on.

50:51

Jakub:

Ok,and then you move to the last step of the process execution. And this is also the step where you with your process mining, find out that you didn't do a very good job and your process is still very faulty. Is that correct?

51:03

Roland Woldt:

The first thing is you go live. And one thing that I highly recommend is as a team is two things. One is celebrate. You accomplished something. You know, we're all humans. We want to have success. You know, you did this. The second thing is you should think about what are the KPIs that I want to measure against. And I've seen too many projects where you had meaningless KPIs. Like how many trainings did I do, you know, as part of my rollout, who cares? Right. I think the more meaningful KPI is, does Patrick, as the user of the new system, six months down the road can work more efficient than he did on day one, right? And I've never seen a project, to be quite honest, that ask those questions, which is one reason why process management and architecture also immature as disciplines, because you don't have a consensus on what are the KPI that you want to measure things against.

52:04

Jakub:

Roland, I think I have one last question for you and that would be what can we as process mining architects learn from you as a business transformation architect?

52:15

Roland Woldt:

Have an open mind. Don't get hung up in the technology, don't get hung up in the vendor spiel. You know, like, oh, you just need process mining and everything else, you know, but open your mind and look at what the reality is that organizations work with. That might not be fancy, some of the organizations you might look at and say, really, that's what they're doing? You know, that's not high tech at all. I'm not interested. But at the end of the day, I think all of our tasks is to make organizations run better, to make a better environment for the people who work in those organizations and obviously produce the right goods for their customers because that's the person who actually pays the bill.

53:00

Jakub:

Yeah, I agree. Hundred percent agree. All right, then, Roland, where can people find you if in case they have any questions?

53:11

Roland Woldt:

So I'm obviously on LinkedIn and I'm pretty sure you're going to put my LinkedIn URL your in your show. I would not have expected something different. The other thing is, obviously, you can go to our website, whatsyourbaseline.com and if you're interested in our shenanigans in audio format, it's whatsyourbaseline.com/podcast and you can subscribe to our newsletter and all those wonderful things to stay in the loop in what we're doing there. And I would encourage every one of your listeners who's interested in either the technology that we provides or who just wants to hang out and geek over those topics that that the three of us were just talking about. And my personal opinions about architecture as a discipline Hey, by all means, reach out to me and I'm happy to have that conversation.

54:03

Jakub:

Which reminds me of a customer of mine who once just scheduled a call with me just to talk about these things because he was like, Yeah, my wife doesn't want to talk with me about process mining. So could you please do me a favour and just openly discuss these things with me? I said, Sure, sure. Let's do that.

54:22

Roland Woldt:

Yeah. Because you never know if you're going to see that person again. You know, it's all building the relationships in the long run, you know?

54:28

Jakub:

Yeah. Yeah. Anyhow, Roland, thank you very much for coming to our show and sharing your wisdom and your experience in the field of not only process mining, but business process management and enterprise architecture. Thank you very much for that.

54:44

Roland Woldt:

Hey, it's my pleasure, guys.

54:46

Jakub:

And for the rest of you, thank you for listening. As usual, you can check out all of our episodes on miningyourbusinesspodcast.com If you have any question, just either reach us out on LinkedIn where we are very active as well, or just write us an email on miningyourbusinesspodcast@gmail.com And yeah, as usual, we will be looking forward to hear back from you what you got to say. If you have any recommendations on future guests, future episodes, if it's something that you would like us to discuss, please let us know. Patrick, Roland, thank you very much and talk to you later. Bye bye.