#34 Getting started with Process Mapping

Hello and welcome back to another episode of the Process and Automation Podcast. Today we will look at process mapping and we will go through 6 methods how you can actually look at your processes and map them out. And yeah, generally there are two really distinct aspects to process mapping. One is using process mapping software tools to create a process map. And provided that you pick the right software, this is probably for most the easiest one. And the other part is capturing the content of these processes manually. So, and we will dive into these methods now one by one. Arno, what 6 methods do we have for our listeners today?

Yes, thanks Sascha. So as we discussed in our Klubbhäl session earlier, and, you know, mapping out the processes is really key part to successful automation projects. And, you know, from the actual ideation to, to actual mapping the process out to the automation, and you want to have real clarity when you map your processes out. So we decided today to really touch on, on 6 main methods to to create these process maps, which is obviously a combination of perhaps your workflow process, or it could be RPA processes that's contained with inside the workflow maps itself. And generally there are roughly 6 methods for creating these process maps. And one of them is obviously through individual staff or small group interviews where it's sort of a workshop setting. Now, these days this can be done online a lot, and there's several tools that you can use, a whiteboarding tool, digital whiteboarding tools, but it's really just kind of getting a group of people together and talk about the process. And really, you know, the main aim here is to really to, you know, talk about the process, map it out step by step, and really get inputs from everybody that is involved in the process. And again, this is by using a technique that's called group interviews. The second method is to facilitate the discovery workshop. So facilitated discovery workshops is more kind of structured, where you have the workshops It's more agenda-driven and it's got the same aim as well as the group interviews. But again, with that, you know, you go in with a specific agenda on a specific topic that you want to cover. And, you know, hopefully the output of that would be that, you know, we've got a process map that represents the process we want to automate. The third method is really to analyze existing documentation. You know, so a lot of our customers, they map out the processes themselves, or to a degree they do so. And, you know, and what we tend to then do is, is really look at that documentation and do an analysis, a process analysis on that. Now, this could be in various formats that we receive the documents. So really, our job is really to take that and really translate it into a process map that we can then, you know, put in an automation tool. The fourth method is by direct works or observations, and it's really what we call time and motion studies, where you, you know, you physically try and understand what people do day to day. So that's a very popular technique as well. There are tools to help you with that, like task capture tools that you could put recorders on, on people's desktops to understand, you know, what they do day to day. And then the fifth method we have is through business analysis design. So basically you go to work at a business problem, you know, you use some business analysis techniques to understand the process and, you know, what the process should do. And really based on those findings, you map out, you know, the to-be process. And, you know, when you do that, you kind of look at, you know, what this process, you know, by analyzing the business, what this process currently is and, you know, how can we improve this process? How can we map this out by, you know, deploying some optimization techniques to make the process as good as possible? And then, of course, we can also import existing process documentation. So if there's somebody in the organization that has used BPMN, which is Business Process Modeling Notation maps, you know, that's something you can easily import into a process mapping tool. And, you know, you can, you can go to work on that. So there's a broad set of techniques that you can use, and I think it's really finding the right technique for a particular scenario or for the particular customer, perhaps, that you deal with. And it also, you know, the approach you choose will depend heavily on the size of the organization, the team culture, the available resources. And, you know, good personal preference. You know, some people might like it if you do discovery workshop. And I think the key here is the fact that you can choose one of the methods, or you can choose a combination of these sort of 6 methods that I've mentioned earlier, you know, to obtain that required degree of accuracy when you map out your processes. You know, again, each of these different methods has got its own strengths and weaknesses as well, you know, and, you know, where one method works in one organization, you know, it might not work in another organization. So it's really important to really understand I guess the audience understand the unique sort of circumstances of, you know, the actual job at hand, you know, when you go into a process mapping session and really to try and pick the right method, you know, for your needs. If you have perhaps an organization where the resources are not readily available, people might be quite busy, and you might have to, you know, resort to, you know, a business analysis design approach where you might have to, you know, discover yourself how the process works, and by, you know, using people's time in short bursts, if you know what I mean, and go around different people and not necessarily get them in the same room, but talk to different people and sort of start to explain.

