ITIL for Managing IT-based Services

(1)

ITIL for Managing IT-based Services

Master Project in Information and Software Engineering

Henrique Jos´e Salazar Delfina - 58401 [email protected]

Advisor: Prof. Miguel Mira da Silva Departamento de Engenharia Inform´atica

Instituto Superior T´ecnico

Abstract. IT has become a crucial concern for the entire organization. ITIL was taken almost as a standard for implementing IT Service Man-agement as a practical approach to the identification, planning, delivery and support of IT services to the business. Unfortunately, this practise is not mimed by the other sectors of the organization. But, if we examine carefully, we can instantaneously notice some similarities between some IT and Non-IT-related processes. One of this examples is ITIL’sChange Managementprocess and despite this, the synergies and techniques (pro-posed by ITIL) have not yet been explored on the various organizational departments where this Non-IT related processes reside. Our goal is to clearly identify similar processes, map them and after careful compar-isons, apply the ITIL directions and methods with all the benefits that thence may come. The demonstration of this work will be its application on a real organization with a clear and specific process. For evaluation we shall use interviews, and the Bunge-Wand-Weber Model.

Keywords: ITIL, Change Management, IT/Non-IT synergies, Enter-prise Architecture, Process mapping

1 Introduction

In the last decades, the role of IT has evolved and it has become a crucial concern on every single part of the organization. IT Service Management (ITSM) was a natural consequence of this substantial growth along with the creation of standards for it’s implementation. In this last matter, ITIL was assumed as the

de facto standard for implementing ITSM[1] as it clearly is a a practical, no-nonsense approach to the identification, planning, delivery and support of IT services to the business[2].

Unfortunately, this practise is not mimed by the other sectors of the organi-zation and there isn’t as well clear and well-accepted frameworks applicable to it’s entire structure with their own specificities and needs.

(2)

One of this examples is ITIL’s Change Management process. In this pro-cess ITIL regulates the addition, modification or elimination of an authorized, planned or supporting service (component) and its related documentation[3] through a variety of steps, goals, policies and methods.

Despite the overall success on the application and execution of this process on the IT Departments and the similarities with several distinct Non-IT related processes among the organizations, the synergies and techniques (proposed by ITIL) have not yet been explored on the various organizational departments where this Non-IT related processes reside.

Thence, our proposal to clearly identify similar processes, map them and after careful comparisons, apply the ITIL directions and methods with all the benefits that thence may come.

These synergies that were decisive on the decision of using this process to proceed our study about the use of ITIL processes on Non-IT contexts were obvious when studying the purpose of theChange Management process and it’s scope.

It is because of its generality that this process fits a great number of processes on the organization: because it deals with addition, modification or removal of components and its associated documentation, almost a commonplace on the organizational process reality.

However, this step has several risks and challenges which must be addressed carefully. First of all the chosen process must be well documented and described prior to any change take place. Hereupon, it is crucial to do a deep survey on the candidate process and map it facing ITIL’sChange Management[4], conducting as well a clear requirements assessment.

Only after this can we proceed and compare and adjust correctly each activity so we can derive which changes are necessary to match the processes perfectly.

Each aspect of the candidate process must be examined carefully so no par-ticularity, specification or requirement is left unattended.

Another important part of our work will be to obtain a consistent mapping onto the Enterprise Architecture. This way, using EA as ITIL’s CMDB we can register and keep track of the changes and outcomes of each CM-like process instance in order to allow a better organizational management and governance. By the end of this Master Thesis we hope to have fully demonstrated our proposal in a real organization and with a clear and specific process in both areas of our thesis: The identification and adjustment of an ITIL’sCM-like process and the correct use of ITIL’s tools and methods to consistently map the process and it’s iterations on the organizational Enterprise Architecture. We have already started our work accordingly at Hospital Santa Maria where we’re working to adapt the Administration Board decision-making and monitoring process.

The evaluation of our proposal will be done through interviews, and also with the Bunge-Wand-Weber Model so we can clearly identify deficiencies and assess results[5,6].

(3)

motivation and all its consequences. We will also look into relevant related work in the area and, after that, explain extensively our proposal. Finally, we will address the first steps of our proposal demonstration and evaluation.

2 Research Methodology

The methodology applied across this thesis is Design Science Research (DSRM), where we develop and validate a proposal to solve our problem[7]. DSRM is a system of principles, practices and procedures required to carry out a study.

Information systems can draw several advantages from DSRM since they are characterized by often using theories from diverse disciplines, such as social science, engineering, computer science, economics, and philosophy, among many others, to address problems at the intersection of information technology and organizations[7].

As so, design can be successfully integrated as a major component of research in order to solve relevant organizational problems. DSRM, then proposes the creation and evaluation of artifacts that may include constructs (vocabulary and symbols), models (abstractions and representations), methods (algorithms and practices) and instantiations (implemented and prototype systems)[7].

