Best Practices for Managing PeopleSoft Help Requests and Effective Incident Resolution

Transcription

1 Best Practices for Managing PeopleSoft Help Requests and Effective Incident Resolution TABLE OF CONTENTS Introduction: Bedding a System In... 2 This Guide... 2 Part One: Response Policies and Procedures What is a Help Request? The Help Request Life-cycle Classification Procedures and Request Routing... 3 Types... 3 Levels... 3 Definitions... 3 Prioritization... 4 Work Tickets... 4 Lessons Learned... 4 Routing Change Management What is Incident Management? Why is Incident Management Important?... 6 Part Two: Best Practices for Help Desk and IT Staff... 7 Documentation... 7 Service Level Agreements (SLAs)... 7 Types of Response... 7 Toolkit... 7 Common Pitfalls in Support Execution... 8 Summary... 9

2 Page 2 Introduction: Bedding a System In When a major new PeopleSoft system, is rolled out for the first time there is always a bedding-in stage. And however well prepared the roll-out is, at the very least we need to be prepared for the unexpected. At AMC we have two key criteria for making this bedding-in stage a productive one for both the new systems users and the roll-out team: 1. Managing the help request or incident resolution process smoothly and promptly, according to certain criteria and best practices 2. Rapidly turning lessons learned into useful information and experience for the enterprise as a whole. The second of these criteria deliberately links Help Request and Incident Resolution to the wider enterprise objective of building user competency and enhancing overall quality in performance. This objective focuses on supporting users, but not encouraging a dependency culture. This Guide This brief guide is in two parts. Part One outlines response procedures for managing Help Requests and for eventual Incident Classification and Management. It is organized in short sections: 1. what is a Help Request? 2. the Help Request life-cycle 3. what is Incident Management? 4. classification and escalation procedures 5. why is Incident Management important? 6. what tools are used for managing responses for help or to incidents Part Two outlines best practices for Help Desk and IT staff. AMCP Page 2

3 Page 3 Part One: Response Policies and Procedures 1. What is a Help Request? It is both welcome and expected that in the immediate ( entry ) roll-out phase of PeopleSoft that users asks for help. AMC sees such Help Requests as evidence of users engaging with the new system and provides AMC with feedback on any fine tuning and support that may be required in the entry stage. 2. The Help Request Life-cycle Help Requests follow a predictable life-cycle, as follows, each generating a Work Ticket: - request occurrence, - request / call logging, - tracking, - analysis, - further requirements gathering and documentation (as needed), - solution management and, if necessary, escalation, - resolution - closure - end state reporting and analysis. - lessons learned i. root cause analysis ii. trending iii. remedial and intervention strategies as needed. 3. Classification Procedures and Request Routing AMC classifies Help Requests in two types and at three levels. Types The types are distinguished between: Type 1: User-facing Type 2: System-facing. Levels The Levels are as follows: Level 1: Help Request Level 2: Minor Incident Level 3: Major Incident Definitions The classification principles lead to the following working definitions, which will be used by the Help Desk to triage incoming requests: AMCP Page 3

