Managing change is hard – either managing organizational change or managing changes in the technology or architecture. In this episode of the podcast we are talking with Caspar Jans from Software AG about the latter and how to implement and operate a program to manage change.

Caspar Jans - Managing Change

Caspar is a high-energy, fast learning and broad-skilled professional (BPM, Business Transformation, Supply Chain, Logistics, Procurement and IT) with an above average interest in the human connection and functional excellence. He excels in connecting human performance with process thinking and improvement.

His public speaking, facilitation and networking skills provide full support for his external orientation approach (never reinvent the wheel).

We are talking about the following topics:

  • Caspar’s background in a manufacturing organization and in consulting
  • Management of change versus change management
  • Four types of change
  • Change request intake and the five roles involved in impact assessment and the ‘rule of ten’ when it comes to effort
  • The management of change process
  • How to manage the changes (the doing)
  • Including governance and [org] change management
  • How to manage and document changes in practice, so that you have things always up-to-date
  • Process Mining in management of change
  • An example of improvements by establishing a management of change process

You can find Capar on LinkedIn here: https://www.linkedin.com/in/casparjans, and on Twitter here: https://twitter.com/nl_cj. via LinkedIn here:

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Ep. 16 – Management of Change: Caspar Jans – What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Additional information

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

  • CP1 (Welcome)
  • RakeBeatChords (Interlude 1)
  • Lofi Lobby Loop (Interlude 2)
  • South Wing (Outro)

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey J-M, how are you doing today?

J-M: I’m doing great, Roland! Today is actually a Snow Day up here in Canada. Were you aware that this could still happen during this time of COVID?

Roland: No, I would never have guessed that. We had a very weird winter day today. Yesterday it was in the teens (Fahrenheit) / -9C, and then overnight it warmed up to the 40s, which meant the snow that fell became rain and now everything has become iced. It’s black ice all over the place – it really stinks. It’s the middle of January 2022 when we record this session, and everybody’s excited about winter. Speaking of which, I’m excited because we have another guest on the show today, and his name is Caspar Jans, who’s dialing in from the balmy Netherlands, and we’re going to talk about Change Management / Management of change with him, and it will be a very interesting conversation, I hope. Welcome, Caspar!

Caspar: Hi guys, thank you for inviting me here. It’s my pleasure today. And yeah, we don’t have snow in the Netherlands, by the way. I think the last time was about more than a decade ago. So I can still be a bit envious of the snow that you have.

J-M: Ah, so where do you go for skiing if you partake in that hobby?

Caspar: Well, if you would partake in that hobby, you would drive down to either side of Germany or Switzerland or Austria. I mean, that’s about a 6 to 10 hour drive depending on traffic. 

J-M: That’s not terrible!

Roland: Well, I see this is where you’ll see the yellow license plates on the Dutch caravans, you know, clogging the autobahns. Hey, Casper. Welcome. Maybe, maybe we just get started with a little bit of introduction so that our listeners know who we’re talking with and why we’re so excited to have you on the show. So maybe you just talk a little bit about yourself and tell our audience who you are.

Caspar: Yeah sure my pleasure. So my name is Caspar. I think we established that. I work for Software AG at the moment as a Senior Director for Transformation Solutions, which pretty much means that I advise and consult our major customers on the wonderful things that they can do with business process management, in the widest sense possible. But I think let’s just dial back a couple of years before I joined Software AG, I spent almost 20 years in the manufacturing world, meaning that I worked for a global manufacturing company where I had, let’s say, half of my time in the business as a supply chain manager and procurement manager, and the other half I was basically running around in the information universe as I used to call it. So I was doing SAP projects, auditing them actually, and I was managing a BPM Center of Excellence for a couple of years. And that’s where I also got in contact and got my experience with management of change. For me, it’s gonna be an exciting talk anyway. 

Roland: Well, I feel sorry for you.

J-M: Having to deal with SAP projects!

Caspar: That’s a whole different story, yeah!

Roland: Yeah. I think we all got our bearings on these types of projects, which are always interesting, interesting in inverted commas. But, having said that, when you look back, what were key experiences that moved you to move towards the process management discipline? Why did you choose that quote, unquote profession? 

Caspar: Well, it started at university to be very honest. When I graduated from the Eindhoven University of Technology, my thesis was all about process simulation and then I went to Ernst & Young consulting to do that project. And they got me hooked on BPM, to be very honest. And then when I moved into that manufacturing company, the first project that they put me on was a process harmonization and centralization process being supported by SAP. And so you can imagine they just threw me into the deep end and I liked swimming in that pool and never stopped, basically.

Roland: Well, good that you didn’t drown because otherwise we wouldn’t have you here on our wonderful show.

