PROBLEM MANAGEMENT

   Overview of the Problem Management Process

Problem Management helps to identify the cause of an error in the IT infrastructure that is usually reported as occurrences of related incidents. Resolving a problem means fixing the error that will stop these incidents from occurring in the future. While Incident Management deals with fighting symptoms to incidents, Problem Management seeks to remove the causes of incidents permanently from the IT infrastructure. Problem resolution and elimination of root cause often calls for applying a change to the configuration item in the existing IT environment.

The ServiceNow platform supports the Problem Management process with capabilities to record problems, create knowledge from problems, request changes, assign to appropriate groups, escalate, and manage through to resolution and reporting. This page attempts to detail the out-of-box functionality provided by the platform to manage problems in accordance with the ITIL process.

Within the platform, problems are handled using the task record system. Each problem is generated through a variety of means as a task record, populated with the pertinent information in individual fields. These tasks can be assigned to appropriate problem management team members, who will deal with the task as appropriate. Once the problem has been properly dealt with, the problem task is closed.

   PROBLEM MANAGEMENT - OVERVIEW DESCRIPTION

 The Problem Management Process consists of the following sub process activities:

 1. Notification The identification of a problem. Examples of a problem might be an outage, an incorrect or an unusual result. This sub process also includes notifying the appropriate support structure that there is a problem and a need for assistance. The initial recording of a problem, including all relevant information that is available when the problem occurs. This is the introduction of the problem into the management system. (Source Incident Management Process)

 2. Problem Determination The collection, analysis, and correlation, of data to determine and isolate the cause of the problem.

 3. Workaround and Recovery Activity to recover, workaround or circumvent the problem, and notification to the affected clients of action taken.

 4. Problem Resolution The identification, implementation, and verification of solutions, and notification to affected clients.

 5. Tracking The assignment of ownership for resolving problems and the follow-up activity to ensure that the goals for problem resolution are being met. It includes setting priorities and escalating issues via the appropriate system.

 6. Reporting and Control The production and analysis of reports, over time, to determine if the problem management process is working effectively and to identify changes that me be necessary. It also helps identify significant results and problem trends.

PROBLEM MANAGEMENT PROCESS FLOW (ITIL)

IDENTIFYING AND LOGGING PROBLEMS

A problem can be generated in a number of ways:

§  An IT staff member can generate one manually using Problem > Create New or by clicking New from the problem record list.

§  An IT staff member can generate a problem from an incident.

§  A record producer can be created to allow users to log problems in the service catalog.

§  If a user attempts to create a generic task, the task interceptor will first ask them to specify what sort of task they would like to create. In this way, tasks are always assigned a handling process.

§  If an appropriate inbound email action is configured, a problem can be generated from an email.

A problem can be associated with a configuration item using CMDB to help the problem management team see the affected item and its relationships to other configuration items.

A problem can be assigned to a user or group. This can be done manually, or using an assignment rule.

A problem can be associated with one or more incidents using a related list, using the Edit button. This will already be the case if the problem was generated from an incident. This allows the problem management team to quickly refer to the knowledge already generated by the service desk in investigating the incidents. 

INVESTIGATING AND UPDATING PROBLEMS 

If the problem management team has a problem model process for dealing with certain problems, they can be codified in the system with workflows. This allows for standardization and automation of the process.

Note: ServiceNow also provides the Structured Problem Analysis application (starting with the Dublin release) as a method for identifying the true root cause of a problem.

As a problem is updated, email notifications will be sent to concerned parties. If inbound email actions are specified, the problem can be updated via email.

The platform has an in-built system of Escalations rules which can ensure that problems are handled speedily. Two escalators are available in the system:

Service Level Agreements - SLAs monitor the progress of the problem according to defined rules. As time passes, the SLA will dial up the priority of the problem, and leave a marker as to its progress. SLAs can also be used as a performance indicator for the problem management team.

Inactivity Monitors - The inactivity monitors prevent incidents from slipping through the cracks by generating an event (which in turn can create an email notification or trigger a script) when a problem has gone a certain amount of time without being updated.

RESOLVING PROBLEMS

If a problem needs a change in order to be resolved, it is possible to request a change, which will be then resolved using the change management process. Once a change has been requested, the problem will appear on a related list on the change item's form. Once the problem is associated with a change item, change the Problem State to Pending Change.

