Types Of Service Providers

Internal Service Provider: It is also referred to as ‘Type I’ service provider. In this various business functions are owned by the business unit they provide services to. Strategy to govern or manage them is dependent on the business unit which owns them.

In the above figure, business functions IT, Finance and HR are embedded in ‘Business Unit’. These business functions are dedicated to the business unit only. Each of these functions caters to a specific need of the business and is the overhead for the unit they serve. They predominantly act as cost centre. The basic financial approach in managing them is to recover the cost.

Key concern for Internal Service Provider is that it can easily be outsourced to an External Service Provider or centralised as Shared Service Provider.

Shared Service Provider: It is also referred to as ‘Type II’ service provider. In this various business functions are owned by the Organization and thus shared across various business units. Strategy to govern or manage them is dependent on the organization. It provides a better economy of operations than Internal Service Provider. It should be noted that Shared Service Provider supports the Organization in gaining a competitive edge but itself is not the core business of the organization they serve.

In above figure, business functions IT, Finance and HR are at the corporate level. These business functions are shared by multiple business units – Business Unit A, Business Unit B and Business Unit C. Each of these functions caters to a specific need of the organization. They may act as a cost centre or profit centre depending upon the organization’s strategy. Generally they tend to recover cost as per the on-going rate in the market.

Key concern for Shared Service Provider is that it can easily be outsourced to an External Service Provider.

External Service Provider: It is also referred to as ‘Type III’ service provider. In this Organizations outsource their service need to one or more service providers, thus transferring the cost and risk associated with provisioning of the service to the service provider. It allows the organizations to focus on their core business. Since External Service Providers caters to certain services in which they have expertise in, they provide better service quality and economical services. 

In above figure, Service Provider A, B and C are External Service Providers having expertise in e-Mail, Payroll and HR services. They provide their services to multiple customers. They act as a profit centre. They enter into a contract for a certain period of time with their customers. They face severe competition and hence they have to provide better service quality at a lower price in order to retain their customers.

Since these services are not in the internal control of organizations, it poses a higher risk in terms of security, manageability and flexibility & adaptability to effectively manage future business opportunities.

DIKW Hierarchy

DIKW Hierarchy represents the relationship between data, information knowledge and wisdom. It is also referred to as Wisdom Hierarchy, Knowledge Hierarchy, Information Hierarchy and Knowledge Pyramid.

Besides the four components represented by the above figure, it is worthwhile to note the basis of origin of ‘data’. We can term this component as ‘Reality’. It is the entities that are available in any given environment. These are the raw facts and are in the raw form. These entities when collected or measured form ‘Data’. Data has attributes. The attribute could be codes that can be used for identification, representation, recording or storing a data.

‘Information’ is obtained by processing the Data. The processing could be organizing, sorting, establishing relationship etc. Thus, Information has context. In other words we can say that Information is created when relationship and connections between the Data is analysed. It helps in ‘knowing’ the data, i.e. answering the simple questions based on – who, what, when and where. Way of processing Data to obtain the Information is based on the target audience.

When Information is processed by virtue of being refined, reformatted, grouped, etc., it leads to creation of ‘Knowledge’. Knowledge has learning. It answers “how” questions. It enables evolving ways for learning and innovation.

When knowledge is used based on the expertise of an individual, ‘Wisdom’ is created. It answers the “Why” questions. It deals with the future and related decision making.

It should also be noted that Information & Data are explicit and easily transferable whereas Knowledge & Wisdom are contextual, tacit and its transfer would need learning. Also, Wisdom is human dependent and based on individual’s judgement.

For basic understanding flow happens from Data to Information to Knowledge to Wisdom, but practically this flow is recursive. It can be argued that knowledge is required to know what data to collect and how to collect it or what information to process. This makes the model recursive. 

Preparing A RACI Matrix

Following are the steps that should be performed while preparing a RACI matrix:

STEP 1: Identification:

a) Identify and list all the activities or processes that are in scope of the RACI definition exercise.

b) Identify or define and list all functional roles that are or could be required for performing the identified activities or processes.

STEP 2: Definition:

Conduct meetings with all identified functional roles and assign RACI codes for each listed activity or process. Draft RACI matrix is prepared.

STEP 3: Verification:

a) Identify gaps or overlaps in the draft matrix and take steps to eliminate the same.

b) Distribute RACI matrix to concerned functional roles for their review and feedback.

c)  Incorporate the feedbacks provided.

STEP 4: Control:

Ensure that allocations as defined in RACI are being followed. This can be ensured by performing periodic audits.

RACI Matrix

RACI is a matrix that is used to assign and describe responsibilities of roles in completing any task or activity.

RACI stand for Responsible Accountable Consulted Informed.

Responsible: Role that does the work in order to complete a task or activity. Typically one role will be Responsible for an activity.

Accountable: Role that is the final approving authority and has the overall accountability for completion of an activity. They approve the work that Responsible does. There must be only one Accountable specified for a task or activity.

Consulted: Role that is consulted for seeking opinion or advice on a task or an activity. There is a two-way communication with this role.

Informed: Role that is kept up-to-date on progress or completion of a task or activity. There is a one-way communication with this role.

SAMPLE RACI MATRIX:

	Role A	Role B	Role C	Role D	Role E
Activity 1	AR	C	I
Activity 2	A	R	I	I	C
Activity 3	I	C	C	AR
Activity 4		AR	C		I
Activity 5	I	I	AR	C	I

 EXTENDED FORMS OF RACI

a) RASCI:  Extended form of RACI where ‘S’ stands for Supportive or Support. It is the role that provides support or assists in implementing the task or activity.

b) RACI - VS:  Extended form of RACI where ‘V’ stands for Verifies and ‘S’ stands for Sign-off.

Verifies: Role that checks if the acceptance criteria has been met.

Signs-Off: Role that approves the Verify decision and gives the final sign-off for handing over the task or activity.

C) RACI - O:  Extended form of RACI where ‘O’ stands for Omitted. It specifies that that role is not part of the task.

Deming Cycle

Deming Cycle or PDCA was made popular by Dr. W. Edwards Deming and hence it derives its name.  It consists of following four phases:

• Plan: During this phase objectives and processes (new or improved) are established which are necessary for achieving the desired output. Expected results are also documented.

• Do: New processes are implemented.

• Check: New processes are measured and results are compared against the expected results. This helps in identifying the differences, if any.

• Act: These differences are analysed to identify the cause. Steps to eradicate the differences are performed.

Cycle is repeated till the desired output is achieved.  Once desired output is achieved, process reaches a new maturity level which provides a new baseline for further improvement.

PDCA cycle can be compared with project management as well – Project Planning fitting into ‘Plan’, Project Implementation into ‘Do’, Project Audit – ‘Check’ and Project Control Actions – ‘Act’

3 Layers of Management

Often we refer to ITIL V3 having processes for Strategic, Tactical and Operational layers of management. Let us understand what these layers mean.

Strategic Layer: It is the highest level of organizational management and consists of roles responsible for managing the company. This is the decision making layer of the organization that is responsible for giving direction to the organization by virtue of the strategies they define. It provides the vision and mission, i.e. long term organizational goals. They perform operations to manage the profitability of the company.

Tactical Layer: This layer is responsible for managing the operational layer and showing them the direction to deliver according to the organization’s goals. They convert the organizational goals into short term targets or milestones. They enable the operational layer to understand how they can contribute towards achieving the vision. They monitor the operational layer and provide regular updates and management reports to strategic layer.

Operational Layer: This is the layer that works on the floor and delivers assigned targets or goals in order to meet the organization’s vision. They perform activities to complete the tasks assigned to them by the tactical layer.

Is ITIL For Your Organization?

