Time
8 hours 35 minutes
Difficulty
Intermediate
CEU/CPE
9

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

Video Transcription

00:04
all right. So what is the role of information systems when it comes to be PR,
00:09
Sokka has actually identified four different
00:12
roles that they feel are important when you're dealing with a B P R project. First, we think about enabling the new process
00:19
by improving automation. Approving automation is always a desirable goal.
00:23
Any time you could move from my manual process to an automated process
00:27
with the same results anyway, that's a good thing
00:31
that eliminates human error.
00:34
And, uh,
00:35
some of the other failings of humans were. People just might make a mistake because they're having a bad day. Or
00:41
or they try to take a short cut because the process is too tedious.
00:45
If we can automate it, then we don't run those risks any longer.
00:49
I also want to think about using project management tools
00:52
to do some of the analysis to help
00:54
the overall project moves forward.
00:57
Whether it's,
00:59
you know, setting up your Gant charts
01:00
or other statistical analysis tools for looking at your evidence of your gathering a lot of different types of data, you might use spreadsheets to organize that
01:12
these are all great ways to
01:15
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.
01:23
We also want to take advantage of whatever tools are already available within the I T support arena.
01:30
So if we can, uh,
01:32
use the teleconferencing to do interviews with people that are local to us, we can use email.
01:38
We can use
01:41
other software tools to enhance collaboration. These are all really good ideas
01:46
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.
01:55
So it's best to try to take advantage of whatever tools might be available.
02:00
Uh,
02:00
also,
02:01
you might use customer relationship management tools
02:05
or or E R. P
02:07
tools as well.
02:08
These are often used between under between organizations and their customers,
02:15
but you could leverage that technology for your own gold within the organization as well.
02:20
So how do we do the documentation
02:23
for the business processes?
02:24
Easier things to think about. You could use process maps,
02:29
flow charts
02:30
influenced I grams fishbone diagrams, maybe mind maps might work those air useful tools for organizing a bunch of good ideas.
02:38
Then you have to think about doing the risk assessment.
02:42
So if the process as it is right now, has certain risks associated with, that should be well understood before you decide to redesign it
02:51
once its redesigned. Of course,
02:53
some more risk analysis needs to be done, but it's important to do the upfront risk analysis so that you know what you're getting into
03:00
and what to look out for, what the pitfalls might be.
03:05
Then we have to think about benchmarking.
03:07
So if we if we have something similar to compare,
03:10
are redesigned process against,
03:15
then that gives us an idea of whether or not we're making improvements or not,
03:17
you may not be able to find a close match for a process that you're trying to redesign, because it's a standalone thing that's not replicated anywhere else in the organization.
03:27
In that case, you're that that particular
03:30
task might be difficult to accomplish, but it's a worthwhile thing to consider.
03:36
We also have to understand
03:38
who are all the roles and responsibilities filled by.
03:42
Do we have people at the executive level people in middle management
03:46
team leads directors.
03:49
You know the regular users that are that are utilizing this process.
03:53
What 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 redesign?
04:05
Then we will drown the tasks and activities
04:09
trying to understand, based on the different roles and responsibilities of people involved.
04:14
Who can we allocate tasks and activities to to get certain aspects of the project moving forward,
04:20
trying to understand
04:23
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 than that could become very cumbersome
04:33
to get. All those people, too,
04:36
offer their input.
04:39
And it could also become, ah, technical challenge
04:42
to redesign something that has so many moving parts in different areas of the organization.
04:48
We also have to think about some restrictions on the controls for the process of security controls
04:55
or any restrictions on what happens with the data that gets produced orchid or
05:00
processed by the process is running itself.
05:04
So knowing what I mentioned this before about security controls, the planned inputs, the expected behaviour in the plant outputs. Those three things will apply in this case as well.
05:15
If we know what data goes in, what's supposed to happen and then what we should get out.
05:19
Then it becomes more clear where the possible areas for improvement are and other factors.
05:26
All right, so now that we've decided how to gather a bunch of data, what do we do to manage it?
05:32
You might want to consider project management type tools again
05:36
for managing this data that you gather to redesign the process.
05:41
So whatever you might use as a p m I
05:44
or,
05:45
you know, your typical Microsoft project or something similar to that
05:48
could also use the Critical Path method
05:51
or the program education review
05:55
you could use per charting.
05:57
These are all things you should be familiar with. If you're already doing some project management
06:01
type activities,
06:03
you could also use more simplified tools,
06:08
just create flow charts and diagrams. Venn diagrams.
06:14
Mind maps are really good for organizing his ideas
06:17
and then having some kind of process
06:19
to show that that were
06:23
managing the gathering of information we're setting some milestones so we could measure our progress to get to the point where the entire process is redesigning. The work is complete.
06:32
Benchmarking some steps here to think about
06:36
if you're if you're doing this. And remember, benchmarking is comparing your process against something else that already exists,
06:44
so we can start with with identifying critical process is and how we measure the performance of those processes.
06:51
Then we try to collect information about
06:54
the process, getting some data samples,
06:57
so now we can have a baseline.
06:58
The baseline is valuable because
07:00
once we know what things look like under normal conditions, then we can compare
07:04
our proposed improvements to see if we've actually made improvements or if we somehow degraded in some way.
07:13
Then you have to gather data, internal data and external data
07:16
so you can compare results
07:18
against your benchmark.
07:19
The more data you can use for comparison purposes the better,
07:24
because that that should prove conclusively that your proposed changes are going to be an improvement or not.
07:31
Then we look for cause effect, relationships in dependencies, dependencies, air very critical.
07:38
You don't want to
07:40
accidentally
07:42
overlook a dependency, and then you've redesigned something and find out that it breaks something else.
07:47
So it's a good idea to pay attention to these these types of details.
07:53
Then we have to take those findings and create a pipe hypothesis or an estimate as to what we think are improvements will actually accomplish.
08:01
As I mentioned before, Maybe it's a an improvement in profits or a reduction in the time
08:07
the turnaround time for customers have a problem with something.
08:11
Then we build a prototype,
08:13
put it into practice to put it into play and start. Let it letting people
08:18
study this
08:20
to make sure that it doesn't have anything unexpected in its operation.
08:26
Some quality assurance testing, basically is what we're talking about here
08:28
so we could do a business impact analysis.
08:31
This is a way to discover details of how you process really works and what it's different. Components are significant constituent pieces.
08:43
So what process is RG are being performed?
08:46
Who the
08:48
processes benefit,
08:50
who uses the process, who owns it,
08:52
what kind of equipment and systems are used in order to to use this particular process?
09:00
What are the inputs to the process? What is its expected behaviour?
09:03
What is the output look like? How time sensitive is it?
09:09
Where where is the actual output saved?
09:13
Is it something that becomes input to another process? Is this part of a workflow?
09:18
These are all questions which should be well understood before you embark on this kind of activity.
09:24
So the output of one process goes into the input of something else. Where where is that going to happen?
09:28
What happens if you find out that the process is not being used any longer
09:33
or it's not currently be acceptable because of its level of risk?
09:37
These are questions that might come up, and that could
09:41
be a showstopper. If you find out that something's just not being used. Well, what's the point of redesigning it? That
09:46
that's, you know, maybe you're better off working on something else.
09:52
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.
10:01
How do you do? You're testing.
10:03
Having a testing plan is very important. You can't just
10:07
say, Well, we we redid the process. Let's just have people start using it
10:11
and hope for the best, right? You want him one heavy defined testing plan.
10:16
And if someone needs to use the process in a crisis,
10:20
could you give them your new instructions
10:22
and have them run with it and actually get it to work?
10:26
That's that's a good test in itself
10:28
that proves that your documentation is correct
10:31
and that the process works as intended because someone that's never done it before congrats that document, follow the steps and get the results that are desired.
10:39
Who's the customer for the process?
10:41
That's a good question asked.
10:43
Is the documentation available is a complete as it been verified,
10:48
going back to the previous slide where,
10:52
if the documentation is available has been verified? Has somebody run through documentation to test it? In a real world scenario,
11:00
I'd be an important thing to think about.
11:03
What about the auto reports about the process?
11:07
Can you compare before and after reports to see if your results are what you expect?
11:13
You might want to think about how how long the lifetime is for the process as well.
11:18
Is it something that's going on? Lee would be needed for another six months, or is it going to be needed for the duration of the organization's lifetime.
11:26
The questions to ask.
11:28
All right, What about a risk assessment for the B P R project?
11:33
There are some risks inherent in the design process itself,
11:37
Right? Your sponsor may be difficult to find,
11:41
or they may not have the appropriate level of authority or influence. That's something to think about.
11:46
We have to worry about the scope being too small or too large. So
11:50
trying to get the scope just right is the goal here.
11:54
There might be political risk.
11:56
For instance, if you redesign a process that
12:00
somebody doesn't like because it
12:01
reduces their importance or
12:05
somehow impacts their ability to do their job they make. They might make things difficult for you politically,
12:11
even though the process might be a good redesigned for the organization as a whole.
12:16
So there are some other side factors there to think about
12:20
when you're doing the implementation.
12:22
This could also entail some different types of risks.
12:24
Your leadership may not like the idea of something being redesigned. Even if they approved it,
12:30
it still may
12:31
not produce the entitled results from their point of view.
12:35
Ah, that could be technical risks
12:37
where
12:39
you fix one thing make something better, but
12:41
now you open up vulnerabilities that raise other concerns.
12:46
So now you have to deal with
12:48
some kind of remediation, some kind of additional testing, risk analysis and so on.
12:54
So these are all things to try to think through ahead of time
12:56
as much as possible, so that when the time comes to actually do the work,
13:01
you don't have to invent
13:03
the activities on the spot that we moved to risks. With the actually rolling out the new process,
13:09
technical risks would be here management as well.
13:13
There could be issues because people don't like change, right?
13:18
That's that's a common, uh,
13:20
problem that we have,
13:22
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
13:31
Now. You're making them do something different,
13:33
and there could be friction and push back as a result. That's just human nature, and it's to be expected,
13:39
all right, so let's think about some practical rules for doing BP our projects,
13:48
one of the easiest ones to do right off the top of that bad. The
13:50
bad here is don't fix something if it's not broken.
13:54
Just because you can doesn't always mean that you should,
13:58
Right? We have to. We have to remember that we were looking for ways to improve our organization's efficiency.
14:05
If you're going to fix something that you believe is broken, try to calculate a return on investment.
14:11
If I spend
14:13
75 hours and three weeks of my time
14:16
doing this work
14:18
for a 1% improvement in efficiency isn't really worth it.
14:22
Maybe it does. Maybe it's not.
14:24
That's where that's where the ah, the analysis would
14:30
steer you in the right direction. Let you know if this is something that maybe is worth. The effort
14:35
this goes without saying is, Well, you don't wantto
14:39
try to fix something that you don't fully understand,
14:41
so making sure you have all the relevant details before you embark on a plan to change.
14:48
And then, of course, the last thing
14:50
is, if you've got any left overs, it's kind of like putting together
14:54
uh,
14:56
you know something from a kitten and you've got leftover screws and nuts and bolts. You know, that's that's always a bad feeling.
15:01
What did I miss? Something would apply here if I've got a process with many different moving parts,
15:07
lots of different components
15:09
when the process is redesigned, have they all been addressed?
15:13
If they're not all addressed, it better be because something wasn't needed. And maybe that was part of the redesign process. Otherwise, you might have more work to do.
15:20
All right, So how do we decide
15:24
which are the best processes that are good candidates for redesign?
15:28
The top priority would be a process that's not working right. It's just a usedto work. Maybe now it doesn't
15:35
so. That would be something that could be critical and should be your first choice for a redesign project.
15:41
You move on, they're from something that's marginal.
15:43
So a process that is doing something.
15:46
But it's not really given the results that everybody thinks it should.
15:50
It's It's odd,
15:52
a poor solution for
15:54
whatever that requirement might be.
15:58
Your third priority would be a process that's already working but still has some room for improvement.
16:03
So a lower priority than the other two, but still worth doing
16:07
if if the conditions are right
16:11
and in the last one to think about is a process that's excluded.
16:14
So maybe it's something that's only done every once in a while.
16:18
Could be something you do annually or quarterly,
16:22
and because of its ah, low frequency of usage,
16:26
it may be the lowest priority for a BP are as well
16:30
just makes sense.

Up Next

Certified Information System Auditor (CISA)

In order to face the dynamic requirements of meeting enterprise vulnerability management challenges, CISA course covers the auditing process to ensure that you have the ability to analyze the state of your organization and make changes where needed.

Instructed By

Instructor Profile Image
Dean Pompilio
CEO of SteppingStone Solutions
Instructor