Abstract

Information Technology is a thing that can’t be missed in this modern

world. In this global era, world demands every things solved as simple as

possible, as fast as possible with less error or failure occurs. That’s why

scientist discovers the great technology that solved those problems.

Effectiveness and efficiency that IT offers are great and gives so much benefit.

Any company especially the big one can’t endure to use IT nowadays.

Developing Information Technology is not an easy task, even tougher for the

company that has a complicated business flow in it. In here ITIL (Information

Technology Infrastructure Library) taking a big part in being the guidance of

full life cycle of defining, developing, managing, delivering, and improving IT

services. ITIL structured into 5 core books: service strategy, service design,

service transition, service operation and continual service improvement.

Top level user such as business manager and IT professional using framework

called COBIT (Control objectives for information and related Technology) for

understand, assessing and managing the risk together with the benefits

associated with information and related IT.

CHAPTER I

INTRODUCTION

1.1 Background

Information Technology is a thing that can’t be missed in this

modern world. Effectiveness and efficiency that IT offers are great and

gives so much benefit. Any company especially the big one can’t

endure to use IT nowadays.

In order to make the structure of IT operates really well, many of

company use ITIL (Information Technology Infrastructure Library),

which is a set of document a set of documents which defines best

practices and accepted techniques in Information Technology

community. Also COBIT (Control objectives for information and

related technology) that helps top tier user (managers, IT professionals

and assurance professionals) develop IT itself.

In completion of this paper, writer using literature study as their

methodology of writing the paper. Also looking for journals and

website surfing related to topics.

Writer hopes that after this completion of paper, reader can

understand what is ITIL (Information Technology Infrastructure

Library), COBIT (Control objectives for information and related

technology), and their differences.

1.2 Scope

1.2.1 Scope Topic

Topic that will be discussed in this paper is:

i. Implementation of Information Technology Infrastructure Library.

ii. Implementation of Control Objective for Information and Related

Technology.

iii.Differences between Information Technology Infrastructure Library

and Control Objective for Information and Related Technology.

1.3 Goals and Benefits

1.3.1 Goals

Purpose of creating this paper is to meet the requirements for

doing thesis and to obtain value and grade for this course

(“TopikTopikLanjutanSistemInformasi”).

1.3.2 Benefit

The benefits of this paper are:

Reader understands about Information Technology Infrastructure

Library and Control Objective for Information and Related

Technology.

Reader can understand the differences between Information

Technology Infrastructure Library and Control Objective for

Information and Related Technology.

Reader understands how to implement Information Technology

Infrastructure Library and Control Objective for Information and

Related Technology.

1.4 Research Methodology

Literature study is a methodology that searching for relevant

theory or references which support the case or problem. References can

be found by using guide books, research and journal in internet.

These references consist of:

- Definition of Information Technology Infrastructure Library.

- Definition of Control Objective for Information and Related

Technology.

- Differences between Information Technology Infrastructure Library

and Control Objective for Information and Related Technology.

The purpose is to be the basic theory or guidance in completion of

problems and cases discussed in this thesis.

CHAPTER II

THEORETICAL BASIS

2.1 Definition of Information System

According to (Satzinger, Jackson, & Burd, 2004, p. 6), A system is a

collection of interrelated components that function together to achieve some

outcome.

According to (Bennett, Mcrobb, & Farmer, 2006, p. 657), a system is

an abstraction of a complex interacting set of elements, for which it is

possible to identify a boundary, an environment, inputs and outputs, a control

mechanism and some process or transformation that the system achieves.

According to, system is a group of interrelated components, and work

together toward a common goal by accepting input and output in the process

of transformation or change management.

Based on the definitions above, we assume that system is interrelated

activities and components that are integrated and working together to achieve

some goals by accepting input and resulting in output in the process of change

management.

2.2 Definition of Information Technology

According to R.Kelly Rainer and Casey G.Cegielski ( Introduction to

Information system p7) Information technology is any computer-based tool

that people use to work with information and to support the information and

information-processing needs of an organization. Although these are distinct

terms, in practice they are typically used interchangeably.

2.3 Definition of IT Infrastructure

According to R.Kelly Rainer and Casey G.Cegielski ( Introduction to

Information system p11) IT infrastructure consists of the physical facilities,

IT components, IT services, and IT personell that support the entire

organization. IT components are the computer hardware, software, and

communications technologies that provide the foundation for all of an

organization’s information system. The IT personnel use IT components to

produce IT services, which include data management, system development,

and security concern.

2.4 Definition of IT infrastucture Library