And sometimes you can break down a bigger process, a bigger problem into lots of smaller ones, and then maybe it's a bit more digestible or manageable within the business.

Yes.

So that brings me actually to the first point you mentioned, the method. So maybe we should drill a bit deeper into that. One by one. What do you think? Yeah, sounds good. Okay, great. And so maybe the first one, yeah, you mentioned was staff and small group interviews. This indeed, yeah, from my experience, for most of our customers, and when we look at departments, is the most popular form of process mapping as a technique. So sitting down in this staff, small groups, and Yeah, get a whiteboard or lots of whiteboards, clipboards, that kind of stuff, lots of good pens, and then just discuss in this small group. Basically bring everyone who's involved in that process. When you think about purchase-to-pay process, very straightforward process, or client onboarding process. So if you have that Yeah, you will bring everyone into the room, or these days into a virtual session. You mentioned you using Miro as well, Arno, on our Clubhouse session. And yeah, so that works really well. You can map out very straightforward the process, how it should run, define sort of all the scenarios and all the little details. So, and if there is a business analyst available in this little group, in this small group. Sometimes someone is just taking over that role, but if you have the luxury of a business analyst, yeah, so you will just gather the information, put it structured into the whiteboards, into Miro, so that person who is sort of leading that session is It's required to ask really, really direct questions to every delegate in this workshop. Yeah, and then you can fill in all the details. You map out all the activities in your process, all the deliverables, all the assets, everything which was part of the process. And then you get to the full picture how process should be put together going forward. And yeah, so there's some pro tips we have as well. When you have a session like this, yeah, have really a prepared set of topics you want to cover and a really good set of specific questions. And don't overdo it because everyone in this room is quite focused on this process, but a 1-hour session is certainly enough to get through a lot of stuff. 2 hours at some point, yeah, your brain is working, you, you can't work efficiently anymore. So if you have a really focused session, 1 hour per session is enough. And yeah, and if, if a discussion doesn't go anywhere, so the discussion is getting blocked, park the problem and come back to the, to, to this problem on another session. Because maybe at the end of a session everyone is so focused and in-depth on a specific topic, you will not get to a solution. And be quite strict, never overrun. You set 1 hour, so you're doing 1 hour, and then people are more open to the next session which is coming up. Because no one hates if it overruns like for hours and suddenly or you can't handle all the other work you have to do. So yeah, that's, um, that's how, how we do most of our sessions. Um, sometimes it goes into bigger, bigger ones and bigger workshops. Um, so Arno, you, you, you had to plan a couple of them, isn't it?

Yes, quite recently. And you know, the technique we use there is, is really, um, you know, facilitated discovery workshops. And, you know, we use this technique where it's important to gain consensus from a larger group of people, you know, and it's really appropriate for these type of sessions to be at a higher level of abstraction as opposed to sort of detailed levels that the group interviews, you know, is conducted in. And again, with these workshops, the discovery-type workshops can be more productive over a longer period of time. So sometimes you would need, you know, several of these to get through the process or the high-level processes. So really the trick is to retain energy and interest in the room, and you also need a very skilled and experienced facilitator that could facilitate the session and also make sure that there are engagement, you know, from the participants. So, you know, there's a couple of tips when you do these facilitated discovery workshops. And again, you know, it is the job of the participants to define the process and to make the workshop successful, you know, not the facilitators. So the facilitator really needs to ensure that this, you know, he or she involves the people in the process discussion, um, you know, keep as much energy and variation and interest in workshops as possible, um, you know, keep, keep to the time frames, you know, make sure that we don't overrun run, you know, and also make sure the participants are comfortable, make sure that the facilities are really comfortable, you know, and stick with your facilitation process and, you know, don't engage in any sort of peripheral subject matter debates, you know, leave that to the participants. I think that the thing that you want to do is you want to ensure that you kind of stay neutral. You want people to start talking among each other, really. And of course, you know, like you said, you need to have frequent breaks. So if you do have long sessions, you might not have a whole day scheduled for this, you know, don't sit people 6 hours in the room, you know, make sure you kind of give people time to have breaks. They will then kind of be able to reflect on what they've just discussed. So all of these are really, really, really good tips to make sure that the session is quite fluid and you make progress. And with these things, you could easily, if you're a facilitator, like, you know, some of the workshops we had recently, you can easily gauge the participation and gauge the interest of people, because naturally sometimes there will be a bit of a quiet period where people don't participate. So I think it's really your job as a facilitator to spark up the interest again, maybe take a break, come back, go over a process segment that you've just covered, and, you know, start with a new section.

