all right. So what is the role of information systems when it comes to be PR,
Sokka has actually identified four different
roles that they feel are important when you're dealing with a B P R project. First, we think about enabling the new process
by improving automation. Approving automation is always a desirable goal.
Any time you could move from my manual process to an automated process
with the same results anyway, that's a good thing
that eliminates human error.
some of the other failings of humans were. People just might make a mistake because they're having a bad day. Or
or they try to take a short cut because the process is too tedious.
If we can automate it, then we don't run those risks any longer.
I also want to think about using project management tools
to do some of the analysis to help
the overall project moves forward.
you know, setting up your Gant charts
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
these are all great ways to
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 I T support arena.
use the teleconferencing to do interviews with people that are local to us, we can use email.
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.
you might use customer relationship management tools
These are often used between under between organizations and their customers,
but you could leverage that technology for your own gold within the organization as well.
So how do we do the documentation
for the business processes?
Easier things to think about. You could use process maps,
influenced I grams fishbone diagrams, maybe mind maps might work those air useful tools for organizing a bunch of good ideas.
Then you have to think about doing the risk assessment.
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
once its redesigned. Of course,
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
and what to look out for, what the pitfalls might be.
Then we have to think about benchmarking.
So if we if we have something similar to compare,
are redesigned 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 a process that you're trying to redesign, because it's a standalone thing that's not replicated anywhere else in the organization.
In that case, you're that 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 in middle management
team leads directors.
You know the regular users that are that are utilizing this process.
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?
Then we will drown the tasks and activities
trying to understand, based on the different roles and responsibilities of 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 than that could become very cumbersome
to get. All those people, too,
And it could also become, ah, technical challenge
to redesign 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 of security controls
or any restrictions on what happens with the data that gets produced orchid or
processed by the process is running itself.
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.
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.
All right, 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 redesign the process.
So whatever you might use as a p m I
you know, your typical Microsoft project or something similar to that
could also use the Critical Path method
or the program education review
you could use per charting.
These are all things you should be familiar with. If you're already doing some project management
you could also use more simplified tools,
just create flow charts and diagrams. Venn diagrams.
Mind maps are really good for organizing his ideas
and then having some kind of process
to show that that were
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.
Benchmarking some steps here to think about
if you're if you're doing this. And remember, benchmarking is comparing your process against something else that already exists,
so we can start with with identifying critical process is 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 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 that should prove conclusively that your proposed changes are going to be an improvement or not.
Then we look for cause effect, relationships in dependencies, dependencies, air very critical.
overlook a dependency, and then you've redesigned something and find out that it breaks something else.
So it's a good idea to pay attention to these these types of details.
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.
As I mentioned before, Maybe it's a an improvement in profits or a reduction in the time
the turnaround time for customers have a problem with something.
Then we build a prototype,
put it into practice to put it into play and start. Let it letting people
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 could do a business impact analysis.
This is a way to discover details of how you process really works and what it's different. Components are significant constituent pieces.
So what process is RG are being performed?
who uses the process, who owns it,
what kind of equipment and systems are used in order to to use this particular process?
What are the inputs to the process? What is its expected behaviour?
What is the output look like? How time sensitive is it?
Where 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 where is that going to happen?
What happens if you find out that the process is not being used any longer
or it's not currently be acceptable because of its level of risk?
These are questions that might come up, and that could
be a showstopper. If you find out that something's just not being used. Well, what's the point of redesigning it? That
that's, you know, 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? You're testing.
Having a testing plan is very important. You can't just
say, Well, we we redid the process. Let's just have people start using it
and hope for the best, right? You want him one heavy defined testing plan.
And 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 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 congrats that document, follow the steps and get the results that are desired.
Who's the customer for the process?
That's a good question asked.
Is the documentation available is a complete as it been verified,
going back to the previous slide where,
if the documentation is available has been verified? Has somebody run through documentation to test it? In a real world scenario,
I'd be an important thing to think about.
What about the auto 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 how long the lifetime is for the process as well.
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.
The questions to ask.
All right, What about a risk assessment for the B P R project?
There are some risks inherent in the design process itself,
Right? 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 redesign a process that
somebody doesn't like because it
reduces their importance or
somehow impacts their ability to do their job they make. They might make things difficult for you politically,
even though the process might be a good redesigned 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 redesigned. Even if they approved it,
not produce the entitled results from their point of view.
Ah, that could be technical risks
you fix one thing make something better, but
now you open 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 to 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 that we moved to risks. With the actually rolling out the new process,
technical risks would be here management as well.
There could be issues because people don't like change, right?
That's that's a common, uh,
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,
all right, so let's think about some practical rules for doing BP our projects,
one of the easiest ones to do right off the top of that bad. The
bad here is don't fix something if it's not broken.
Just because you can doesn't always mean that you should,
Right? We have to. We have to remember that we were 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.
75 hours and three weeks of my time
for a 1% improvement in efficiency isn't really worth it.
Maybe it does. Maybe it's not.
That's where that's where the ah, the analysis would
steer you in the right direction. Let you know if this is something that maybe is worth. The effort
this goes without saying is, Well, you don't wantto
try to 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.
And then, of course, the last thing
is, if you've got any left overs, it's kind of like putting together
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.
What did I miss? Something would apply here if I've got a process with many different moving parts,
lots of different components
when the process is redesigned, 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 redesign process. Otherwise, you might have more work to do.
All right, So how do we decide
which are the best processes that are good candidates for redesign?
The top priority would be a process that's not working right. It's just a usedto work. Maybe now it doesn't
so. That would be something that could be critical and should be your first choice for a redesign project.
You move on, they're from something that's marginal.
So a process that is doing something.
But it's not really given the results that everybody thinks it should.
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 if the conditions are right
and in 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.
Could be something you do annually or quarterly,
and because of its ah, low frequency of usage,
it may be the lowest priority for a BP are as well