ITIL is the most widely adopted approach for IT Service Management

in the world. It provides a practical, no-nonsense framework for identifying,

planning, delivering and supporting IT services to the business.

ITIL advocates that IT services must be aligned to the needs of the

business and underpin the core business processes. It provides guidance to

organizations 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 which provide a systematic and professional approach to the

management of IT services, enabling organizations to deliver appropriate

services and continually ensure they are meeting business goals and

delivering benefits.

The five core guides 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

into operation and finally, on to the monitoring and improvement phase of the

service.

Adopting ITIL can offer users a huge range of benefits that include:

Improved IT services

Reduced costs

Improved customer satisfaction through a more professional approach to

service delivery

Improved productivity

Improved use of skills and experience

Improved delivery of third party service (ITIL)

2.5 Definition of Service

Services are a means of delivering value to customers by facilitating

outcomes customers want to achieve, without the ownership of specific costs

and risks (Service Strategy 2011).

2.6 Definition of Control Objective for Information and Related Technology

According to Koen Brand, Harry Boonen ( It Governance Based on

CobiT 4.1: A Management Guide p21) COBIT ( Control objectives for

information and related technology) is a model designed to control the IT

function. This model was originally developed by the Information System

Audit and control foundation (ISACF).

COBIT support IT governance by providing a comprehensive

description of the control objectives for IT processes and by offering the

possibility of examining the maturity of these processes.

It helps in understanding, assessing and managing the risk together with

the benefits associated with information and related IT. COBIT provides an

IT governance instrument that allow managers to bridge the gap with respect

to control requirements, Information system & Information Technology

issues and business risk in order to communicate that level of control to

stakeholders. It enables the development of clear policy and good practice for

the control of IT throughout organization. (Brand & Boonen, 2007)

CHAPTER III

DISCUSSION

3.1 Example of ITIL Implementation

3.1.1 Process Implementation

3.1.1.1 Objective

The objective of this document is to provide a template for developing

process implementation plans that will be usable across a wide range of

diverse organizations. The guidelines within this document are designed for

use as a general roadmap or plan, for any major process development or re-

engineering project.

3.1.1.2 Program Management

Many organizations that undertake programs to improve their core

business processes and service delivery capabilities experience the overriding

frustration of failure, or at best minor successes in the place of their ambitious

goals. The failure of many improvement initiatives can be directly attributed

to management’s lack of understanding that by implementing processes

within traditional hierarchal organizations they are in reality reengineering

and changing a large part of the IT business culture and accountability

structure.

3.1.2 Process Implementation Projects

As part our consulting engagement model, Pink follows a standardized

and scalable approach for implementing ITIL processes. This model begins

with the creation of a core process design team and the identification of a

larger group of stakeholders involved in review, feedback and signoff

activities. A typical project plan includes staged milestones and project

activities, which consider the requirements and dependence of process,

people, and technology.

The process implementation model has been designed to facilitate a

greater level of success for project completion and process embedding. The

high-level project model demonstrates the integration and sequence of

activities for a typical process implementation project.

3.1.2.1 Process, People And Technology (The Integrated Project Plan)

To ensure a greater level of success for project completion and process

embedding, organizations need to take a holistic view of process

implementation projects. Serious consideration needs to be given to the

development and mapping of the three basic elements of any quality

improvement initiative; process, people and technology. To concentrate on

one area to the detriment of the other can jeopardize the success of the

project. The following model demonstrates the integration and sequence of

activities for a typical process implementation project. As can be seen from

the model above, process implementation is a complex, integrated and multi-

faceted set of activities and as such warrants the use of a formal project

methodology such as PRINCE2 (Projects in Changing Environments). The

recommended formal role established to manage process implementation

programs is discussed under the Process Roles and Responsibilities section

below.

The implementation of each ITIL process follows the model depicted in

Figure 2 above. The scope of this document covers the development of IT

service management processes. The Tool Selection, Quality Assurance, and

Development of Management Information are handled in other internal

documents.

Project Timelines

Based on Pink’s experience, a typical project in a single location will

take between four and six months to complete based on the model illustrated

above. The reason for this duration is related to several factors:

1) Internal resources are typically assigned to the project in a part-time

capacity with at best, two to three days a week being made available for

status and design meetings as well as the creation of deliverables.

2) With the understanding that process implementation is fundamentally

about organizational change, it is necessary to build activities into the

project timelines that are focused on receiving feedback and signoff from

process stakeholders. Actual design and creation of deliverables

constitutes approximately a third of the time required to implement a re-

