Exclusive New Report ITIL Design Guidelines Part 4 – ITIL Service Operation Randy A. Steinberg Robin Yearsley © 2007 Randy A. Steinberg & Robin Yearsley. Page: 1 ITIL Design Guidelines Part 4 – ITIL Service Operation Paper Overview Purpose This paper briefly describes the concept of using guidelines when designing ITIL services. It then presents a starter set of design guidelines that can be used by IT Service Management Implementation teams. Contents This publication contains the following topics: Topic Paper Overview Understanding Design Guidelines Design Guideline Examples for ITIL Service Operation © 2007 Randy A. Steinberg & Robin Yearsley. See Page 1 2 9 Page: 2 Understanding Design Guidelines Overview Introduction The following section provides some basic background on what Design Guidelines are and how to use them. Contents This part contains the following topics: Topic Design Guidelines Defined Components of a Design Guideline Examples of Design Guidelines Examples of Poorly Constructed Design Guidelines Examples of Design Guideline Categories © 2007 Randy A. Steinberg & Robin Yearsley. See Page 3 4 6 7 8 Page: 3 Design Guidelines Defined Introduction The following section defines Design Guidelines within an ITIL context and lists their key attributes. Definition Design Guidelines: • Are statements about how IT Services should operate. • Support the IT Service Management Vision. • Are critical statements of direction that will have major impact on how IT services should be designed and operated. • Should be clearly understood and communicated both internally and externally to IT Services. Derivation These Guidelines are derived from: • Basic beliefs • Experience • Priorities • Underlying culture within a business organization • People involved with the delivery of IT Services. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 4 Components of a Design Guideline Introduction As an early activity in IT Service Management implementation, consider each guideline in isolation. The underlying rationale for advancing each guideline with its resulting implications and impacts should be agreed to and documented. Describing Guidelines Each guideline has three parts, which are described below: • Statement • Rationale • Implications Statement This consists of a single sentence that states the guideline. Example: We will let our customers know the key services we offer them and who is accountable. Rationale This lists reasons why the guideline should be accepted by the business. Considerations include: • Why should the organization do this? • What business benefits does this guideline advance? • What characteristics can be used to defend the guideline? Examples: • Will provide clear accountability for the service. • Will provide service clarity for the customer. Continued on next page © 2007 Randy A. Steinberg & Robin Yearsley. Page: 5 Components of a Design Guideline, Continued Implications This lists areas of impact to business and IT units as a result of operating with the guideline. Considerations include: • What needs to be done if the guideline is implemented? • What impact will it have on business and IT units? • What kind of behaviours, tools, data or processes need to be in place to support it? Example: • We will need to define each service that we offer in a Service Catalogue. • We will need to develop cross-organizational capabilities. • We will have to establish a formal communications program. • We will have to establish a single owner for each service. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 6 Examples of Design Guidelines Characteristics Well designed guidelines have the following characteristics: • States a fundamental belief of the enterprise in one or two clearly written sentences. • Relevant to the IT Service Management solutions. • Worded directly and simply in terms understandable by both business and IT managers. • Widely applicable. • Will not be outdated quickly by advancing technology. • Have objective reasons for advancing it over the considered alternatives. • Have impacts which need to be documented. Examples The following are examples of some well constructed design guidelines: • External customer information will be kept strictly confidential within policies set by the organization and regulatory agencies. • Service Management solutions, whether purchased or developed internally, will be highly structured and modular. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 7 Examples of Poorly Constructed Design Guidelines Characteristics The characteristics of a poorly designed guideline are: • The statement is difficult to dispute. • Is a general business or financial statement. • Does not support business goals. • Is stated at too low a level or names a product/technology. • May be included with "because I say so". Examples Examples of some poorly designed guidelines are: • The overall cost of computing must be reduced. (A business objective but not a guideline) • All servers will use the EISA Bus to achieve high performance. (Specifies an exact standard at a very low technical level) • Only Ethernet LANs will be implemented in our corporation. (Specifies a standard with a specific technology already selected) © 2007 Randy A. Steinberg & Robin Yearsley. Page: 8 Design Guideline Examples for ITIL Service Operation Overview Introduction The purpose of these examples to give the reader a starting point for defining their own unique design guidelines, not to dictate or recommend them. For purposes of clarity, the examples are grouped by key topics within the ITIL Version 3 Service Operation book. Contents This section contains the following topics: Topic Event Management Examples Incident Management Examples Request Fulfillment Examples Problem Management Examples Access Management Examples Service Desk Examples Common Service Operation Examples © 2007 Randy A. Steinberg & Robin Yearsley. See Page 10 19 26 31 35 42 49 Page: 9 Guideline Example #1 – Event Management Guideline • Event notifications will only go to those responsible for handling or decision processes related to them. Sample Application Each event is tagged to a set of distribution lists of who receives the event. These lists are maintained though Change Management. Rationale • Directs event handling activities only to those who must process them. • Avoid needless notifications to those not directly involved in processing events. Implication • We identify which departments, groups or individuals need to respond to events. • We maintain event routing information as new events are added or personnel responsibilities change. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 10 Guideline Example #2 – Event Management Guideline All event management and support will be centralized. Sample Application All events from distributed e-mail processing servers will be routed to the main processing center for escalation and handling. Rationale • Avoids conflicts in management of events. • Allows for appropriate operational response for new events and changes in processes. • Avoids support personnel receiving event notifications for events they are not prepared to handle. Implication • A common rule base has been built and maintained. • We process rule changes and additions through a change management process. • Support personnel have buy-in processes to accept/reject event changes. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 11 Guideline Example #3 – Event Management Guideline All application events must utilize a common set of messaging and logging standards. Example All ABC application transaction programs will raise their events by logging an event alarm record. This record will have fields and a structure that conform to the corporate standard record structure for system events. Rationale • Consistent, common ways to process and handle events. • Faster implementation of event processing. • Sets common expectations for how events will be recognized and handled. Implication • Publish a standard set of APIs, event message formats, usage and event classification criteria. • Communicate event management standards to application development personnel. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 12 Guideline Example #4 – Event Management Guideline Only application events that are made available will be recognized and processed. Sample Application End-user availability of application ABC cannot be monitored unless dummy transactions are developed that run automatically during periodic intervals that drop status information. These dummy transactions must be reflective of general end-user behavior and the basis for end-to-end availability will be calculated from the logged status information. Rationale • Cannot effectively monitor what cannot be seen. Implication • Application developers identify which application events are to be recognized. • Application developers build messaging hooks into the applications for events they wish to recognize. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 13 Guideline Example #5 – Event Management Guideline Event processes will be automated whenever possible. Sample Application Event handling procedures will be reviewed on a bi-monthly basis to determine candidate activities for automation. A small Service Improvement Program will be put into place to implement any automation recommendations found. Rationale • Eliminates potential problems that can be caused by human error. • Targets event processing that can occur transparently to end-users and IT personnel. Implications • We implement programs to continuously look for candidates for automation. • Automation solutions for application events involve developers who may need to construct additional scripts, code or procedures to provide automated recovery at the applications level. • Application dependencies are considered when developing automated response handling. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 14 Guideline Example #6 – Event Management Guideline All events must subscribe to a standard classification scheme that references common handling and escalation processes. Sample Application All ABC application database events will be classified as application level events and escalated to the applications support group. Rationale Implication • Provides a consistent approach and set of expectations for handling and managing events in a manner tied to service level objectives. • Streamlines the number of escalation approaches and handling processes that will need to be built. • We tie common approaches to service levels and objectives for problem severity, notification and priority levels. • We establish common handling processes for each class of event. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 15 Guideline Example #7 – Event Management Guideline Only events that require operational intervention will be recognized. Sample Application User-ID password resets will only be logged to the central security database for audit purposes. Password reset attempts that exceed 3 tries will raise a Security event that will escalate to the Security Management support group. Rationale • Eliminates needless notifications. • Makes recognition of events more noticeable to support staff by not mixing important events with unimportant notifications and messages. Implications • We identify what messages are important. • We list events in a common classification scheme. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 16 Guideline Example #8 – Event Management Guideline All recognized events will be captured and logged. Sample Application All application ABC events will be tagged with their event classification type and logged into event databases for review and analysis. Event history will be maintained for 6 months. Rationale Implication • Provides a means for examining problems and trends after events have occurred. • Serves as an aid for root cause analysis in Problem and Availability Management. • We log all recognized events. • We provide adequate storage resources for event capture and retention. • We implement data manipulation, filtering and reporting to quickly search and identify event situations. • We interface events with Incident and Problem Management databases. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 17 Guideline Example #9 – Event Management Guideline Every recognized event must have a clear owner. Sample Application John Smith will own all events classified as security. John will triage and forward events to needed operational support staff when they have been recognized. Rationale Implication • Clearly identifies responsibilities for event handling. • Clearly communicates to support staff who should handle what kind of events. • We identify default owners by event or class of event. • We differentiate roles and responsibilities between groups charged with event handling responsibilities. • We split roles and responsibilities for complex events. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 18 Guideline Example #10 – Incident Management Guideline Incident processing and handling must be aligned with overall service levels and objectives. Sample Application All application ABC database events must be escalated to third level support if they have not been resolved within 5 minutes. Rationale • Ensures incident handling supports service levels and objectives. • Identifies which incidents require high priority handling based on actual business need. Implications • We understand service levels and objectives that need to be provided for. • We build event handling that is targeted towards service levels. • We develop Service Desk and Incident Management Operational Level Agreements to set thresholds for when Incident escalation and notification actions should be taken. • We implement reporting on service actions and thresholds within Incident Management functions. • We time stamp key Incident Management activities. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 19 Guideline Example #11 – Incident Management Guideline All incidents should be stored and managed in a single data repository. Sample Application A central repository database exists that is the definitive source for all incident information. Rationale • Provides definitive recognized source for incident information • Provides easier access for reporting and problem investigation efforts Implications • We have implemented an Incident Management Database capability for incident information • We have implemented integration between this repository and other service management tools that use or provide incident related information © 2007 Randy A. Steinberg & Robin Yearsley. Page: 20 Guideline Example #12 – Incident Management Guideline All incidents will subscribe to a standard classification schema that is consistent across all of IT. Sample Application A standard schema exists for classifying all incidents. All IT incidents are logged to the categories in this schema. Rationale Implications • Provides easy access to incident work-around and troubleshooting information • Critical for supporting Problem Management activities • We have a well defined and communicated set of incident classification categories • It is impossible for anyone to enter non-standard categories for incidents • Service Desk and incident handling staff are aware of what categories exist © 2007 Randy A. Steinberg & Robin Yearsley. Page: 21 Guideline Example #13 – Incident Management Guideline Incident records will be audited on a regular basis to ensure they have been entered and categorized correctly. Sample Application At the end of each day, closed incidents are audited to verify that they have been entered and categorized correctly. Rationale • Ensures incident information is accurate and useable by Problem management and other support areas • Supports trending analysis and related activities around incidents and problems Implication • We have an independent auditor role in our organization to audit incident records for accuracy • Feedback mechanisms are in place to communicate audit findings and issues to incident handling staff © 2007 Randy A. Steinberg & Robin Yearsley. Page: 22 Guideline Example #14 – Incident Management Guideline IT will own and manage all definitive sources of knowledge used to diagnose and troubleshoot incidents related to IT services. Sample Application Each service unit within IT has the responsibility to provide knowledge for diagnosing and handling incidents to Incident management staff. This responsibility includes maintaining that knowledge on a regular consistent basis to make sure it is timely and accurate. Rationale • Ensures up-to-date and accurate information is available to incident handling staff • Supports efforts to get incidents handled faster and at first call more frequently Implications • We have roles and responsibilities assigned for each service component to input and maintain knowledge for incident handling staff • We have tools in place to capture and communicate knowledge and knowledge changes to incident handling staff • We handle knowledge changes through the Change Management process • We integrate with the Problem Management process to get information on problems and work-arounds. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 23 Guideline Example #15 – Incident Management Guideline All incidents will be recorded in the incident management system. Sample Application Periodic audits are conducted on a regular basis to check that all incidents are being recorded. IT support labor is tied to incident tickets to quickly raise awareness of resolution work for incidents not recorded. Rationale • Ensures recognition of all incidents and activities taking place to resolve them. • Provides an authorized record of incident management activity. • Ensures incidents do not “slip through the cracks” and go on unaddressed. • Provides IT management with an accurate picture of the quality and issues with the IT infrastructure. Implications • An investment in an Incident Management system will be needed. • Service Desk and IT support staff will need training for recording and accessing the incident management system. • Recognition and possible penalties need to be in place for incident resolution activity taking place without a corresponding incident ticket. • A mechanism must be put into place for recording incidents raised through automated tools and alerts. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 24 Guideline Example #16 – Incident Management Guideline Standard criteria will exist for identifying incident severity levels. Sample Application The Service Desk maintains a standard chart showing all incident severity levels and their criteria. Service Desk staff use this chart extensively when escalating calls and reported incidents from end users. Rationale • Prevents incidents from being handled based on isolated judgments of IT support staff or business users. • Prevents users from raising incidents to high levels to get attention when that is unnecessary. • Eliminates finger pointing over why incidents were handled one way versus another. Implications • Detailed criteria for severity levels needs to be defined and well communicated throughout the enterprise. • Severity level criteria needs to be agreed to by the business. • Service Desk and IT support staff need to understand that the criteria determines the severity level, not the judgment of staff and callers. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 25 Guideline Example #17 – Request Fulfillment Guideline A separate process will exist for handling day-to-day IT requests from the business. Sample Application A business user contacts the Service Desk with a request to move her PC to a new location. The Service Desk routes the request through a request handling process that is separate from Incident and Change Management processes. Rationale • Requests typically have known outcomes, approval and execution paths that are not incidents or changes. • Mixing requests with incidents and changes skews the real operational quality picture when measuring the effectiveness of those processes. • Simplifies handling and tracking of day-to-day requests with a minimal amount of management overhead. Implications • Well established criteria for what is a request versus a change or an incident needs to be in place and well communicated. • Requests need to be linked to change management as standard changes. • Business users need to be made aware of the request process and what they can expect. • Service targets and priorities will be different for requests than they would be for incidents and changes. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 26 Guideline Example #18 – Request Fulfillment Guideline Criteria need to be in place that differentiates a request from an incident or change. Sample Application A Request Management Policy is in place that differentiates what determines a request from an incident or change. Key criteria for this includes: • Must be recurring event that is performed frequently in the company • Must follow a standard processing path with a known outcome • Approval has been provided in advance • Follows the Change Management criteria for a Standard Change Rationale • May mishandle request of not properly classified. • IT staff should not be in position of making judgment calls on whether the request should be handled via the Request Fulfillment process versus Incident or Change processes. • Sets expectations among business users and IT staff for how their requests will be handled. Implications • Criteria for what determines a request will have to be clearly defined and communicated. • Both IT and the business need to agree on what events will be considered requests. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 27 Guideline Example #19 – Request Fulfillment Guideline The means for processing requests will be planned for in advance. Sample Application The company has established a predefined process workflow to include the stages needed to fulfill requests for provisioning office LAN servers. The individuals and support groups involved, target timescales, and escalation paths have been designed in advance. Provisioning the office servers has been established as a Standard Change with Change Management. The ownership of those requests will reside with the Service Desk, which will monitor, escalate, dispatch and close the request. Rationale • Requests are planned events whereas incidents and changes are not. • Requests cannot be handled in a consistent efficient manner if the means for handling them has not been planned for in advance. • Planning is needed to ensure that unplanned events do not occur in the course of handling a request. Implications • We need to understand which events will be categorized as requests in advance. • Procedures, activities, roles and responsibilities for processing requests will have to be designed and built in advance. • Training and communications to Service Desk and support staff will be needed before processing of requests can begin. • Service targets will need to be established and tested for in advance of starting request fulfillment processing. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 28 Guideline Example #20 – Request Fulfillment Guideline All service requests must be handled in a consistent manner that meets established service targets. Sample Application The company IT department has created sets of pre-defined Request Models to handle each kind of request that will be part of the Request Fulfillment process. Development activities for this include preapproval by Change Management to establish them as standard changes. Rationale • Variation in handling requests increases labor costs and threatens service quality. • Inadvertent handling of requests may bleed over into events that would be better processed through incident or change management. • Increases overall business satisfaction with IT services. • Reduces bureaucracy and overhead for handling of day-to-day requests and needs. Implications • Standard processing for fulfilling requests needs to be planned for in advance and well communicated to support staff. • Request fulfillment procedures will need to be tested to ensure they work and meet desired service targets. • Any business needs that might cause variation in handling of a requests should be known to the greatest extent possible. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 29 Guideline Example #21 – Request Fulfillment Guideline Handling and processing of requests should be automated to the greatest extent possible. Sample Application Company business users are offered a ‘menu’-type selection via a web interface, so that they can select and input details of Service Requests from a pre-defined list. In some cases, the requests themselves are processed automatically with only a notification back to IT. In other cases, work orders to IT support staff are automatically generated. Rationale • Greatly increases the efficiency of handling and fulfilling requests. • Greatly reduces the risk of human error when processing requests. • Reduces labor costs. • Increases business satisfaction with IT services. • Services can be offered more easily 24x7 or when the business needs them instead of confined to IT operating hours. Implications • Request types must be known in advance. • Investment may be needed in automation tools to handle requests electronically. • Automated processing of requests must still be logged and communicated. • Increased skills among IT support staff will be needed to manage and maintain any automated solutions used. • Investment in a workflow management tool may be needed. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 30 Guideline Example #22 – Problem Management Guideline Every high severity problem will require a documented root cause and control. Sample Application All incidents marked as SEV1s will be assigned to a Problem Owner who has the responsibility to identify and document the Root Cause. Rationale • Ensures Problem Management focus on all high severity incidents. • Proactively works to reduce or eliminate future high severity incidents. • Provides upper management communication and assurances that high severity incidents are being appropriately addressed. Implication • Problem Owners are assigned to every SEV1 generated. • Solid skills are in place to identify Root Cause. • Management communications are in place to communicate timely and useful Incident information. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 31 Guideline Example #23 – Problem Management Guideline Problems will be tracked separately from Incidents. Sample Application A separate database exists that contains Problem Records to record Problem Tickets and status. Known Errors, Problem Workaround information and status on Problem and Error Control activities is also kept in this database. Rationale • Provides clear separation between proactive Problem Management activities and reactive Incident activities • Easier ability to track Problem management activities and progress separately Implication • Tools are in place to track Problems separately from Incidents • Problem categories and reporting are in place © 2007 Randy A. Steinberg & Robin Yearsley. Page: 32 Guideline Example #24 – Problem Management Guideline Every problem will have an assigned owner. Sample Application After identifying a problem that appears to be causing multiple incidents, the Problem manager has assigned an owner dedicated to finding its Root Cause and coordinating activities to remove the error. Rationale • Ensures responsibility assigned to fix problems • Provides single point of contact for communications about problems Implication • The Problem Owner role is understood and communicated throughout the organization • Problem Owners have appropriate authorization to coordinate and take actions to identify Root Cause and remove the error © 2007 Randy A. Steinberg & Robin Yearsley. Page: 33 Guideline Example #25 – Problem Management Guideline Standard criteria will be in place to raise problems from incidents. Sample Application An INCIDENT will become a PROBLEM when any of the following as occurred: • Incident management cannot match an incident to existing Problems and Known Errors • Trend analysis of logged incidents reveals an underlying problem • The INCIDENT is a SEV1 Other IT areas identify that a problem condition exists Rationale • Provides clear distinction between Incidents and Problems within the company. • Focuses Problem management resources on higher priority areas. Implication • Clear communication on what is a PROBLEM versus an INCIDENT needs to be understood and communicated • Current practice of conducting root cause activities for ALL company incidents may change • May need to provide dummy Problem records that can be used by Incident Management for low impact, non-recurring incidents. • Need to clarify Incident management role in providing and documenting root cause for incidents © 2007 Randy A. Steinberg & Robin Yearsley. Page: 34 Guideline Example #26 – Access Management Guideline The costs and overhead of an access management solution will be balanced against the risks associated with the information or physical facilities being accessed. Sample Application It is our practice to require an employee at a high security facility to spend 30 seconds to verify on the system; such users are unlikely to feel offended by the technique or to find it an invasion of their privacy. At the other extreme, if access is implemented to allow an employee into the company cafeteria, the same access strategy will make that employee feel uncomfortable or intruded upon unnecessarily. Rationale • • • Implication • • Low business satisfaction levels will occur if access mechanisms are way too high for information and areas that are low in risk. Costs may be higher than necessary to manage access. IT needs to be aware of the risk levels they are managing against. The level of risk exposures need to be known for each item or facility being accessed. High risk areas will require more investment in access management supporting technologies. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 35 Guideline Example #27 – Access Management Guideline Access Management deployments must not be expanded to perform broader verification or identification-related functions than originally intended. Sample Application A company policy exists that strongly states that Access Management solutions are strictly for validating access to company secure information, applications and physical facilities. Any expansion or retraction of scope for access management solutions is accompanied by full and public disclosure, under the oversight of an independent auditing body, allowing individuals to opt-out of system usage if possible. Rationale • • Implication • • • Risks are created when access management solutions are employed for purposes beyond those originally intended. Privacy policies and regulations may be compromised. A strong policy defining the scope of access management solutions must be in place and strictly enforced. An independent auditing body may be needed to oversee scope of access management solutions. Investments in access management solutions may not be leveraged for other purposes. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 36 Guideline Example #28 – Access Management Guideline There should be no establishment of a unique identifier within the access management solution. Sample Application The company implements sufficient protections to ensure that user information cannot be used as a unique identifier. Enrollments to the access management network are carefully controlled and encrypted to ensure they also do not become unique identifiers. Rationale • Unique identifiers facilitate the gathering and collection of personal information from various databases, and represent a significant threat to privacy. • This type of identifier could be used as an identifier across multiple databases and applications. Implications • The unique identifier issue will become more problematic if a biometric technology is developed which generates the same template every time a user interacts with a system. • There is a risk that DNA could develop to this point, as a user's DNA profile does not change from day to day as does a finger or facial-scan. • Enrollment data for secured access solutions will have to be carefully controlled as it could be shared across various agencies or companies in unencrypted form. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 37 Guideline Example #29 – Access Management Guideline Protection of access management information should be tightly controlled at all times. Sample Application The company protects Biometric Information at all stages of its lifecycle, including storage, transmission, and matching. The protections enacted may include encryption, private networks, secure facilities, administrative controls, and data segregation. The protections necessary within a given deployment are determined by a variety of factors, including the location of storage, location of matching, the type of biometric used, and the capabilities of the biometric system, which processes take place in a trusted environment, and the risks associated with data compromise. Rationale • Exposure of information will create great risks for unauthorized access to company resources. • Loss of access management information may create a major business disruption of resources cannot be accessed by those who need to. Implication • An investment in securing access management solutions must be made. • Policies and procedures for management of access must be tightly controlled and strictly enforced. • Compromise or failure of access management solutions should be regarded as major incidents. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 38 Guideline Example #30 – Access Management Guideline Protection of post-match information should be tightly controlled at all times. Sample Application Data transmissions resulting from biometric comparisons are strongly controlled and protected by the company. The network handling these transmissions is securely controlled within the company’s DMZ. Rationale • Although these post-comparison decisions do not necessarily contain any biometric data, their interception or compromise could result in unauthorized access being granted to personal information. • Some comparisons might take place in non-trusted environments such as the Internet. Implication • The entire infrastructure used to underpin access management activities and actions must be protected, not just the access management solution itself. • Access management solutions must be implemented within company secure perimeters and trusted networks. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 39 Guideline Example #31 – Access Management Guideline Access management information must only be stored for the specific purpose of usage in accessing systems and facilities and should not be stored any longer than necessary. Sample Application Company policies state that Biometric information should be destroyed, deleted, or otherwise rendered useless when the system is no longer operational; specific user information should be destroyed, deleted, or otherwise rendered useless when the user is no longer expected to interact with the system. This also applies to templates generated during comparison attempts, such as a template generated in the verification stage of an application. Rationale • The longer access information is left in storage, the greater the risk it may be compromised. • Allows for additional risks of exposing information for other purposes than what was intended. Implications • Awareness of access management transactions needs to be in place with events triggered to delete information at the earliest point possible. • Access management information may not be used for any other purpose than what it was intended for. • Periodic audits and oversight may be needed to validate that information is being deleted properly. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 40 Guideline Example #32 – Access Management Guideline Ample and clear disclosure must be provided when individuals are being enrolled in an access management system. Sample Application Company policy states that ample and clear disclosure must be provided when individuals are being enrolled in an access management system. Disclosure must take place even if the enrollment templates are not being permanently stored, such as in a monitoring application. This includes employees enrolled in a facialscan system through badge card pictures or drivers’ licenses photos, or telephone callers enrolled in a voice-scan system. Rationale • A basic privacy principle is that individuals must explicitly consent to the collection, use and storage of personal information. • Access information and data is personal information, and its surreptitious collection for the purpose of enrollment is inconsistent with reasonable privacy expectations. • Access information can easily be shared between corporations, partners, and other agents who may not adhere to the same data or privacy protections as the original entity to whom the user provided access data. Implications • Biometric information must only be used for the purpose for which it was collected, within the system for which it was collected, unless the user explicitly agrees to broader usage. There must be no sanctions applied to any user who does not agree to broader usage of his or her biometric information. • As control over personal information is a basic privacy principle, individuals should have the option of extending the utility of their access data. For example, a user who accesses an online account through a biometric should be allowed the option of securing additional accounts with the same biometric information. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 41 Guideline Example #33 – Service Desk Guideline End-user support will be provided by a single toll-free number. Sample Application All company ABC employees are to call 1-800-HELP-NOW to access the company Service Desk. Rationale • Provides ease of access to services. • Promotes use of the service interface. • Reduces the number of interfaces. • Promotes user satisfaction. • Provides single-point-of-contact for all IT services. Implications • Service Desk support is effective. • There is investment in tools to provide support. • User satisfaction is continually measured. • Telecom costs have been considered. • Overseas calls are accommodated. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 42 Guideline Example #34 – Service Desk Guideline The Service Desk will be the single-point-of-contact for all communications about IT incidents, problems, and announcements throughout the company enterprise. Sample Application During the course of a major incident, all requests for incident status, expected recovery times and actions being taken for resolution are communicated via the Service Desk. Rationale • Provides an authoritative source for all IT communications. • Prevents IT labor from being spent on non-authorized activities and requests. • Ensures consistent communications – especially for major incidents and IT actions. • Allows IT to focus on resolving incidents and requests versus being interrupted to provide status to many stakeholders. Implications • IT staff will need to be authorized to reject requests for help unless authorized by the Service Desk. • An incident and request ticketing solution needs to be in place. • IT Labor reports may need to be tightly tied to incident tickets and requests that they are working on. • The Service Desk must be seen as helpful and the preferred way of getting things done by business users throughout the company. • The Service Desk will need to be easily accessible throughout the company. • Multiple channels of communication may be needed to communicate with the Service Desk (e.g. Telephone, Fax, Email, etc.). © 2007 Randy A. Steinberg & Robin Yearsley. Page: 43 Guideline Example #35 – Service Desk Guideline The Service Desk will prioritize activities based on service levels and priorities for services being impacted. Sample Application Email service for the company’s commodity traders receives priority response from the Service Desk for even the most minor service outage. Other company departments will receive priority response only if entire departments are impacted. This decision is based on business priorities since the commodity traders use Email as a critical service to bring in major revenue dollars to the company. Rationale • Ensures that the most critical issues are addressed by the Service Desk first. • Aligns Service Desk activities and priorities with business priorities. • Ensures valuable Service Desk resources are not being overly devoted to non-critical services. Implications • Services and service targets must be understood and well communicated to the Service Desk. • Warnings and alerts will be needed to identify critical service targets that are being missed or in jeopardy. • Management must provide support for Service Desk decisions on service and business priorities. • Some executives and users will try to raise the priority of their calls and issues unfairly. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 44 Guideline Example #36 – Service Desk Guideline The Service Desk will ensure that the user who raised a call is satisfied with the resolution prior to closure of the call. Sample Application After indication that an incident has been resolved, the Service Desk contacts the end user to obtain their agreement that the incident can be closed. Rationale • IT should not take the decision to close an incident on their own without business user agreement. • Increases business satisfaction with IT services. • Prevents frequent reopening of incidents after they have been closed. Implications • Call management procedures should ensure that callbacks are placed to the business user at the resolution of each incident or service request reported. • Incident tracking systems will need to recognize the difference between tickets that IT says are complete distinctly from final closure of them agreed to by the business. • Service Desk call agent labor should take the time needed to process user callbacks into account when determining staffing levels and call agent targets. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 45 Guideline Example #37 – Service Desk Guideline An escalation policy should be established in order that the Service Desk can make decisions on when an incident should be escalated through the management chain. Sample Application When an incident is reported, the Service Desk has established predefined time limits that define how long a call agent should try to service a call before escalating to the duty manager. Rationale • Ensures timely handling of incidents. • Raises awareness of more severe incidents more quickly and efficiently. • Lack of a policy will lead to delays, finger pointing and redundant labor in handling incidents. Implications • An escalation policy needs to be defined and well communicated to Service Desk and IT support staff. • Automated warnings and event triggers may need to be defined to recognize when calls are exceeding threshold times or for when service levels are being threatened. • Levels of management higher up the escalation chain must explicitly understand and recognize their priorities in dealing with calls that may be escalated to them. • Communication and awareness needs to be established to identify incidents that have been escalated and to what level. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 46 Guideline Example #38 – Service Desk Guideline Service Desk call handling will be designed to resolve as many calls within the Service Desk as possible without escalation. Sample Application Each month, the Service Desk manager reviews calls that have been escalated outside the Service Desk to identify actions that can be taken to avoid further escalations. This may include increased training of call agents, better knowledge tools or identifying incident trends to IT support staff. Rationale • Greatly increases business satisfaction with IT services. • Greatly increases business confidence with the Service Desk. • Prevents callers from bypassing the Service Desk. • Maintains company investment in high quality Service Desk support services. Implications • Additional investment in call ticket review activities will be needed. • There will be a temptation on the part of the Service Desk to not escalate calls in order to show better results when in reality, those calls should have been escalated right away. • The Service Desk will require strong working relationships with other IT support staff to implement improvements when needed. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 47 Guideline Example #39 – Service Desk Guideline The Service Desk should have easy access to a comprehensive, accurate, and holistic view of the IT environment. Sample Application The Service Desk has been co-located with the company’s IT Command Center to provide easy local access to infrastructure displays and alerts. Rationale • The Service Desk is the communications hub for the IT infrastructure. • Provides capability to resolve many more calls and incidents without escalation to other support groups. • Provides early warning of impending problems and issues that can be communicated at the point of end user call. • Service Desk cannot provide high quality service if it is not aware of what is going on in the IT infrastructure. • Other IT support groups do not always have an interest in maintaining a holistic view of what is happening throughout the IT infrastructure. Implications • Investment will be needed in consoles, monitoring tools, alerting and display technologies. • Service Desk staff will need to adopt a holistic view of the IT infrastructure when providing services. • Service Desk staff will need to be trained on monitoring and display technologies that have been implemented. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 48 Guideline Example #40 – Common Service Operations Guideline There should be a common naming convention for job and event scheduling. Sample Application All naming conventions for job scripts, JCL and event schedules matches the naming conventions in the IT Release Policy. Rationale • Simplifies administration across platforms. • Common language across platforms. • Simplifies integration between Systems Management and Service Management. Implications • Common and integrated data model for Systems Management and Service Management is needed. • Must be aligned with naming conventions used across IT. • Tools will be needed to administrate naming conventions. • Ownership of the naming convention must be defined. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 49 Guideline Example #41 – Common Service Operation Guideline All documentation regarding scheduling should be located in one place. Sample Application Operational run books are kept online and easily accessible from the company’s intranet. Hardcopy versions are also stored in each command center in the event the intranet is not accessible. A procedure is in place to keep hardcopy and online versions synchronized triggered from Change Management. Rationale • Instruction will be available for corrections and re-executions. • Increases quality in operations. Implication • Supporting tools will be needed. • Centralized coordination will be required. • Ownership must be defined. • Documentation must be easy to access. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 50 Guideline Example #42 – Common Service Operation Guideline All changes in scheduling should be handled through the Change Management process. Sample Application The RFC for adding a new module to the Sales Reporting system includes job schedule changes caused by the new reports that the module will generate. Rationale • Increases the quality of services. • Improved reliability and availability. • Changes are possible to track. • All changes within scheduling are documented. Implications • Testing environment must be available. • More administrative overhead must be acceptable for making scheduling changes. • Well defined change categories are needed. • Implemented Change Management process must be in place. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 51 Guideline Example #43 – Common Service Operation Guideline Backup process and tools must be 100% reliable, compatible and fault tolerant. Sample Application For backup jobs that handle critical company data, data validation steps are performed to ensure data backed up is complete and accessible. Backup media itself is stored in a separate media library and this is rotated with an offsite storage facility. Rationale • Ensuring the availability of key systems and data that underpins services is critical. • Regulatory requirements and audits will require data to be available or else severe penalties may result. • Much wasted labor occurs to recover data that is lost or corrupted. Implications • All backups must be verified for successful completion. • Change management must be in place. • New applications, HW, tools, etc. related to backup must be tested and certified. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 52 Guideline Example #44 – Common Service Operation Guideline Routine backups of data will be automated wherever possible. Sample Application An automated backup and restore tool is used to schedule and execute backups. Retrieval of backups is also automated. Rationale • Creates greater efficiencies and reduces errors. • Facilitates greater levels of management control. • Reduced human intervention and enables faster recovery. Implications • Costs and customization of tools will be required. • Comprehensive documentation will be needed to enable manual recovery when required. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 53 Guideline Example #45 – Common Service Operation Guideline All requests for non-standard operational services must be routed through the Request Fulfilment Management process. Sample Application A one-time request to extend hours of operation for the Sales Support System for an extra 30 minutes is submitted via a Request For Service submitted to the company’s Request Fulfilment process. That process will coordinate the activities for the extension, ensure it does not impact other operational schedules for that day and validate that the extension has been put into place. Rationale • Provides an efficient way to support non-standard requests for operational services. • Ensures requests will not compromise day-to-day operational activities and functions. • Provides an audit trail and authoritative record for requests. Implications • A Request Fulfilment process must be in place. • Operations personnel must be authorized to reject operational requests if they were not initiated by Request Fulfilment. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 54 Guideline Example #46 – Common Service Operation Guideline The type and criticality of the data will determine the requirements for backup and recovery as per Service Level Requirement. Sample Application The backup strategy for the command center prioritizes backup of data that supports vital business functions. Rationale • Provides an effective use of backup resources and investment. • Avoids unnecessary backups. • Ensures critical data gets the most attention. • Reduces requirements for backup windows. Implications • Will need to understand services being delivered and criticality of the data that supports them. • Will need concurrence of the business for backup service targets. If you enjoyed this Report, then why not download part five in the series: visit: http://www.ITILVersion3.com and recommend us to get instant FREE access. © 2007 Randy A. Steinberg & Robin Yearsley. Page: 55