It is possible to create a business rule that will close the problem automatically if the change it is associated with is closed. This automates the process of closing problems that are Pending Change. It is also possible to create a business rule that will automatically close all incidents associated with the problem if the problem is closed.

If a problem's cause has been determined but there is no permanent fix, changing the Problem State to Known Error communicates this fact to the IT staff. This helps reduce the time spent on incidents dealing with the known problem by making known errors easy to find, automatically creating a list of Known Errors. To communicate knowledge related to this problem to users, Create Knowledge from Problem can either communicate a workaround, create a knowledge base article, or create a news item. This is important in the Knowledge-Centered Support process, which reduces repeat incidents and problems, and in the Knowledge Management process.

The following process flow shows an overall ITIL based version of the Problem Management process for resolving client problems. This illustration is meant to provide the reader with an understanding of the general functional flow of the problem process.

PROBLEM MANAGEMENT MEASURES

The reports that are produced for the problem management system are designed to help manage the process. Daily reports identify results from the previous day, and any problems, which must be confronted during the day. Weekly reports provide a summary of the previous week’s success, current status and weekly trend information. Daily reports are primarily for technicians. Weekly reports enable effective management of the process. Monthly reports can also enable IT to evaluate the effectiveness of the problem management system.

 PROBLEM MANAGEMENT PROCESS MEASUREMENTS

The problem management process measurements are used to determine if adjustments must be made to the process:

•  Cost and resource time to support the process
•   Number of problems raised
•   Number of known errors identified
•    Number of incidents linked to problems
•    Number of rejected resolutions
•    Number of changes resulting in problems
•     Number and cost of problems caused by changes
•    Numbers of problems fixed by changes.

    ROLES AND RESPONSIBILITIES

      PROBLEM MANAGEMENT PROCESS OWNER

   

      PROBLEM MANAGEMENT CONTROLLER 

      PROBLEM MANAGEMENT ANALYSTS

·             http://wiki.servicenow.com/index.php?title=Problem_Management#gsc.tab=0

·            http://www.itsmcommunity.org/downloads/Sample_Process_Guide_-_Problem_Management.pdf

ITIL,CMMI,COBIT,TOGAF and relation between of these

Dear followers,

I'll try to give information about ITIL,COBİT,TOGAF,CMMI and the relationship between them.

First  I give information about ITIL: ITIL advocates that IT services are aligned to the needs of the business and support its core processes. It provides guidance to organizations and individuals on how to use IT as a tool to facilitate business change, transformation and growth.

The ITIL best practices are currently detailed within five core publications: 
   ITIL Service Strategy,    ITIL Service Design,    ITIL Service Transition,    ITIL Service Operation ,  ITIL Continual Service Improvement. 

These five volumes map the entire ITIL Service Lifecycle, beginning with the identification of customer needs and drivers of IT requirements, through to the design and implementation of the service and finally, the monitoring and improvement phase of the service.

COBITs are now in,you think :Why am I a huge fan of COBIT?

•  COBIT is relevant- the goal is to deliver value
•  COBIT still focuses on information.  
•  COBIT is not just for the big companies.
•  COBIT is a framework that looks beyond just processes.
•  COBIT is a great reference for process owners
•  COBIT has a goals cascade that is flexible and useable
•  COBIT has a product family that is consistent, like a single playboo
•  COBIT can be incorporated with other frameworks
•  COBIT is the “middleware” between Governance, IT, and Assurance
•   No more control objectives

Whether you’re a board member, executive, auditor, or IT Operator, do yourself a favor and learn more about it.

Do you wonder TOGAF then , TOGAF is an architecture framework - The Open Group Architecture Framework. It enables you to design, evaluate, and build the right architecture for your organization.

The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy.

Today's CEOs know that the effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it assures the needs of the organization for an integrated IT strategy, permitting the closest possible synergy across the extended enterprise.

The technical advantages that result from a good enterprise architecture bring important business benefits, which are clearly visible in the bottom line:

•    A more efficient IT operation:
•  Lower software development, support, and maintenance costs
•  Increased portability of applications
•   Improved interoperability and easier system and network management
•   Improved ability to address critical enterprise-wide issues like security
•    Easier upgrade and exchange of system components
•    Better return on existing investment, reduced risk for future investment:
•   Reduced complexity in IT infrastructure
•   Maximum return on investment in existing IT infrastructure
•  The flexibility to make, buy, or out-source IT solutions
•   Reduced risk overall in new investment, and the costs of IT ownership
•   Faster, simpler, and cheaper procurement:
•   Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan.
•   The procurement process is faster - maximizing procurement speed and flexibility without sacrificing architectural coherence.

