Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Problem Managment Yields Service Improvementv2
Ähnlich wie Problem Managment Yields Service Improvementv2 (20)
Problem Managment Yields Service Improvementv2
- 1. Problem Management Yields Service Improvement
- 2. “ Why are we in business? To help our customers achieve their goals. Simple as that.” John Varley, Group Chief Executive Barclays
- 4. ITIL DEFINITION A Problem A cause of one or more incidents, the cause is not usually known at the time a Problem record is created, and the problem management process is responsible for further investigation. The Problem Process The process responsible for managing the lifecycle of all problems, the primary objectives of problem management is to prevent Incidents from happening and to minimize the impact of incidents that cannot be prevented.
- 5. SOMETIMES YOUR REPUTATION GOES BEFORE YOU
- 7. Incident starts Incident detected User impact mitigated Service restored to pre incident level and set up Root cause analysis Identify root cause Apply fix Option 1 Option 2
- 8. IT’S NEVER GOING TO BE PERFECT “ A common mistake that people make when trying to design something completely fool proof is to underestimate the ingenuity of complete fools” Douglas Adams
- 10. Severity 1 High Severity A direct threat of damage to the image, reputation or credibility of the group. Multiple lines of business or locations critically affected. Severity 2 High Severity Significant degradation or outage affecting a line of business key services or locations Severity 3 Low Severity Minor degradation to a key service, business process or location or a more severe degradation or outage to a non critical service, business process or location Severity 4 Low Severity Small issue with localized scope typically affecting a single user. Can either be tolerated or worked around for an extended period of time due to its limited impact Before We Go Any Further Lets Define Our Severities
- 13. Evolution Options Fight the gators Or Drain the swamp and find the gators a nice safe home THE CRITICAL POINT IN THE PROCESS DEVELOPMENT This is the point of no return
- 16. The Next Steps
- 18. Nothing wrong with any of the versions they were right for their time
- 21. WHY CHANGE? WHY NOT? Continual service improvement ensures people don’t become complacent, and start to think they know things so well they cut corners, or they start to follow the process without thinking why.
- 28. “ An environment of continual challenge will add value across your organisation not just to your processes”
- 29. Clarification time Question time Quick coffee?
- 30. Thank you very much
Hinweis der Redaktion
- We are all working to ensure the customers of the organisation we work for are able to use our products and services to do what they want when they want. For me that means every time customer logs onto internet banking it works When they go to the cash point it works When they walk into a branch the computers the staff use are working But its import for IT people to remember that they are part of a delivery chain and that they do not work in isolation, And neither do our processes they should all be focused to delivering improved service to the organisations customers if we remember to put yourself at the end of that supply chain it helps focus your attention on delivering a quality service.
- Here are the ITIL based definitions This is the theory and as we all know putting the theory in to practice isn't as easy as it sounds, partly because in practice we have to deal with restrictions around time and resource. Implementing processes always carry's the danger of over engineering and this leads to poor take up, users not following the new processes and poor process performance. But we will come back to poor user acceptance of the processes later Process improvement doesn’t have to be based on ITIL processes it works for any process in any organisation, we’ll use the problem process as an example but continual service improvement is the way forward what ever your process do.
- Sometimes things get a reputation and once the reputations in place it hard to remove Processes have acquired an unfair reputation , immediately you start talking about process people put up barriers they see processes as stifling initiative and inhibiting growth
- It all sounds so simple that you would expect a one size fits all solution would be available, Often we charge headlong into process deployment in the belief that it’s going to solve all our problems and turn our organisation into a smoothly oiled high performance machine. In order to stop this charge we should always start with a feasibility study. The key to any implementation is review learn and evolve This sounds as simple as the problem definition In practice it’s the hardest part of the problem or any process It’s tough to think that you we’ve been wrong
- With problem management perhaps the biggest issue around implementation is getting the practical split between incident management and problem management. At which point does ownership change User impact mitigated (work around in place) Service restored (past the work around perhaps we’ve gone to our backup system) My view service restored and infrastructure set up returned to original design. If we don’t wait until this point service recovery can move into problem management where it losses its time driven focus and moves to a quality driven focus. This can lead to dangerous exposure to repeat and potentially catastrophic failures.
- So lets look at how a process evolves When we design our processes perhaps we should remember Before we do we need to remember that no matter how hard we try what we put in place isn’t going to work the same forever and at some point some how someone is going to break it. The trick is to learn each time process breaks down and develop the process amend and change to stop the same error occurring again it’s the same as running an IT System. If we believe the process to be faultless and that it’s the people who let us down we will have missed the point and will be driving headlong towards a brick wall If we accept that the processes may fail we could spend time considering how they may fail and put proactive countermeasures in place,
- The problem process and its evolution this is a view built up from amalgamation of real processes although its not based around one specific organisation it is easy to imagine one organisation going along this particular path Lets picture an organisation that’s taking on the ITIL principles and setting out to implement its nice shiny new processes We’ll look at problem management and watch as it changes over time This may be years ago under version 1 or recently under version3 This process evolution could be viewed as moving from being a fire fighter to being a fire prevention Officer
- During the presentation I’ll mention severities the decision was used to base the process on a 4 severity model your model may be different but most groups like to be able to differentiate at some level to a problem record
- This first version that the organisation implemented was really little more than a set of rules and regulations policed by the problem management team. It did nothing more than ensure problem records were opened The more records there we’re the happy the team we’re The high volume of problem records managed were their pride on joy Was this an interesting team to work on ? Not really little ownership and not really and sense of achievement.
- Version 2 This was the first and possible the hardest obstacle to overcome the realisation that what you thought was working effectively may not be as good as you thought its the first tipping point on the process evolutionary journey Some high level filters were put in place to remove system enhancements but the measures stayed focused on volumes and a drive to drive the volume of records down it was still an inwardly focused team Split into BAU low severity problem records and high severity whilst they were able to identify some key business focused records this often happened reactively when multiple repeat high severity incident occurred. The team started to build a reputation for delivering result in response to specific business requests But up to this point the process had built a swamp full of unknown dangers lurching just below the surface and some of these danger can be deadly MEASURES Still focused on process adherence and compliance, and a drive to reduce the volume of records So we have two options if we are to evolve further
- They had our choices they could do the fun things or the right thing The organisation was now at the tipping point, They had built a swamp full of unknown dangers, the gators hiding beneath the surface. Now fighting the gators as they surface is always fun everyone likes to play the hero and pull of the last minute victory the overtime kick to win the game. And with the set up they had they now had the chance to be the hero's driving forward critical problem records when the business areas shouted loud enough. And as we all know this kind of work is fun. The other option they had was to do the right thing which was drain the swamp stop the massive flow of problem coming in and then move the gators to a nice safe home where they could be care for and managed simply and easily
- the decision was made to do the right thing and take the major step forward in the process development. To do this an aggressive closure process was undertaken to clear away the mud and to build a new based line, All new problems were validated This started to remove records from the system This still lacked effective measure but having taken this large step the measure were going to be the next areas they attacked and as the momentum grew it was clear these measures were going to be more business focused
- Having gone through the first versions they were now ready to really get problem management working for the organisation as a whole Validated records are logged and reviewed with the business areas to understand the full impact and prioritise the fix order. Prioritised list s were then reviewed with the technical areas to agree fix dates, these fix dates are then built into the technical areas measures they are measured against the number of dates they make or exceed Process now drives out solutions linked to business impact and need The processes ensures there is a controlled flow of problem records into system Implementing a provisional root cause time scale has also allowed them to ensure all areas remain focused on the root cause investigation as the record moves from the incident phase to the problem phase, No measure around the accuracy yet but one may well be on the way.
- Have they now reached the end of the process Sadly the answer is no there are still many steps to take and perhaps you'll never get to the end in fact if anything once the initial reluctance to change has been overcome the process builds its own momentum So what might the next steps be
- Well a drive to deliver faster and cheaper I’m sure will be something they want to consider, One way could be to blur the lines between the incident management teams and the problem management teams, end to end fix targets in place with clear accountability. They can also bring in some measures around the accuracy of the provisional root cause, the more accurate this is the quicker we can get to identifying the fix.
- But if the first process was working , or the second why do we need to change Lets have a look at the reasons why we don’t change and then why we should.
- Organisation have to overcome some very basic objections as they evolve their processes “ Why should we change something that’s working” does that sound familiar well first are you sure its really working Some people and some organisations are just resistant to change do what you do and you’ll get what you’ve also got and many people would say what we always got was good enough. Well just because they’re delivering what they always have and delivering what we expect of them to are the processes really doing what we need the to do. In many industries the requirements of the business areas change on a regular basis to meet the particular market demands of the industry and as such the requirements they have for the technology are likely to change as well if we don’t keep up with the changes in business requirements we can easily end up with a set of processes that are working well and doing what we want them to do but they are no longer meeting the real requirements of the organisation as a whole. Its this kind of approach that has historically been one of the reason why IT has ended up with such a poor reputation with business areas. In many cases whilst we run the existing processes even the requirements for the IT areas may have changed but fro some reason we still try and use the existing processes because they’re known, and comfortable like a pair of old sneakers.
- We need to build a culture that continually asks could do this better. This isn’t change for changes sake just because its old doesn’t mean it doesn't work or that its not the best there is. This is change because change is needed, Its in our nature to drive forward The needs of the IT community change the platforms we use may change and require amendments to the process, as we’ve already mentioned the business needs will change and the processes must ensure we can change quickly to meet thee changes We shouldn’t be asking is it working, we should always be asking can we do this better
- So if the organisation understands that it needs to continually improve its process how does it ensure that these processes remain functioning effectively, When processes fail to deliver what they are expected to its often down to the implementation Its very easy to become a process bully here and just say do it because I say so and its going to make things work more effectively. This approach is often used because its quick , and easy the training minimal and we can quickly tick the boxes on the deployment plan. Its much better to build understanding and acceptance with the users not only saying how to follow the new process but benefits to the organisation and much more importantly the benefits to them and their job. If we go through this type of implementation process which does take longer users feel ownership and with ownership come responsibility and a desire to make the process work in the best organisations the users will help reshape the process themselves for the benefit of the organisation.
- There is a danger that the processes them selves actually stifle the performance of the organisation There can be a difference between theory and practice. In theory a process should deliver results but its often only when the processes are put under pressure that their true effectiveness shows and that depends on the people using them. If things go wrong and people blame the process you’re in trouble, Processes are not barricades' to hide behind they are instruments that we work with to deliver a solutions, they really show there worth when they are flexible and the people using them are able to amend them as they work to deliver the best out come.
- People can follow the David Brent quote and lets be honest that’s often what happens. “ I did what the process said its not my fault” What organisations need are the right people and the right atmosphere Processes improve and organisations flourish when there is an atmosphere of Positive challenge if you say something doesn’t work Back that with why and show how it can be done better This is about more than complaining that something doesn't work because you don’t like it or disagree with it If you’re the owner of the process or the manager be ready to be challenged as the challenger may be able add even more value to your change Every process comes with a hidden built in a potentially toxic by-product that can have an adverse impact on the organisation, that by product is a set of behaviours
- As we come towards the end today perhaps we’re coming to the point where we can say the process are now going to continue evolving without any more work and we can now rest and take the glory. Its not going to happen I’m afraid to tell you in case you hadn’t already guessed process them selves are not going to delivery for you no matter how good they are and how many steps along the evolutionary ladder they've come. Unless you continue to put in the effort . Ensure that the targets drive the right behaviours look unusual trends and change the targets regularly to meet the changing needs of the organisation and to stop people playing the systems/process. So if your behaviours are to work effectively the targets you measure need to change not to stop cheating but to make sure that you always reassess the drivers fro the process as over time these will change as we saw with our process evolution.
- Every time you develop or review a process, walk through the process. Think of the possible issues that may be encountered, new process. One of the key points is to treat your processes just like any other IT tool. If the process fails, make sure you’re aware and start to review and amend the process. Each time we review our processes, we need to bring our skills and processes into play. Each time we review the processes, our response will be different. We just need to make sure that we do what’s right at the right time for the organisation as a whole.
- Process on their own will not deliver you must ensure that no one can hide behind the process Always be open to change and always challenge what you do Evolution not revolution is the key most of the time, a slow Targets and behaviours can have devastating effects on the overall deliverables Business drivers are the key not the It wants For process to work and grow ownership is the key without ownership nothing is going to change Ideally you want the growth to come from with the teams as they identify process improvements This isn’t just something that work problem management this is the example but all processes need to be treated in the same way using continual service improvement, a major step forward in ITIL that’s been introduced in version 3.
- This needs an environment of support and encouragement from the leadership team and a willingness to make changes suggested by junior members of staff It also needs the right leaders in place those who are prepared to be challenged not the easiest of people to find