J-M: But, but isn’t that how we do it all the time. Right? Our experience has helped shape what we do and we find things we love. I mean, when I moved away from manufacturing engineering, into process engineering, I was like, oh, it’s not something cool to discover. And then you move from that into more things and hey, listen, life, life evolves. Isn’t that beautiful? And speaking about life, tell me a little bit more about, you know, what you do outside of this. What, what are your hobbies? Things you love, we call these bucket list items. We ask about this for all of our guests.

Caspar: Yeah, sure. In my life, I have a full time occupation as a father of three kids. They all have, of course, attention desires and requirements, so I’m more than happy to fulfill those. Actually, one of my kids plays sports on a fairly high level that takes quite some time driving him up and down to the practice grounds and to games. And besides that, I love playing the occasional video game, even though I’m pushing 50 almost I still like a game of Fortnite now and then. And I listen to music, watch movies a lot, and if you talk about bucket list, there is one thing on my bucket list that I’m dying to do and that is together with my wife around Christmas. Go to New York, go to Radio City Music Hall and see an episode of The Nutcracker dressed up in a tuxedo and anything posh that to me sounds like such a great experience that that’s on my list to do sometime. 

Roland: And make sure that you wear a real tuxedo, not a Canadian tuxedo, right?

J-M: Wait, are you saying a Canadian tuxedo is just a Mountie uniform. Wow. Okay.

Roland: It’s the matching jean pants and jacket, come on!

J-M: Are you saying that Canada is stuck in the 70s?

Roland: Our listenership in Canada is now dropping significantly.

Caspar: Let me help you let me help you there. One of my favorite actors comes from Canada, so let’s leave it at that. 

J-M: Now it’s the audience’s turn. Lock in your answers now. What is Caspar’s favorite Canadian actor? We will reveal that at the end of the show, or we will forget. Well, let’s get into this show here. It’s really such a wonderful thing to have you on here and to bring your expertise and context behind the management of change or change management. I mean, tell me, those terms are not interchangeable, even though the words are the same. Tell me about management of change versus change management. What do we mean by this? 

Caspar: Yeah, that’s a good question. To me, they are two sides of the same coin. Or if you want, the Yin and the Yang when it comes to transformation in businesses. And there are a lot of people that have their own definition of it, so I’ll stick to the one that I got used to in my manufacturing days. Change management typically deals with the soft side of things, so the behavior, the culture and anything that has to do with people. And management of change is a process where you have to make sure that whatever needs to change in the things that you can record, and so that’s the hard side of things. So you talk about the processes and the applications and the IT systems that you have and how do you deal with change. And obviously those two, they are interconnected because at the moment that you start making changes to either a process or an application, sometimes you need to have people adapt their behavior as well. But they have very different centers of gravity. They have very different focal points, I would say, but to me, the bridge is communication. If you don’t communicate and you focus only on one, the other one will fail.

Roland: Yeah. And we’re going to have an extra episode, which will actually air two weeks after this episode that we’re currently recording with you, where we will cover the people’s side of org change management, and what does that mean? You know, as, as a little preview. But having said that, when we look at the quote-unquote hard side of change, Caspar, what different types do you see there? What different types of change are we actually talking about? 

Caspar: So normally, when I talk about management of change, it depends a little bit on who you’re talking to, but very often either they look at process changes – changes to business processes or maybe to policies or roles. And on the other hand, when you talk more to the IT side of the organization, you talk about the changes into applications. So, process change is one, application change is two. And of course the combination of the two is a third type of change that you can see where you both change a process and an application at the same time. And those three types of change, and they all have a slightly different way of dealing with them in my experience. 

Roland: So, what is the problem, then, with that? Because obviously change is inevitable and things will change, but why is this a topic where  organizations have a problem ‌ managing the change?

Caspar: Well, let me ask you a question, then have you recently been in contact with companies that still have a whole battery of people sitting on typewriters outputting actual paper and putting it in a cupboard somewhere? 

J-M: No.

Caspar: It’s very unlikely, so that means that whatever organizations do nowadays is being supported by a system or multiple systems, and that means that at the moment that you start making changes it’s a tad bit naive to just look at one of the aspects of it. When you look at the processes you always need to at least make the determination if the application needs to be changed as well. And the same goes, of course, the other way around. And just as a small example, when I was working in this manufacturing company, we had a change request that the company logo needed to change from the left hand side to the right hand side of the invoice. That seems like such a straightforward change in SAP, right? You just have a template and it outputs on the other side of the picture. If that was it, we would have run into major problems going into one of the countries that we actually manufactured in, where there was an obligation to have it on the left hand side. So we moved it to the right hand side, and the first invoice that came out in that country was already an incident. And what if you had done a proper impact analysis where you also included the process and many of its variants? You might have caught that before you actually started making changes. So they had to go back in again and add that part of conditional logic to make sure that the logo was printed on the right hand side, depending on the country it was printed in.

Roland: Yeah. So we’re talking about the actual value of the change. We’re not talking about people being upset that everything nowadays seems to go through a ticketing system. And if you’re not a Jira master at closing tickets, you’re on the bad list and naughty list. 

