2 hours 3 minutes

Video Description

This lesson discusses the role of information systems when it comes to Business Process Re-engineering (BPR). This lessons covers Business Process Documentation using the following tools: - Process maps - Risk assessment - Benchmarking This lesson also covers the Business Impact Analysis (BIA) which is used to discover the details of a production process. The unit also discusses the risks in the process: - Design - Implementation - Operation/Rollout [toggle_content title="Transcript"] Alright, so what is the role of information systems when it comes to BPR? ISACA has actually identified four different roles that they feel are important when you're dealing with a BPR project. First we think about enabling the new process by improving automation. Improving automation is always a desirable goal. Any time you can move from a manual process to an automated process, with the same results anyway, that's a good thing. That illuminates human error and some of the other failings of humans where people just might make a mistake because they're having a bad day, or they try to take a shortcut because the process is too tedious. If we can automate it, then we don't run those risks any longer. We also want to think about using project management tools to do some of the analysis: to help the overall project move forward, whether it's setting up your Gantt charts or other statistical analysis tools for looking at your evidence, if you're gathering a lot of different types of data. You might use spreadsheets to organize that. These are all great ways to get all of your information together in a format that's easy to use for the auditor and easy to use for other people that might be part of the project. We also want to take advantage of whatever tools are already available within the IT support arena. So if we can use teleconferencing to do interviews with people that aren't local to us, if we can use email, we can use other software tools to enhance collaboration: these are all really good ideas because it's difficult to get people together in the same room at the same time to sit there for an hour, or two, or three, and hash these things out in person. So it's best to try to take advantage of whatever tools might be available. Also, you might use customer relationship management tools, or ERP tools as well. These are often used between organizations and their customers, but you could leverage that technology for your own goals within the organization as well. So how do we do the documentation for the business processes? Some easy things to think about. You could use process maps, flow charts, influence diagrams, fishbone diagrams, maybe mind maps might work. Those are useful tools for organizing a bunch of ideas. Then you have to think about doing a risk assessment. So if the process, as it is right now, has certain risks associated with it, that should be well understood before you decide to re-design it. Once it's re-designed, of course, some more risk analysis needs to be done, but it's important to do the up-front risk analysis so that you know what you're getting into and what to look out for, what the pitfalls might be. Then we have to think about benchmarking. So if we have something similar to compare our re-design process against, then that gives us an idea of whether or not we're making improvements or not. You may not be able to find a close match for the process that you're trying to re-design because it's a standalone thing that's not replicated anywhere else in the organization. In that case, that particular task might be difficult to accomplish. But it's a worthwhile thing to consider. We also have to understand who are all the roles and responsibilities filled by. Do we have people at the executive level, people at middle management, team leads, directors, regular users that are utilizing this process? What do they contribute to the use of this and what information might they have, or what opinions might they have, that could be useful for those people that are trying to do a re-design? Then we'll move on to tasks and activities. Trying to understand, based on the different roles and responsibilities of the people involved, who can we allocate tasks and activities to, to get certain aspects of the project moving forward? Trying to understand who does what and how that affects everything else. If you've got a process that involves people from multiple different groups or different business units, then it can become very cumbersome to get all those people to offer their input. And it could also become a technical challenge to re-design something that has so many moving parts in different areas of the organization. We also have to think about some restrictions on the controls for the process: the security controls or any restrictions on what happens with the data that gets produced, or processed by the process running itself. So I mentioned this before about security controls: the planned inputs, the expected behavior and the planned outputs. Those three things will apply in this case as well. If we know what data goes in, what's supposed to happen and then what we should get out, then it becomes more clear where the possible areas for improvement are and other factors. Alright, so now that we've decided how to gather a bunch of data, what do we do to manage it? You might want to consider project management type tools again for managing this data that you gather to re-design the process. So whatever you might use as a PMI or your typical Microsoft Project, or something similar to that, could also use the critical path method, or the program education review. You could use PERT charting. These are all things you should be familiar with if you're already doing some project management type activities. You could also use more simplified tools: just create flow charts and diagrams; Venn diagrams. Mind maps are really good for organizing these ideas. Then having some kind of process to show that we're managing the gathering of information, we're setting some milestones so we can measure our progress to get to the point where the entire process is re-designed and the work is complete. Benchmarking: some steps here to think about, if you're doing this. Remember: benchmarking is comparing your process against something else that already exists. So we can start with identifying critical processes and how we measure the performance of those processes. Then we try to collect information about the process; getting some data samples. So now we can have a baseline. The baseline is valuable because once we know what things look like under normal conditions, then we can compare our proposed improvements to see if we've actually made improvements or if we've somehow degraded in some way. Then you have to gather data: internal data and external data so you can compare results against your benchmark. The more data you can use for comparison purposes, the better because that should prove conclusively that your proposed changes are going to be an improvement or not. Then we look for cause/effect relationships and dependencies. Dependencies are very critical. You don't want to accidentally overlook a dependency and then you've re-designed something and find out that it breaks something else. So it's a good idea to pay attention to these types of details. Then we have to take those findings and create a hypothesis, or an estimate as to what we think our improvements will actually accomplish. As I mentioned before, maybe it's an improvement in profits, or a reduction in the turnaround time for customers that have a problem with something. Then we build a prototype to put it into practice, to put it into play, and start letting people study this to make sure that it doesn't have anything unexpected in its operation. Some quality assurance testing, basically, is what we're talking about here. So we can do a business impact analysis. This is a way to discover details of how a process really works and what its different components are, its different constituent pieces. So what processes are being performed? Who do the processes benefit? Who uses the process? Who owns it? What kind of equipment and systems are used in order to use this particular process? What are the inputs to the process? What is its expected behavior? What does the output look like? How time-sensitive is it? Where is the actual output saved? Is it something that becomes input to another process? Is this part of a workflow? These are all questions which should be well understood before you embark on this kind of activity. So the output of one process goes into the input of something else. Where is that going to happen? What happens if you find out that a process is not being used any longer? Or it's not currently acceptable because of its level of risk? These are questions that might come up, and that could be a show-stopper, if you find out that something's just not being used, what's the point of re-designing it, then? Maybe you're better off working on something else. Maybe think about alternate ways to accomplish the process. Other tools, other methods that might already exist, but just aren't being used for this purpose - How do you do your testing? Having a testing plan is very important. You can't just say, 'Well, we re-did the process. Let's just have people start using it and hope for the best.' You want to have a defined testing plan. If someone needs to use the process in a crisis, could you give them your new instructions and have them run with it and actually get it to work? That's a good test in itself. That proves that your documentation is correct and that the process works as intended, because someone that's never done it before can grab that document, follow the steps and get the results that are desired. 'Who's the customer for the process?' That's a good question to ask. Is the documentation available? Is it complete? Has it been verified? Going back to the previous slide where if the documentation is available and has been verified, has somebody run through the documentation to test it in a real-world scenario? That would be an important thing to think about. What about the audit reports about the process? Can you compare before and after reports to see if your results are what you expect? You might want to think about how long the lifetime is for the process as well. Is it something that's going to only be needed for another six months or is it going to be needed for the duration of the organization's lifetime? Big questions to ask. Alright, what about a risk assessment for the BPR project? There are some risks inherent in the design process itself. Your sponsor may be difficult to find, or they may not have the appropriate level of authority or influence. That's something to think about. We have to worry about the scope being too small or too large. So trying to get the scope just right is the goal here. There might be political risk. For instance, if you re-design a process that somebody doesn't like because it reduces their importance, or somehow impacts their ability to do their job, they might make things difficult for you politically, even though the process might be a good re-design for the organization as a whole. So there are some other side factors there to think about. When you're doing the implementation, this could also entail some different types of risks. Your leadership may not like the idea of something being re-designed, even if they approved it, that still may not produce the intended results from their point of view. There could be technical risks where you fix one thing, you make something better, but now you've opened up vulnerabilities that raise other concerns, so now you have to deal with some kind of remediation, some kind of additional testing, risk analysis and so on. So these are all things to try and think through ahead of time as much as possible so that when the time comes to actually do the work you don't have to invent the activities on the spot. Then we move to risks with actually rolling out the new process. Technical risks would be here: management as well. There could be issues because people don't like change. That's a common problem that we have. Even though the old process might not be as efficient as it could be, if everyone knows how to do it, they're comfortable with it, they might just want to stay with it because it's what they know. Now you're making them do something different and there could be friction and push-back as a result. That's just human nature, and it's to be expected. Alright, so let's think about some practical rules for doing BPR projects. One of the easiest ones to do, right off the top of the bat here, is don't fix something if it's not broken. Just because you can, doesn't always mean that you should. We have to remember that when we're looking for ways to improve our organization's efficiency. If you're going to fix something that you believe is broken, try to calculate a return-on-investment. If I spend 75 hours and three weeks of my time doing this work for a 1% improvement in efficiency, is it really worth it? Maybe it is. Maybe it's not. That's where the analysis would steer you in the right direction to let you know if this is something that maybe isn't worth the effort. This goes without saying, as well, you don't want to try and fix something that you don't fully understand. So making sure you have all the relevant details before you embark on a plan to change it. Then, of course, the last thing is if you've got any leftovers. It's kind of like putting together something from a kit and you've got leftover screws and nuts and bolts. That's always a bad feeling. 'What did I miss?' The same thing would apply here. If I've got a process with many different moving parts, and lots of different components, when the process is re-designed, have they all been addressed? If they're not all addressed, it better be because something wasn't needed, and maybe that was part of the re-design process. Otherwise you might have more work to do. Alright, so how do we decide which are the best processes that are good candidates for re-design? The top priority would be a process that's not working. It used to work maybe and now it doesn't. So that would be something that could be critical and should be your first choice for a re-design project. You would move on there from something that's marginal, so a process that's doing something, but it's not really giving the results that everybody thinks it should. It's a poor solution for whatever that requirement might be. Your third priority would be a process that's already working but still has some room for improvement. So a lower priority than the other two, but still worth doing if the conditions are right. The last one to think about is a process that's excluded. So maybe it's something that's only done every once in a while. It could be something you do annually or quarterly, and because of its low frequency of usage, it may be the lowest priority for a BPR as well. It just makes sense. [/toggle_content]

Up Next

IT Governance and Management

What does CISA Domain 2 cover? Domain 2 of the CISA surrounds the governance and management of IT, with included topics ranging from IT monitoring and assurance practices

Instructed By

Instructor Profile Image
Dean Pompilio
CEO of SteppingStone Solutions