4 Page 4 Level 1: Help Requests that can be dealt with in a business as usual manner, usually by resolving a simple user question or request. Most Help Requests are Type 1 User-facing. Level 2: A Help Request takes on a more significant character, requiring a more complex response and therefore a longer resolution time. When a Help Request escalates to Level 2, we refer to the request as an Incident, meaning that some System-facing aspect is likely, although the emphasis of the solution will still be User-facing. Level 3: A major incident is likely to lead to a need for a system change, such as a new (unplanned) report or an unexpected customization. Hence the consequences for resolving Level 3 incidents are invariably system-facing in nature, even if user initiated. Prioritization In addition to the classification by level there will also likely be prioritization procedures, typically designating a response as Low, Medium or High Priority. The prioritization process tends to change between 1. the initial roll-out, 2. the bedding in, and 3. the business as usual phases of a new system implementation. Work Tickets The work tickets that are generated for managing the Help Requests and Incidents will reflect the classification and escalation procedures. Lessons Learned Once a system reaches the business as usual state, the use of a Change Advisory Board is often a helpful discipline on both users and support staff for managing change requests in an orderly and coherent fashion. It is important in digesting lessons learned to maintain an enterprise-wide perspective on any change as well as satisfying requests for help from individual units. For it may be that meeting the change demands of one unit actually impedes the effectiveness of another. Conduct a proper impact analysis under the umbrella of the Change Advisory Board before approving any significant changes. Routing During the period of AMC on-site support AMC will work with you and also with Oracle / PeopleSoft to triage and route requests according to three channeling criteria: 3.1 Where the request centers on a business process, the primary channel will be to management 3.2 Where the request concerns the application, the channel will be to IT and AMC 3.3 Where the request concerns product (system) related issues, the channel will be to Oracle / PeopleSoft. AMCP Page 4

5 Page 5 Help Desk: Request Routing and Change Management Business Processes MSD Management User Request Triage Application MSD IT/ AMC System Oracle/ PS/ AMC Solution N Change? Y? Change Advisory Board Change Y (denied) Impact? Y (approved) Accompanying the channeling will be an initial assessment back to the user as to the likely process required for resolution. 4. Change Management Some Help Requests are in effect user-initiated requests for changes or enhancements to the system. Others may require such changes to be made to resolve the user requirement. Whenever a request is identified as having a likely system change as a consequence, it is advisable to route that request through a Change Advisory Board. Such a Board would have oversight over the policies and procedures to be followed in adopting or refusing requests for change. Ideally, any change request will be subject first to a system-wide impact assessment. In particular, changes that may act to the benefit of one group of users may unintentionally adversely affect another. It is the role of the Board to identify and mitigate such risks. A possible routing procedure for identifying and assessing change requests is outlined in the figure above. 5. What is Incident Management? When a Help Request is triaged it is also categorized according to the severity of the problem faced. The most severe problems are designated as incidents. As a general rule, in the bedding-in stage of a roll-out the rule if in doubt, escalate applies, whereby the team leaders or project managers can assess early (triage) the Help Request to see if anything more complex is likely to emerge. So in the early stage of a roll out, there is likely to be a higher occurrence of incidents than once the system is in business as usual mode. After a few days normally 5-10 business days the if in doubt, escalate rule can be set aside in favor of the opposite principle, of escalation only when truly needed. It is important not to encourage users to think that they can simply contact the Help Desk with any query, however trivial. AMCP Page 5

6 Page 6 6. Why is Incident Management Important? Incident management is the critical spoke in the support wheel. Every IT Manager, CIO, and Business Manager needs to push for optimal processes in this area so that the PeopleSoft support ecosphere can be effective. Incident management is a pre-requisite for success, but, in isolation, will not guarantee it. Other critical success factors, including management support, workforce empowerment and motivation, competency building, resources, and budget must be aligned as well. If all the components are in place, there will be a significant return on investment. AMCP Page 6