In our work we will mainly focus on models, methods and instantiations. Models use constructs to represent real world situations, the design problem and the solution space whereas methods provide guidance on how to solve problems. Instantiations show that constructs, models, or methods can be implemented in a working system. They demonstrate feasibility, enabling concrete assessment of an artifact’s suitability to its intended purpose. They also enable researchers to learn about the real world, how the artifact affects it, and how users appropriate it[7].

In both the construction and evaluation of the designed artifacts, the appli-cation of strict practices is required. In Fig. 1 we map the DSRM steps to our work.

This image is available for Download in High Resolution clicking this link.

(4)

The following sections of this document follow the methodology’s steps[8]. ”Research Problem” and ”Related Work” will cover aims and objectives as the awareness and recognition of a problem from a state of the art review giving us the issues that must be addressed. Afterwards, ”Research Proposal” presents a proposal as an attempt to solve the previously described problem. Next, we present a ”Demonstration” followed by the ”Evaluation” section comparing the results with the research questions and finally, we show our proposal applicability and themes for further work.

3 Research Problem

This section describes the ”Identify problem & motivate” step of the DSRM process, where we become aware and recognize a problem from a state of the art review, giving us the issues that must be addressed.

Today, there is no fully complete framework applicable to the entire organiza-tion’s sectors and/or departments. This is explained due their own specifications and apparent particular needs: The IT department doesn’t seem to have the same necessities and know-how as the Human Resources department for example. This led to a multitude of frameworks and sets of methods and techniques that satisfy each and every single silo of the organization (solving their individual problems) but creating divisions among them even when their problems are common or similar in some aspect.

Each department deals with it’s own problems and needs on their own terms (and sometimes even using their own IT platform) and doesn’t know if or how other parts of the organization face the same or their own issues.

Specifically, IT Service Management is implemented using ITIL in the major-ity of cases as it has emerged as thede facto standard. Basically, ITIL describes processes, procedures, tasks and checklists that are not organization-specific, and these are used by an organization for establishing integration with the organiza-tion’s strategy, delivering value and maintaining a minimum level of competency. It allows the organization to establish a baseline from which it can plan, imple-ment and measure. It is used as well to demonstrate compliance and to measure improvement.

This set of practices has been generally well received mostly due to its success and scope and being this popular, an increasing number of software has been developed to support and implement ITIL on IT Departments making it easy to deploy and fairly flexible to adapt to each organization reality and needs.

However all this efforts and achievements die in the IT department where they were meant to be used. Similar processes and activities on other departments of the organization (others than IT) don’t rely on ITIL methods or software to solve (or help solving) their own issues. Each part of the organization looks inside themselves searching for answers instead of talking to each other, sharing and adapting solutions, saving time and money and spanning advantages.

(5)

planned or supporting service (component) and its related documentation[3] through a variety of steps, goals, policies and methods. If we disregard the IT component and if we manage to abstract ourselves of the specific scope of the process we can clearly see the extent of fitting possibilities alongside the entire organization. From human resources to the administration board. So, why does the synergies and techniques (proposed by ITIL) have not yet been explored among departments other than IT?

This image can be downloaded in high resolution by clicking this link.

Fig. 2.Problem Illustration

Fig. 2 helps understanding the problem by transposing it to a visual envi-ronment. We have three silos on Fig. 2: IT, Human Resources and the Admin-istration Board. In all silos we have different problems, and for each problem, different processes (depicted by the arrows) to obtain a solution. Despite all the solutions appear to be quite different we can see that there are some processes that are similar, even with different names or slightly different outcomes: the orange processes, all result on a orange square-like solution.

These similarities have not yet been explored or even addressed much because every single part of the organization tends to look inside itself and doesn’t realize it can take advantage of this affinities.

Current literature supports this very same fact. Not only there is a general lack of academic conclusions about the topic but the few results that we came across during our research state that the use of IT-designed frameworks on non-IT scenarios is scarce and diffuse.

(6)

based scientific approach to this issue and supported it with a relevant research and/or tool integration.

Without stating the multitude of individual solutions for each organizational silo that fail to deliver convergence on the various sectors of the organization, we think it’s also important to remember the absence or deficiency of correctly defined processes on the organizational Enterprise Architecture and/or methods to accomplish them in an updated and reliable manner.

Being a reliable framework with a great number of success stories around its implementation and a considerable number of powerful and efficient tools, it is somewhat odd that ITIL is only being used currently inside the IT departments of organizations worldwide.

Being a framework with a large scope, it seemed fitting that we only focused on a small part of ITIL and fully explored the possibilities among the other organizational silos (other than IT). That’s why we are going to focus mainly on ITIL’sChange Management process from now on.