engineered process. Most organizations that choose to discount consensus

building will find that the processes designed without the involvement

from stakeholders will be highly resisted and most likely fail.

3) Due to the complexities of running a process implementation initiative

with strong cross-departmental or regional participation, it is necessary to

staff the core process team with diverse members from all stakeholder

groups. The added expense and time involved in travel and logistics

around these projects requires a creative use of physical as well as virtual

participation in relationship to design and feedback activities.

Coordinating the logistics and tools required to facilitate the involvement

can add several months to the duration of the project overall. Typically a

core team will be brought together more frequently at the beginning of a

project and can then work in a more virtual mode as the project progresses.

In order to meet these time lines the following assumptions have been

made:

Executive Sponsorship and Process Owners allocated.

An approved budget for internal and external resources over the twelve

month period.

Funds are made available for tool selection and customization according

to the ITIL processes being designed and implemented.

There is a political will to define new ongoing roles for process

management and coordination.

Small core teams can be constructed from internal resources Core team

members can be dedicated to their perspective projects at a minimum of

three days per week.

Expected Project Deliverables

Documented and formalized process and procedures Documented and

formalized process policies Automation requirements defined and customized

within technology availability and constraints Documented and defined

awareness campaign and training activities for process implementation.

Documented and formalized management reports and key performance

indicators Documented and formalized ongoing roles and responsibilities for

the management and continued ownership and improvement of the process.

3.1.2.2 Implementation Roles

The following section represents the typical roles required for a process

implementation program:

1) Process Owner

The initial planning phase of an ITIL program must include the

establishment of the role of process owner. This key role is accountable for

the overall quality of the process and oversees the management of, and

organizational compliance to the process flows, procedures, models,

policies, and technologies associated with the IT business process.

The process owner performs the essential role of process champion,

design lead, advocate, and coach. Typically, a process owner should be a

senior level manager with credibility, influence and authority across the

various areas impacted by the activities of the process. The process owner

is required to have the ability to influence and assure compliance to the

policies and procedures put in place across the cultural and departmental

silos of the IT organization.

A process owner’s job is not necessarily to do the hands on process

re-engineering but to ensure that it gets done. They typically assemble the

project team, obtain the resources that the team requires, protect the team

from internal politics, and work to gain cooperation of the other executives

and managers whose functional groups are involved in the process. This

role’s responsibilities do not end with the successful embedding of a new

process. In a process-oriented company, the Process Owner remains

responsible for the integrity, communication, functionality, performance,

compliance and business relevance of the process.

For global projects it is critical to implement tiered governance and

process ownership model that provides the flexibility and needed structure

to maintain process consistency across the various regions.

2) Core Process Team

Each core process team would be consisting of between four and six

members, which will include the process owner in addition to cross-

functional representatives from key departments, functional groups and

regions within the organization. The make-up and composition of this

team is a critical success factor in the overall success of the design,

acceptance and effective implementation of the processes. In a global

initiative, a regional representative will typically assume the role of

process manager or regional process owner and be responsible for further

coordinating and defining the process procedures, tool customizations and

implementation strategies required to deploy the process in their specific

region. The core process team members should expect to spend at least

two to three days a week on the design and deliverable creation activities

defined in the projects.

The majority of the actual work of process development and

reengineering is the job of the core process team. They will develop the

high-level process model based on the ITIL framework and examples of

existing within Atlas or internal organizational documents.

3) Stakeholder Groups And Subject Matter Experts

In order to maintain a control on cost but yet handle the cross-

functional requirements for feedback, expertise, and sign off, additional

stakeholder and subject matter experts will be defined and brought into the

project at key times. The project work assigned to these individuals should

not require significant changes in the volume of daily activities and

workload, but will add time to the duration of the project. It is important to

re-iterate that the inclusion of these roles and activities in the project is

critical for addressing political constraints and for ensuring the long-term

success of the process initiative.

4) Internal and External Process Advisors

Process owners, project managers, and the core process teams focus

is on the specific reengineering activities being carried out in the

organization. The process advisor role is to provide strategic, tactical, and

operational knowledge transfer at the right place, at the right time, and in

the right quantity in order to facilitate the activities of the entire project.

The process advisor has the responsibility of enabling and supporting the

process owners, project manager, and the process teams with the correct

knowledge, methods, and tools.

The process advisor also brings to the project, the experience of past

implementations and is equipped with in-depth knowledge of best practice,

time saving strategies and templates. This role does not have to be a

dedicated to the project 100%. Typically, the process advisor expends the

