Did you know Cybrary's video training is FREE? Join more than 2,500,000 IT and cyber security professionals, students, career changers, and more, growing their careers on Cybrary.
This lesson covers business process re-engineering. This is the idea that organizations are always in need of improving processes and procedures to make sure they stay on top of a competitive market. At the same time businesses must be aware that changes can bring new risks. [toggle_content title="Transcript"] Alright, so now let's talk about business process re-engineering. The idea with this is that organizations are always in need of tweaks and adjustments to the way they do things. Unless the organization's been around a very long time and has extremely well-defined processes and procedures, there's almost always some area where there is room for improvement. So BPR gives us the ability to make the business more efficient over time. As your employees and workers gain more experience, they can do their job more quickly with less errors; basically raising their productivity after they reach a certain level of competency. You could also consider BPR as being a way of introducing improved techniques. We might think of instances like manufacturing where microchip manufacturers improve their techniques on a regular basis. Every two years, or so, the speed of the processors in all of our PCs and laptops takes a significant jump. Sometimes it even doubles. These are because new techniques come along. Maybe there's ways to fold multiple step processes into one step because of some new tools or some new technology. So that's a definite goal. Also, BPR is important when we have new requirements. So there might be a situation where an organization has certain products and services but now there's something new on the landscape, or something new that their customers want so they've got to rethink how they do things in order to satisfy that demand. So what are the goals of BPR at the high level? We're talking about continuous improvement. Any adjustments, any tweaks, any re-thinking of existing processes is potentially going to be helpful. What we don't want is to get stuck into the mindset of doing something the same way all the time because that's the way we've always done it. That's an easy trap to fall into. 'We've always done it this way. It's been working fine for ten years. Let's just keep doing it that way.' That might be fine, but if you can take the attitude of looking for ways to improve and become more efficient, then possibly that helps the business overall to improve itself financially, gaining more market share, new customers: who knows what the limits are there. We also have to remember that change introduces new risks. So just because we find a better way of doing something, doesn't mean that we haven't solved one problem and created two new ones. So this is really important to tie back to something like change control and doing business impact analysis. So if you're introducing some new process, some new tools, there has to be some study conducted to make sure that that new way of doing things doesn't break something else that's already in existence, or doesn't open up some vulnerability that wasn't foreseen when the change was being proposed. And, of course, that ties back to our security controls especially as it relates to them being continuously monitored. If we're continuously monitoring the controls, then we make changes to the environment, there should be some evidence of those changes in the monitored controls. Maybe that can be correlated to know if your change was a good thing or a bad thing. Any time you make an important change, you always want to have a roll-back plan anyway. So that's something good to close that loop a little bit. So how do we go about BPR in a structured way? One way to think about it is to think big, to think outside the box. If your organization does some certain things, certain tasks, or provides products and services, an interesting concept would be to basically try to wipe your mind clean to say, 'I don't want to rely on anything that already exists. If we had to design this from scratch right now, how would we do it? How would we accomplish the goals of the business without using anything that's already been done before?' That might be a great opportunity to bring someone new into the situation who doesn't know how things were done before so they don't have that stuck in their mind as a reminder which may lead them down the wrong path. Another approach is to do what I was mentioning earlier: more of an incremental approach; where you look at all of your processes, document how they work, from the bottom up, and see if there are little areas where you might be able to make small little improvements. Maybe a few percent here, a couple of percent there, all that might add up to a significant change if it's done carefully. One downside with the incremental approach is that it might be easy to get lost in the details documenting the current process and that might take a lot more time than just trying to re-design from scratch. The thinking big idea, anyway, doesn't hurt anything if you're just putting ideas down on paper or discussing it. So incremental is good as well, because that's a more natural flow for the way most people think. 'I just want to make a slight adjustment here and a slight adjustment there.' Another option is to use a hybrid approach. Meaning that you're looking from the top down, trying to get the big picture, but also trying to make incremental adjustments so that you're not starting completely over, but you're trying to blend the best of both of those worlds. You do have to have a reasonable body of knowledge in order to be successful at doing BPR. For instance, having up-to-date skills for auditing makes sense. You wouldn't want to attempt business process re-engineering if your auditing skills were a little bit rusty. Having the CISA audit skills, that we've talked about, looking at the ISACA code of ethics, knowing how to go about the methodology of auditing an information system would be an important consideration as well. Knowing how the company works. What is their business logic? What are the moving parts involved? How do you analyze that in a way that makes sense, especially when you have requirements to measure something and to provide proof that your analysis shows there could be improvements if we changed this, or if we changed that? Being a good people person doesn't hurt. Since you may have to interface with various different people, all the way from CEOs down to regular users, on the network, asking them questions, trying to get them to cooperate, getting useful information that you can pull together as your evidence to support your opinions. So if we're trying to apply the guidelines for BPR, you have to think about some different types of steps here. We have six major steps. First we can start with envisioning. So here we're trying to say that we can see that there's a need to improve something. We're trying to get a better return-on-investment. Trying to show, with a project plan and some other details, that we think that we can modify this, or this, or this, or re-design that and produce some better result after it's all completed. So some deliverables to think about there: trying to find a project champion. Someone who can work with you to remove obstacles and to advocate for the cause. Again, dealing with a project plan, define your scope, define your goals and your objectives. That way it's clear to anyone who looks at this documentation that, 'Here's where you are now. Here's what you're trying to accomplish so you can get to some other place.' It helps the person doing the work to keep track of where they are in the process as well. Then, of course, describing all of the other deliverables that are expected in as much detail as possible is going to be helpful to anyone looking at this. If you're trying to get people to help, showing them good detailed documentation can build confidence and make them want to be part of the project. After we envision, then we have to think about initiating. So talk with your sponsor that you started to work with in the first step, and agree upon some goals. If you can agree upon the goals, then you can start going about the process of gathering the evidence to support the BPR plan. Some deliverables to think about here: looking at internal and external requirements. Maybe doing a business impact analysis or a business use case. Trying to show that if we change the way we do things, we can make an extra 10% profit, or something of that nature. Put together a formal project plan. Find out how much your sponsor or the project manager; how much authority they have to actually help you make changes. Look at your profit and loss statements. So if you've got details like this to work with, you can say, 'We're spending this much money on this. If we do this project that I'm proposing, we'll end up spending this much money,' which is hopefully less. Then try to get your sponsor to sign-off on your charter, showing that they truly support the effort and they're not just giving it lip service. Then we move on to part three of the application where we diagnose the problems. So this means you're studying the processes in very low-level detail, trying to understand where the value comes from in doing things the way that they've been done before. That helps to identify areas where there might be able to be some improvements instituted. Some deliverables to think about here: try to document the existing process as best as you can. Again, this could be an area where things might slow down, but it's worth doing because you want to be able to compare the existing process with the one that's being proposed as the new process. Try to find a way to measure the performance of the individual steps in the process: the current process, anyway. If you can do this, then it should be easier to show where the improvements might be once the process gets re-designed. Then you're trying to look for ways to add value to your customers, to your users, to your management, to the bottom line, wherever the value might be. Also you want to find those areas in the procedure or the process that do not add value so that you can consider re-designing those separately, or maybe even removing them altogether because they might just be taking time and effort without any tangible benefit. Then you also want to think about, what are the attributes that are defined that show that this process does provide some value, does provide some meaningful use to the organization? Moving on to part four, where we think about re-designing the process. Now that you've gathered some information, you've done the analysis; you've diagnosed the problems that you think the process has, then you can consider re-designing. It may take several attempts at re-designing before you get a solution that works to everyone's satisfaction. That's normal and expected. It would be very difficult to just re-design the first time and have everything be great. Unless you've been doing the work for a long time and you have some brilliant insight, most likely there will be some iterations that will have to happen. But that's okay. So you analyse your alternatives. When you come up with a solution, you build a prototype, do some testing.Do some more analysis and determine if the prototype is a successful replacement for the process that was being re-designed. Then you formally document the final re-design once you've determined that that's going to be a suitable alternative. Then we move on to the reconstruction. So you can take your processes apart and put them back together by following the BPR plan. You might have instructions that were generated. Say that we want to start every process over from scratch. We're going to disregard any existing processes and start with the top-down approach that I talked about earlier. Or you might say, 'Well, we're going to go with the bottom-up incremental approach and look at every process, document it and figure out where we can tweak it and where we can change something to provide some small improvement,' hoping for a large net improvement once that process is completed. So, deliverables to think about here: having a conversion plan. Paying attention to dependencies. If you're going to re-design something, you have to make sure that you don't break something else in the process. So process A depends on process B. When I'm re-designing process B, I need to keep process A in-mind otherwise something will break between those two. Dealing with change control: that's an important consideration. Making sure that you're monitoring the progress of the BPR. Making sure that if you do design something new, or you re-design an existing process, that you have training materials or a training program ready to go. It would be foolish to re-design a process without educating the users of that process as to what to expect. How do they do things differently now than the way they used to do it to support the new method? Of course, you want to be able to set-up a pilot. This means that you're going to potentially run the new process in parallel with the old process, have some people use it, have people test it, make sure that it actually performs as expected. Then you can finally go for some formal approval by the sponsor of the project. Getting them to sign-off to say that, 'We went through all the appropriate steps and this looks to be a good solution so we're going to move forward with that.' Moving on to BPR step number 6 where we evaluate. This is an important step because now that the process has been re-designed, you've gathered all or your evidence, you've put it into production; you need to start measuring the performance of this process. Finding ways to contrast that with the performance of the previous process would then close the loop to show that this was a worthwhile effort. You did all the research. You found all the details you needed. You gathered all the evidence required. Did the analysis, re-designed, re-deployed something new, now you're measuring it and you find that it actually works and it's generating the improvement that was expected. So some deliverables to think about here: comparing the forecast to the actual performance. So you expected a 10% improvement in the time or maybe profits, but the process re-design actually produced a 12% improvement. So that would be a great result to achieve. Trying to find those lessons learned: the post-mortem, if you will. 'What did we discover when we re-designed this process that we didn't know before? How can we use this information for the next BPR exercise?' that would be good documentation to have. Of course, we have to make sure that your quality assurance process or program works with the new process to make sure that everyone is aware of it, they're properly trained and that it's being monitored for problems just like all of the other processes in the organization. [/toggle_content]