That being said, we can now present our problem. In short, we define our problem asthe lack or absence of a proper and definitive approach to the usage of ITIL’sChange Management process on non-IT contexts, despite the similarities between processes and the overall success on the appli-cation and execution of this process on the IT contexts it was designed for.

4 Related Work

In this section we present a literature review of the topics related to this project. We are also going to cover some practical approaches to the problem, as astate of the art description of what is currently being made regarding ITIL (and more specifically ITIL’sChange Management process) on non-IT organizational contexts.

We start by introducing what is ITIL, a best practice model to IT service management. Later, we’ll introduce Enterprise Architecture, a well-defined prac-tice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execu-tion of strategy[11]. Finally, we’ll show how ITIL is being introduced to non-IT departments and processes.

4.1 ITIL

ITIL was created by the Central Computer and Telecommunications Agency (CCTA), an office of the British government and was first released to the public in the late eighties[12]. Is was created mainly because enterprises need to manage the delivery of services that support users in conducting their activities in the context of business processes[13].

(7)

v2) was launched becoming the worldwide de facto standard for IT Service Management[12].

In 2007, ITIL V3 introduced the lifecycle principle, whereby the provisioning of services was considered to be a continuous process in which new services are brought into existence whilst others are phased out[12]. The current version of ITIL covers the major weaknesses identified in the previous versions, namely being too focused on technology[14]. Now, instead of focusing on the service itself, the focus lay on this cycle of life, renewal and decommissioning of services, with a greater business-focused perspective[12].

The ITIL Core consists of five publications: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. Each book covers a phase from the Service Lifecycle with various processes which are always described in detail in the book in which they find their key application[3].

4.2 EA

Today, business performance depends on a balanced and integrated design of the enterprise, involving people, their competencies, organizational structures, busi-ness processes, IT, finances, products and services, as well as its environment[15]. Enterprise Architecture (EA) is a coherent set of principles, involving the de-sign and performance of different architectures. It specifies the components and its relationships, which are used to manage and align assets, people, operations and projects to support business goals and strategies[16,17], concerning those properties of an enterprise that are necessary and sufficient to meet its essential requirements[15].

EA is based on a holistic representation of organizations, on views and the ability to map relationships between artifacts and architectures, and on the independence and connection between layered architectures[14] which usually are: Business, Process, Application, Information, and Technology. The alignment between architectures allows a coherent blueprint of the organization, which is then used for governance of its processes and systems.

4.3 ITIL on Non-IT scenarios

After deep research, we have concluded that there is a general lack of academic studies about the topic but the few results that we came across during our research state that the use of IT-designed frameworks on non-IT scenarios is scarce and diffuse.

(8)

EFACEC’s relation with ITIL is solid and consistent. The IT Department was organized from the start with ITIL’s good practices in mind so everything falls into place when changes occur. The first ”experiments” with ITIL on Non-IT contexts were related with Non-ITIL’s Service Request. The transport and fleet request management and the legal department management were the first pro-cesses to be designed or adapted from ITIL into a Non-IT context.

As success factors,EFACEC states the importance of top management sup-port, the importance of being focused on the process instead of being perma-nently focused on the object(s) and the value of the attention to terminology and nomenclature challenges. Their main pillars for ITIL use outside IT contexts are

Incident Request,Service Request andChange Request. Because these ITIL con-cepts are so simple and common to their daily use, the adaptation process was quite simple and didn’t raise many concerns among the users and developers.

Tool-wise, EFACEC’s experience was fairly positive but there were some aspects that required extra attention:

– The language adaptation

– The importance of user training and documentation – The software front-end adaptation

– The software fitting to the real needs and requirements of the end users As for future implementations it is EFACEC’s hope that much more pro-cesses go through the same path. In fact, every administrative, financial and/or management process is, in theory, a good candidate to undergo this proceeding.

EFACEC’s ITIL work on Non-IT contexts is currently on Infrastructure man-agement and Quality. In fact, ITIL’s Change Management is currently being adapted into the Quality Department to deal with nonconformities and product changes and requests.

Auckland Airport Other related work data about the use of ITIL on Non-IT contexts focused around the Auckland Airport experience with HEAT Service Management.

Basically, due to the configuration capabilities of their ITIL solution, Auck-land Airport has been able to leverage the platform beyond IT to support re-quests and incidents logged across a number of business divisions. Technical advances were also possible because tools designed for the solution were adapted to fit other business areas and needs[10].

Auckland Airport is the second busiest international airport in Australa-sia after Sydney, servicing more than 22 international airlines and more than 14.000.000 passengers each year.

(9)

Although the chosen solution was primarily an IT Service Management solu-tion out-of-the-box, Auckland Airport quickly realised that its capabilities were much broader. It offered a powerful workflow platform that could significantly improve data communication across a number of key business divisions. Now, the same base process is used to manage the Lost & Found service request han-dling, the Failure in equipment or facilities or the Record of regular scheduled inspections.[10].