7 Page 7 Part Two: Best Practices for Help Desk and IT Staff Here are some best practices to consider: 1. Implement a process for each phase of incident management. The AMC process may act as a template. 2. Map out the roles and responsibilities and associated service levels for each process. 3. Especially in the roll-out and bedding-in of any new system, such as iwave, pay close attention to trending and root cause analysis. MSD can significantly reduce the number of tickets by identifying the trends for the root cause of the problems, and address via training efforts. 4. Make sure everyone in the process is "on board" with the resolution methodology, understands interrelationships and dependencies, and enjoys the recognition that comes when their role is visible to the organization. Documentation Document the processes via integrated workflow diagrams. For example, roles, responsibilities, and accountability become a lot more understandable when graphically depicted. The old adage is true: a good picture is worth a thousand words. Document the rules surrounding the incident management function. For example, the organization should agree on incident priority definitions by Level - low, medium, high, and critical. Service Level Agreements (SLAs) Define the SLAs in close collaboration with the business users and their managers. Define clearly the consequences of SLA breaches. If you wait too long to get management involved, you will most likely run the risk of breaching SLAs. Define the criteria for when the clock stops running on the SLA. You need to be clear on what situations warrant stopping the clock. Types of Response Design your processes by Incident Type - Level 2 and 3 processes are going to be different in their demands and management procedures. Approval processes, forms, testing procedures, and project management will vary depending on ticket type. Expect Level 3 to be more difficult to design, since there is more involved. Toolkit Develop a toolkit to help simplify and streamline the support processes associated with incident management. This will not only help enable greater productivity of enterprise resources, but also come in handy for the purposes of review or audit. Typically, effective Help Desks develop some diagnostic and reporting templates which to leverage experience and lessons learned and assist users organize their thoughts clearly and systematically when requesting help. AMCP Page 7

8 Page 8 Some of the components of the Toolkit should include: Solution Diagnostic Script for Level 1 support Skills Assessments and improvement template Functional and Technical specification forms Project plan template to help manage small and large projects Approval forms from the Change Advisory Board (CAB). Common Pitfalls in Support Execution 1. The inability to make sound business decisions in the area of change management (governance). There is an inherent level of risk associated with the following three factors: 1. Making system changes without being aware of both short and long term impacts. 2. Not aligning system enhancements with the long term strategy of the organization. 3. Not keeping tight controls and audit of changes occurring in the production environment. 2. Lack of clear processes surrounding the enhancement lifecycle. Handling requests for enhancements and system changes is a very different process from troubleshooting. Channeling these through a Change Advisory Board and Quality Control system will enable the enterprise to discriminate effectively between occasions to intervene to enhance their systems and occasions to intervene to assist the users build their competency in using existing systems. 3. SLAs are breached and there is no accountability or measurement. The wording and operation of SLAs really needs to be squeaky tight. If Business calls IT to the carpet on performance/cost justification, the Support Team needs to know when to hold its hands up and when to push back. This begins with keeping good documentation providing facts and figures on how well they met SLAs and their overall service delivery levels. Metrics are the key to providing visibility and to good defense. Equally important is an internal process of measuring support performance' - meaning effectiveness. How well did you resolve the issues last month? Is there a QA process? Did you contribute to the high performance enterprise goal? 4. Being reactive, instead of proactive Reactive support teams tend to get the same issues logged month after month because they fail to take the time to perform root/cause analysis. Proactive teams perform this key root/cause analysis function routinely. They can quickly identify what the (PeopleSoft) pain points are and take corrective action. Support management should take ownership in performing root/cause analysis on a monthly basis. Most support teams we have encountered are closer to reactive than proactive. As a result, costs are not optimized and resources are not productive. 4. Lack of knowledge transfer and experience The investment any enterprise makes in its business systems is highly significant. IT has a general AMCP Page 8

9 Page 9 responsibility to ensure that the return on that investment is optimized to the extent possible. Competency building and knowledge transfer is the key for maximizing user and support productivity. Summary Make continuous improvement of these processes part of your on-going effort to improve service quality. Consider quarterly or semi-annual reviews. Use a Change Advisory Board for major decisions, using a full impact analysis as a prior diagnostic tool. AMC has seen many organizations that lack these processes. They tend struggle from a support competency perspective. Too often, the focus is solely on resources and the wing and prayer methodology of resolving Help Requests and Incident. These organizations risk never reaping the rewards of an optimal support environment - both from a cost and service level perspective. Our advice is to take the time to map-out and design your incident management processes, and then test and tune them before they are implemented. If you do it right, the Business perception of service capability greatly improves, and your PeopleSoft iwave Support organization will be a step closer to world-class. AMCP Page 9