Often people think “Is ITIL relevant for my organisation?”  The answer is that ITIL is relevant to all organizations that use IT. Today every organization is dependent on IT. Thus, ITIL is applicable to organizations across the following domains:

Airlines	Banking	Consulting
Defence	Education	Finance
Government	Healthcare	Insurance
Legal (LPOs)	Manufacturing	Media
Outsourcers	Publication	Retail
Service Providers	Tourism	Others…

Why An Organization Needs ITIL?

With globalization and increasing dependency of business on IT, the IT environment is getting even more complex day-by-day. Availability of IT services supporting the business is very critical for the survival of organizations. Thus, managing these services gains utmost importance and hence ITSM. Since ITIL is the most widely accepted framework for ITSM, it has to be adopted by IT support teams to ensure that quality and continuously improving & evolving IT services are available to support the changing business needs. It provides a structured approach to service provisioning alongside embedding discipline in the IT organization. This also helps in proactive risk assessment and thus its mitigation.

ITIL helps in developing a service culture in the organization. This ensures that a clear communication channel is established between the business and IT.

Need of ITSM

Overall complexity of IT is evolving with increased global scope and competition. Business is demanding more value even from their internal IT organizations. Besides, dependency of business on IT is increasing everyday which has made IT critical for success of the business. This has resulted in a shift of focus. In a number of organizations, IT is now being considered as a ‘Profit Centre’ instead of ‘Cost Centre’.

Thus, to ensure that IT is constantly able to deliver value effectively and efficiently, ITSM is the key. Today, every organization is investing in ITSM, trying to develop it as their capability and as a strategic asset.

IT Service Management

IT Service Management or ITSM is the ‘subject’ of ITIL.  Before focusing on ITSM, it is important for us to understand the meaning of Service.

Service: Service is the mean of delivering value to the customer. It assists in achieving the results that customer* wants. It takes away the associated costs and risks from the customer, i.e. ownership of the cost and risks is transferred from customer to service provider**.

Key characteristics of a service are:

• It enhances performance of the task it assists in delivering
• It facilitates achievement of the outcomes desired by the customer
• It reduces the effect of constraints that exists in service delivery

ITSM is the discipline responsible for management of IT services and systems. It includes set of processes and functions that are used to provide these services. It can be said to be the set of capabilities that an organization has which provides value to the customers in the form of services.

Let us consider the following example:

Couple of years back one of the banking institutions in India outsourced its entire IT infrastructure to one of the leading IT Service Providers. Charging was based on number of transactions that the bank performs. Cost of the entire IT infrastructure and its day-to-day maintenance was to be borne by the service provider.

Service provided by the service provider was ‘IT infrastructure provisioning’. This service facilitated the transactional requirements of the bank. The bank did not own the IT infrastructure or any risk associated with it. Thus, by availing the service, bank transferred the ownership of both cost and risk to the service provider.

---

* Customer is the one who pays for a service.

** Service provider is the organization or unit that provides the service. They can be internal (internal service provider) or external (external service provider) to the customer’s organization. 

Policy Series - 4.: Change Management Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy Change is defined as addition, modification or removal of any Configuration Item (CI) or its attributes.

SCOPE:

This policy is applicable to the entire change management life cycle as described in Change Management process document. Thus, the scope encompasses:

•        Business/IT services & CIs

•        Documents (Process, policy, contracts, manuals, SOPs, etc.)

•        Other CIs

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Change Management process will be defined and adopted by all business units/functions

• Emergency Change Management sub-process will be defined and followed to address major changes

• Staff should be trained to ensure that a common understanding on change and emergency change management prevails across the organization

• Roles and responsibilities shall be defined and communicated for effective Change Management

• Change Manager will be the single focal point for coordinating all changes

• Change requests should be classified, recorded, validated, accepted and prioritized

• All changes should be recorded in the change management tool

• Change Manager will allocate a priority for every RFC based on the impact and urgency; This priority rating should be used to decide which changes should be discussed and assessed first, either by Change Management or by the Change Advisory Board (CAB)