majority of their efforts at the start of the project conducting training and

awareness seminars to ensure the project begins well and is equipped with

the knowledge required. From that point forward the process advisor

interacts with the project at key milestones.

The process improvement program will be greatly assisted by the

correct and timely use of both internal and external advisors.

3.1.2.3 Pink Elephant Consulting Roles

Pink Elephant provides several defined roles and resources for

implementation projects. These roles have been designed to provide the right

level of experience and advice to the organization and the process design

teams. A typical implementation project will have a Managing Consultant

overseeing the overall relationship with the organizational Sponsors and

Process Owners.

A Senior Consultant provides subject matter expertise and provides an

advisor role to the process owner and process design teams. This role will

provide most of the knowledge transfer in the beginning phases of the project

and then will work with the team on a periodic and decreasing basis as the

project matures in its lifecycle.

In addition, Pink Elephant can provide hands on assistance with

deliverables alongside the process team members. This role is typically

handled by a Pink Elephant process consultant and can be shared between

multiple process projects.

The following table provides a visual representation of the model used

in our standard engagement activities.

3.1.2.4 High Level Process Model Development

The first phase of the project plan is the development of the high-level

process model. The high-level process model is critical to understand the

drivers for staffing requirements and tool selection. In its most elemental

form, the high level process model maps the key process steps in a sequential

flowchart design as shown in figure below:

As the figure below illustrates, this high-level process model will map

the flow and life cycle of inputs entering the process, through to the output of

desired results. Through the identification of process activities and process

integration points, decisions can be made according to staff roles, skills, and

competencies. Also, areas for automation will become clear as detail is

developed within the activities.

The goal of this phase is to establish the basic requirements that will set

the tone and the direction of all future work. The high-level process model

describes the following components:

1) What is the objective of the process and how does it integrate with other

processes?

2) What are the activities of the process and how do they flow from a

sequential and parallel perspective?

3) What decision-points exist within the process and what information is

required to make the decision?

4) Which are the roles that interact in the process and what do they do? These

points can be summarized into the following statements.

What is it and what is the point? (i.e. What is the purpose of the process

and its role in the framework) What happens when? Who gets to do it?

It is absolutely critical to establish these elements and gain political

consensus on these points in the high-level process design phase, before

moving the project forward. Ineffective consensus making at this point, will

result in disagreements and excessive debate over basic decision on what,

when and who, during the definition of policies, procedures and deployment

training.

3.1.3 Process Embedding Strategy

When it comes time to embed a process within an organization the

sequence and timing of activities plays an important role in insuring the

success and acceptance of the new processes, procedures, and policies.

The critical inputs for this stage of the project are as follows:

High Level Process Flow

Detailed Procedures and Work Instructions

Guidelines/Support and Policy Documents

Correctly installed and configured tool

The right skill level and knowledge of staff

Management Commitment

Supporting staff commitment to authority matrix

Customer awareness and acceptance

A constraint or limitation on any of the above points could indicate a

potential problem with the embedding phase of the project.

3.1.3.1 Process Workshops / Training

This phase in process embedding uses the output from the High Level

Modeling and Detailed Design Phase, and makes us of user guides, procedure

guides, Policy Documents and other training materials to communicate the

new “Way We Work”. The goal of this activity is to insure that roles and

responsibilities are clearly understood, procedures followed and policy

adherence is understood to be a requirement as the IT organization moves

forward in a Service Management centered and Process based work culture.

Process workshop and training activities are described below:

1) Develop Lesson Plans

Define target groups; for example:

o Service Desk

o Team Leads

o Management

o 2nd and 3rd level support

Set Objectives

Develop Time frames

Develop Workshop/Training

Develop specialized presentations

Develop handouts and documentation

Develop Marketing Material

2) Schedule Workshop And Process Embedding Date

Timing is the key when scheduling the workshops. Ideally, the

training should be delivered just prior to going live with the new

procedures. It is always a best practice to go live in a limited pilot location

to minimize any potential impact to the organization.

3) Coaching Period

After the process start-date, coaching workshops should be offered

to prepare the staff to use the new procedures. This coaching serves

several important purposes. First, the coaching will function in a quality

audit capacity to ensure that the new process and procedures are being

adhered to. Second, during this period process functionality will be

examined to provide information for the first review. In the case of a pilot

project, improvement adjustments can be made for the full implementation

of the new process before organization wide application.

4) Initial Process Review And Adjustment

Following the two-weeks of process coaching and monitoring, an

initial review should be held on the functionality of the new process. If

bottlenecks or improvement actions can be identified, the process and