Caspar: Yeah, well. I think a lot of companies still manage their change processes in Excel. To be very honest, ticketing systems are being used but very often only on the IT side of things, because that’s where it’s most often used. In my experience, that means that application changes which are very often, let’s say, owned by IT, typically get through that ticketing process pretty nicely. But process change, on the other hand, can originate anywhere in the organization. And they don’t automatically end up in these kinds of ticketing systems. So the question is, do you have transparency in what’s going on in your organization anyway? Because of that lack of consolidation?

J-M: Right. And you’re talking about consolidation. I mean, you’re alluding to this idea of different types of change. So let’s, let’s walk through that cause we’ve talked about the word ‘management’ now let’s talk about ‘change’. What has change looked like to you? What sorts of changes are there? What should people be sort of bucketing in order to address that with the types of management of change that are going to impact?

Caspar: I think we typically distinguish about four types of change, and the first one is the easiest one. I would say that’s what we call editorial changes. So imagine that you have a whole bucket of documentation, because that’s ultimately what we’re talking about, so you document it the way that you work. You have documented the way that your IT landscape looks like, and all of a sudden there needs to be a change. So in editorial change means that you simply have a typo. Or you need to change a word somewhere. It doesn’t change anything to the way it’s working, so it’s a very straightforward change. 

The second type of change is then the process change, where you say, listen, this is the process that we have now, and we need to make a change to it, but it doesn’t seem to have an impact on applications. 

And the other one is of course the application variant of that. So there’s an application change that needs to be done, like a security upgrade that has no effect on the process that the application is supporting. 

And then the last, the last type of change is the combination of the two, and that’s the most elaborate one, where you need to look at both, changing the process as well as changing the application.

J-M: And when you talk about managing change, so, so you, you stop at the point of the person in, in what you’re referring to when you say process change. And really,y what I think we see this as is a practice change, and that process changes are being enacted by people. But you wouldn’t use this discipline to feed into learning and development directly. That would be a separate conversation, right? 

Caspar: Yeah, that would be a separate conversation from your process change. Obviously you can have an impact on the way that people practice it and do it and that could be an outcome of your management change process, but it could be included in what you call the post-transfer activities of a change. 

Roland: I’m curious now, and I completely understand your four different types of changes. When I think about our listenership, typically these are architects, these are process managers. People who are tasked with implementing that process. What do you see as the role of these individuals in that process? Is it something that if you have a process change where you just say, oh yeah, business unit, you figure it out. You have 200 grand to hire your Lean Six Sigma person and you just make it better. And buy my solution. Or do you go back and say, no, no, no, very strict governance here. We need to have a task force who is looking for that little change that you want to do, and it’s all centralized. But when I think about the audience of our podcast  here, how do you see the role of architecture in this change process? 

Caspar: That’s a very interesting one, and I think in order to answer that one, I need to add an extra dimension into this equation and that’s what I call process classification. Not all processes within organizations are equal. Some are more equal than others, so to speak. Just to quote a famous book. And so there’s two different types of processes that I very often use. You have either a differentiating process or non differentiating processes. The differentiating processes are core processes that are very often being centralized, standardized and put into shared service center modes. The non-differentiating ones typically end up with ownership within the business unit that actually has that process. Now when you talk about management of change, I would certainly recommend centralizing at least the intake and the impact analysis of changes. 

So it doesn’t matter what kind of process you’re actually changing. It doesn’t matter if it’s a small change or a large change; make sure it’s being centralized via that one process that you have. You can use that ticketing system for it if you want, and say “listen, all of the change requests, whether they come from incidents or from Lean Six Sigma improvement projects, they all come in into one process.” And then you have a cross functional group of people. It doesn’t need to be big. We typically used five different roles that would come together, look at the change request, and then within two days they would render judgment on the change request to see if it was feasible and desirable. And if it was, it would continue throughout the design and build and deliver phaseware. Then you would see the difference between differentiating and non differentiating processes. But just to get back to that point, Roland, a process manager or a process owner, very often plays a role at the end of the impact analysis. If that group says yes, we will do this change, we think it’s good. We think it’s useful. This will be the cost estimate and this will be the impact, and then the process owner has to render judgment on that to see if it has to give a go or no go.

Roland: So, yeah, just to make it clear, what are those five roles that you just mentioned?

Caspar: So there’s always the requester of the change because that person obviously knows what he’s asking for. And then there is a central process expert for that particular functional domain. So if you talk about a purchase order activity, it’s the Procure to Pay process expert from a centralized function. So that’s the person that oversees the whole procurement area for the entire company. And then there is always a finance expert because in the end everything ends up with money, whether you like it or not. There is an IT expert to make sure that you have the impact on the application side covered. And finally, there is a risk expert (risk and control) because in the company I come from that was a really important part to make sure that whatever you did, did not create any problems, for instance, with the “four eyes principle” or with your authorization profiles. Because very often when you talk about, for instance, role changes because of other authorizations, you need to have that risk check in there as well. So the composition, of course, would depend on the type of change that would come in. And those five would sit together – it could take 15 minutes; it could take three hours, but the demand date that they had and the objective that they had was very simple. You look at this and you don’t come out until there’s white smoke.