4.4 Summary

It is noticeable that all these aspects are important and are part of the path that led our research here but, from the first two sections, we can see that ITIL and EA often lack fitting and dialogue between each other. We can also see that there’s a general lack of academic studies about the topic of our thesis: there is a clear absence of a proper and definitive approach to the usage of ITIL’s Change Management process on non-IT contexts, despite the similarities between processes and the overall success on the application and execution of this process on the IT contexts it was designed for.

This is supported by the data ofEFACEC’s and Auckland Airport’s ITIL experiences. We acknowledge the added value of these descriptions, models and records and we are not claiming they are incorrect, but simply pointing out in-stead they lack completeness, because or they limit themselves to some processes and not others (and none of them focused on ITIL’sChange Management), or they lack scientific guidance, documentation and testing or, most importantly, they are relative to two particular realities of the companies they were conducted into and cannot be generalized or used in profoundly different contexts.

5 Research Proposal

Here we explain our approach to adapt ITIL’s Change Management process to other similar Non-IT processes. Based on the problem we described and on the lack of suitable solutions, we propose a Change Management process mapping or adaptation to Non-IT specific processes, taking advantage of the benefits and conclusions that already exist on the IT (normal) usage, thus obtaining processes that are far easier to include, manage and update on the Enterprise Architectures.

Hence, through this section we’ll present our proposal steps. First we’ll estab-lish the objectives of our solution, followed by the reasons why we chose ITIL’s

Change Management (CM) as the process to adapt. Then we’ll propose a set of mapping guidelines for Non-IT processes based on ITIL’s CM. Afterwards, we’ll identify and represent the data structures, roles and concepts to accurately identify our candidate process and then we will redesign or adapt the process based on ITIL’sCM, testing it on an ITIL-driven software.

(10)

CM) and to the ”Design and Development” (where we present the process of reconstruction and testing of the mapped process) steps of the DSRM process.

5.1 Objectives of the Solution

As we’ve seen before, ITIL is used and designed with IT concerns and challenges in mind. Therefore, by adapting it to a Non-IT reality, our main concern should be an efficient mapping and adaptation. We should as well keep in mind that one of the main advantages of this procedure is the possibility of attaining a consistent mapping onto the organizational Enterprise Architecture, allowing a better management and governance. Knowing that, we must assure that the tools and characteristics that allow this process to occur shouldn’t be left aside.

Fig. 3.Proposal Ilustration

Once again, Fig. 3 helps understanding the proposed solution. Our goal is to identify the processes that occur in the organizational silos other than IT that have similar behaviors as ITIL’sChange Management. This processes, similarly as we observed on Fig. 2 are depicted by the orange arrows and their solutions by the orange square-like figures.

(11)

5.2 ITIL’s Change Management

In the ITIL framework,Change Management is a part of ”Service Transition” -transitioning something newly developed (i.e. an update to an existing produc-tion environment or deploying something entirely new) from the Service Design phase into Service Operation and aims to ensure that standardised methods and procedures are used for efficient handling of all changes.

Change Management is a process used for managing the planned deploy-ment of alterations to all configuration items in the configuration managedeploy-ment database, (or ”CIs” in the CMDB) that are a part of a business’s live (”produc-tion”) and test environments along with any other environment that a business wants to have under Change Management - generally all environments that are under the control of ’ICT Operations’). It is not typically responsible for change within development environments.

Basically, we can define a change as an event that is: – Approved by management

– Implemented with a minimised and accepted risk to existing IT infrastruc-ture

– The reason of a new status of one or more configuration items (CIs) – The provider of an increased value to the business (in the form of an

In-creased Revenue, an Avoided Cost, or an Improved Service for example) from the use of the new or enhanced IT systems.

On the other hand, the goal of theChange Management process is to ensure that:

– Standardised methods and procedures are used for efficient and prompt han-dling of all changes

– All changes to service assets and configuration items are recorded in the Configuration Management System (CMS)[18]

The synergies that were decisive on the decision of using this process to continue our study about the use of ITIL processes on Non-IT contexts were obvious when studying the purpose of theChange Management process and it’s scope.

Basically, the purpose of change management is to:

– Respond to the customers changing business requirements while maximizing value and reducing incidents, disruption and rework

– Respond to the business and IT requests for change that will align the ser-vices with the business needs[18]

The objective of the change management process is to ensure that changes are recorded and then evaluated, authorised, prioritised, planned, tested, imple-mented, documented and reviewed in a controlled manner and take necessary corrective action

The top five risk indicators of poor change management are: – Unauthorised changes

– Unplanned outages – A low change success rate

(12)

– Delayed project implementations[18]

