Business Process Re-engineering (part 2)

Video Activity

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 p...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

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