That's great. Yeah, so the first two sessions or methods are sessions with people, but there could be also, like you mentioned earlier, a bit easier approach. The analysis of existing documentation is, yeah, is maybe not as obvious to many. But yeah, it is, I would say, an underused technique. But when you ask people within the business how does the process run already, maybe they point you to this existing documentation. Sometimes that documentation is very old, but still it can give you a lot of insight into the process, how it's generally running. In most organizations we come across as well, it is very outdated, that documentation, and inaccurate. Sometimes it's absolutely useless indeed. But if you come across a document which is more up to date, it could be a big time saver. If you can actually derive the whole process from that documentation alone, or maybe in combination, a bit of documentation and then a really small session, a small group session maybe fills in the gaps and brings it really up to date. But if you have a more established environment where you already have a couple of processes, so this technique could be very useful. You could take that documentation and then start mapping that process from that documentation. Sometimes you already have that ready-to-go process documentation within these documents you can use. Yeah, so I guess a tip, if you have access to this existing documentation, yeah, you have to really go through this in depth and This is a job for somebody who can hunker down and grind through these documents until the job is done. So you really have to turn through, go through everything here, get all the document sources together at the beginning and keep that as a defined scope. So it's very discouraging to manage if the documentation pool is allowed to grow. Mid-analysis and yes, it was like a moving target. Yeah, much better to complete the job with the first set of documentation and then repeat the whole process again if new sources come, you come across new sources. Yeah, I think that sometimes is the problem, especially in large organizations. Suddenly another department comes with a different variation of that process. So we have a couple of those customers big finance institutes, lots of old documentation and plenty of places where documentation is stored. So that, that could, could be a bit of a bummer.

But yeah, I think, I think you, by the trained eye, it's easy to discount documents that's perhaps not relevant or discount documents that's out of date. I think if you, if you have got a trained eye and you look at process documentation and you know what you look for, you know, it can sometimes be, you know, quite easy to, to understand, you know, how do I actually extract the, the actual process that we need to go and automate from this, and how do I sort of ignore some of the noise. Now, you know, it takes a bit of experience to get to that level, but I think the more you do it the easier it gets. And that sort of brings us to the fourth technique to, you know, to do process mapping. It's really direct work observation. And, you know, this particular method is usually more efficient, you know, in a highly manual business environment, you know, where process steps can be overseen and you can observe the tasks in real time. And, you know, of course you need to have permission to do that. We call this a time and motion study, but that's a very, very tried and trusted method. Again, you need to prepare for this. You need to make sure that people understand that, you know, your particular process mapping exercise will involve direct work observation. Ask the right questions, ask people why they do specific things. And I think you will soon realize, you know, how, how the, the process flows. And if I just jump into the fifth method, and that, that's our business analysis and design. And, and this is the one that I mentioned earlier where you don't particularly have access, um, to, to stakeholders, or the process you're trying to map doesn't really exist. So, you know, it's one of those where you don't really have access to those subject matter expertise because it's either too impractical, you know, you can't just drag the CFO into a process discovery workshop for 5 hours, or it's very expensive to do so. And it's quite typical in sort of clinical and academic environments where it is really hard to, to, you know, to get those experts in the room. So I, I think, you know, this is where the sort of business analyst element comes into play where, you know, your direct knowledge of the process or the process to be is important. And, you know, it, it will require you to, to you know, to use a variety of methods to get to that point where you could propose a proposal for a process that would work, you know, and it shouldn't be a guesstimate, it should be something that you've analyzed, you've calculated it, and of course, you know, that's something that you could put together and you need to present it back to the business, you know, so, and again with this technique, It's not so invasive because you're not really asking too much of people's time, but it can take a bit longer because behind the scenes you do the business analysis and then from there on, you know, you need to create the process map. So there's a couple of tips there as well for our listeners if you do this approach. And the first one is really not to make any assumptions. It's very easy to dive into, you know, this sort of business analysis or process analysis and make a lot of assumptions. And once you've got your process map, when you review it with the stakeholders, you know, it's full of holes. So that's very important that you really understand the things you work with is factual. You've got evidence to back that up. And again, that's part of sort of the analysis that you will do with insight that the problem you're trying to solve. The second tip is really that you need to gain strong approval, you know, from people once the process is mapped. And, you know, if you don't have the subject matter, the business subject matters expertise involved, within Site Mapping, you know, what you need to be able to do is involve them in the sign-off of it. So you need to have very practical ways and easy ways to explain to them what your idea is to solve this problem and, you know, the benefits it will bring in automating this type of process. These people might be quite busy, so you, you know, you need to deploy really strong techniques to to really use their time, you know, their time quite efficiently. So, you know, keep your presentation of what you think the process should be like and how to solve the problem really to the point. And again, when you employ this sort of business analysis design technique, what you need to do is you need to timebox yourself. And not get too carried away. You need to look at a process and perhaps create, I don't know, a couple of pages of it, map it out, and once you're done with that, optimize it, make sure it's as best as it could be, and try to get that sign-off from the process stakeholders. So you could move forward, right? So I think that the whole idea here is that it is a bit of self-discovery. You need to have creativity in mind as well, because sometimes you're not going to, you know, have all of the answers. But I think that also provides an opportunity to create something quite new that's perhaps not just automating an existing manual process, but it's coming up with a really new idea that could, you know, make the process a lot better.