J-M: I did have a question about this in particular on the effort required, because what you’re talking about, if I was sitting as an organization or a practitioner listening to you say this, it feels like a lot of additional burden you’re not thinking about today. We have an expression, though, in the podcast, you’re going to pay for it somehow. So what’s the business case you often make to say, okay, look, let’s regiment this and let’s centralize this, because I’m assuming right now this is kind of getting done, but only halfway in BUs.

Caspar: Yeah, and ‌the rationale behind it is typically what we call the ‘rules of 10’, meaning that whenever you let an error exist in the process, every step that process takes multiplies the effort you need to make to correct that effort by 10. So what we really went for in that case was to say, listen, we need to solve certain problems as soon in the process as possible. What we saw with management of change throughout the years is that if you don’t do your impact analysis right, you’re going to pay for it in the development or in design of the change, and then it will cost you much more effort to correct that compared to doing it in the impact analysis right at the start of the process.

Roland: Yeah. But I’m switching hats now, Caspar. I’m Agile. I don’t need all that stuff. You’re forcing me to make those big decisions upfront, you know, do your block five resources to do that impact analysis. I don’t want to do this. I’m Agile. I switch on a dime. So what, what is your opinion on that?

Caspar: Yeah, I would say it’s based on the myth that when you work in an Agile manner that you don’t need to document anything anymore and that you don’t need to go through proper change management. It simply means that you take small little strides to get there with intermediate products or solutions. And that’s the way to get there faster compared to waterfall methods of developing. And Agile itself is in the DevOps realm, I would say, and what I’m talking about, the impact analysis is much more on the functional side before it even gets to being Agile. First, you need to know what do I need to change and do I need to change? And what will the impact be? And do we accept the impact and then once we accept it how do we design a solution. And at the moment that you say, “OK, now we’re going to design and develop a solution” you can work in Agile or you can work in waterfall, whatever I don’t mind, but it comes into the process way later than the impact analysis side. 

Roland: So basically what you’re describing is helping the product owner, as the Agile role, to set up the scope. Help the product owner to determine what should go on his list and then it will go into Epics and Stories and all those other formats – that makes sense.

J-M: Well, this is getting a little bit more into the ‘how to’, and we’re going to cover that in our next section. So for our first break on the show, we’d love to leave you, our dear listeners, with a question to ponder when you listen to some wonderful music to get you in the winter spirit. And that is thinking about you and your organization. So what kind of changes are you currently going through and where are you in this process? How is change organized at your organization? And how are you involved in that? So I want you to take the time to frame that conversation, ask yourself those questions so we can better understand where you connect and how we can bring this all back together. We’ll leave you for a moment and come back with our thoughts and the ‘how’ on the management of change.

Musical Interlude: RakeBeatChords, Jeremy Voltz

Roland: Welcome back to the second segment of the show today with Caspar talking about the management of change. And starting with that, there’s some form of process that’s underlying a management of change. Either one of the four changes that you’ve mentioned in our first second, can you talk a little bit about what that process looks like?

Caspar: Yeah, of course, and I think the first step in this management of change process typically is capturing the change request and the change requirements and then again they can come from multiple various sources. Of course you have incidents; you have regulatory changes by your government. I live in the Netherlands. The Dutch Government likes to change the rules from time to time and then expects you to very quickly process that into your application and process landscape. And then at the moment you captured it, the first thing that you that you would like to do is that impact analysis, making sure that you understand truly what is the actual change and what type of impact might we expect on other processes, on other applications, in anything that you already have on the radar, so to speak. And I think this particular step also underscores the importance of having that single source of truth or repository that many companies are now working on where you have your processes and your application landscape brought together. Your enterprise architecture really is key here. And once you get past that impact analysis stage, the next one that you do is design. So if you come to the conclusion that yes, we do want to do this change, it seems desirable, it seems effective. The first thing you’re going to do is say “OK, so how are we going to solve this high level and what kind of cost estimate would be attached to it?” And once your process governance has rendered judgment on the cost estimate, you can move on to the last three phases, which are typically build, test and deliver. I think these are very straightforward standard DevOps stages. And whether you do this at waterfall or Agile, I mean, that’s up to the organization. As long as you go from the approved design and make sure it actually ends up in production with the people being trained in the fact that there is a change. 

Roland: Yeah. But I think you mean you missed one more step, right. Which is basically the measurement step or the analysis step afterwards, you know, once you go live with your change in the end three months, six months after you want to know what did we accomplish and what we wanted to do?

