Process Empathy – What’s Your Baseline Shorts 7
People.
For better or worse, a lot of the topics in EA and BPM center around people. They are the reasons why we do things (customers who pay for our goods and services), who does the work (employees and partners), or why processes and architectures even exist in the first place.
In this What’s Your Baseline Shorts, we are talking about process empathy:
- What does it take to facilitate the development of a human-centric process model?
- What kinds of things should you think about, and when in the process?
- What does it mean to have people-focused processes?
- What are Customer Journeys?
- How can we use the methodology of Customer Journey Mapping to make more human-sustainable processes?
Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.
Additional information
There is no additional information for this episode.
Transcript
(The transcript is auto-generated and was slightly edited for clarity)
Roland: Hey J-M, how are you doing today?
J-M: Hey Roland, I’m doing great, and you know what? The mood, the time of year, it’s got me really thinking about people. And when I’m talking about business and business processes, I really want to take people into account. And so today’s episode of What’s Your Baseline Shorts is all about what we’re calling ‘process empathy’.
Roland: Hmm, that’s interesting. What is ‘process empathy’, J-M?
J-M: Well, if you think about design thinking and you have the phase called empathy. It’s certainly a part of how a lot of people do design, and it’s really important. But I’m going to talk about business process development, and in particular we’re going to address this idea of processes as they relate to people and their experiences, and the very first part of that is thinking about customer journey, customer experience and turning the lens internal. Oh, I’ve seen a lot of customers do that. Because one of the things about customer journey mapping is, you’re taking a look at the experience of how people interact with their products and services as an organization. Something that I’ve seen a couple of my customers do very successfully, and I’ve actually had a chance to do myself internally a couple of times quite successfully, is take customer experience management and focus on the internal products and services we offer to our business. So first and foremost, ask who is using these, how are they using them? What is their experience using them, and where are they struggling to be successful with them? Because a lot of times, we don’t take a look at that when we’re doing our process design. We designed for automation / we design for systems, and I’d say a lot of times people are kind of the last consideration in a process model. Have you seen that, Roland, a lot of times those handoffs between people go unaddressed – it’s a ‘hand waving’ thing.
Roland: Yeah, I’m absolutely with you because people want to go and say “oh which interfaces do I have to build? Which applications run which transactions” and these types of things. I think it’s a little bit wider, so I agree with what you said, but I think it’s a little bit wider because what needs to be clear is why do we do this process? What’s the bigger picture? Because we as humans are very, very motivated by understanding why we’re asked to do certain things, because the more we understand it, the higher the acceptance is when you and I are actually participants in that process and actually have to do what somebody has designed.
J-M: Yeah, absolutely. So your process models should explain that as well, and so I want to dig into this topic because I really feel passionate about this. So one of the things I do when I design processes is put people first. That’s why the BPMN spec is something that I often struggle with, because it seems very automation-focused and people are kind of the last part of the puzzle – they’re lanes, but also systems are lanes, so people are kind of resources. So the first thing I do when I think about processes is I take a look at all my process steps and I try to understand which ones I’m currently today automating, which ones I’m currently today having as a user task in BPMN or just as a person interacting with a system creating a process and which steps that I’m designing that are entirely human focused. So I want to segment these out into different things. The next thing I want to understand is what am I providing to people who are doing tasks in systems – so user tasks, and what am I providing to them in terms of resources? So think about inputs and outputs and the SIPOC approach (supplier, input, output and customer) with the process, of course, being in the very middle. What am I providing to them on either side of that that helps them to understand why they’re doing it, what information they need to know, how they have to produce as a result of doing this, and who they’re producing it for. So I try to put a SIPOC around all of my steps from a step that is in the system, but also a step that is brand new and manual. So those things I want to do on every level of that experience. And then I want to take that and flip it on its head and say, “OK, just show me what a person’s experience is.” So by role, what a person’s experience would be interacting with this process. And that’s where I draw my customer experience map, customer journey map. Does that make sense to you?
Roland: Yeah, it does make sense, even though I wouldn’t attach it to a specific notation, and I’ve read a couple of them and I don’t want to re-do the Shorts where we were talking about BPMN or EPC. That ship has sailed and I won, but on the other side I also read about UPN or whatever other notation one might come up with. That’s not the point here. The point is to literally understand what are the steps that need to be done and then look at them from a people’s perspective. And the people’s perspective to me could be two things, and you will talk about that. I’m pretty sure one is obviously the customer journey. What is the sequence of steps that I go through? What do I feel about it? Do I enjoy doing it and all those things that go with that? The second thought that I have is, especially when it comes to design of workplaces, the design of interfaces is what’s the usability of the thing that we interact with? Do I have to lift a 100-pound bag of something in a manufacturing process, which is OK when you do that once or twice. If you do that 8 hours a day, for 40 years, that is a different story. Or do you have a GUI for your application that’s hard to use and you don’t know where to look for it? Hint hint, listen to the last What’s Your Baseline Shorts when we were talking about how to design a good dashboard and figure out the usability of your applications.
J-M: Absolutely, and I think that ties into how I normally lay out customer journey maps, particularly for internal processes. So first and foremost, I want to understand ‘what is the customer doing or what is my internal customer doing at this point in time’. And note that it does not necessarily have the same language as a process step. What, are you kidding me? Because your end customers aren’t thinking about it in the same way that you as a designer are necessarily thinking about it. Now, there can be an argument to try and get them closer to each other, but in a lot of ways, process modeling has to be at this level of abstraction. Customer journey mapping is more personal, so first and foremost document what the customer says they’re doing at every point in time. So you’re going to get a list of steps and you can tie them to your internal process steps through the idea of a customer touchpoint. So what am I creating through my process capabilities that my customer is going to access in order to get their job done?
Roland: I think that the customer journey – at least the way I rationalize it – is a different perspective on the steps that you have. There is the outside-in perspective – you might book a plane ticket. But the process steps that you have to do are from the inside-out perspective. What do I as an organization need to do, or what do my systems need to do so that the customer can book a plane ticket? So outside-in versus inside-out and in a good design you have considered both of them and hopefully you create a joyful experience.
J-M: One hopes! I’ll get to that at the very end here, because alongside those customer steps what I’ll normally lay out are a lot of things you’ll find on a customer journey map normally. So what channels are they accessing to be able to do that step? What systems do they have to interact with? What data do they need to know; what data they need to create as a result of this, what sort of risks are they facing or challenges are they facing? We’ll talk at the end about sentiment analysis, as well as a ton of other information about how they use our systems and processes. And so now what I’ve got is I’ve got two sides of the same coin. I have my process and I have my journey and they are aligned along the lines of my touchpoints. How do my customers interact with my process (internal customers) and so now I have this automation perspective and now I’ve got the customer journey. What’s the third thing I need? I need to have feelings. And you talked a little bit about it before Roland, but I think that a lot of times feedback from your internal customers is poorly used. It’s misplaced. It’s talking about problems with systems, so they say I can’t get the screen I want. The button I hit doesn’t do what I need. It’s too arduous, but that’s not really the problem. So if all you do is attribute a problem to a system, sure, some things you can fix at a low level, but the problem is actually a process problem. And so when you put your sentiment analysis and your emotions, feelings, and pain points on your customer journey, then you can say “OK, where in this process can I really make a change that will change that sentiment?
Roland: Why is it such a pain in the rear to do exactly this step? And interesting enough, when I look at the KPIs that I see for projects, I’ve never seen those in whatever KPI trees or lists or whatever where people say “yeah, this is what I want to accomplish.” Or they put some lip service on it and said “yeah, it should be user friendly.” What does that actually mean? But the customer journeys, with that feeling component; is it a joy to do this task? Or is it a pain in the butt? That’s exactly what gives you that information, and you should keep this in mind when defining your processes and when you design your systems and your GUIs and all those things that we just spoke about.
J-M: Absolutely, and I think Roland, you and I have touched upon this a couple of times in the podcast, but it really all comes back to enabling people, right? Your process is designed to help enable people. People are your business. They are your business. They’re the most important resource you have. You talked about the person behind the desk. If you don’t give them a reason why / you don’t give them the right information, they’re not going to do their job. But we’re also looking at this time of the ‘great resignation’ or the ‘great shuffle’, or whatever you want to call it, where people are realizing that the processes that their companies are forcing them to follow that are things that they don’t want to do or don’t feel natural to them don’t give them joy. They don’t let them do the things that they’re good at. That’s going to make them feel worse about that company and look for companies that are doing it better. And if you can use that sentiment analysis to power your customer journey mapping, which can power your people-focused empathy process, now you’ve got a real chance of turning that corner and making empowered employees happy to do their job.
Roland: Yeah. And I think this is exactly what the crux underneath the great recognition is. You know, I read that 75-80% of employees have checked out, which is obviously not true for you and me because we’re having fun doing this podcast here. But, what is the underlying reason, and the underlying reason, in most cases it is that they don’t understand why they’re asked to do certain things. There might be the perceived economic problem. They don’t get paid too much. You can’t have that problem. But the third one is, it’s just not enjoyable doing the work. And I think this is where customer journey mapping and human centric design obviously can help.
J-M: And then the very last thing you do, along exactly those lines, is to create something like an SOP (standard operating procedure). A document that helps enable people to do their job right. When you take it from an empathetic process perspective – from a process empathy-based discovery and design journey, what you’re actually doing is your SOP isn’t your process model. Your SOP is their model. And you’re building your process SOP off of the customer’s journey. And when you need to change it – where you say, “I need you to do something different / I need your journey to look a little different”, you’re using their language. You’re using the way they think of things; you’re using the terminology they call applications. Don’t give it to them by their IT name. Give it to them by their name that they know. That also goes for interfaces that they use – explain the forms they use by the common name! And we’ve got it in a customer journey that that’s what you’re using. Here’s the data you’ll use. Here’s what the document is called. We’ve got it by the customer journey focus name. So you’re designing your SOPs with empathy based off of those customer journeys and the steps that they go through. That’s going to give you so much more power, and that’s going to give them a more familiar feeling to be able to execute things in a space that they understand with all the tools that they need to be successful.
Roland: So maybe to summarize our episode, because I see we’re getting to the self-imposed limit of 15 minutes. To summarize it, the first step is to think about the why of the process so that you can communicate that to your end users. Why should you do this? The second point is to use customer journey mapping, not as an alternative to processes, but maybe like an overlay. The upper part of your process. Think about the outside-in versus inside-out perspective. And then the third step is to design your process / design your applications with the user in mind. Or with the person who has the 100-pound bag to schlep around the facility. And then the last thing is ‘what’s the SOP’? How do we roll this out? How do we bring this to an end user so that they understand it and it makes sense for them? And when you do this, I think you have a much better designed application and a much better designed process than if you didn’t look at this. Do you agree, J-M?
J-M: I do Roland, I do. And I’m so glad we had a chance to talk about this. I feel like I see a lot of people heading down the wrong path thinking they’re doing the right thing. Let’s work together. Let’s think about people. And let’s have empathy in our process design. Well, for this short folks, my name is J-M Erlendson.
Roland: And I’m Roland Woldt.
Both, actually pretty together: And we will see you in the next one.
Roland Woldt is a well-rounded executive with 25+ years of Business Transformation consulting and software development/system implementation experience, in addition to leadership positions within the German Armed Forces (11 years).
He has worked as Team Lead, Engagement/Program Manager, and Enterprise/Solution Architect for many projects. Within these projects, he was responsible for the full project life cycle, from shaping a solution and selling it, to setting up a methodological approach through design, implementation, and testing, up to the rollout of solutions.
In addition to this, Roland has managed consulting offerings during their lifecycle from the definition, delivery to update, and had revenue responsibility for them.
Roland has had many roles: VP of Global Consulting at iGrafx, Head of Software AG’s Global Process Mining CoE, Director in KPMG’s Advisory (running the EA offering for the US firm), and other leadership positions at Software AG/IDS Scheer and Accenture. Before that, he served as an active-duty and reserve officer in the German Armed Forces.