Analyzing the purpose of the process, we can see that it almost directly fits the purpose of many different processes inside other departments of the organization: React to different requirements and respond to different requests are almost cross-cut concerns of an organization. The risk indicators accentuate the relevance of this choice as authorization, planning and delays are problems that we can as well relate to a big part of organizational issues and risk factors. As so, we finish this subsection analyzing the scope of ITIL’sChange Manage-ment: The addition, modification or removal of authorised, planned or supported service or service component and its associated documentation.[18] It is because of its generality that this process fits a great number of processes on the orga-nization: because it deals with addition, modification or removal of components and its associated documentation, almost a commonplace on the organizational process reality.

5.3 Candidate Processes

Choosing effectively which Non-IT related processes are suitable candidates to fit into ITIL’sChange Management must take into account a series of factors:

– The purpose and scopes of both processes must fit, even if some terminology aspects of ITIL’sCM have to be adjusted or replaced;

– The candidate process must resemble a decision-making process-like struc-ture (as ITIL’sCM does);

– Mapping the candidate process into ITIL’sCM must be immediate or fairly easy to do;

– ITIL’sCM data structures can be adjusted to fit the needs of the candidate process but never in a way it changes the ITIL process, it’s direction or objective;

– ITIL’sCM roles can be merged and new roles can be added but they should never be deleted;

– ITIL’sCM concepts can be adjusted to fit the reality of the candidate process but never changing the scope and purpose of the process.

If this factors don’t apply to a supposed candidate process it is clear that it’s a far more complex and specific process and can’t be fitted into ITIL’s Change Management.

Another important part of choosing a candidate process is to make sure it is well documented and described prior to any change take place. Hereupon, it is crucial to do a deep survey on the candidate process and map it facing ITIL’s

Change Management[4], conducting as well a clear requirements assessment. Some mapping guidelines to carry on this step include:

– Map the candidate process using a blank ITIL’sCM process map or study carefully ITIL’s process so it is easier to identify relations and similarities; – Aggregate small parts of the candidate process to fit a less granular part of

ITIL’sCM;

(13)

– Document the process to keep track of changes and meanings of connections and/or data updates.

Only after this can we proceed and compare and adjust correctly each activity so we can derive which changes are necessary to match the processes perfectly.

5.4 Data Structures, Roles and Concepts

Each aspect of the candidate process must be examined carefully so no particu-larity, specification or requirement is left unattended.

The data structures can be adjusted but all the information that could be in-cluded in the structure of a ”Request for Change” (RFC), part of ITIL’sChange Management core, must be inserted and controlled here. It is because the RFC stores most of the relevant data about the process[4] that ITIL’sCM is so ”valu-able” in this contexts. To neglect this aspect is to abdicate of a very important asset we are trying to transfer.

ITIL’s Change Management roles are part of the process we’re trying to mime, hence the importance of not deleting them. It is important to clear that we’re not trying to create new responsibilities or positions. Reviewing ITIL’s

CM roles we can clearly see that their responsibilities are obvious and are most likely already assigned to someone[4,19]. Our objective is to focus on the clear association between ITIL’sCM role (or roles) and the organization’s candidate process role (or roles). This should be done at the same time the process mapping is carried out. That way it’s much more clear who does what and when.

ITIL’s Change Management concepts include clear definitions of Change, Change history or even Change control[4]. As stated previously, this terms can (and should) be adjusted to fit the reality of the candidate process. Some termi-nology can be deceiving or misunderstood in certain contexts. It is, then, crucial to pay special attention to this aspect. It is also important to do this at the early beginning of the entire procedure so there’s no room for ambiguity and overlapping.

5.5 Process redesigning and testing

After all the previous work is carried we can now redesign and test our new

CM-like process.

The redesigning phase must be easy with all the documentation and knowl-edge we have gathered in the previous steps. The Concepts, terminology and roles must be the candidate process’ ones but the mapping should indicate clearly the ITIL’sCM equivalent so it is easier to analyze the process with a Non-IT context background and with an ITIL perspective simultaneously.

Finally we should test ourCM-like process. The best way to do that is im-plement it on an ITIL-driven software or tool. Using the ITIL concepts mapped on the process and with few or no modifications it should be easy to track, document and simulate the candidate process inside the tool.

(14)

process or their own actors. This shouldn’t be a problem: our proposal is not to exclusively enable tool or software reuse but also allow the transfer and applica-tion of much more broader knowledge from the IT world to the Non-IT contexts it can be applied to.

The final step of our proposal is to enable a consistent mapping onto the Enterprise Architecture. This way, using EA as ITIL’s CMDB we can register and keep track of the changes and outcomes of each CM-like process instance in order to allow a better organizational management and governance.

6 Demonstration

This section describes the ”Demonstration” step of the DSRM method, where we demonstrate our proposal. For this, we shall use a demonstration on a real organization: Hospital Santa Maria. This demonstration will use our proposed method to map and adapt a candidate process into an ITIL’s Change Man-agement-like process: First by identifying, assess and map the process, then by adapt the data structures, roles and concepts and finally by redesigning and testing the process with an ITIL-driven software tool.

