Apoyar Service Management Consultancy

From Apoyar Wiki

Jump to: navigation, search

The A1 system is based on different processes and workflows according to the ITIL/ITSM idea.

These processes are:

The workflows show the action(s) to be performed within the Process.

It is our aim to enhance the A1 application in such a way that it will provide the functionality to execute these actions.

Service Management Processes

Service Desk

The Service Desk provides the primary window for customer and user contact with the service organization on a day-to-day basis. The Service Desk may be responsible for a number of discrete functions within the support organization, including;


Provision of a single point of contact for customers


A day-to-day contact point between customers, users, IT services and third party support organizations. At any operational level, its objective is to provide a single point of contact to provide advice, guidance and may also be involved in providing a rapid restoration of normal services to its customers and users' following any service disruption.


Incident Classification


Incident classification is an important role of the Service Desk. The final classification(s) of an incident may vary to the initially reported one. The customer/user often report a 'symptom' of the incident and not necessarily the root problem. However, the incident classification process should not be over-complicated by adding too many classifications.


Incident Control


The Service Desk should own the incident control process and monitor progress on all incidents regardless of origin.


Incident Reporting and Review


The Service Desk form the main day-to-day interface between the Service Delivery organization and the users. Whilst the Service Desj plays an active role as a comunication channel for incident control, it also provides a contact point for enquiries on general service issues (including advice on progress on prior reported incidents/problems) and the dessimination of relevant information (e.g via bulletins, system messages, etc.).


Incident Management


The Service Desk is responsible for monitoring the resolution of all registered incidents - in effect the Service Desk is the owner of all incidents. Incidents that cannot be resolved immediately by the Service Desk may be assigned to specialist groups or teams (departments). Incident Management includes the following activities;


Incident recording and alerting


All incidents should be recorded in terms of symptoms, basic diagnostic data and information about the configuration item(s) and service(s) affected. Irrespective of the mechanism or pathway through which incidents are recorded, the Service Desk should receive appropriate alerts and maintain overall control.


Incident support and classification


Incident records raised should be analyzed to discover the reason for the incident. Incidents should also be classified, and it is this classification system that further resoltuion actions are based on.


Investigation and diagnosis


Wherever possible, the user should be provided with the means to continue their business functions, perhaps via a degraded service. Every effort should be made to minimize the impact of the incident on he business and to provide mor time to investigate and devise a structural resolution.


Resolution and recovery


After succesful execution of the resolution or circumvention activity, service recovery actions can be carried out, often by specialist staff. The incident management system must allow the recording of events and actions during the resolution and recovery activity.


Incident tracking and customer/user communication


Procedures need to be in place to guarantee that each individual incident is resolved within the agreed timeframes, or at least, as soon as possible.


Incident ownership, monitoring and closure


The Service Desk is responsible for owning and overseeing the resolution of all outstanding incidents whatever initial source. When the incident has been resolved, the Service Desk must ensure that the incident records are completed and are accurate, and that the resolution is agreed with the customer.


Problem managament


Problem management differs from incident management in that its main goal is the detection of the underlying causes of an incident and their subsequent resolution and prevention. This goal can be in direct conflict wih incident management where the goal is to restore service to the customer as quickly as possible rather than search for a permanent solution.

The scope of problem management is assumed to be;


Problem control


The identification of the root cause of incidents (problems), such as the configuration items that are at fault, and to provide Service Desk with information and advice on workarounds when available. The process needs to be carefully managed and planned. problem control activities include: problem identification, recording, classification, investigation and diagnosis.


Error control


The correction of configuration items to remove errors/faults, and the overall managment of known errors whilst they remain unresolved and until they are eliminated by the successful implementation of a change under the control of the Change Management process.


Proactive Problem prevention


The monitoring and analysis of th problem environment and the provision of information for proactive measures to improve service quality. This includes the identification of 'fragile' components (by analysis of incidents, problems and known errors), highlighting the potential for, and prevention of errors in one sytem recurring in other systems, identification of any other trends (e.g. a gradual increase in problematic changes from one area of the organization)


Production of Related Management Information


Overall management information related to problem management, including completion of major problem reviews, integrated with incident control management information produced by the Service Desk.


Change Management


The purpose of change management is to ensure that potential changes to IT service components are reviewed in terms of their afficacy to meet business requirements, and that their impact on service quality is minimized. Change Management is best implemented concurrently with Configuration management.

Better change management practices include:

  • facilitating the introduction of all types of change via simple, clear and effective procedures and tools across the various environments.
  • progressing changes on the basis of sound business and technological cases
  • assessing all changes for impact on the business and IT assets
  • providing a framework withing which those initiation changes may retain accountability for the actual work content
  • supporting project management and coordination
  • ensuring the feasibility of all proposed changes
  • preventing the introduction of changes which represent and unacceptable risk to the reliable delivery of services
  • preventing the introduction of unauthorized changes


Change management assumption


The scope of change management is assumed to be such that all changes to registered configuration items, inculding; hardware and software products and versions used in the provision of IT services, and the inclusion of new items into the live environments, will be subject to change control procedures. These would include hardware, communications equipment, system software, live applications software, together with all documentation and procedures associated with the running support and maintenance of live systems.


Service Level Management


Service Level Management is the name given to the processes of planning, negotiating, coordinatin, monitoring, and reporting on Service Level Agreements(SLA's). The process includes the on-going review of service achievement to escertain that the required service quality is maintained and wherever necessary improved.

SLA's contain specific targets against which permonance can be evaluated. They also define the responsibilities placed on all parties, in particular beinding Service Delivery to offer an agreed quality of service so long as the users constrain their demands within agreed limits. The relationship between Service Delivery and its customers is therefore put on to a formal business-like footing similar to those which exist between Service Delivery and its suppliers. When used in conjunction with the financial management process, service level management provides the basis for running Service Delivery as a business or profit centre.

Service Level Management provides a number of benefits not least of which is that it enables specific targets to aim for and against which service quality can be monitored and measured. Furthermore, service monitoring will allow weaknesses inexisting services to be identified, so that the quality of service provision can be improved.

Request for Change

A1 core can be seen as a foundation and once sold to a customer then can start building on it to fit their own purpose. As a result of that process the customer can request changes (Request for Change) in the A1 application provided to them as a service. Since the application is built on the methodology of ITIL/SM and thus Service Level Management, the processes involved are called Change and Release Management.

As a result of event mgt, problem and incident mgt a request for change can occur. To smooth these flows a template has been created with the information needed by the CAB (change coordinator, ..) to make a decision about the approval of the Request for Change (RfC). Aside from that the costs of the implementation are also weighed. Based on those decisions the RfC will either be rejected or added to the list for the next CAB meeting.

Why is the CAB involved? The CAB has multiple votes which see the RfC from different angles. A diversified opinion makes sure the change is useful and can/will be implemented without any problems for the system.

Once the CAB and the coordinator give the OK for the RfC. Aside from that the costs of the implementation are also weighed. Based on those decisions the RfC will either be rejected or added to the list. When approved the release and change coordinator will start working together on implementing the change successfully.

Personal tools