View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Courtesy of SilverMist's Shyamal Addanki below is a transcript of his speaking session on 'Using process risk analysis to determine the starting point of digital transformation' to Build a Thriving Enterprise that took place at Digital Workplace Transformation Live.
Using process risk analysis to determine the starting point of digital transformation
Process Risk Analysis (PRA) is a method of examining and classifying operational processes into categories based on a variety of factors. This will help understand the completeness, accuracy, and precision, and automatability of process models and can also explain process discrepancies and lack of performance. More importantly, this exercise will provide a picture of which business processes are ready for automation and digital transformation, and will clearly illustrate the work that needs to be performed for processes that are not ready. Companies that do not examine their processes before implementing automation solutions tend to focus on the processes that cause the greatest problems – but automation is not always the solution and in fact may vastly accelerate failure.
The goal of this session is to provide a framework of PRA as it applies to a digital transformation strategy and encourage the user to focus on preparing processes for digital transformation before implementing technology.
I'm talking about, a donkey, who is here with us, to talk about use the use of process risk analysis to determine the starting point of your digital transformation. ..., a pleasure to have you with us. I want to just quickly introduce you to the audience. Tamale has spent his career, Optimizing operation processes and focusing on process optimization for digital transformation is passionate about process management and governance and has develop a process risk analysis framework that he used to help organizations identify and improve processes. To support business growth. Shomali knows that you cannot automate without first understanding our processes.
Eliminating the value added, reducing it, and then you can look at automation intentionally and thoughtfully.
Chema, it's wonderful to have you with us. Thanks for our thought leadership, and thanks for taking the time to share your expertise with our global audience today.
Thank you so much, Josie. Thank you so much for having me here. It's, it's great to be here, obviously, always involved with with vetoes. And what I'd like to talk about today to everyone who's online, you know, is, is how do you do that digital transformation journey from your starting point? I think this is, you know, the kind of content that we talk about it at this event, has been great regarding digital transformation, what's necessary, where, you know, we can go with digital transformation. one of the things that I've noticed is really the struggle that a lot of companies have to say, Alright.
But where do we get started with this? So, welcome, everybody, to this session, and I will spend the next 35 minutes trying to give you some ideas of how you can determine that starting point in the way that will make you really set up for success going down. There's a lot of studies that have been shown that did a lot of digital transformation projects fail or struggled to meet their expected Roy. 2, 3, 5 years down the road. And a lot of that has to do with how pilot projects are selected and whether or not they're really representative of the potential of digital transformation and digital workplace.
So, the title of the session is Using Process Risk Analysis to Determine the Starting Point of Digital Transformation. And that is a mouthful, and it sounds scary. So, if you're, if you're still here listening to this, and that you're in the right place, this is something that's, that's really important.
But, I would like to start with the question of why? Why do we need to consider such things. That's something that's really important.
So, let's take a scenario, and this is a scenario that I'm sure many of you are familiar with.
Let's imagine, your company has said, we know we need to change the way we work. We need to step up to this digital transformation everyone's talking about, here's a budget.
Go figure out what we can do. Show was an idea, shows a proof of concept. Let's see how we can take our processes to the next level, to the future.
Now, you take this, and if the project is successful, you're going to be the one rolling it out globally. You're going to become the big heat on the company. So, it's something that's in your hands, and you really want to make this work. This is your project. So you attend a conference, typically, something like ..., for example, and you attend all these great sessions and really understand, you know, what's possible.
Understand all the concepts of people, process technology, how it works, and then you go and talk to a lot of vendors at the exhibition hall. And the vendors show you tons of solutions from RPA vendors to BPM vendors, and all these automation, collaboration, tools, and everything that's possible, and that's great. There's, There's just so much out there.
It would make sense to start this project. Pick a couple of vendors, and I'm guessing, at this point, most of you already have something in your mind mm. If I had to do a pilot project, you know what? I would pick this process, there's something that you already have thought about. Perhaps it's something that you're working on right now, or perhaps it's something that you're going to be working on, but most likely the seed has been planted.
The question that I ask is, Well, which process would you choose for your proof of concept?
And, that's really the thing that I want to address, Because, in many cases, I've done proof of concept projects for many companies, and I've been in companies where we've run proof of concept projects, and, typically, they were using the wrong criteria.
And what I mean by that is this: Most people, when they go around to select, OK, which process should be be working on? Which process should be improved? And even the process that you have in your mind that you thought about. Ask yourself, why.
Why did you pick that process? What is it that made that pop into your mind and say, yes, we need to fix this first, and then we can fix sort of everything else. Most often, you've got the one that everyone complains about. That's the one that everyone is coming to you and saying, Hey, this is not working. We're creating all these problems. We're always having issues with the system, with the software. People aren't doing it properly.
You hear the complaints. You received the complaints, and you have it in your mind, saying, We need to fix this process. We should use digital transformation, Use these cool automation tools, and we can do all this great stuff with it.
And then they are the ones that, that impact the bottom line, that your management has come to you a few times and said, Hey, you know what? We have an issue. Our invoices are always going out late, or going out incorrectly, and we're not getting paid the right amount, or not getting paid on time. That's impacting us. What's going on with our invoice software? What's going on with our invoice verification process? So this is something that directly impacts the business. And you hear the complaints.
So you're like, hey, maybe we need to fix this, then there's obviously, there's always this processes that we've always done it this way, it's working, yeah. Sure.
It involves sending a fax, it doesn't matter, but it, but it's working, you know, that's something you want to update and then there's the process that isn't well documented, those are the ones that, oh, you know, Joe in the corner over there knows how to do it. Just go ask him kind of a kind of a process, and you say, well, maybe maybe we need to document this. Maybe we need to see how we can do it, do it better.
And this is probably the most common reasons that I hear about how people select pilot projects. So, what's the risk If you use one of these criteria to select the pilot project, and I'll get into this in more detail later on. If you use one of these criteria, select a pilot project for digital transformation. You're not proving digital transformation, you're fixing a broken process and applying digital transformation.
And of course, that's good. That's good for the process. But you're not proving your point with digital transformation.
So let's talk about Process risk analysis PRA.
Um, PRA is something you should be doing anyway. It is a good exercise. It is something that you could do once a year. You could do what, you know, twice a year, depending on your bandwidth and capabilities to do it. It helps you understand where your process transcript lies, But we're also going to talk about how that tool can then help you determine your starting point.
Process risk analysis, you can think about this, too, is there's two things that it does: It helps you visualize at a macro level where your process landscape is in terms of maturity and stability, and it helps you understand where your risks are in terms of aligning your process to your business, goals, to your business strategy. Does your process map reflect your corporate strategy that you have? Another way to think about it's by asking two questions. Are your processes today aligned with your actual company operations the way it's meant to be? And are your processes aligned with your company strategy? So, there's a lot of ways to figure this out.
one good starting point is to understand, OK, what is our company operations, what what do we do? How do we do it? Ask some very basic questions and rollback and get a map of what you should be doing? And what is your corporate strategy? This includes things like, yes, this is wherever you expect the company to be, in five years, 10 years, This is where the market forces are, but it also includes things like, these are our company values. These are our company main operating principles. And does your process aligned with that? These are the kind of questions that we want to answer.
And a lot of this will be done through surveys, through sitting down with key users to really understand their needs. And, again, you know, this is a high level overview to get you started, but then you can dig deep into almost every topic here and say, Interview. People create a matrix, understand how users are actually performing the process versus how it's actually being documented, or it's expected for them to perform that process.
So, to do that, there are two metrics that we look at: process accuracy and process precision. And this is, you know, very much coming from six Sigma in statistical analysis, but we're not looking at, necessarily, you know, a single process by itself. We're looking at it as part of a whole landscape.
So, for, for a quick review, when we talk about accuracy, we're talking about whether the end state of the process is actually achieved. We're not looking at how you get there. For example, in a process invoice process you have, an invoice is generated at the end. I don't know if that was the most efficient way to get to that invoice. Maybe that could be improved, but at the end of the day, a process is an invoice is generated. If you're not going through the process and coming up with a contract document, you are coming up with the right end state.
And a process is precise if the steps of the process are always followed. Now, again, at this point, we're not talking about, is it the right process? Is it the efficient process we're seeing?
Do you even have your process and control? Are people following every single step of the way, or are they doing extra work? Or are they finding shortcuts and things like that? This is what we want to find out first. This will help you determine the health of your process.
So we can quickly look at a few conceptual examples and then I'll show you a real example as well.
Now, this is your documented process. This is what it looks like. This is what you know, we said you should do. These are all the steps. Obviously, something very simple, and then you go and you start interviewing key users and say, Tell me how you do this process. Tell me what exactly your steps are. Who do you send that e-mail to? Where do you log this information? What exactly are you doing in the next step? And so on and so on.
And then you start mapping that out and find out, well, that is exactly what they're doing, is it. Here are some things that they're taking sidesteps. Here's some things where they're going to other people, sending the e-mail to the head of HR, they're sending it to the group director, who then has to forward it to ... Y. So you're finding out all these escapes. All these points where something is not being done the right way. And you're mapping it out, and you're scoring it, And again, the way of scoring it, there's a numerical formula that we use, But the important parts to find out how much deviations there, and in some cases this deviation is, an extra work does, Deviation is skipping steps as well, why are they skipping that step? You know, we need to sit and examine, and figure that part out.
On the other side, this is where you've got processes that are precise, but not accurate, because they aren't going through all the steps as they're meant to go.
They end up with different results every time it could go in any 1 of 3 buckets. And this still does happen, and usually, it's caused by a lack of training, a lack of control of the tools. in the previous case, when you've got the processes and people going through many different steps. I would say 80% of the time that I've seen that, it's a lack of proper training.
Here, it's less about training. It's usually more about tools and systems that allow for these sort of things to happen.
And, you know, one example that I've seen, and it's sometimes it's the most simple little thing.
one example, is where you have a form, and there's a date field on the form, but there's no instruction on whether the date is supposed to be day, month, year, or month, date, year.
So, someone writes eighth of January as 81, and someone else is writing it as 1, 8. While, the system has a Preferred format, obviously, so it's, it's classifying these documents is different ways And putting them into different buckets because it thinks the dates are different? This is a simple, you know, basic example of where this kind of thing can happen, but this is what you need to be able to catch and understand, you know, where does this happen?
Sometimes, though, you know, just as in the other case, we have people taking shortcuts. Could be a good thing, and we need to validate why they're taking shortcuts. Is that a better process? Sometimes here, when you've got multiple outputs happening, it could also be that you require it. But it's simply not documented.
So, again, at no point here, are we saying the process is right, the users are wrong. We're really just trying to understand the disconnect between the document to process and what's actually happening.
And then, of course, you know, it's rarely one or the other, a lot of times, it's a mix of both. A lot of times, it's a lot more to do with process accuracy and less precision and things like that. So then you've got processes, where you've got the mix of things happening.
Now, you sit down and you analyze. And you get all of these, this data down, and you sit and map out where your processes are. And you can then put this against a matrix, a simple 2 by 2, and look at your precise, not precise, accurate, not accurate, and understand, OK, so this is my process landscape. If I'm going vertical, that means I've got more variations in my process. If I'm going horizontal, I've got more waste happening in my process. So, this is what you want to understand.
And then you can actually go ahead and map your processes that you have on this, and try and understand, OK, so in our entire process landscape, this is where they all sit.
This is the important part, because when you're able to do this, now you have an idea of your process landscape. Where do our processes sit in a chart like this? Now, we can look through and say, all right, we meet, maybe we need to sit and look a little closer at these processes and focus at fixing these. But these are pretty mature process. And overall, you can say, you know, if you have less process risk, when you're on your upper right quadrant and greater process risk in your lower right quadrant.
So this is, this is the start of process risk analysis. You're trying to really understand your landscape, where it fits here. And then you can start even making connections because processes can be linked to each other. So if one process is stable, but the other ones risky, and it's an upstream process, then you want to make that connection as well.
So, but when we talk about process risk, the next important thing is to understand, OK, what are we doing with that process risk? What type of risks are we really talking about? And there's really three types of process risks that I want you to classify these process risks into.
The first are short-term risks. And when I say short-term risks, these are issues that are having no issues daily. These are creating problems today in production and operations. Your car is leaking oil. This is a thing where you're getting a ton of rework because you've got a bad quality process, or whatever it is, this is costing money today. It needs to be fixed today. So, you classify those as short-term risk.
Medium term risk is really looking at processes that, you know, they work, but they're not optimized for.
Today, they're not, but perhaps as digital as they could be there, They've been like this for, you know, the last 10 years, and they work, and they're stable, but we could make them better.
Because, if we don't, other companies will. And then, that'll become a competitive advantage that they can deliver faster, better, quality products, because they're using latest processes when we're not.
So, those are, sort of, medium term risks that have, and then, long term risk is really about now, aligning your processes with your company strategy to say that the process works today. It is where it should be today, but is, you know, is it in line with where we wanna go 10 years from now? So, for example, if you know that as a company, you're involved in a lot of M&A activity and you're planning on on, you know, entering a new market. Do your processes work in that market, or do you need to update it? At one example that I've seen in this cases where you had a very old-fashioned brick and mortar company that was running well, had a great cash balance and wanted to get into an online market.
And part of what it wanted to do was to hire a lot of young sort of new marketing folks and get the company's brand awareness more hip, if you will, is the way they put it. But the problem is their entire onboarding, processes and workflows were very much old fashioned, So they had to re-imagine to say, hey, when we need to hire new, younger people, and this was a family business, so, this was the first time that we're actually looking at hiring completely outside.
You know, what is it that people are looking for in terms of benefits and salaries and work culture and working from home and things like that pre covert, obviously, you know, this was the kind of thing that was a new onboarding experience that had to be done and had to line up with and the company was ready to make that shift.
So, this makes sure that when you do make that strategic change for the company, your processes are already aligned and able to support you from doing that.
A lot of what I've talked about so far is very qualitative. We're talking about being able to have these interviews and talk to people. And you absolutely have to do that. I'm a firm believer that the data alone cannot drive your processes. You have to talk to your key users, understand where they're coming from, make those interviews. But there is a quantitative aspect to it as well, because you can score your processes based on the process accuracy and process precision. Using a couple of different formulas. To give you an example, this was in a wire harness production company.
We did this sort of project for the processes and you can create for every process that they have, you know, a scoring methodology and and a risk methodology. And the real numbers that you want to look at are these. These are what are really giving you know, your, your key metrics for your accuracy and precision, their accuracy index and precision index. What that does is essentially tell you how far the actual process is straying from the documented process. Again, it's not telling you why or anything like that. That takes much further investigation that you need to do, but it gives you a starting point, because now with this, you can actually plot tips.
Again, on an accuracy and precision chart. And this is giving you some real values.
And this is actually now looking at, all right, so here's a process layout, this is what it looks like.
And this, you know, very much, is in line with the previous qualitative matrix that I showed you, you can just overlay it and really understand, all right? Here are the processes that are more at risk. Here are the process that aren't. And this company, actually, in fact, they, there were an engineering company that also does manufacturing.
And what they wanted to do, was, to, know, for looking at the long-term risks, they wanted to branch out and perform manufacturing for other companies where they would do the engineering release. That was a long term strategy of the company.
However, what we discovered, if you look down here, E N, 138, is actually there, is actually their review change, sorry, release Engineering Model process. So, they're, they're engineering release process itself was creating a lot of issues. And had they made that strategic step to start releasing engineering for a bunch of other customers. That would have ended up becoming a huge bottleneck. But we were able to catch it up here and say, no, hang on. We need to fix this process before it becomes a major issue down the road.
And this is, this is not a bad landscape if this is what you have. Really, a lot of companies end up with more processes on this side. But this isn't bad, But, again, this gives you a start.
But, going back, you know, to the original question, and the theme behind this session is, if this was your company, and this was your process landscape, which of these processes should you pilot for digital transformation?
And I'm kind of hoping that by now you get the idea that it shouldn't be this one, and shouldn't be that one.
And the reason for that is, yes, these processes definitely need work. They need to be improved. But when you've got a pilot project, and you say, We're not going to improve everything across the board, we're going to be selecting some specific processes, and we've got a fixed budget to do it. You might have that.
Whatever it is, 15 K budget, you're gonna spend eight K of that, just improving the process to be able to automate it.
And then you're gonna automate it. And yes, it's going to be fantastic, because, obviously, you've started with something that wasn't a lot of trouble. You will end up with a great process, assuming you actually improve the process first, and then automate it. The other risk is, a lot of people take a process that isn't working well and say, well, this isn't working.
Let's automate it. That's put it some workflows in it and keep the main process structure going. And obviously, all that does is make you fail faster. So, that's not what you want to do. But in any case, for all of this is just going to either mean you have a bad proof of concept, it's not going to work well, because you automated a bad process. Are you going to spend a lot of time improving the process? And the middle time automating a process? And at the end of the day, it's not going to give you an accurate reflection of what digital transformation could do for you. Because even if you did everything correctly, you're gonna get this fantastic 400% ROI and things like that. When you're doing this process.
And then, great, let's roll it out for the rest of the company that's rolling out globally for the rest of the processes, and guess what the process is up here? Obviously, you're not going to get that same return because they're mature, and they will benefit from digital transformation, that will benefit from automation. Clearly, just not as much as as everything that you've done here. So, again, that starts to become a case of, well, that's not quite what we expected from our investment, where the digital transformation go wrong. And, you know, we hear that over and over again. Oh, we tried digital transformation. It didn't really meet the expectations. And, and every, almost every month is a new publication not about how digital transformation has an, you know, really changed everything for this company at that company and why a lot of it has to do with this. We're talking about managing these expectations from a proof of concept.
Then, there's a few other considerations as well that I want to touch on, because it's nothing, that's absolute. I'm not saying, Hey, do with the ... risk analysis, and now, pick that process that was right there and go for it. There's a few other things you want to think about. How well is your process documented? How well is it understood?
How well does an accurate, and we're trying to capture all of this in PRA, but you're not going to necessarily capture all the essentials. This is where you can talk to people, talk to five different people.
PRA showing you how much variation you have, but but how well is it actually documented? What people are doing? How complex is the process? Or is it something relatively linear or there are lots of logic gates and approvals. And loot bags, If you're trying to create a digital transformation pilot project for an incredibly complex process, you are, again, going to spend so much time trying to figure that out. It's not going to give you the kind of result you want, unless you're trying to do a real let, you know, do some, some destructive, testing, push, this tool, until it breaks to see if we can use the thing. That's a whole different story. And yes, we've done those as well.
But the real thing you want to do is understand, let's not jump into something so complex that It's just going to drown the entire project up to something that the with the process life cycle that makes sense. Not a property purchase that takes six months to a year before you actually see any results. Something that takes a couple of weeks is great, but obviously all of this depends on you. There's a lot that that's very unique to your company, but these are considerations that you should have as well. And how critical is it to the core business activity?
Are we, you know, improving a purchase requisition sort of workflow, or we are improving a core business that you, the company performs?
And if that breaks, what are the issues going to be? That's what you really need to understand as well. And how does it integrate upstream and downstream activities? Because keep in mind, you might pick this pilot project and deploy it, and suddenly your lead time has gone from three days to three hours. But that's really going to kill your upstream and downstream stuff and create huge bottlenecks and issues, so something you want to keep in mind. And again, there's no absolutely right answer for all of these. It's just something to consider.
And then the other thing is, when we talk about process risk, and how you're implementing all the processes that you're doing, the other thing that you want to do is, understand, it depends on which kind of automation you're trying to go for.
Some automation involves much more process improvement and some dozen. So let's start with Robotic Process Automation, which actually should be called Robot Task Automation, personally. But the idea with our case, you don't have the Process governance side of it.
So if you're going to do RPA, make sure you really have determine, you know, your process landscape, your process risks, you've improved, your process documentation, your process management and governance is great.
Then implement ARPI technologies on top of it.
Same for workflows because with workflows that are, again, not necessarily reflective of the process. You got to make sure that your process and process governance is in place.
On the other hand, when you're talking about business process automation or business process management, there's much more of a link to your end to end process. In fact, if you're implementing a business process management solution, then you've got your process modeling, and governance built in, right into it. Which is great. And so that's a chance for you to say, let's improve the way we manage the process, and automate it, at the same time, obviously, it's a much bigger project.
But you're gonna get some much more interesting results, in a way to manage the rest of your processes, and process landscape at the same time. So, this is something to be cognizant of which kind of technology you're going to jump into. Business process management is also going to give you a good sort of backbone of your processes that you can then use to trigger RPA bots to go and do other things and so on.
So, a couple of parting thoughts that I'd like to leave you with just, you know, and to talk about it as well, because it's not just about PRA, but it's all about how you know, what's the right way to digital transformation?
get to know your processes. That is key. That is the most important thing that we want to do. When we talk about getting to know your processes, it's really understanding how users are performing the tasks, what their interfaces, how many tools they're using, how many systems that they use.
one of the worst things that I've seen as someone saying, look, we're implementing all these tools, and now, we've got, I'm just going to name a few, but, you know, we've got Trello and we've got Teams, and we've got jira and we've got SharePoint, we've got all these other things. And, look how great it is.
And then, you talk to an end user, and they're, like, I come in in the morning, I have, you know, 10 Windows open on my desktop. I now have to do this in there enough to do that, and there and have to do this other thing there, and it's, it's, it's a headache for the user, and that's not what we want. So a lot of times, you know, we tend to forget that point.
When you find shortcuts, when you find users purposely skipping steps in the process, it's very important to sit down.
And we'll find out why lot of mistakes that, Especially quality management, doesn't say it's a, no, you shouldn't do that. You need to follow the process, which is true, but you need to understand why they're skipping it. Is it something that they've discovered?
Always remember that people are inherently lazy, which is good, but no one does.
Extra work for the sake of doing extra work is usually rewarded at the end of it, and if they're skipping steps, they might have found a great shortcut that everybody should be using, and we want to understand that. So, every time I find a user skipping some steps, I love it, and I sit down and say, OK, why did we have this in the first place? What was, you know? What was the value that we're getting out of it?
And then validate that.
Now, that's not always going to work, But it's a great starting point, and it's also great, because it will. Once you make a sort of reward culture around it, you'll start people coming up to you and saying, Hey, You know what? I haven't done this for like the last five years. I don't know why it's in that process documentation. And suddenly, you're like, aha! Now, I know. Instead of people trying to hide it and say, Oh, yeah, I do it this way, but don't tell this process, guys, right? We want to make sure that we find that out.
As I, as I alluded to before, process risk analysis should be a regular exercise. Yes, it's a way to get started for digital transformation, but it should be something that you're doing anyway. It's a great tool, very few companies do it. But, you know, when you go to a company and you talk to the process managers and the operations manager and say, What are your weakest processes?
Either they don't really know, or they think, they know what they think they know based on how many users complain about it. But, users complain about processes that are running really well as also. So, how do you differentiate that from the noise? So, process risk analysis just really helps you understand, this is my landscape for my processes. Here are my risks. Here are the things that are working, and more interestingly, doing that at a regular timeframe and every six months every year, lets you then see your trends. How are we improving our process, and really justify all these exercises that you're doing towards your processes.
And, long term risks. The whole concept of long term risks only works.
if you have a great communication channel to your steering committee level, your strategy level, at the company, which means you need them to communicate to you, what is the five year strategy of the company. So that I can go and make sure that we can support that, and we don't, you know, steer the ship this way, and everything breaks, because we weren't ready for it. That communication needs to be open, and that's something that's very important. Otherwise, none of this matters, and that's something that not a lot of companies have in place, and it's a very, very, sort of important thing.
And if you're already doing, you know, six Sigma analysis and if you've got your six Sigma team on board, PRA is something that you could even then rope into that. Because when, again, if we were to get the nitty gritty, the formula details of it, it's a lot to do with the six Sigma analyze phase that they're already doing for processes, but they're doing it in a slightly different way. We're not looking at performance metrics and runtime numbers. We're looking at the actual process since a slightly different way of thinking, but using the same concept, So it's if you've got a six Sigma team, great, bring them on board. You know, everyone who's into six Sigma loves to be into these projects. I certainly do so. So, it's a great way to kind of get this going with the company.
And here's sort of the thing that, for me, is really, really important that we need to do.
Digital transformation has been around for awhile it.
I've been doing digital transformation before. It even had a name. It wasn't called digital transformation. But we had this idea of saying, we're managing processes, and we've got a team of great software developers.
We could do something cool here and, you know, figure out how to make that work. That turned out to be digital transformation later on, but the focus has always been, you know, let's look at systems. So let's look at technology and how they apply to processes.
Where what we've learnt today, you know, after doing this for awhile is that that's creating a lot of failures and a lot of issues. Because companies invest in all the greatest new technology, but the users aren't happy. And when users aren't happy, they're not going to use that new technology. You could spend, you know, tons of money, developing a specific feature in your intranet, but users don't use it. Why did you do it? There's less and less. I feel real user involvement in these projects, a lot of times we end up talking with IT, or directorate of operations and they drive the project down. Very rarely do users get involved from day one and they really should and I, I challenge you to make that part of the culture in your company. It's something that's very, very important.
The reason for that, it's, it's interesting, You know, if you go back a decade or two, what we've done is, created the silos. The silos of systems. And what I mean by that is, take, take your ERP system, whether you're using sap or Dynamics.
Anyone, the ERP system, if you are in material management, for example, procurement. That is your application, you get into the morning, That's what you open up, that's what you start, that drives your daily business. And then the company says, oh, now we're using Trello for this. I'm using Teams, and I'm using, that's fine, but this is my main system, that is your sort of control panel that you use.
And everyone else is now, you know, using all these other tools.
But, in fact, what you really want to do is, uh, change that around. So, you're not looking at purely the IT side of things and saying, Here's my system, here's my CRM that's driving things. You understand how your users process is, how your users process goes through, and make sure that that is well documented, and that is being followed properly.
So, that's everything from my side. Obviously, you know, I'm open for questions, You can always re feel free to reach out and contact me if you have any questions further down the road. My e-mail addresses listed right there, and you can connect with me on LinkedIn. I'm always happy to answer any questions for later on further down the road. This is something that I'm very passionate about. I love talking about things like process risk analysis, and process improvement projects, and I'd love to chat more with anyone about this.
That's terrific, Shamil, thank you so much. What a, great, great, great, practical advice says, Stephen Parker, coming from UK. Giant Monster, the ..., who is from Sao Paulo, Brazil, says it's a masterclass, so well done in delivering and delivering very practical use for information to the audience here. And I'm going to bring more of their questions on the time that we have here.
And as I scan through several of them, you talked a little bit about, you've talked about the doing the analysis, and you're looking at accuracy and precision. From a process perspective, how do you translate that into the language of the C suite, which is value creation, so how do you go for accuracy and precision? And you'll make the translation to value creation to the C suite.
Hmm, hmm, That's, that's a fantastic question, and that is something that I should touch on.
So, all the analysis that we're doing with accuracy and precision again, should filter down to those three risks. Now, if you go to the C suite, with accuracy and precision there, they're not going to be listening at all. But if you go to them, and say, Look, we took all this data, we looked at, our accuracy and precision. Here's how, you know, we filter the data doesn't matter, but this is what came down. And now, we've identified three types of risks here. Are the short-term, midterm, long-term risks that is the communication to the C suite. Because now you can see, in our short-term risks, we have these processes. These processes individually are, you know, creating this much of failed invoice payments, because you're sending them to the wrong place. You can then quantify, based on those failures, where your short-term risks are. You then want to look at how, obviously, how much that's costing the company, if it is a short-term risk. Again, you know, short-term risk, meaning you've got process failures today, then that's something that you should be able to translate into cost.
And ultimately, that's the point, Everything we're doing here, is all about improving company profits. Not, you don't improve a process for the fun of it. one of the, you know, examples on that is always, you know, you can move a copier closer to a person so that they don't have to go as much. That's not going to improve company profits, right, So you don't want to be wasting times, and that. when you talk short-term risk, it's really, This is where we're bleeding money to date.
That should get the C suites attention.
And when you talk of the midterm risks, you're basically a way to phrase, the medium term risk is saying, yeah, we're doing it fine now, but those guys are doing it better. And they're doing it better than us, and they're doing it faster than us, and they're doing a cheaper than us, because they're using all these new processes and new tools. And batch it, again. Get the C suite attention from a competitive standpoint. And, like I said, with long-term risk, this is really a conversation that we should be having constantly with the C suite on saying, where's the company strategy and having regular meetings and saying, all right, you told me, you know, mister C suite at the last briefing that this is the five year plan for the company, I've gone off and I've done my analysis. And here's where I find the risks.
You want, you know, you want to expand out of the United States and create operations in Europe and Asia, but all their documentation are, you know, using inches and feet, so we need to go update all our documents. Before we do that. Things like that. You can show concrete examples of where their growth strategy for the company is not going to work with.
What you've investigated in the processes. So, my suggestion with community of C suite is not to go with process risk analysis, but really got to go with the risk results and saying, here are the short-term midterm, long-term risks, and here's the impact to the company that you can then quantify.
I hope I was able to answer that question, but, again, that's very good. And I want to follow up on this, because there are a lot of questions around this. Which shows that you did a really good job talking about the evaluation of the process, and the and the and showing the value that that this approach can have. And, just to quote, one of the many inputs that were provided by the audience, as you as you're presenting is that ..., for example, says, it's a great presentation. So, feel really understand this space or confuse it. As you mentioned, during your presentation.
in an era of exponential technologists exponential technologists can be great if there, if they're enabling the right processes.
But they also can make stupid happened at the absolute. you, you, you, your presentations at the heart of the issue. But, look, Lafountain also wants to go a little bit further on the, on the building, the business case. And he talks about, can you, can you talk about building the business case? Because, in the investment people, process technology, and his words, how translate that a little bit further?
That organizations and professionals really struggle from going from, yeah, our process is not stable, or our process is creating some defects here and there to quantifying the value creation potential of that.
For a multitude of reasons, sometimes, organizations are not transparent enough with their costs. You know, sometimes you don't have the right champion over a certain of a certain initiative. I'm curious about, you have a lot of very practical experience.
Do you have some tips on, on quantifying no dollars and cents, you know what, there's just, does, the ... are costing us this much? What, do you see? an organizations that do this? Well?
What does it do?
Yeah, that's, that's, that's another fantastic question. And I, you know, it's, one of those things.
If I, if I had it my way, I would really love companies to understand the importance of process management and people management to the bottom line. But let's face it, we all know, and especially those of us here at this conference, know that that's, that's not always the case. All right.
one of the examples that that really struck me that I saw worked really well, and this is specifically in the legal industry, but. but it's sort of got me thinking. I was like, well, why don't we do that everywhere? And what I loved about doing this for a law firm was we did an exercise in, very, very clearly marked out for every attorney, the work that they did as billable hours and non billable hours, Right? And again, I said, this is legal specific, but billable hours were great because they're doing, you know, a couple of reports doing this work and just charging the client, they're getting revenue.
But then they're spending, you know, two hours looking for a file that they couldn't remember where they put our, it's not in the right place, and those hours are not billable.
That lawyer is still getting paid for it, but the company can build the client, So, that is just pure cost, and so, once we did, that's a differentiation. We said, look, all these process deviations that are happening That's creating, you know, seven hours a week per attorney of wasted time. How much are you paying the attorney per hour? And coming up with that sort of cost. And when you're talking about attorneys, that number is very, very high.
And you can very quickly say, we can save you $20,000 a week, just by implementing, you know, a better, just by better processes. We're not talking about automation, digital transformation, just by approving the process that you have, using the tools that you have.
So that was a great way to just get everyone's eyes, light up and say, Yes, we've got a problem to address, but if you're even if you're not the legal space, that's what I would urge and say, OK, we want to understand. When we talk about waste, we've got a couple of different things. We've got our production, waste material, waste different, manufacturing, it's easy.
I get everyone's already doing that today. Why aren't we doing that for business processes? If I've got somebody who needs to go and file the paperwork and go and send it to somebody else every single time, instead of putting it in a shared folder and a link is automatically sent, I can easily quantify how much time they're saving.
And then I can even add a factor that because when I go and I have to wait for the elevator and I have I run it to somebody else and I start chatting with them and go get a cup of coffee, All that time is factored in versus just here at ... Show location, it is quite an involved exercise. And that's why, you know, on this topic, I focused on the pilot project because this is where you really wanna go in and say, Here's how we can do it. And once you can show them that these are the kind of savings that we can get in or interviewing people were understanding the way through understanding the Rs You have to get it into a dollar and cents figure. You have to get it into.
Here's the amount of time being wasted by people who are being paid this much per hour, that we can then result by doing these sort of things. But if, again, we start implementing these on the wrong processes. We're just wasting our time.
So, process, risk analysis is going to tell us, where do we start? Where do we go through? And, you know, just to follow, that is another example. That engineering company, I was talking about the idea that their engineering release process was so terrible, and very badly managed, and with very bad governance was a shock.
That was something that, that senior leadership did, not know until we were able to show them the metrics, and just statistics and say, out of every hundred engine releases that happen, only something like seven of them were happening correctly by process, and everything else had a failure somewhere, or the other.
They just didn't have that knowledge, and once we were able to show it to them, it was just, you know, something really amazing for them.
Very good. Very, Very good, good, good discussion. There's a tremendous discussion to your point, on using that, a lawyer example, they are mm, and especially in operations, that can be more complex than that. Sometimes it's hard to determine exactly what some of the costs are associated with those people and those functions, and unfortunately some organizations keep a very close tab on, on on that. Right. And they do not, you know, don't want to share that information for different reasons, which becomes a real issue. But, but, that's not a discussion to be had, you made it very clear.
That. And I think that's a very important point to, to, to conform with the entire audience about this important asaf, having an assessment of value creation from an internal efficiencies standpoint, but also from our revenue generation standpoint. And, real to tackle both opportunities. When you look at value creation now, let's go a little bit step further now. A number of questions related to governance. And you talk about governance, You know, a little bit, you talked about governance, and governance can happen in multiple layers and multiple levels.
But, if we focus at the process level, I think that this audience will recognize that most processes that maybe matter, and they are not functioning very well. There's a very high degree of correlation between that process not working well, and poor governance at the process level, and what that means is that you don't really have a champion who may be overseeing that area very, very effectively. You may not have process ownership. That's defined, answer. And worse yet, you may have multiple process owners and they all have a different definition on how to do things. So, let's tackle that one piece only.
How do you deal with ineffective process ownership that either you have multiple process owners who are not agreeing on what you do or, are nobody owns the process? Tell us a little bit about nailing down that process, ownership?
Yeah, that's great. That's, that's, that's another fun exercise to path.
So when we do workshops, very often, the thing to start with, and then I will come to the process of governance, but, but it is linked. The thing to start with is with process naming. How do you name a process? And that's, that sounds like a silly question, but it's not because it gets people thinking. If you take a process, like, I didn't know, employee onboarding.
And that's a common name. That people give their new hire process, employee onboarding. And I always ask, alright, employee onboarding, who's doing the employee onboarding? And they say, well, HR's doing it. Well, who and HR is onboard and employee? And of course, as many people doing it, and truth be told it's not just HR, the line manager has some functions to do, security has some functions to do with badging and and so on and so on.
But I'd say, OK, when everyone is having trouble, who are they going to and saying, What's the status with a new employee? Where are we? Why isn't he here yet? And that's the person that you identify. So when you talk about process naming, then, I change it around and say, don't say employee onboarding, for example.
Always start with the verb that you want. The reaction, where it. So, you're saying onboard employee and gives it a much clearer way of action, the employees, the person that it's happening to. And, onboard is what's happening and you can easily add the person, the owner of that before, that you should be able to do that.
Same with, you know, verify invoice, the invoices, the object. What's the subject? Who is the subject? And, you start sort of pushing on that. They should always be. And, I know people will say there's exceptions, but I'd, I'd push this very hard. There should always be a 1 to 1 ownership between a person and a process, Never, multiple process owners and definitely never know Process owner. The process owner doesn't have to be responsible for every step in the process. They own the process documentation. They're responsible for revisions. They're responsible for approving changes that other teams want to make. And now, who's the right person?
It depends. If you could go with the person who's got the most steps to doing the process in terms of deliverables, the person who has got the biggest risk. If the process fails, typically with sales processes, it's the account manager because they're the ones that are facing the customer. They're the ones that if, you know, someone doesn't do a good job and invoicing or contract management, they're the ones who the customer yields that. So, I say they own the process.
And, like this, every process has a customer, whether it's internal or external, And to me, they should be the process owner. But, whichever way you to do it, there has to be a 1 to 1 relation, before you can have any kind of process governments.
That's terrific, Shamil, thank you so much for those insights. Wonderful presentation, grading traction from everybody in the audience. I saw all of your questions. Many great questions. Thank you for sharing your wisdom and expertise or global audience today HTML.
Thank you very much! It was really great being here.
Ladies and gentlemen, that's tomorrow at donkey, and the real pleasure to have him share his deep experiences and expertise on this very important area of pre automation if you will pre digital transformation which is a deeper understanding and of our processes of the key business processes that create value for the customers for the organization. Now we're going to be taking a break now and when we come back, we're gonna come back with the director of digital transformation from electrolux. It's how DIN housing is a very dynamic interesting speaker who provides very practical perspectives on on digital transformation.
And he's going to talk about the human capital side, it's so easy to think about that knowledge. When we talk about digital transformation, he wants to refocus us on on the human capital behind digital transformation success. So I will take a break now, see everybody back at the top of the hour. Thank you.
Shyamal has over 15 years of experience in process optimization and automation, bridging the gap between operational processes and IT, and has championed process improvement and development projects in a number of industries with examples including aerospace, legal, commercial real-estate, manufacturing, and insurance. He has led award-winning process-improvement projects in the aerospace industry and has consulted on numerous digital-transformation projects in various other industries. He is a strong advocate for digital transformation with a focus on process management and governance, and when approaching process optimization projects, Shyamal believes in preparing and aligning people and processes, before implementing technology – rather than forcing people and processes to react to new technology. To this end, he enjoys spending time with his clients and getting a deeper understanding of how an organization functions in order to create a sustainable environment for digital transformation. After working both on the industry-side as well as software supplier-side, he now provides advisory services to help companies with their process automation projects.
Search for anything
October 19, 2021
11:00 AM - 12:00 PM ET
October 28, 20211
1:00 PM - 2:00 PM ET
November 9, 2021
11:00 AM - 12:00 PM ET
January 13, 2022
1:00 PM - 2:00 PM ET
January 27, 2022
1:00 PM - 2:00 PM ET
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Watch On-Demand Recording - Access all sessions from progressive thought leaders free of charge from our industry leading virtual conferences.Watch On-Demand Recordings For Free
Courtesy of DC Government's Ernest Chrappah, below is a transcript of his speaking session on 'Going Digital To Enhance The Customer Experience' to ...
Courtesy of 's Anu Senan, below is a transcript of his speaking session on '' to Build a Thriving Enterprise that took place at Enterprise ...
Courtesy of Tasktop's Dr. Mik Kersten, below is a transcript of his speaking session on 'Project to Product: Driving Digital Transformation Insights ...
Courtesy of Nintex Pty's Paul Hsu, below is a transcript of his speaking session on 'Improve employee productivity during and post-COVID by ...
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events