Finally I tell CMMI , Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes.

CMMI stands for "Capability Maturity Model Integration". It's the integration of several other CMMs (Capability Maturity Models). By integrating these other CMMs, it also becomes an integration of the processes and practices within the model in ways that previous incarnations of the model(s) didn't achieve. The CMMI is a framework for business process improvement. In other words, it is a model for building process improvement systems. In the same way that models are used to guide thinking and analysis on how to build other things (algorithms, buildings, molecules), CMMI is used to build process improvement systems.

It is NOT an engineering development standard or a development life cycle. Please take a moment to re-read and reflect on that before continuing.

The CMMI helps us understand the answer to the question

• How do we know?
• How do we know what we are good at?
•  How do we know if we’re improving?
•  How do we know if the process we use is working well?
• How do we know if our requirements change process is useful?
•  How do we know if our products are as good as they can be?

The most important part now, ITIL,COBIT,CMMI,TOGAF relation between,

Analysing The Relation in Between ITIL, Cobit, Togaf and CMMI

The relation of enterprise architecture with some wellknown  management practices in each of these areas:

1.IT Governance:COBIT

2.IT Service Delivery and Support:ITIL

3.IT Implementation:CMMI

4.A framework for developing  an enterprise architecture:TOGAF

COBIT is a framework for the Governance and Management of the Enterprise IT covering the Enterprise End-to-End including the business processes from the board of directors to the IT operation levels, enabling a holistic approach based on 7 enablers :
- Principles, Policies & frameworks),
- Processes,
- Organizational structures
- Culture, Ethics & Behavior of the Enterprise stakeholders (including the Board, Employees, Management, etc)
- Information,
- IT (Services, applications, infrastructure)
- People, skills & competencies (HR management)
while ITIL is a framework of best practices in IT Service Management (covering the IT side only) and focused on processes only which doesn't allow any holistic approach.

ITIL could be seen as the way to manage the IT services accross their lifecycle while COBIT is about how to Govern the Enterpise IT in order to generate the maximum creation of value by the business, enabled by IT investments while optimizing the risks and the resources.

This is definitely two very different things which are complementary but with a huge difference in terms of scope and objectives

CMMI and ITIL are two distinctly different maturity models that can complement each other when used together. The fundamental difference between the two is that CMMI is a method of process improvement for software development, while ITIL focuses mainly on IT issues.

Business architecture is addressed by TOGAF but not by ITIL and,similarly, IT services are addressed by ITIL but not by TOGAF.The other elements  are covered in both frameworks,

albeit that the level of detail differs for each framework. In summary TOGAF gives you all you need to build the perfect IT solution and monitors the actual building, but provides no

guidance on how to actually deliver IT services. ITIL gives you allyou need to deliver IT services perfectly.

While TOGAF adds structure for enterprise architecture, processes and techniques, COBIT puts TOGAF into context by relating architectural processes to all other IT processes. And COBIT, through RACI charts, adds responsibilities for TOGAF, helping organizations implement TOGAF and connect it to broader IT processes. To complete the circle, COBIT also adds key performance indicators for TOGAF.

I use a lot of web sites and some of these:

http://sdtimes.com/togaf-cobit-and-the-governance-and-management-of-open-source-software/2/

http://www.dit.dk/Nyt_fra_DIT/Presse/Analyser_og_rapporter~/media/44D91BB37048417A8D1F4EDFF0E5BE27.ashx

http://blogs.interfacett.com/itil-cobit-pmbok-babok-togaf-5-tools-to-improve-your-it-department

http://www.slideshare.net/seveman/cobit-itil-and-cmmi-a-tutorial

tanışma

merhaba arkadaşlar,
öncelikle kendim hakkında kısa bir bilgi vererek başlamak istiyorum. Ben istanbul üniversitesi bilgisayar mühendisliği 4.sınıf öğrencisiyim. Sizlerle genellikle bilgisayar ve teknolojideki yenilikler  hakkında bilgiler paylaşmaya çalışacağım. Onun dışında da Malatya hakkında da bilgiler verebilirim belki de ;)

 Şimdilik kendinize iyi bakın en kısa zamanda görüşmek üzere :)