Caspar: Yeah, absolutely. And that’s an interesting topic because that’s typically where process mining comes in. And if you, this is the control phase that you have in your DMAIC from Lean Six Sigma. So you implemented an improvement or change. How do you make sure that you actually reap the benefits from it? And then that’s obviously the sustainable control phase that you have at the end. So you’re right, you’re right about that, Roland. 

J-M: And I want to ask a question about the decision-making process here, because it sounds to me that in your third point, the design of change, there is at some point in time, a decision around financial outcomes and impacts. How do you build the business case in this framework? Is a business case required to be developed? Who’s developing that and what are they using?

Caspar: Yeah, so I think that depends a little bit on the severity of the change. If you’re talking about small changes and very often what you see within organizations is that each of the process owners have their annual change budget. So for instance, in the company where I came from, the process owners had about 200K of change budget, so any type of change that they thought were good could be funded from that budget. 

J-M: So ‘discretionary funding’.

Caspar:  Yeah, discretionary funding. And then if you had really large changes that affected multiple functions or multiple applications, it would become a topic for the process governance body. So you would make a cost estimate. You say “listen, this change is going to cost us about 500 K, but we think the additional benefits in the long run in a one and three year scenario would be a million plus.” I’m just making up some numbers. And that would then be sent to the responsible process owners, and if it was severe enough or big enough, it would end up with the process governance board actually, which also had the CFO in there. And then they would render judgment on ‘do we want this yes or no?’ And then they would make the fonts available from other means to make this happen. 

J-M: Right. So the third phase then does have sort of a governance side to it. It’s kind of ‘design AND govern’ the change. And particularly when we’re taking a look at moving things upwards, some of these things are kicked off with a requirement for change. It doesn’t really matter what you want.  Like when you’re talking about regulatory requirements, you need to change. And so the governance of it is to ensure the change occurs; but there are some changes that are proposed that are not cosmetic, but are, like, nice to have. How do you balance the approach when you’re looking at change that must happen versus change that probably should happen.

Caspar: Yeah, so that typically happens right at the capturing of the changes, because at the moment you capture a change requirement, you know where it’s coming from. So if it is coming from regulatory reasons then very often it comes in via your corporate risk department or your corporate regulatory affairs department, and they already tell you “this is a must do” and then budget budgeting becomes very simple because they pay for it on a corporate level. If it’s coming from a project or a person, so you have a person in a business group that says ‘listen, I have this great idea how to make Procure to Pay much more efficient.’, that requirement would then go into the change coordinator. That’s the role that I haven’t mentioned yet, but there is one person that actually looks at the captured change requirements and determines in which buckets should this go and which group of people do I need to put together to do the impact analysis. And that person would also then take a first guess around and then based on experience. This change might indeed be very interesting, so we might promote this into a more generic change for the entire company compared to this is a very business group-specific change that might be dealt with by the business group itself. So there’s a point very early on in the process where you do that. And I think just very briefly coming back to that, the most important thing that you need to do with management of change is to figure out what kind of change am I looking at and how do I want to solve that? And you do that as early on in the process as you can to make sure that the rest of the process is a very efficient lean and mean delivery machine. Well, that even rhymes.

Roland: This sounds like a very complex thing to manage, you know, because everybody in the organization will have some ideas on how to do this. And I know that people have implemented ticketing systems for this purpose. And I know that I’m one of the guys who hates these ticketing systems with a vengeance because they are not pretty and not flexible. What have you seen in the past about how people manage those changes, especially from an enterprise-wide perspective? And maybe the second part of the question, what would be your ideal scenario on how to manage those changes going from?

Caspar: Things I’ve seen range from little Excel files where they record what they’re actually trying to change, all the way up to a centralized ticketing system where everything comes in, and that’s the one repository for change that they have. You could basically say ‘listen, I have this repository of change’ which is your ticketing system or your collection of Excel files, although of course the collection of Excel files is not nearly as in control as a ticketing system can be, even though you might not like them. And sure, I’m not a big fan of them, but they do serve a good purpose when it comes to the management of change. And if you look at the ideal situation, I would say that it is a rather complex process. Yes it is, but change is complex nowadays. Organizations have become so complex, most of them. We are talking about major corporations. We’re not talking about small and medium enterprises at the moment, at least I’m not, if you look at‌ larger organizations, they are complex and you need to manage that complexity. You cannot do that with a very simple process. I mean, the steps I described seem simple enough, and the execution of it, once it runs a bit like an oiled machine, is also not that complex. But you do need to have transparency on ‘what is it that I’m working on and what is it that I’m going to be delivering in the next batch or in the next release?’ Or maybe even continuously?

J-M: And when you’re talking about transparency, you’re implying the need for multiple different parties, multiple teams to be brought into sync around this. And you’ve talked a little bit about some of the roles and talked a little bit about some of the generalized teams. Like you talked about their change counselor or the change evaluation board, or however you want to call it. But talk to me about how this fits into an organization. How do you set up your organization to accept this type of change and change process into its very fabric? Because it feels like this applies across the whole company, whether it’s an editorial change at the lowest level, or a sweeping pivot for the organization. How do you accept that, and how do you set yourself up for success?