procedures should be modified and republished.

3.1.3.2 Detailed Activities (Project Check List)

These are the Project Check List:

Process design and implementation plan

Terms of reference and statement of requirement

Feasibility study

Project Brief (high level project definition)

Project Initiation

Document (detailed description of Work Break Down and Product Break

Down)

Appoint a Process Owner

Define a mission statement

Set objectives

Agree on scope, roles and responsibilities

Review experiences, tools and processes at similar sites

Risk analysis

Product selection and overall design

Mount awareness campaign

Recruit and train staff

Development and validation

Pilot Project

Pilot Review

Implementation

Post implementation review

On-going management and operation

Efficiency and effectiveness reviews

Audit

People Involved

Customers and IT staff

Appointment of Process Owners

Support staff Suppliers, contractors and vendors

Consultants

Project teams

Auditors

Awareness Campaign

Sponsorship Communication Plan

Newsletters

Workshops

Bulletins

Seminars

Presentations

Marketing Information

External education

Systems Implementation Activities

Acquire and install equipment

Customize tools

Test system

Create hardware and software inventories

Prepare documentation

Train staff

Carry out acceptance testing

Post implementation review and audit

Support Tools

Automated wherever possible

Integrated with other SM processes

Provide accurate and timely information

Post Implementation and Audit

Reconcile requirements with reality – on time, on budget, deliverables met

Compare activity levels with forecasts

Assess human element

Review effectiveness and efficiency

Identify benefits gained

Reconcile actual and planned roles

Review overall project – how well did it go?

Prepare review reports

Quality management (assurance and control)

Other Considerations

Finance and administration

Human Resources (embed expectations for modified responsibilities into

performance reviews)

Suppliers, contractors and vendors

Environment, accommodation and equipment

Security

Operations

Networks

3.1.4 Evaluation of The Project

As the project draws to a close, it is important to analyses how the

project was managed and to identify lessons learned. This information can

then be used to benefit the project team as well as the organization as a

whole. An End Project Report will typically cover:

Achievement of the project’s objectives

Performance against plan (estimated time and costs versus actual)

Effect on the original plan and business case over the time of the project

Statistics on issues raised and changes made

Total impact of changes approved

Statistics on the quality of the work carried out (in relation to stated

expectations)

Lessons learned with recommendations

Post project review plan

3.1.4.1 Post Project Review

A business case will have been built based on the premise that the

project outcome will deliver benefits to the business over a period of time.

The delivery of these stated benefits needs to be assessed at a point after the

project has been completed and the process has been in operation. The post

project review is used to assess if the expected benefits have been realized as

well as to investigate if problems have arisen from use of the process.

Each of the benefits mentioned in the business case should be assessed

to see how well, if at all, it has been achieved. The post project review should

also consider any additional benefits achieved or unexpected problems that

arose. Both of which can be used to improve future business cases. If

necessary follow-up actions may be developed as, adjustments or

improvement actions are identified.

3.1.4.2 Auditing Using Quality Parameters

Process quality parameters can be seen as the "operational

thermometer" of the IT organization. Using quality parameters allows you to

determine whether processes are effective and efficient. There are two types

of quality parameters, process specific and generic:

1) Generic Quality Parameters for IT Service Management

The following parameters are in fact measurement categories that

need to be quantified before a valid assessment can be done. This task will

be easier once you have determined the required Service Levels and

Internal Service Requirements. Generic Quality parameters to consider

include:

Customer satisfaction

Staff satisfaction

Efficiency

Effectiveness

2) Process Specific Quality Parameters for IT Service Management

Process specific quality parameters are measures of the degree to

which the process delivered the desired outcome. Efficiency of key

process activities, reliability of process integration points, and specific

measure of process automation tool efficiency are examples of process

specific quality parameters.

The appropriate information will need to be collected to quantify the

quality of each parameter. The nature of the information required would

vary depending on how an organization decides to measure each aspect.

These indicators should be clearly defined at the start of the project so that

such benefits can be assessed objectively at a post project review.

3.2 Example of COBIT Implementation

This example is a real-life example of using COBIT® for IT risk

management within a global bank. COBIT was used effectively for managing

risk within the technology teams to ensure that appropriate IT governance and

IT assurance processes were utilized throughout the bank.

3.2.1 Background

The bank in the given case is a global conglomerate with operations in

more than 50 countries and with more than 125,000 employees across the

globe. The bank’s technology teams are located throughout the world to

support global lines of business. The IT teams include development centers

that are part of the bank and others that are outsourced to vendors, as well as