Yeah, so that brings us to the, to the last method and the last technique. Maybe, maybe on this good position, you can import and use existing process documentation. So that's, I guess, in the perfect world, what you What you will have in the perfect world, we would import process documentation from existing sources. These days we probably would look at these sources in 3 different types. One would be unstructured sources of process documentation, some documents, we covered that earlier, maybe some slides from previous workshops, some videos, spreadsheets, all sorts of stuff we could use to document our process and import that stuff into our process mapping tools. And so unstructured is quite difficult, as we know. So we need some really good understanding of what's really part of it, probably very manual to start with. Otherwise, they are structured. Where we already have process maps and flowcharts available. And the third type we talk about is interchangeable content sources. So this could be models, UML, BPMN, and different other types. So when we look at the unstructured part, Yeah, so there's a lot of stuff happening at the moment. So we as well have the, the Conveyor Intelligent Capture Cloud to make meaning out of unstructured information. So if we want to really import that information, we need some help, I guess, with AI to extract that meaning. Otherwise, if we have unstructured content, it goes back to to the analysis of existing documentation, which is a very manual approach and tedious approach. But then this, in these documents and spreadsheets and all that stuff, we find a lot of information potentially. And we wouldn't need so much BA time, we wouldn't need so much workshop time. So it's definitely interesting to look at this, and hopefully in the future we can get even more out of unstructured information. Automatically. But when we look at structured sources, that's information we can import in sort of an original format. That could be maybe a Visio diagram or could be another one, BPMN diagram from another tool. So that's very structured and that's absolutely ideal if we have that, so we can import that straight away. And then there are other interchangeable formats you might have come across already, BPML or xPDL. So these formats, there are some tools out there which are writing these formats out sort of in a standard and compliant way to to define a real process. And if you have a system out there who can import it, you have all the definition, everything in place straight away.