6.1 HSM context

Our Demonstration will be done using the Hospital Santa Maria’s Administra-tion Board decision-making and monitoring process. This is a crucial process on the Hospital’s operation and it wasn’t performing as desired by the Administra-tion Board. It was the perfect fit for our Proposal and work started on October 2013.

Our first challenge was to identify clearly the context of the process at Hos-pital Santa Maria. This HosHos-pital which had more than 700.000 medical appoint-ments in 2012[20] needed a new way of processing and monitor the requests and decisions made to the Administration Board and their members.

To accomplish this, we made a set of interviews with the Administration Board Adviser, several process (system) users and with the Director of the IT Department, Eng. Jo˜ao Louro.

Basically, the process starts with a request that is send to one of the Admin-istration Board (AB) members. This request can be internal or external. The request is recorded and the AB member then reviews the request and makes one of three decisions: 1. marks the request for discussion at the next AB meeting; 2. returns the request to one or several people to review or take notice (this peo-ple can be the sender, peopeo-ple external to the Hospital or even Hospital workers or advisers); or 3. marks the request as a minor or prompt subject and makes the decision without sending it to the board meeting.

This last cycle can repeat itself as long as the notifications or review requests bounce between middlemen along the process.

(15)

and 2. it is Prioritized based on impact, urgency or origin of request. This infor-mation travels with the request on it’s next iterations and as it is discussed on the next AB meeting.

On the AB meeting, the request is approved or denied. If denied, the process ends with a notification to the request sender. If the request is approved, it is updated with the AB approval information or details and starts a phase we called Coordination.

It is also to the Coordination phase the request travels when it is approved directly by the AB Member (as depicted on item 3 above). This phase is when the request is planned, communicated or executed depending on their individual specificities. This cycle can repeat itself or not (as long as the request or its actors demand). Every step it’s registered and when it’s done the AB Member closes the request with a brief evaluation.

Every data specification, types of identification or record numbers, actor identification methods and type and number of comments sections were analysed and assessed and are depicted on the next subsection.

6.2 Process and data assessment and mapping

We first started our work in this section by mapping ITIL’s Change Manage-ment according to the best sources available[3,4]. The result of this work can be observed on Fig. 4.

Our main concerns were to correctly identify the roles and responsibilities of each activity and access when and how the Request For Change (RFC) document was updated so we could establish a comparison with Hospital Santa Maria’s Administration Board decision-making and monitoring process.

We could identify three clear roles within the Process: – The Change Initiator (who starts the Change Request);

– The Change Manager (who Receives, logs and allocates the requests, tables all Request for Changes (RFCs) for a board meeting, issues an agenda and circulates all requests for changes to Board members in advance of meet-ings to allow prior consideration, decides which members will come to which meetings, who gets specific RFCs depending on the nature of the RFC, convenes urgent meetings for all urgent RFCs, chairs these meetings, autho-rizes acceptable changes either alone or after a meeting has taken place, is-sues change schedules, liaises with all necessary parties to coordinate change building, testing and implementation, in accordance with schedules, updates the change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve service quality, reviews all implemented changes to ensure that they have met their objectives, referring back any that have been backed out of have failed, Reviews all outstanding RFCs, Analyses change records to determine any trends, closes requests and produces regular management reports) and, finally;

(16)

The Lane ”Data” is only showed for simplicity purposes.

Because we were mapping this process for an Administration Board-related process we decided after careful thinking not to implement the Change Advisory Board as depicted but rather delegate it’s responsibilities onto the ”Administra-tion Board” role that we will soon present.

Fig. 4.ITIL’sChange Management Process

(17)

We can identify in Fig. 5 five clear roles within the Process: the Request Initiator (with similar responsibilities and functions as in ITIL’s CM), the AB Member (similar to the Change Manager), the Administration Board (the entity who decides on the great majority of occurrences of the process, similar to the Change Advisory Board), the Accountable (who represents basically the executor of the request made) and, finally, the External Entity (here representing all the external entities to this specific request, both internal and external to the Hospital context). Again, the Lane ”Data” is only showed for simplicity purposes.

Fig. 5.HSM’s Administration Board Process

(18)

process is almost equal to ITIL’sChange Management. It is important to notice as well that the occasions and content of the updates made to the Request Docu-ment (ITIL’sRequest For Change (RFC)) were piratically the same. The minor difference were related to the new data fields we had to add to the original RFC in regard to the regular Administration Board decision-making and monitoring process.

Finally, we analyzed the Data Structures available on both Processes. Fig. 6 represents this analysis in a summarized form for ITIL’sRequest For Change (RFC) and HSM’s Request Record.

Fig. 6.Comparison of Data Structures