technology back offices that support IT infrastructure and services. The bank

had a history of multiple governance and assurance templates and processes

followed by different teams, regions and locations. Hence, the key challenge

was to create a common governance and assurance process across technology

teams.

The technology governance and assurance program was designed

through a risk management framework to ensure effective risk and control

management.

The framework was defined to address existing risk and control

management weaknesses, such as:

• Immature processes for assessing and testing compliance

• Lack of a single control repository, resulting in control duplication

• Lack of a clear, repeatable process for completing risk assessments

The new framework was expected to enable technology teams to

understand the significant operational risks and their impact on the wider

organization by:

• Addressing areas in which risks were not effectively controlled

• Allowing technology executives to demonstrate regulatory responsibilities

efficiently

• Using a common platform for reporting all regulatory requirements across

regions and countries

• Effectively reporting technology risk and control weaknesses that may

impact the business

• Implementing a standard process across regions and offices to ensure

consistency and avoid duplication of reporting

3.2.2 Use of COBIT

The governance team decided to use COBIT as a standard framework.

A team of professionals including risk, IT security and US Sarbanes Oxley

Act process experts was set up to define the processes and templates. The

team primarily worked on three areas:

• Defining a framework to use—Control objective framework (COF)

• Identifying a standard definition of ‘entities’ against which risks and

controls were to be evaluated—Key entity management model

• Identifying a risk management process—Risk and control assessment

(RCA)

Key steps in the process of developing a new risk management

framework are described in the following sections.

3.2.2.1 Defining COF

The COF was defined to link risks affecting technology offices and

industry standard best practice controls as defined by COBIT. Three

objectives were set whilst defining the COF:

• It should act as a tool to facilitate the effective assessment of risks and

controls within technology.

• It should act as a reporting framework to demonstrate how technology

satisfies reporting regulatory requirements, including those of Sarbanes-

Oxley.

• It should act as an aid to drive management assurance.

The steps in implementing COF using COBIT included:

• Identify principal risks

The principal risks of level I were defined and frozen based on

earlier information. Those identified included risks related to technology,

operations, people, legal and regulatory, financial reporting, financial

crime, brand, and change.

• Identify level II risks

The principal risk was further broken down into level II risks. As an

example, the ‘technology principal risk’ was further drilled down to:

o Inadequate design/testing of IT systems

o Unavailability of IT systems

o Lack of IT security

• Identify control objectives

For each of the level II risks, control objectives were identified using

COBIT. Figure bellow indicates the mapping of the level II risks with the

control objectives identified against each of the technology risks.

Benefit of Defining COF

Prior to implementing this framework, each entity, organization and

location had its own set of controls. COBIT helped in developing and

managing a single list of controls for each type of risk through the mapping of

needed controls to COBIT. In turn, this assisted with the attestation of each

type of risk, which provided confidence to senior executives on the reporting

and attestation process. Subsequently, a risk assessment process was

developed to define risks and controls. This helped in ensuring that adequate

controls were deployed to cover the principal risks and level II risks.

3.2.2.2 Identifying Entities for Managing Risks and Controls

The key entity management model was defined to include IT building

blocks, against which risk and control assessments were to be performed. The

IT building blocks are logically linked together for reporting purposes to

provide a risk and control assessment for all supporting services within the

purview of the technology office.

The IT building blocks were defined as:

• Process entities

These represent the processes used to support, control and

manage the IT environment. Any control issues in a process entity

would affect many IT services, e.g., change control is pervasive across

most IT services.

• Supporting services entities

Linking with process and technology entities allows for a

complete end-to-end risk and control assessment for that supporting

service, e.g., interfacing risks amongst technology entities, service-

level risks for end-to-end IT service, and integration risks (the

management of handoffs between departments).

• Technology entities

These represent the ‘traditional’ IT components, e.g., servers,

applications, networks and firewalls. The service maps and the RCA

process were used to facilitate the identification of the key technology

entities that make up each supporting service.

• Project entities

Whilst project entities have no effect on the top 20 services, it is

very important to capture any control and risk information ahead of

go-live. This will allow the target state controls for a new

development/project change to be assessed, reported and

communicated prior to go-live. Some examples of the top 20 services

include ATM connectivity and core banking application support

services.

The bank’s method for defining IT services is through an IT service

catalogue. As part of its IT service catalogue, each of the top 20 services was

identified for the supporting services that underpin it. A service map was

created for each supporting service. The service maps illustrate the

technology components that are linked together to support the end-to-end

services.