Yeah, I mean, I think ideally that, that's the ideal place you want to be. But I think, you know, from a practical sense, you know, just looking back at, you know, the years with the process mapping we've done, I think you know, interview style kind of group sessions work pretty well. I think that the key is to, to have the right people in the room, representatives and stakeholders of, of the actual people that participate in the process, perhaps the process owner or owners, um, clearly defined roles and responsibilities of You know, how workflow between the different people that participate, clearly defined sort of metrics on how long it should take for work to flow. You know, so these are things that's quite subtle, but you know, it's, it's a good facilitator would, would be able to table these questions and challenge the people around the room to, to you know, provide their input. And really, I think the, the ultimate goal is really, as people speak, is, is to solve these problems, you know, and to have the debates on should it go to this department or should it go to that team member? What happens if somebody's out of office? Should we send a notification because we get so many notifications anyway, or should we send a daily summary of notifications to people to alert them that they've got a task? You know, what happens in exceptions? How do we deal with any exceptions? For example, where can we plug RPA robots in? For example, you know, what type of reporting do we need to have for our process that's in flight? That's very important to talk about. When we interact with our processes, what type of user interfaces do we require? If we design dashboards with, with SLA indicators, how that What does that need to look like? So there's so many talking points that you can bring into these sessions, and I think the key is to get the participants to engage. I'm a firm believer that people tend to only talk about stuff that's important, and this is really important because people tend to, when they have a discussion, especially in process mapping exercises, The things that's really relevant to them in terms of automation is the stuff they talk about, and everything else is really what we could consider to be out of scope. So it's really, really quite a focused thing. And hopefully, if you conduct these sessions in the right way and you ask the right questions, you know, you can walk away with a well-defined process map that's ready for automation, that hasn't got too many areas of outstanding discussions or discussion points. And, you know, that's ready to pass to automation developers to configure within the automation tool.

Yeah, one thing we came across as well, sometimes when you— yeah, this is why it's so important to get really the right people and everyone of that process, part of this process in the room, because sometimes If you have a good energetic group and discussing one person is missing, yeah, they definitely talk about stuff they think is important. But then suddenly someone else comes along and looks at the output of that workshop, say, but what about this and what about that? So we have this department here and what about this? Suddenly the whole thing falls apart, isn't it? So you mentioned that. That earlier in the Clubhouse session, and that's very important to look at potentially. If you don't have the right access, if you have already some other information which can help in a workshop, that will be good. Otherwise, yeah, there's always a bit of a risk. Yeah, and I think it's an important point.

And I think that, you know, assuming that the right people are in the room and you host the sessions in such a way that you make really good meaningful progress, I think you energize people. And if your technique is refined and you do it the right way, people will more likely return to these sessions and contribute more. And I think it's easy to gauge their interest because if your sessions are boring, they're long-winded, you don't get problems resolved, and people tend to have this kind of mindset of, well, this is pointless, we're never getting anywhere, it's too hard, we can't do this, there's too many people in the room, you know, can't we just write a document and and give that to you. But of course, the danger with that is that people write in different styles, people put too much details in the document. It's very hard to extract the MVP or Minimal Viable Process from the documentation. So your technique really needs to be quite, quite good. So, so there's, there's meaningful flow, there is solutions to problems. If, if there's blockers or points people get stuck in. This is where experience is quite good, where you can perhaps on the fly suggest alternative ways of doing it, and perhaps you, you've got some experience of a similar process you've done for another customer that, that could help. So all of these, these things really help to, to make the sessions, um, you know, quite dynamic, quite enjoyable. And, you know, we find that at at the end of these sessions, once you have mapped the process out and, you know, people can see it, you know, there is a sense of pride that people feel. Well, I've actually participated in this. We have actually nailed this. We've, we've got the process mapped out. You know, we are quite pleased, you know, with what we've achieved today. And, you know, that's a good start to any project because once you get to that point, and you've already got that sort of early success in just doing something small but important like process mapping, you know, the rest, you know, it's a good start for a successful project delivery then.

Absolutely, it's key. Without that, how would you know in what direction you have to go, isn't it? So it's absolutely important to get that part right. That's, I think that's it for today. Some or 6 methods how you can create your process maps. So if you are keen to learn more about creating your process maps or you need more help with this one, Arno and I are here for you. And reach out to us via the social channels or visit our website theautomationguys.net. And yeah, so we can, we can help you to get, get started with your, with your automation initiatives. And yeah, thank you, thank you very much for listening. And yeah, see you all soon. Let's automate it. Unfortunately, that's it again with this episode of the Process in Automation Podcast. If you like this episode, please give us a 5-star rating and don't forget to subscribe to this podcast so you don't miss any updates. Upcoming episode. We hope you will tune in next time, and until then, let's automate it!