(19)

on the process because the decisions are still made by the AB Member. The difference is that these same decisions are inserted and updated into the system by other person accordingly to previous indications.

The Coordination record stores the history of each request so this process can be a truly monitoring process as it is supposed to be. This field allows to know precisely when was a certain request updated, by whom and if it is pending from some kind of review or feedback.

6.3 Tool designing and testing

After we correctly mapped and assessed HSM’s Administration Board decision-making and monitoring process we started gathering requirements for an ITIL based tool to manage and monitor the requests inside the process.

Part of the requirements assessment document can be see on Fig. 7.

Fig. 7.Excerpt of the Requirements Assessment Document

(20)

a tool that was built with an ITIL operation in mind. Some screenshots of our prototype can be seen in Figures 8 to 10.

Fig. 8.Screenshot of our Requirements validation prototype: Request Creation Screen

Fig. 9.Screenshot of our Requirements validation prototype: Request View and History Screen

(21)

Fig. 10.Screenshot of our Requirements validation prototype: Request External Re-view Screen

like EAMS will be much easier to accomplish. Our goal is to show onEAMS’s Enterprise Architecture blueprints for example the (immediate and long-term) outcomes that result from a certain Administration Board decision or Request. This work, is already going through it’s second iteration as some flaws and requirement conflicts have been detected during the implementation or request validation phases, however the backbone process that supports the tool and that was based on ITIL’sChange Management-like process that was chosen and mapped: the Hospital Santa Maria’s Administration Board decision-making and monitoring process is accurately miming the original (candidate) process.

With all this we, thus, demonstrate that a Change Management pro-cess mapping or adaptation to a Non-IT specific propro-cesses, taking advantage of the benefits and conclusions that already exist on the IT (normal) usage is possible and far easier to manage and use.

6.4 Case Study

A clear and quick example of the functionality and validity of this process is the actual requirements gathering, assessment and validation procedures and the actual tool development that is currently an ongoing process in our work.

(22)

final steps will finally prove the process one hundred percent exact and reliable as we finish the demanded software tool to support the now-tuned Administration Board manage and monitoring process.

7 Evaluation

This section is the ”Evaluation” step of the DSRM process, where we will eval-uate the demonstrated sections of our proposal. Our evaluation method has several steps. We will start by interviewing two sets of subjects: 1. general ITIL practitioners who have already started mapping Non-IT processes on ITIL to assert our work relevance and correction; and 2. stakeholders from the organi-zation where we will perform the real demonstration. The Bunge-Wand-Weber Model will be used to evaluate our concept mappings from the Non-IT to the ITIL’sCM process. We will also submit articles to international conferences and journals where we will communicate the artifacts, its value and utility

7.1 Interviews

Interviews allow to ask questions that are open-ended and explore emotions, experiences or feelings that cannot easily be observed or described via pre-defined questionnaire responses[21]. Therefore, we will use this method for two groups of subjects:

– General ITIL practitioners, specialists from different areas but with strong ITIL and EA background and preferably that already started map-ping Non-IT processes on ITIL to assert the quality, relevance, correction and utility of our mapping; and

– Distinct stakeholders with different roles in the organization where we are performing the real demonstration.

Moreover, we will also ask our interviewees to fill out a small form, so we can gather some quantitative data for later analysis.

7.2 Bunge-Wand-Weber Model

For evaluating the concept mapping from ITIL’sCM concepts to Non-IT’s ones we will perform an analysis based on the Bunge-Wand-Weber ontological eval-uation of grammars method, where we compare two sets of concepts to identify four ontological deficiencies.

– Incompleteness: can each element from the first set be mapped on an element from the second? - the mapping is incomplete if it is not total. – Redundancy: are the first set elements mapped to more than a second set

element? - the mapping is redundant if it is ambiguous.

– Excess: is every first set element mapped on a second set one? - the mapping is excessive if there are first set elements without a relationship.

(23)

7.3 Publications

This section describes the final step of the DSRM process: ”Communication”, where we will communicate our proposal, its demonstration and evaluation. Hence, besides this thesis, we will submit articles to international conferences and journals where our work will be subjected to peer evaluation.

8 Conclusion

In this thesis, we purpose to explore the similarities, synergies and techniques (proposed by ITIL) that exist between some IT and Non-IT-related processes and that have not yet been explored. Hence, we purpose aChange Management process mapping or adaptation to Non-IT specific processes, taking advantage of the benefits and conclusions that already exist on the IT (normal) usage, thus obtaining processes that are far easier to include, manage and update on the Enterprise Architectures.

To achieve this, we have already produced the following outputs:

– Assessed the context of our Demonstration process;

– Assessed and Mapped the Administration Board decision-making and mon-itoring process, data structures and roles facing ITIL’sChange Management

process;