Each process entity and technology entity is distinct and can be linked

to multiple supporting services. As a result, the key entity management model

is flexible and can support expansion to additional IT services as required.

The linkage amongst entities allows risk assessments to be aggregated to

provide an end-to-end service risk profile, which is meaningful to

management and the different clusters managing the entities in the overall

service.

Benefit of Identifying Entities for Managing Risks and Controls

Prior to implementing the new risk management process, each region,

country, etc., of the bank had its own risk and control matrices. The risk and

controls evaluation was based on the understanding of each team working on

risk management within the region, and there was no focus on the ‘end

result’, i.e., the impact of risk on customer service. COBIT helped in

identifying key services that had an impact on business and customers and

kept the focus on controls. Once such risks were identified, the controls were

frozen based on the COBIT framework and were evaluated for control

effectiveness—with the clear objective of determining the impact on

customer service. This resulted in reducing the total number of incidents and

reducing the impact of incidents on customers’ and\or customer services.

3.2.2.3 Defining and Implementing the RCA Process

The process overview in figure below highlights the five steps to

performing a risk assessment. Within each of the steps, the key tasks were

identified. A series of tools/process aides was defined to assist with the

scoping, scheduling and delivery of the risk assessment, and is outlined in

figure below.

The objective in developing the common RCA process was to ensure

that the analyses of risks and controls were consistent across the teams

globally.

One of the tools was a simple Excel template defined to capture risk

and control information. The template then was frozen for use by all of the

entities. The template was defined to capture the following key information:

• Principal and level II risks

• Control objectives with reference to the COBIT controls process

• Reference to Sarbanes-Oxley control requirements

• Control owner

• Control assessment—effective, ineffective

• Actions to make the control effective

• Action closure details—action owner, target date

The templates were filled by the risk and control owner and were sent

to the central risk team for review. They were then entered into the risk

management tool to track actions for closure and reporting on open risks.

Each was tagged with:

• Entity owners—Typically the owners of the RCA

• Risk owners—The owners responsible for the risk

• Control owners—The owners responsible for maintaining control

effectiveness

• Action owners—The owners of actions defined due to ineffective controls

Benefit of Defining and Implementing the RCA Process

Through training programs, the terms ‘entity/RCA owners’, ‘risk

owners’, ‘control owners’ and ‘action owners’ were explained using a

Responsible, Accountable, Consulted and Informed (RACI) chart (see figure

below for an example). The responsibilities were also mapped in the job

descriptions and in performance evaluation criteria of the staff.

The example in figure above clarifies that, although the head of

facilities was held accountable for providing physical security on an ongoing

basis, the chief operations officer (COO) was accountable for ensuring

reporting of incidents and follow-up thereof. For any actions of employees

and vendor staff working out of the office, human resources (HR) was

consulted and informed.

3.2.2.4 Training Key Stakeholders

One of the main challenges was to explain the entire process to all of

the stakeholders with different backgrounds and understanding of risks and

controls and at various locations. The challenge was managed by creating

additional training programs at various levels. This involved:

• Creating risk experts (typically with background experience and

certifications such as Certified Information Systems Auditor™ [CISA®]

and Chartered Accountant [CA]) across the regions and offices who were

trained under a train-the-trainer program. Such resources were used to

train the stakeholders.

• Tailoring the training delivered by the risk experts to the audience. For

entity owners, a simple process overview was provided through mandatory

computer-based training. For risk and control owners, training was

detailed and included examples and tests, and it was delivered through

classrooms at different locations or through web-based training sessions.

• Offering, as part of the mandatory training program, an awareness training

session that explained the process and provided links and contacts for local

risk experts within the organization for further information and guidance.

• Arranging a workshop to disseminate the relevant information to

stakeholders; this should begin any risk assessment process. The training

resources were used to facilitate the control self-assessment (CSA) at

different locations.

• Modifying the role description and performance evaluation process to

include specific tasks for risks and controls

Benefit of Training Key Stakeholders

Due to this top-down approach, the importance of risk management was

well accepted and it was effective at all levels of the organization.

3.2.2.5 Using a Reporting Tool

A simple spreadsheet was used for maintaining a risk and control

repository for each entity. Within the entity, the risk team member used an

Excel spreadsheet for tracking risks, actions, etc. However, there was a

requirement to have a single, common database repository for maintaining

organization wide risks and controls. Hence, a tool was developed to gather

information for all entities. This helped in:

• Tracking all risks related to a ‘service’

• Centralizing a repository for all risks and control information

• Tracking all actions defined and agreed to in the RCA process