Caspar: So I think the main premise here is that an organization needs to understand that process management is wider than just documenting some processes. It also includes the whole governance part and that includes management change as well. So if done properly, organizations already have a process governance body somehow. So they have a group of executives that own the processes that meet up regularly to discuss problems that they have in and around process management. And for me, the application landscape is intrinsically linked to your process management part. It might not be completely part of ‌governance, because they very often have their own governance within the IT industry, but it’s certainly linked to it. So at the moment that you say ‘I already have a process governance structure in place’, it becomes a little bit easier to also persuade the organization to say ‘we now need to consolidate that management of the change process and we need to structure it a little bit’. Because there are not many additional rules that you need – there’s that one change coordinator role that you need to have, but the process experts and the IT experts and the finance experts – they’re already there. These are existing roles that you have either on a corporate level or ‌in the business group. You simply bring them together. And just as an example, I had that role that changed coordinator for a couple of years when I set up that whole process at my previous company. The one thing I did was I had a weekly short meeting with representatives from all of the functions that we had. So I had a representative for the finance part, the marketing and sales part, the procurement part, the risk, and the IT part. And we would sit together and we simply would go through the list of all of the open change requests that we had and in which part of the process they actually were. Just to make sure that we stayed on top of that transparency that I mentioned. And we could always say, well, we have changes that run that quick enough. We need to accelerate those, and it can go at a cost of that one that might be held back a little bit, but we need to figure out how to bring these changes into production as efficiently as we can. So complexity – once it’s up and running, it’s not complex at all. It’s simply an operation that you need to run. It’s sort of a shared ‌service, actually. 

J-M: So, it seems like you’re saying when you make change and the need for change, the transparency of change, the conversation around change, an ongoing activity rather than a “surprise baby” (Oh my God. We need to change something. Something’s breaking. Something’s going wrong.) When you make it a topic of conversation, you are much better prepared because you have ‘people’, and you’re much better able to execute because you have ‘processes’ already in the structure. I love it. I love it. So that’s some fantastic advice for a lot of the folks out there. If change is a surprise, if change is a panic moment of urgency, then it’s already maybe a little too late. So set yourself up now for success so that when the change comes and it is “a comin’”, then you’re ready to address it with your whole organization in alignment. And that transparency seems like a really important part of that.

Caspar: And there’s one thing I’d like to add because I like the way that you rephrased it. At the moment that you’re implementing a change and you notice that you’re going to have an unexpected side effect anywhere else in the organization, then that’s a clear sign that you’re not doing your impact analysis or you’re not doing it right. One or two. 

J-M: Surprise! Someone else is now going through pain because I wanted to change!

Caspar: I’m not that naive that I think that you can predict everything. But you can predict 90% of what’s going to happen when you change something at the moment that you have a clear view on your processes and how they link to your application landscape.

J-M: And I actually have a question for you then along those lines, because you are obviously offering incentives in some way to other departments to give you information. How do you bring those people into the fold? How do you convince them as part of your process that they need to be involved? Is it a mandate? Is it an offering of information? Is it simply that you’ve established a practice and those relationships are strong enough to sustain you as you go through this process?

Caspar: I think it’s a combination of the first two. Of course you need to have a mandate, because ultimately, you’re putting activities on top of the roles that people are already playing, and so they need to be made aware that they’re going to have additional responsibilities and maybe something else has been taken away from them, so it still stays manageable. So that is one. But what’s more important, I think, is that at the moment that you start collaborating with the different functions like IT and finance and risk and the function itself, you provide transparency to all of them, which makes their work more predictable. And more predictable means that they can do it in the end with fewer people. So the information exchange will help them become more effective.

Roland: Very good point, Caspar but the question that I have is, well, how do you organize this? And one example that I like to bring up is all those small IT changes that you have, you know, and I’ve seen IT organizations having their own change board for this. Because they are tasked with implementing with different groups, they come to them and say, “Oh, yeah. Do this, do this, do this.”, and I’m a little bit afraid that they lose the big picture overview of all those little changes, which can accumulate to obviously bigger problems there. But how have you seen this in the past? 

Caspar: Specifically, with those little, I would say low level IT issues and changes that you need to make, I think that’s something that really stays within the IT part. They do have change boards and depending a little bit on how they work, there’s two things to it. So either in the change board they decide that a certain change has a bigger impact than just a local one, and then they bump it up to the ‘management of change’ process that’s more centralized. Or they simply fix it. For instance, if a router in your network malfunctions, you go ahead and either replace it or you fix it. And if such an incident occurs multiple times, it’s typically promoted into a ‘problem’ and then from the problem you’re going to get a root cause investigation and that might actually trigger a change request that ends up in the MOC process that you’re then going to deal with from a more centralized perspective. So I would certainly say all the really low level detail stuff that is not impacting anything other than the very local situation is something that, for instance, the IT department can handle themselves pretty well. You need to have a certain threshold in there above which you’re going to send it up to the MOC process. 