• Testing should be successfully completed before change is authorized/approved for implementation by Change Manager; Emergency Changes require Emergency Change Advisory Board approval for this exception but needs as much testing as possible before implementation

• All Changes to the production environment should be made within agreed Change windows;  Any exceptions will be agreed and communicated via a Projected Service Outage (PSO)

• All changes will be assessed for performance, risk and resources needed to implement the change

• Back out or roll back plan is mandatory for all changes including emergency changes

• Forward Schedule of Change (FSC) should be communicated to the users; Change Manager should inform Service Desk for effective communication of FSC

• Post Implementation Review is mandatory for all changes; Standard changes is an exception to this

• Any addition of service to the standard change list should be approved by CAB 

• Any unauthorized change should be considered violation of this policy

• Progress of all changes should be monitored by Change Manager till closure of RFC

• Change Management performance shall be reported and reviewed periodically

• Continual Service Improvement (CSI) initiatives should be taken up by Change Management 

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE:

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy

• Change Manager(s) and Quality Leads are responsible to drive adherence to the policy and process

• Accountability to adherence to policy and process lies with individual staff

• Change Management process document

• Release & Deployment Management policy

• Request Fulfillment policy

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

REFERENCES:

Following documents should be referred to along with this policy document:

Policy Series - 3.: Request Fulfillment Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy Service Request is defined as end user requests that an IT organization is required to fulfill.

SCOPE:

This policy is applicable to the entire Request Fulfillment life cycle as described in Request Fulfillment process document. The scope encompasses entire ICT infrastructure of the organization. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Request Fulfillment process will be defined and adopted by the entire organization
• Staff should be trained to ensure that a common understanding on service request and request fulfillment prevails across the entire organization
• Roles and responsibilities shall be defined and communicated for effective Request Fulfillment
• Service desk should be the Single Point of Contact for the users; Ownership of service requests will rest with the Service Desk
• Single Request Fulfillment tool shall be used across the organization; All service requests should be recorded using this tool including:
• Call to service desk
• e-Mails to service desk
• Service desk should ensure the correct logging of service requests (incident tickets should not be logged as an service request)
• Service desk should correctly categorize all service requests
• Priority should be assigned to every service request based on the impact and urgency (Impact - urgency matrix and critical services list should be referred to)
• All service requests shall be provisioned/fulfilled only after required approvals are obtained
• All service requests that has impact on any CI should be fulfilled/provisioned post change approval; Change Management process should be followed at all times in such cases; Tagging of ticket to CI shall be done in all such cases
• Requests not auto-assigned by the tool has to be routed by the Service Desk to relevant support group
• In case the service request is assigned to a support group and not assigned to the individual support engineer, the accountability for ticket assignment lies with both the team/shift lead of that support group as well as with support engineers
• Progress of all service requests should be monitored by service desk and record updated on the progress till resolution and closure
• User should be updated regarding the progress of the service request as per the communication matrix agreed upon till closure of the ticket
• Escalation matrix should be clearly defined and followed
• All SLAs for Request Fulfillment including the ones related to service desk (average wait time, average hold time, etc.) as agreed with the customer should be adhered to
• Customer should be informed of any breach or potential breach of service levels
• Priority of service requests should be upgraded or downgraded only post approval from the concerned approval authority
• Request Fulfillment process performance shall be reported and reviewed periodically
• Continual Service Improvement initiatives should be taken up by Request Fulfillment

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Request Fulfillment Managers, Service Desk Leads and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

REFERENCES

Following documents should be referred to along with this policy document:

• Request Fulfillment process document
• Change Management policy
• Service Level Management policy

Policy Series - 2.: Problem Management Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy problem is defined as underlying unknown root cause of one or more incidents or potential incidents.

SCOPE:

This policy is applicable to the entire problem management life cycle as described in Problem Management process document. The scope encompasses entire ICT infrastructure of the organization. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Problem Management process will be defined and adopted by the entire organization.
• Staff should be trained to ensure that a common understand on problem management prevails across the organization.
• Roles and responsibilities shall be defined and communicated for effective problem management
• All problems should be recorded in the problem logging tool.
• All problems should be updated on progress till resolution and closure.
• Problem ticket should be created for all incidents that do not have a match in the KEDB.
• Problem ticket should be created for all major incidents.
• Proactive problem management should be driven as documented in the problem management process document and create proactive problem tickets. Proactive analysis of repeat incidents should be done to identify and reduce potential problems.
• In case permanent fix is unavailable, workaround should be provided wherever possible to minimize business impact.
• Problem tickets should be correctly logged, categorize and prioritized.
• Priority should be assigned to every problem based on the impact and urgency.
• All problems should be linked to a CI.
• Any corrective actions should be controlled through the Change Management process.
• Known errors should be updated in KEDB for every problem for which resolution is available.
• Problem Management performance shall be reported and reviewed periodically.
• There should be defined reports and review schedules for the closed and pending problems.
• Continual Service Improvement initiatives should be taken up by Problem Management.

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Problem Managers and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

REFERENCES

Following documents should be referred to along with this policy document:

• Problem Management process document
• Change Management policy

Policy Series - 1: Incident Management Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy incident is defined as:

• Unplanned interruption of any IT Service
• Degradation in quality of any IT Service
• Failure of any CI (configuration item) that has not yet affected a service

SCOPE:

This policy is applicable to the entire incident management life cycle as described in Incident Management process document. It includes all the IT services and underlying infrastructure & applications used to deliver the business services. Thus, the scope encompasses entire ICT infrastructure which includes servers (physical & virtual), applications, software, network components, user end devices, etc. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Incident Management process will be defined and adopted by the entire organization
• Major Incident Management sub-process will be defined and followed to address major incidents
• Staff should be trained to ensure that a common understand on incident and major incident management prevails across the entire organization
• Roles and responsibilities shall be defined and communicated for effective incident and Major Incident Management
• Service desk should be the Single Point of Contact for the users
• All incidents should be recorded in the incident logging tool including:
• Call to service desk
• e-Mails to service desk
• Service desk should ensure the correct logging of incident tickets (service request should not be logged as an incident)
• Service desk should correctly categorize all incidents
• Priority should be assigned to every incident based on the impact and urgency (Impact - urgency matrix and critical services list should be referred to)
• All incidents should be linked to a CI
• Tickets not auto-assigned by the tool has to be routed by the Service Desk to relevant support group
• In case the ticket is assigned to a support group and not assigned to the individual support engineer, the accountability to assign the ticket not only lies with the team/shift lead of that support group but also on the support engineers
• Progress of all incidents should be monitored by service desk and incident record updated on the progress till resolution and closure
• Service desk should immediately inform Major Incident Manager in case of major incidents in order to ensure that Major Incident Management sub-process is triggered
• User should be updated regarding the progress of the incident as per the communication matrix agreed upon till closure of the incident
• Roles and Responsibilities should be clearly defined for escalations
• Service desk should ensure escalation of incidents as per the escalation matrix
• All SLAs for incident management including the ones related to service desk (average wait time, average hold time, etc.) as agreed with the customer should be adhered to
• Customer should be informed of any breach or potential breach of service levels 
• Known errors should be made available for effective Incident Management
• Corrective actions should be controlled through the Change Management process
• Incident priority should be upgraded or downgraded only post approval for the concerned approval authority as documented in the process document
• Incident Management performance shall be reported and reviewed periodically
• Continual Service Improvement initiatives should be taken up by Incident Management 

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Incident Managers, Major Incident Managers, Service Desk Leads and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

EXEMPTION:

N/A.

REFERENCES

Following documents should be referred to along with this policy document:

• Incident Management process document
• Problem Management policy
• Change Management policy
• Service Level Management policy
• Availability Management policy