• Tracking closure of actions

• Reporting to senior executives on risks based on the specific requirements

and levels of risk

• Basing regulatory requirements reporting on a common, single database of

risks and controls

Benefit of Using a Reporting Tool

A single repository of all risks, controls and actions was used by

assurance teams in their reporting to the chief information officer (CIO) and

for tracking compliance at a high level.

3.3 Differences Between ITIL and COBIT

COBIT and ITIL are both frameworks. This means that both shares

guidance that enterprises need to get the solution they need for their each own

unique problems. None of them give implementation blueprints. Both of the

frameworks are based on a real-world experience. This means it is certain that

both will provide practical advice that will work. And lastly, both advices can

be used by any type or size of enterprise.

COBIT and ITIL are complementary frameworks. COBIT describes

what should be done, while ITIL describes how to do it. When asked about

what you need, the answer is both.

Both of them are concerning IT, but the other difference between ITIL

and COBIT is that ITIL have IT as the prime focus. ITIL emphasizes that IT

exists to support the business. The advices are relating to IT.

COBIT in the other hand, has the enterprise perspective. It has the

whole organization as the main concern. The advices are also relating to IT,

but it recognizes that it is not limited to IT.

Another comparison of COBIT and ITIL are expressed below:

COBIT

o Control Focused

o Uses IT Metrics

o Used by auditors in SOX

o Critical Success Factors

o Includes a discussion of quality

o Includes a discussion of process maturity

ITIL

o Strong concentration on processes

o Security is a very important component

o Focused on service delivery

o Has a broad base of adopting organizations with lessons learned

o Has an organization certification schema

Bottom-line, when implemented properly, both COBIT and ITIL

provide the necessary framework of good practices that enable and IT

organization to clearly align itself with the goals of the business, manage its

resources to enable those goals through the optimized delivery of information

needed by the business, and the deliver IT services and provide for their

direct support.

Here is a table explaining COBIT, ITIL, and one other framework

(CMMi) for SOX :

Another table describing COBIT, ITIL, another framework (CMMi) for

non-SOX Objectives:

CHAPTER IV

CONCLUSION

4.1 Conclusion

4.1.1 Implementation of ITIL

The objective of this document is to provide a template for developing

process implementation plans that will be usable across a wide range of

diverse organizations. Managing change and ensuring overall project success

is greatly facilitated by the development of a detailed implementation

strategy. The guidelines developed within this document are designed for use

as a framework or general methodology to consider when undertaking any

major process development or re-engineering project. The applicability and

level of detail used from this report will depend on the scale and complexity

of the project or organization being considered. In general however, it can be

said that process implementation projects vary somewhat from traditional IT

projects. They are by nature, culture change dependent projects. Proactive

measures to address change resistance, proactive project sponsorship

activities and creative communication planning activities must be

incorporated into project planning at the earliest phases. Process

implementation projects present special challenges for IT organizations, but

adequate planning will help insure an effective implementation strategy.

4.1.2 Implementation of COBIT

The entire development and implementation of the new process took

almost two years. While the central team was responsible for developing the

process, the location-based risk resources were instrumental in

implementation, training, etc. Since the implementers at the different

locations were part of the team, their feedback was used in making suitable

changes and corrections that helped improve the maturity of the process.

4.1.3 Differences Between ITIL and COBIT

COBIT and ITIL are both frameworks. This means that both shares

guidance that enterprises need to get the solution they need for their each own

unique problems. None of them give implementation blueprints. Both of the

frameworks are based on a real-world experience. This means it is certain that

both will provide practical advice that will work. And lastly, both advices can

be used by any type or size of enterprise.

4.2 Suggestion

For student, increase willingness to learn about implementation of ITIL

and COBIT in real life because it really helps user to know more about IT

development.

For researcher, develops more about implementation of ITIL and COBIT

in more specific area or business structure in certain company.

For government, create more training facilities about ITIL and COBIT and

demonstrate it for any party that would gain great benefit between those IT

developments.

REFERENCES

Bennett, S., Mcrobb, S., & Farmer, R. (2006). Object-Oriented Systems Analysis and Design Using UML. McGraw-Hill Higher Education.

Brand, K., & Boonen, H. (2007). IT Governance Based on CobiT 4.1: A Management Guide. Van Haren Publishing.

ITIL. (n.d.). Retrieved from http://www.itil-officialsite.com/AboutITIL/WhatisITIL.aspx

Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2004). Object-Oriented Analysis and Design with the Unified Process. Cengage Learning.

BIOGRAPHY