J-M: And that’s the question I had about the people part of things, because I know we’re not going to talk about ‘change management’, but how do you enable people to see change as part of their ‘daily’ and to put them in the right mindset for this kind of practice and process? Are you giving them the power to manage small changes and as a result, they feel like they’re more involved with the change process?

Caspar: I think there you need to make a bit of a distinction between end users, on the one hand, that typically have no interest in change management whatsoever, they just want to do their work, and that’s absolutely perfect. And then there are, let’s say, the subject matter experts in that group, and those are the people that really look for ‌process improvements and the optimization of whatever it is that they’re doing. And these people typically are well aware of the fact that you need to change, and you can of course help them by giving them good arguments and make a change process or a management of change process as effective as possible to make sure that the end user is certainly not bothered with it too much. But that at a certain point in time that an end user does need to change, that they have all of the ammunition that they need – those subject matter experts to say “OK to your end user. This is going to change. This is the way that you did it. This is the way that you’re going to be doing it and let’s have a training session on it”. And we typically call that a part of the post-transfer activities, the PTAs. And then one of the things that you do is you train people if needed, or you just communicate the change to them and let them decide how they want to deal with it. 

J-M: I think it makes a lot of sense. Well, I’m actually also interested in another component of this because it’s just besides the people, you’re creating a lot of collateral. That’s the “collateral damage of change” is where you create a bunch of stuff. One of the things that I’m interested in is what format that collateral takes. So as part of this change process, what deliverables are expected out of these different phases and what form do they take? And how are they shared and consumed?

Caspar: Yeah, so it depends a little bit on how your organization has actually documented the way it works. So let’s take a basic scenario where they have PowerPoints and Visios on a SharePoint drive. Well, then, one of the deliverables that you need to create as a result of a process change is an updated version of that PowerPoint or Visio. We can go into a whole different podcast on the things that that can end up in, so we’re not gonna be doing tha. But if you have, let’s say, a more ideal situation where you already have a BPM platform like ARIS that says, “well, I have all my processes documented properly including the link to roles and risks and applications”. Then you simply would need to have an updated process model as ‌collateral to make sure that you reflect the things that actually have been changed. From the IT side of things, you very often talk about technical design specifications and functional change specifications that need to be updated in whatever form they are documented in. That could be Word documents. It could be in systems like ServiceNow or Jira or whatever you have. But you need to make sure that whatever you’re changing is actually reflected in the existing documentation, and you need to do that before you bring the change live. And I stress that point a little bit, simply because of the fact that if you don’t do that before the changes are delivered, you need to do it afterwards and then different priorities will emerge very quickly and it never gets done.

Roland: Which I think is, is a problem in itself. I’ve worked on projects where we were looking at those changes, you know, and, and from my experience, if you just say, Hey, write it down in Word and save it on SharePoint. And we have that very elaborate structure. They are by project, by year, whatever your structuring is. I noticed there’s a lot of outdated information there. And nobody finds it and whatnot. So the one thing that I like in these situations is when people start using Wikis. And the assumption is, well, all those changes that we have, they’re part of the change documentation that we have. And that could be then, whatever, a link in your process model to a Wiki page or a link in your Jira to that Wiki page, right? And I’m a big believer in those DevOps idea of ‘You build it. You own it’ and make people responsible for. Yeah, you buildit, now, you maintain your documentation and you manage your changes so that two years down the road or six months down the road, we know why we did those changes and don’t forget it.

Caspar: Weah absolutely agree. Well, if you take a little bit of a helicopter approach here, we’re gonna go up a little bit. At the moment that as an organization you say “listen process management is the way that I use to streamline and my process management and execute my processes”. Management of change is there to make sure that whatever you have documented in your repository actually stays up to date. And whether you use links to Wiki pages – that can absolutely work fine. Whether you have documents that you have attached to your process models or into your IT application landscape, that can also work. That really doesn’t matter too much, as long as you understand that whatever you’ve documented about how you work, you need to keep that up to date, and that’s where management of change comes in.

J-M: . And the other thing we talked about a little bit earlier, and I wanted to make sure we loop back on it, besides the documentation that’s coming out of what you’re doing, is also the loop back of information that’s coming out of the ‘run’ of your system. We talked about this and I think it’s kind of an edge case, but that’s process mining. That’s both for the initialization of the need for change, and also for the check back for things like compliance and for business case satisfaction and things like that. Where does this fit into that story of process mining and how have you seen process mining support detection of patterns and trigger the needs for change, like becoming an actor in this process.