– Gathered requirements for an ITIL based tool to manage and monitor the requests inside the ”new” process;

– Developed a prototype to validate the requirements using ITIL’s process backbone;

– Started developing the final software with Enterprise Architecture tools (like

EAMS) in mind so future requests can be showed into the Architecture like changes are recorded on ITIL’sCMDB.

For future work, we’ll leave the finishing process of the final software tool; the integration with the chosen EA tool; the evaluation procedures and, if possible, the assessment and mapping of new candidate processes in different areas. On Appendix A we present a gantt chart with these activities scheduled in time.

In short, in times where cost and value generation are such important drivers, we should, more than ever, turn and take advantage of the valuable synergies and techniques (proposed by ITIL) that have not yet been explored on the various organizational departments where a lot of Non-IT related processes reside.

(24)

Acknowledgements

This work would never been possible without the persistence, vision and much needed assistance of my adviser: Prof. Miguel Mira da Silva; the openness, receptivity and availability of Hospital Santa Maria’s Director of the IT De-partment: Eng. Jo˜ao Louro and, finally, the appreciation and readiness of EFACEC’s IT Infrastructure Manager:Eng. Rui Leit˜ao.

References

1. Hochstein, A., Zarnekow, R., Brenner, W.: Itil as common practice reference model for it service management: Formal assessment and implications for practice. In ’05, E., ed.: Proceedings of the 2005 IEEE International Conference on e-Technology, e-Commerce and e-Service. Volume 1. (3 2005) 704–710

2. Arraj, V., Compliance Process Partners LLC: Itil: The basics whitepaper. Best Management Practice’s White Paper1(7 2013) 3–5

3. van Bon, J., de Jong, A., Kolthof, A., Pieper, M., Tjassing, R., van der Veen, A., Verheijen, T.: Foundations of IT Service Management Based in ITIL V3. 3rd edn. Van Haren Publishing (9 2007) ISBN: 978 90 8753 057 0.

4. Universities and Colleges Information Systems Association: ITIL Example change management procedure. University of Oxford, Oxford. (10 2012)

5. Fettke, P., Loos, P.: Ontological evaluation of reference models using the bunge-wand-weber model. In: Ninth Americas Conference on Information Systems. (2003) 2945–2955

6. Pries-Heje, J., Baskerville, R., Venable, J.: Strategies for design science research evaluation. In: Proceedings of ECIS 2008. Number 87 (2008)

7. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systems research. MIS Quarterly28(1) (3 2004) 75–105

8. Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S.: A design science research methodology for information systems research. Journal of Management Information Systems24(3) (8 2007) 45–78

9. Larsen, M.H., Pedersen, M.K., Andersen, K.V.: It governance: Reviewing 17 it gov-ernance tools and analysing the case of novozymes a/s. In ’06, H., ed.: Proceedings of the 39th Hawaii International Conference on System Sciences. Volume 8. (1 2006) 195c

10. FrontRange Solutions USA Inc.: Auckland airport significantly enhances service delivery. HEAT Hybrid1(9 2013) 1–3

11. Federation of Enterprise Architecture Professional Organizations: A common per-spective on enterprise architecture. Architecture and Governance Magazine1(9-4) (11 2013) 1–12

12. van Sante, T., Ermers, J.: Togaf 9 and itil v3: Two frameworks whitepaper. Best Management Practice’s White Paper1(9 2009) 3–16

13. Braun, C., Winter, R.: Integration of it service management into enterprise ar-chitecture. In: Proceedings of the 2007 ACM symposium on Applied computing. Volume 1., New York, ACM (2007) 1215–1219

(25)

15. Greefhorst, D., Proper, E.: Architecture Principles: The Cornerstones of Enterprise Architecture. Volume 4 of The Enterprise Engineering Series. Springer (5 2011) ISBN: 978 36 4220 278 0.

16. Lankhorst, M.: Enterprise Architecture at Work: Modelling, Communication and Analysis. 3rd edn. The Enterprise Engineering Series. Springer (8 2012) ISBN: 978 36 4229 650 5.

17. Ross, J.W., Weill, P., Robertson, D.C.: Enterprise Architecture As Strategy: Cre-ating a Foundation for Business Execution. Harvard Business Review Press (8 2006) ISBN: 978 15 9139 839 4.

18. Universities and Colleges Information Systems Association: ITIL A guide to Change Management. University of Oxford, Oxford. (10 2012)

19. Universities and Colleges Information Systems Association: ITIL Change man-agement: Roles and responsibilities. University of Oxford, Oxford. (10 2012) 20. Centro Hospitalar Lisboa Norte, EPE: Relatrio anual sobre o acesso a cuidados de

sade. Technical report, Centro Hospitalar Lisboa Norte, EPE, Lisboa (2012) 21. Oates, B.J.: Researching Information Systems and Computing. 1st edn. SAGE

(26)