ICAITS022B Determine client computing problems and action
Overview
We would all like an easy life. We would like systems to operate smoothly and without fault. However, when things do go wrong we need them fixed as quickly and with as little disruption as possible. It is important to consider and minimise the impact to users when changes are implemented. This topic will show you how to do this.
Inside this topic:
How users are impacted
How to minimise impact
Documenting and planning for the impact
Summary
1. How users are impacted
If you are like most people, losing the electrical power might be a major disaster. You could not cook, could not see and worst of all you could not watch television. It is now quite difficult to appreciate how people managed before we had a reliable electricity supply industry.
In the same way, organisations and users now depend upon their computer systems. Many systems are mission critical and if they were unavailable for even a few minutes they could cost the organisation millions of dollars.
Practice
Consider the impact of a systems failure for:
- an airline check-in counter
- a supermarket checkout
- a bank ATM system
- a word processor user
- a small business using an accounting package.
2. How to minimise impact
It is most likely that every system can be considered critical at some moment in time. This then gives us a clue as to how we could minimise the impact of changes. We should schedule changes and upgrades to take advantage of “slack” periods (periods that are not so busy)
Practice
For the examples given earlier, when would each organisation or operator have a “slack” time?
Reflect
How could a user still be impacted by a revised version of the software?
3. Documenting and planning for the impact
It is important to clearly understand:
- what the impact on users will be
- what can be done to minimise the impact.
Then activities can be devised to minimise impact in the change process.
Documenting information is often a helpful way of clarifying a situation. The grid below has been developed to identify the severity of the impact on various users if their system were unavailable for different periods of time. This may be further refined to take into account different times of the day or month.
For example:
Dept A | 10 mins | 30 mins | 1 hour | 2 hours | 4 hours | 8 hours |
Mon | 1 | 2 | 3 | 4 | 5 | 5 |
Tue | 1 | 2 | 3 | 4 | 5 | 5 |
Wed | 1 | 2 | 3 | 4 | 5 | 5 |
Thur | 1 | 2 | 3 | 4 | 5 | 5 |
Fri | 1 | 2 | 3 | 4 | 4 | 5 |
Month end | 0 | 0 | 1 | 2 | 3 | 5 |
Year end | 0 | 0 | 0 | 1 | 2 | 3 |
Dept B | 10 mins | 30 mins | 1 hour | 2 hours | 4 hours | 8 hours |
M | 1 | 2 | 3 | 5 | 5 | 5 |
Where 5 = critical
Once it is known when users will be the most impacted, you can begin to plan around these days to ensure that you make changes or upgrades in the “slack” periods.
4. Summary
Now that you have completed this topic , reflect on the skills you now possess.
You should be able to carry out an impact analysis by:
- recognising how users will be impacted
- considering how to minimise impact
- developing documentation and plans to minimise impact.
No comments:
Post a Comment