Caspar: Yeah, so process mining indeed has a couple of different roles to play, and if you already have process mining up and running in your operational systems, it can give you a lot of insight in where do you want to make improvements, and typically as a result of an improvement you’re going to have a change left or right. But more interestingly, I would say for this discussion today, is if you apply process mining to your management change process, you’re going to get very valuable insight in the way that certain changes run through the whole process, because it also captures the involvement of all the different parties in management of change. It’s not just at the corporate level or the IT folks. It’s also the business group that initiates the change because they also have activities in that process. As a quick example, when I ran the management of change process in my previous company, we added process mining to it. So we connected the SAP systems to it. We connected the SAP Solution Manager to it. We put the information from the ticketing system that was in this case, Remedy from BMC, into it, and we quickly found out that yes, changes did take a long time to be delivered and the business groups were complaining about it. But the main root cause for the long lead times actually were the business groups themselves. Because they took very long times in signing off on the cost estimate or actually executing the user acceptance testing. And once we made that transparent, they stopped complaining, so that was good. And they started acting quicker, so ‌lead time also went back. So we went back from nine months on average about 3 1/2 weeks after a series of improvements to the MOC process. And as a business that makes you much more agile because you now have the capability to much more quickly respond to changes because you can process them quicker throughout your process and application landscape. 

Roland: Yeah, that makes sense, and it’s quite impressive to cut it to a third over time. I can imagine there were a lot of unhappy people on the way to get there, you know, because they had to change how they do things. 

Caspar: But it was appreciated. Part of that was also going back from a bi-annual delivery release into continuous delivery. That helped a lot, of course. But it was the predictability for the business groups, knowing exactly where my change is, and when I can expect it. That was the biggest benefit that they indicated afterwards. And they said we now know what to expect so we can organize ourselves for it at the moment. It helps. 

Roland: Well, that is a very good segway. Caspar to the questions that I have to our audience listening to this segment of our show. So please think about what’s your next step with change? How can you work in your organization in partnership with your team? I’m going to leave you alone for a couple of seconds and we’re going to play some nice music and then we’re going to come back and close out the show.

Musical Interlude: “Lofi Lobby Loop”, Jeremy Voltz

J-M: All right. Thanks so much folks. And hopefully you’ve had a chance over the course of the last hour or so to really reflect on what it means to become part of the management of change, what’s necessary for the management of change, and why it’s so important that we manage change effectively. And thank you so much to our wonderful guest, Caspar, who has done an incredible job of guiding us through this really essential process. Now, Roland. I know you have a couple more questions for him before we go away. Why don’t you take it away. 

Roland: Yeah. So first of all, Caspar, thank you from my side. I think it was a very interesting conversation that we had, and I appreciate you being on the show. Having said that, where can people listen to our show today, find you, and reach out to you and continue the conversation with you?

Caspar: First of all, it was my pleasure to be here. I enjoyed it very much and so if you’re trying to find me, you can of course go to LinkedIn. Look up my name and connect to me and I’m always open to connecting to people. You can find me on Twitter, where I frequently tweet around the world around BPM. Just ignore the Dutch tweets. They’re much more personal, I think. And then finally, of course I read I write a weekly blog on the ARIScommunity.com in the BPM Blog section, and where I think you will have a link somewhere around Roland for that. That’s where you can find me, and you can always reach out to me if I have one of these three platforms and I am more than happy to engage in any kind of conversation.

Roland: And we definitely will put the links into our ‘additional information’ section of the show notes so that you don’t have to take notes while driving and getting to the right place. If somebody reaches out to you, Caspar, what are the topics that you’re offering to them or what would be conversations that you would like to have with people?

Caspar: The conversations I typically focus on are what are the things you can do with process management in general. And also management of change in particular, of course, because to me it’s part of BPM and how we can support you with that. And it can range from strategy to implementation to rollout, whatever you like. More than happy to have that conversation. 

J-M: Well, thank you so much again, this was a lot of fun. And another, thank you, but this time to our wonderful listeners. Thank you so much to everyone for loving and supporting the What’s Your Baseline podcast. We’re watching our numbers go up and up and up of listenership and it really feels good to be connecting with our industry and some wonderful listeners who are part of our community. So thank you again. Please reach out to us. You can find lots of information at whatsyourbaseline.com, but you can even email us at hello@whatsyourbaseline.com. Or if you’re listening to this on Anchor, you can leave us a voice message, which is great. We can hear your wonderful voices along with our own. 

And of course, please make sure you leave a review and a rating on your podcatcher of choice. That helps us to find more loving ears for our next podcast show. And if you want to find all the show notes and lots of links, tons of great thought, go to whatsyourbaseline.com/episode 16, where you’ll find all the information about this episode, and of course, whatsyourbaseline.com for everything you might need around the whole transformation of enterprise architecture and business process. Well, thanks again to everyone for being here. 

Thank you so much to Caspar for joining us. And as always, I’ve been J-M Erlendson.

Caspar: I’m Caspar Jans

Roland: I’m Roland Woldt

J-M: And we’ll see you in the next one.