Preface
This research report is the end product of my master program Technology Management at the University of Groningen. The research was conducted as part of an internship placement in Shell, which started in May 2008 and lasted for six months. An additional two months were spent on finishing this thesis. Most of the research was conducted from the central office at the Shell Pernis refinery site, close to Rotterdam. However, to conduct my research I spent many hours in conference calls with Shell people from all around the world.
First of all I would like to thank my Shell supervisor René Jansen and mentor Marianne van de Velde‐Overweg for providing me with the opportunity to conduct my master thesis research at the business applications support organization in Shell Downstream and providing me with a challenging assignment. During my internship I gained valuable experience in IT service management and it gave me insight in how IT is organized in an organization as large as Shell. Furthermore they have been very approachable and provided me with sensible advice on a daily basis, which made my internship a valuable and enjoyable experience.
Next, many thanks to Rob de Graaf, who supported me as a first supervisor representing the University of Groningen. He has been closely involved during my whole internship period and showed interest in the subject matter from the start. Regular meetings with him often provided me with new insights and helped me to structure my reasoning and streamline my research at times when this seemed impossible to me. I also would like to thank my second supervisor, professor John Simons, for providing me with valuable guidance on my research design, at the moment when to me progress seemed to come to a halt.
Last but not least I would like to thank all people in and outside Shell, that contributed to this research. The names of all interviewees and contacts are listed in appendix 12 of this report.
Management summary
This thesis report is the result of a research into data registration and maintenance in the Business Applications Management organization within Shell Downstream. BAM MSD is facing problems with the registration of data on the business applications they support, which is stored in various administrations across Shell. This application and support data is used in operational and planning processes by both BAM and the business. It is recognized, that the quality of application and support data is currently insufficient to help improve operational performance in BAM to achieve Top Quartile Performance.
The aim of this research is twofold: to provide BAM MSD with a design of a data registration process by which data is correctly and completely stored and to provide a high‐level data management solution for maintaining the quality of application and support data. Therefore the following research question is answered: What should a data registration process for BAM
MSD look like that is part of a data management solution that ensures the correctness, completeness and timeliness of application and support data in all relevant administrations?
After identifying best practices in the area of configuration management and analysing the fit between the current situation in BAM MSD and these practices, design specifications for a data registration process are obtained, ultimately leading to the design of the End2End Data Administration process.
The End2End process satisfies predetermined (user) requirements in the categories of completeness, effectiveness, transparency and efficiency. Therefore support staff in BAM MSD is able to register data correctly and completely, by using this process. It is suggested to automate parts of the End2End process, by means of a workflow system or electronic (web) forms, to enforce the correct execution of the process.
However, to ensure quality of all data in the administrations, BAM MSD should establish a data quality cycle that continuously monitors and improves the data (as is shown in section 7.2). This can be realized by setting up a correction process and enhancing the existing reporting and audit processes. To ensure the timeliness of data the existing Change Management process has to be integrated with the End2End process. The scope of the Change Management process should be widened, so that it covers all application and support data. Further recommendations concerning the implementation of the presented solutions include: • Publish the End2End process on a central website to advance adoption and by which it can easily be kept up to date.
• Establish a data registration project team consisting of the End2End process owner, update process owners and application specialists, which aims at improving and standardizing the various update processes and maintains the End2End process. • Delivery Managers should set and actively communicate data quality objectives to
their support teams. Data with potentially the highest impact on business activities should have priority.
• The existing CM Audit report should be better utilized, by the design of macro’s that can identify various types of data discrepancies.
• Audit results have to be communicated monthly to the application specialists.
1 Introduction
1.1 Introduction to the organization
1.1.1 Royal Dutch Shell
Royal Dutch Shell, or Shell in short, is a global group of energy and petrochemical companies, active in more than 110 countries and territories and employing 104,000 people worldwide. Shell’s aim is to meet the energy needs of society, in ways that are economically, socially and environmentally viable, now and in the future.1 As an energy company, Shell explores for, produces and trades in a range of energy resources. The majority of activities of Shell can be seen in exploring for and producing oil and gas and creating essential products from them, such as fuels and petrochemicals. Shell also has a broad portfolio of hydrogen, bio fuels, wind and solar power interests. In addition Shell provides consultancy and technical services as well as research and development expertise to the energy industry.2
Shell businesses
Royal Dutch Shell consists of the upstream businesses of Exploration & Production and Gas &
Power and the downstream businesses of Oil Sands, Oil Products and Chemicals. In 2007, the
Group strategy
Shell’s business strategy over the past years has been and will continue to be More Upstream,
Profitable Downstream. Upstream, the Shell group aims to search for and recover more oil and
gas. The upstream businesses continue to focus on developing major new projects. It is expected that in 2008 around 80% of capital investment will be in upstream and oil sands projects.4 Downstream, Shell aims to refine and deliver products to its customers in a profitable and sustainable way. In the downstream businesses the emphasis will be to maintain and to enhance their competitive position by improving the quality, safety and competitiveness of refineries and building on presence in growth markets, like the Asia Pacific region.5
1.1.2 Shell Downstream
Operational excellence
The strategy in the downstream organization is aimed towards delivering added value to customers by operational leadership and lowest total costs. Treacy and Wiersema (1993) characterize a strategy based on this value proposition as a strategy aiming for operational
excellence. Downstream is pursuing this by simplifying the global organization and
standardizing operations and policies. Several major projects in Downstream focus on implementing global standard processes and platforms to be able to deliver quality products and services at competitive prices.6 These projects are initiated to ensure that all Downstream businesses become world class in what they do, with the aim to regain market leadership.
Classes of Business and functions
The Shell Downstream business is made up of a number of Classes of Business: Oil Sands,
Chemicals, Manufacturing, Supply and Distribution, Retail, Lubricants and B2B (Business‐to‐
Business). Together these Classes of Business (CoBs) turn crude oil into a range of refined Shell products, which they move and market around the world for domestic, industrial and transport use.7 In addition there are seven worldwide functions that support the CoBs. The functions are: HR, Finance, IT, Contracting and Procurement, Strategy and Portfolio, Legal and
Communications.
1.1.3 Downstream IT
The Downstream IT function is responsible for delivering world class IT services to the several CoBs in Downstream globally. Therefore Downstream IT consists of three main delivery
organizations, each of them being responsible for delivering specific IT services to the
Figure 2 Simplified overview of the Downstream IT organization (Shell Wide Web)
1.2 Business Applications Management
1.2.1 Business application support services
BAM is responsible for delivering application support services to the downstream businesses. This means that BAM staff is primarily responsible for maintaining and guaranteeing the availability of business applications that are being used by employees in the business. Shell defines business applications as (sets of) software executables, which meet a certain business need, and are designed to perform a specific function, often by applying business rules and by transforming or transferring data.8 Business applications are thus computer programs used in the various CoBs in Shell Downstream, ranging from applications that support refining and trading, to distribution and sales of (end) products to other businesses or consumers. More specific examples include tools for demand forecasting and production optimization, applications for refinery planning and scheduling, applications for stock management, transportation scheduling, and (crude) oil trading, but also Customer Relationship Management (CRM) tools, and accounting and reporting tools.
1.2.2 Organization
BAM is a global organization consisting of approximately 1000 Shell employees. In addition over 200 contractors are working part time or full time in BAM. BAM staff is located at various locations around the world. Major Shell locations with a fair amount of BAM employees include the United States (Houston), the United Kingdom (London and Stanlow), Malaysia (Cyberjaya), Singapore and the Netherlands (Pernis and The Hague). Additionally, the BAM work force consists of around 500 to 600 offshored personnel. As substantial parts of the support work are outsourced to India, this organizational construction can be referred to as offshore outsourcing9. The majority of the so‐called offshore staff is located in Bangalore (India) and hired from very large IT services companies.
BAM is organized in different areas that largely correspond with the CoBs they serve. These areas are: MSD (Manufacturing, Supply & Distribution), Retail, B2B & Lubes (Business‐to‐ Business and Lubricants), Downstream Functions & Chemicals and Oil Sands. The research that is presented in this report focuses on the MSD area in BAM.
1.3 BAM MSD
1.3.1 General introduction
The MSD area in BAM (also see figure 2) is responsible for the maintenance and support of business applications in the CoBs of Manufacturing and Supply & Distribution. BAM MSD is organized in four regional teams, and three global teams. The regional teams are responsible for the support of legacy applications10. The respective regions are Europe, Americas, Asia and Oceania. The majority of legacy applications in the Europe region are running locally at refineries in the Netherlands (Pernis), the UK (Stanlow) and Germany (Harburg/Heide and Godorf/Wesseling). Global teams are responsible for the support of newer applications, which are implemented globally. The total amount of Shell staff and contractors in BAM MSD adds up to around 160 people. Examples of typical applications in the MSD area include software that supports refinery planning and scheduling activities, demand forecasting and production optimization tools, tools that provide stock information, support for transportation scheduling, loading and unloading of barges, etc.
An application instance is defined as a physical implementation of an identifiable version of an application for a specific community of users.11 So applications can have multiple instances installed across the organization. BAM MSD is responsible for the support of at least 2000 application instances in the Manufacturing business and 750 application instances in the Supply & Distribution business. The number of users for each instance is highly variable. There are local application instances, only used at one specific refinery, with only one up to a handful of users. But there are also application instances that have around 10, 20, or 50 users. Applications that are implemented globally can have 500 up to 1000 end‐users. A good example of a larger, global application with approximately 500 users is Barge Suitability Web, which is a web based tool used for transportation scheduling of barges throughout Europe.
9
1.3.2 Roles and organization
The global BAM organization is presided by a General Manager IT, who is located in London. Each of the BAM areas is headed by a Global Delivery Manager. For BAM MSD, this is the
Global MSD Delivery Manager, who is based in Canada. Within each BAM area a number of Delivery Managers is leading a number of regional and/or global support teams. The regional
Delivery Manager for MSD Europe is the principal for the research project that is described in this report. She is responsible for 26 application specialists in five support teams and additional offshore staff in India. In general, support teams vary in size from two up to approximately eight application specialists. A support team is usually headed by a Team Lead. An overview of the organizational structure and the corresponding roles in BAM MSD is presented in figure 3. The organizational structure and the allocation of roles in the other areas in BAM are similar. Figure 3 Organization diagram of the MSD area in BAM
1.3.3 Support teams
1.4 Introduction to the problem situation
1.4.1 Business challenge
The Downstream strategy focuses on operational excellence in all Classes of Business and functions in the Downstream organization. In line with Downstream strategy, BAM aims to provide high quality support services to the business in an efficient way. Therefore all organizations within Downstream IT are required to perform in the top quartile, particularly in the areas of cost and service delivery.12 This means that performance should be within the area of the top‐25% of performers in the market, which is referred to as Top Quartile Performance (TQP).
To achieve this goal, over the past years standard support process have been implemented in the BAM organization, to facilitate the reliable and consistent delivery of IT services to the internal customers in the various CoBs. The standard support processes that were adopted are largely based on the standard ITIL processes. ITIL stands for IT Infrastructure Library and can be considered the industry standard for organizing and managing IT operations based on a number of standard processes. ITIL provides guidance on what these processes should look like and how these could be implemented (Van Bon (ed.), 2008).
Performance in Downstream IT is measured on three dimensions: process maturity, cost and
operational, which together define TQP.13 To measure current performance on process maturity in Downstream IT a third party was hired to conduct a benchmark study. The peer group for this study consisted of organizations of the same size and complexity as Shell, some of them also active in the energy sector. A Process Maturity Benchmarking Model was used, which measures the performance of a number of standard processes and dimensions in the organizations in the peer group on a process maturity scale. Standard service delivery processes of which performance was measured include the Change Management process, the
Incident & Problem Management processes and the Service (Level) Management process.14 These are some of the basic ITIL processes that were implemented in BAM to realize efficient delivery of support services. The benchmark results of 2007 for application support (see appendix 1) show that performance in terms of process maturity of the majority of standard processes and dimensions in BAM is not yet in the league of top‐quartile performers. Also the end‐to‐end application dashboard, used by senior management, shows that application support services do not meet business requirements yet.15 Therefore performance of service delivery processes needs to improve.
1.4.2 Problem situation
A large amount of information is stored on each application for various purposes. BAM management for example uses cost information for financial planning and budgeting purposes, while Business Systems Managers use application information for portfolio management. For application specialists it is important to have insight in the current status of the application service (and the components that realize the service) at all times. Details on the application
12 Downstream IT Functional Plan 2007 – 2012 (sww.shell.com) 13 Downstream IT Quarterly memo (Q3, 2008) sent by Arjen Dorland, Vice‐President and CIO Shell Downstream 14
Change Management, Incident Management, Problem Management and Service (Level) Management are all standard processes defined by ITIL. A description of the first three processes can be found in appendix 3.
15
services16 and data necessary to execute support processes are stored in various administrations. From this point forward this information will be referred to as application and
support data. Since applications or settings in these applications tend to get updated regularly
throughout their lifecycle, application and support data is subject to continuous change. For example, when a minor change is made to an application service, this needs to be reflected in the relevant administrations. The primary administration containing application and support data E‐PIMS receives around 500 requests to update multiple data fields every month for applications in BAM MSD alone.
Application specialists are responsible for the correct, complete and timely registration of application and support data for the applications they are supporting. More emphasis was put on this responsibility lately by adding requirements concerning data maintenance in this year’s GPA (Goals & Performance Appraisal) for all application specialists within BAM. With the aim for TQP in mind, application specialists and Delivery Managers have identified that the quality of application and support data is an area in need of improvement. At the start of the research project that is described in this report, the quality of the application and support data is identified as being insufficient: the necessary data is not always available in the administrations nor does it always represent the correct values or is it up to date.
Causes of problems with data quality
To get more insight in the problem situation, application specialists in BAM MSD and the project principal are interviewed. Various reasons are identified for the incorrectness and incompleteness of data in the several administrations. The main problems are classified in two categories. The first category of problems refers to the data model that is currently in use for storing application and support data. The second category of problems involves the available processes for the registration of this data, the so‐called update processes. 1. Data model • Application specialists are not always aware of the existence of all the administrations they need to update; • Application specialists are not aware of or do not fully understand all the relationships that exist between the various data types in the administrations; • Application specialists do not know which data they are responsible for; • Application specialists do not always understand the purpose of the data types in the administrations. 2. Update processes • Some process documentation is not available or up to date;
to take the responsibility for the correctness and completeness of application and support data as they lack the necessary ‘tools’ and instructions for making the updates.
Consequences
The lack of correct and complete application and support data leads to various problems. If application specialists do not have full insight in the current status of the applications they are supporting, this will lead to less efficient execution of support processes. Management will struggle with making cost reports and defining budgets and the BSMs will find it harder to make sound decisions concerning application portfolios.
Moreover, incorrect data on the current IT infrastructure can lead to interruptions in the functioning of business applications, which could have a major impact on the activities in the Downstream business. If, for example, a refinery planning and scheduling tool is not available, in the worst case scenario this may lead to a slowing down or stop of refinery production, which is very costly. Therefore the quality of some application and support data in is also of high value to the business.
Based on the causes and consequences of the problem situation, it is concluded that the lack of correct and complete data in the administrations is a real problem. To use the words of De Leeuw (2002), this problem is defined as a reality problem, because it is necessary to make changes in the actual situation in order to solve the problem. Application specialists in BAM MSD and all other parties dependent on the availability of accurate application and support data are the main stakeholders of this problem.
1.5 Report structure
Based on the causes of the data quality problem it seems BAM MSD is in need of an improved process for data registration. Therefore the research that is described in this report aims to design a data registration process. Chapter 1 introduces the organization and problem situation. Chapter 2 defines the problem statement and states the research questions. In chapter 3 the research methodology is presented; it explains the type of research, the data sources that are used and the methods that are used to help answer the research questions.
The following four chapters, 4 up to 7, are each aimed towards answering one sub question. Firstly, chapter 4 identifies proven practices with respect to configuration management and especially for designing a data registration process, found in literature and based on expert opinions. The next chapter involves an analysis of the current processes for data registration that are used in BAM MSD and the administrations that are updated by them. The analysis is presented after the identification of practices, because in this order the researcher is able to determine whether these practices are currently already incorporated within the update processes that are found in BAM MSD. Going forward, chapter 6 presents the design of a data registration process for BAM MSD, based on the insights found in chapter 4 and 5 and the design specifications which are stated in chapter 3. Further advice for the deployment of a data registration process and a solution for maintaining data quality is presented in chapter 7.
2 Problem statement and research questions
This chapter presents the problem definition and states the goal of this research. Subsequently it introduces the research questions that are answered in the following chapters of this report.2.1 Problem statement
2.1.1 Problem definition
Application and support data that is stored in various administrations is of insufficient quality to contribute to achieving top‐quartile performance in BAM MSD. Based on the three quality criteria of information in information systems of Bots, Van Heck, Simons and Van Swede (1999), the following issues define the insufficient quality of the data: • Incorrect data in the administrations: 1. Data does not represent the actual status of the application service; 2. Data does not represent the authorized status of the application service; 3. Data is not consistent within and across the various administrations; • Incomplete data in the administrations: 4. Data fields do not contain any or a meaningful value; • Data is not updated in time: 5. Data is not updated in a timely manner after changes in the application service.Regarding issue 1 and 2, data correctness is defined along two dimensions: compliance with respect to business policy or rules and representation of the actual situation. First of all, a relevant party in the organization must authorize a certain state of an application service, based on compliance with business rules or policy, before the data representing this situation is stored in the administrations. Secondly, data in the administrations should represent the actual situation of the application service. The value of a data field in an administration is only correct if it meets both criteria. Officially the specific status of the application should first be authorized, before it is brought into this compliant state in reality. Data that is compliant, but does not represent the actual situation, is incorrect, just like data that does represent the actual situation but is not compliant with the business policy. This is explained in table 1.
Compliant
Yes No
Yes correct incorrect
Actual sit u atio n
No incorrect incorrect
Data inconsistency (issue 3) occurs because the same data is stored in multiple administrations. The values of these data fields should contain the exact same values across the various administrations. If these values are not similar, at least one of them is incorrect, because the value does either not represent the actual situation or is not compliant with business rules. This makes the issue of data inconsistency a sub‐problem of the data incorrectness. Other types of data are not exactly similar but related to each other, by which they influence each other’s value. An example is given: Business rules define that if an application X is assigned a service level “Consumption”, all its instances must also be assigned the same service level. Thus individual instances being versions of application X should not be assigned other service levels than “Consumption”. If, for whatever reason, an instance of application X is assigned a service level ‘’Maintenance”, then it is not compliant with business regulation, and the corresponding data must be fixed.
If data fields do not contain a value when they should or if the value does not have any meaning with respect to the purpose of the data field (issue 4), than the data is recognized as incomplete. Furthermore, data that is not updated in time after changes in the actual situation (issue 5), causes an inconsistency between the administration and the situation in reality.
2.1.2 Research scope
Several parties in Shell are dependent on the current data model that is in use for storing application and support data. In addition, a solution for improving the data quality is required on a short notice. Although this may look an obvious solution, the data model is not considered to be a feasible object of research, as the redesign of a suitable data model would involve a major effort including a multitude of stakeholders for which no time is available, due to a six months time constraint for this research project. Instead, this research focuses on finding a solution by solving the problems that fall in the category of the update processes. Data model Update processes Correctness, Completeness and Timeliness of application and support data
Scope of the research
Figure 4 Scope of the research project
Data registration process
In Galbraith’s (1976) view, as presented in Bots, Van Heck, Simons & Van Swede (1999), this research aims at solving the problem situation by increasing the force of control, instead of simplifying the system itself. Adding an overall data registration process that facilitates the correct execution of the existing update processes enforces the control of data registration in BAM MSD. This situation is presented graphically in figure 5. The update processes itself are not improved by redesigning them, that would imply simplifying the system itself.
Current situation data registration (simplified) Update process A
Admini-stration Admini-stration Admini-stration Update process C Update process B Data registration process
Figure 5 Data registration process ‘controlling’ the current update processes
Data management solution
However, it is recognized that the adoption of a data registration process will not solve all the existing problems concerning the data quality on a short notice. The data registration process only prevents the introduction of new inconsistencies in the administrations. It is highly unlikely that all faulty data will pass through this process within one or two years. Therefore a more extensive solution for data management is necessary that ensures the data quality of application and support data, in which the data registration process serves as a starting point.
2.1.3 Research objectives
Considering all of the above, the goal of this research is defined as follows:
To provide BAM MSD with a data registration process that is part of a data management solution that ensures the correctness, completeness and timeliness of application and support data in all relevant administrations.
The overall research goal is translated into two objectives. The first objective focuses at solving the existing problems around data registration, by
a. the design of a data registration process that ensures the correct and complete registration of application and support data. The second objective aims at an overall solution to this problem and therefore provides b. a system‐level design of a solution for data management that ensures the correctness, completeness and timeliness of application and support data.
quality of data in the administrations, nor its effect on the operational performance of BAM or the business. Suggestions for enforcing correct execution are stated in chapter 6.
2.2 Relevance
2.2.1 Problem area
Optimizing the performance of the delivery of services in an IT organization falls within the area of IT service management (ITSM). ITSM is a process‐oriented discipline that aims for delivery of quality services to customers by effective and efficient IT operations (Galup, Dattero, Quan, Conger, 2007). Nowadays, the ITIL publications are considered the standard approach to ITSM by IT organizations around the world (Van Bon (ed.), 2008). Looking at the goal of this research, this research project falls within the area of configuration management. According to ITIL, the Configuration Management17 process is responsible for maintaining
accurate data on the IT services and the IT infrastructure components necessary to deliver services to customers. According to Van Bon (2008i) one of the sub processes within the Configuration Management process cluster is aimed towards the correct registration of data.
The choice for designing a data registration process is justified by the outcomes of a processes performance study by the IT Processes Institute (2007). The study states as one of its five key findings that ITIL processes are not likely to succeed or deliver expected results when the organization does not have a culture of following well‐documented processes and procedures. This emphasizes the need for well‐documented processes in the organization.
2.2.2 Additional research motives
Top‐quartile performance ITIL claims that Configuration Management is essential for executing the other ITSM processes efficiently and effectively. This is in line with the reasoning of application specialists in BAM MSD, who indicate they need accurate application and support data to be able to execute support processes effectively and efficiently. BAM MSD strives for higher performance in its service operations by more efficient and effective execution of processes, in order to achieve TQP on the operational dimension. This line of reasoning is presented in figure 6.
Figure 6 Line of reasoning
There exists an additional reason for the initiation of this research project by the project principal: the PATIO project.
PATIO project
As it was recognized that information in BAM is scattered throughout the organization ‐ it is stored in various administrations, on websites and in document sharing tools – the PATIO project was initiated. PATIO stands for Processes and Tools to Improve Operation, and aims to implement a tool that will function as a central information portal that is accessible for all
17
application support staff. The tool will provide a single access point for data that is stored in a number of administrations, among which the application and support data. The full implementation of this tool is planned for 2009. Management considers this an opportunity to tackle the problems relating to data registration and data maintenance in these administrations as well. The outcomes and recommendations of this research provide input to the PATIO project.
2.3 Research questions
2.3.1 Main question
Based on the research goal the following main research question is defined:What should a data registration process for BAM MSD look like that is part of a data management solution that ensures the correctness, completeness and timeliness of application and support data in all relevant administrations?
The identification of the relevant administrations18 is part of the analysis phase of this research and therefore these are not determined yet. For the definition of the term process refer to appendix 2. This report uses the term process in its broadest meaning, which implies that it also covers processes detailed in procedures and work instructions. Work instructions could consist of additional documents or ‘tools’ that assist in the execution of the process.
2.3.2 Sub questions
The following sub questions are constructed by which ultimately an answer to the main research question can be given:
1. What should a data registration process look like and how should it be employed to ensure data quality according to literature and expert opinions?
This sub question provides a theoretic background for answering the succeeding research questions. The idea of the first sub question is to find out what are proven practices with respect to a data registration process in the context of configuration management (see section 2.2.1). It is useful to have knowledge of state‐of‐the‐art practices when designing a solution that has to meet explicit requirements, which are listed in section 3.2.1. Insight in these practices also provides implicit specifications for the final data registration process’ design. Additionally, this sub question’s aim is to construct a framework that shows how the data registration process can be incorporated in a solution, by which the data quality can be further enhanced. This framework serves as a benchmark, by which implicit specifications are obtained for the implementation and enhancement of processes that help ensure data quality in BAM MSD.
2. How are the processes for updating application and support data in the various administrations currently organized and to what extent do they incorporate the best practices found in the previous sub question?
The first aim of the second sub question is to identify and analyse the administrations and consequently which update processes exist to have application and support data stored in each one of these administrations. Insight in the current administrations and update processes is essential as they are elements of the data registration process that is
18
designed. The second part of this question is concerned with assessing the current situation, by identifying to what extent the best practices for data registration and data management found in the previous sub question are already incorporated in the existing update processes. This information provides useful input for the design of the data registration process in the next question.
3. What does the data registration process design look like that improves the current situation for BAM MSD?
This question directly aims at answering the first part of the main research question and thereby the first research objective: providing a data registration process that ensures the correct and complete registration of data. The design is presented and it is explained how this data registration process satisfies the predetermined requirements and the implicit specifications obtained from the best practices. Also, some practical recommendations are made towards the implementation of this process within the BAM MSD organization. As this process provides a solution for the existing problems with data registration, a first important step is made towards improving the quality of application and support data.
4. Given the implementation of the data registration process proposed in sub question 3,
what more can be done to ensure the correctness, completeness and timeliness of application and support data in the administrations?
The final sub question aims directly at the second part of the main research question and thereby at realizing the second research objective: providing a solution for data management that ensures the correctness, completeness and timeliness of all the data. This sub question addresses the gaps that still exist after the implementation of the data registration process, based on the implicit specifications obtained from the benchmark. Advice is provided on which actions could be taken in the BAM MSD organization in order to establish a data management solution that ensures the correctness, completeness and timeliness of application and support data.
By the provision of the design of a data registration process (sub question 3) and the provision of a high‐level data quality management solution (sub question 4), which are tailored to the needs of BAM MSD, the main research question is answered. Figure 7 shows how the four sub questions are related and how they are used to answer the main question.
SQ1:
Best practices data registration & maintenance
SQ2:
Current situation data registration BAM MSD Design specifications SQ3: Data registration process SQ4: Data quality management solution
Functional & user requirements
3 Research design and methodology
This chapter discusses the technical research design. First the type of research is defined, and subsequently the design specifications for the data registration process are stated. Following up on this the research approach, or research strategy, is determined and discussed. Next the methods and techniques that are used for answering the various research questions are mentioned. The various data sources, including the techniques for acquiring and assessing these sources are discussed. Finally the design approach that is used during this research is explained.
3.1 Research type
3.1.1 Design‐focused business problem‐solving project
Following the terminology of Van Aken, Berends and Van der Bij (2007), this research can be characterized as a design‐focused business problem‐solving (BPS) project. BPS projects are typical for business student graduation projects. BPS projects aim at improving the performance of a business system, department or company on one or more criteria, by the design of a specific solution (Van Aken, Berends and Van der Bij, 2007). The designed solution is not an end in itself but a means to improve performance. When translating this to the current situation, the data registration process provides the solution design by which application specialists will be better able to conduct their data maintenance tasks, by which application and support data quality can improve, which ultimately helps improve the operational performance of BAM MSD. The criteria that ultimately measure the performance of the solution are defined by the specifications of the data registration process itself, which are listed in the following section.
Next to being performance‐focused and design‐oriented, BPS projects should also be theory based, justified and client‐centred. This research uses the latest literature on ITSM and configuration management, for analysing the current situation and designing the final solution, while being aware of its limitations. The justification involves the explanation of how and why the designed solution will improve the problem situation, which is covered in chapter 6. The main purpose of this research is to provide the project principal and other problem owners with a solution and advice for solving their performance problem. Therefore the analysis of the current situation and the design of the solution are performed up to a level that satisfies these stakeholders.
3.1.2 Design specifications
BPS projects involve the creation of a design, therefore the criteria on which the quality of the design is assessed are now defined. Van Aken, Berends and Van der Bij (p. 24, 2007) suggest four categories in which criteria, that the design of the data registration process will have to meet, can be classified. First the boundary conditions for the solution and the designrestrictions that the ultimate design should respect are stated. Next the functional requirements, which represent the performance demands of the data registration process, and
the user requirements, from the perspective of the application specialists that will have to execute the process, are given. The design specifications are obtained by interviewing the research principal, application specialists in BAM MSD and the process owners of the existing update processes in BAM MSD.
Boundary conditions
• The design has to fit the current organizational structure of BAM and BAM MSD. Changes with respect to the structure of the organization should not be necessary for the implementation of the process. • The design must fit the current IT architecture. This implies that the data registration process will not compromise the current data model and the existing administrations. • The design must respect the existing update processes for data maintenance that are currently available within the organization.
• The process design’s successful implementation must not be dependent on the implementation of a technological support tool, like an automated workflow system for instance. Design restrictions • Preferably, the process should be ready for direct implementation. This requirement strongly relates to the boundary conditions stated earlier. Functional requirements The functional requirements distinguishes between two dimensions: 1. Effectiveness The data registration process must o ensure the data values correctly represent the actual situation; o ensure the data values represent the authorized situation; o ensure consistency of data across the various administrations. 2. Completeness The data registration process must o ensure the data is stored in all necessary administrations; o ensure data modifications are executed as the requestor originally intended; o ensure mandatory data fields always contain a correct value. User requirements The user requirements are also classified in two categories: 3. Transparency The data registration process should
o provide the application specialist with insight in the relationships between existing administrations and available update processes;
o provide the application specialist with insight in their role and responsibility within the update processes;
o provide the application specialist with clear instructions on the correct execution of the update processes;
o provide the application specialist with insight in the current status of the update requests they submitted.
4. Efficiency
The data registration process should
o reduce the effort needed by application specialists to maintain data in the various administrations.
It is emphasized that the four groups of criteria (effectiveness, completeness, transparency and efficiency) are listed in their order of importance. Effectiveness being the most important requirement that the ultimate design will have to meet and efficiency being less important, while it is still a requirement that has to be considered.
Specifications for the data quality management solution
The wider solution that ensures the quality of application and support data also involves a design, however on a system‐level, and thus less detailed. The implicit specifications for this data management solution are obtained by the identification of the best practices in configuration management and from the construction of a framework in the first sub question.
3.2 Case study
3.2.1 General
Next to being a design focused BPS project this research also involves a case study. Verschuren and Doorewaard (1998) characterize a case study as a research by which the researcher tries to gain a deep understanding of one or a few temporary objects or processes, which the researcher cannot influence. Depending on the number of cases that are researched a case study can be either singular or comparative of which different variants exist.
This research project studies data registration in the context of configuration management at BAM MSD and aims to design a solution that can improve it. The existing processes for data registration in BAM MSD form the research object. The researcher cannot influence these existing processes. The processes for data registration are studied at a single company and therefore this research comprises a singular case study.
3.2.2 Advantages and disadvantages
The method of case study has several advantages when conducting practically oriented research (Yin, 1984). First of all this method provides the opportunity to obtain an integral view of the research object, which could be an advantage when aiming for changing an existing situation, as is the case for this research. Secondly case study research is very manoeuvrable as it can adapt to the situation as it unfolds. Another advantage involves the fact that the outcomes of a case study are usually accepted earlier than other types of studies, because the researcher often works on location, being closer to the actual field. A main disadvantage of case studies is the fact the outcomes usually have low external validity, because only a few or just one case is being studied. The fewer cases are being studied, it becomes increasingly difficult to generalise results (Verschuren & Doorewaard, 1998).
3.3 Sources and research techniques
3.3.1 Triangulation
In singular case studies the method of triangulation is very important in order to guarantee the quality of the research (Verschuren & Doorewaard, 1998). Triangulation helps reduce the chances of coincidence in the research to a minimum, by using various sources of information and using several techniques to come to solid conclusions. Therefore this research uses various sources and several techniques for acquiring information from these sources. An overview of the sources and research techniques used per sub question is provided in the following table. The table also indicates in which chapter the various research questions are answered. Report chapter 4 5 6 7 8 Methodology vs. Question 1 2 3 4 Main RQ Persons Interview X X X X X Survey X X Observation X X X Documents Content analysis X X Literature Search registers X X X Snowball principle X X X Table 2 Overview of the sources and techniques used per research question It is emphasized that the methods and techniques used for answering sub question 4 are also based on the outcomes of the analyses in the previous sub questions. The reasons for choosing these sources and techniques for each research question are stated in the following section.
3.3.2 Research questions
1. What should a data registration process look like and how should it be employed to ensure data quality according to literature and expert opinions?
managing IT operations in IT service organizations. And thirdly, ITIL provides substantial information on configuration management, which is the information that is needed. The main search registers that are used include the catalogue of the University Library Groningen, EBSCO host (including Business Source Premier and Academic Search Premier), and Google scholar. Persons Experts in the field of configuration management are interviewed either by telephone or face‐ to‐face contact, because this quickly provides a lot of information and they can help explain and assess the concepts found in literature. The following experts are interviewed because they have in‐depth knowledge and experience with implementing configuration management processes and processes for ensuring data quality:
• Mr. Jan van Bon, who is the CEO of Inform‐IT, editors and innovators. He has been involved in the development of IT service management best practices since the early nineties, managing the production of dozens of publications, conferences and several knowledge platforms. Mr. Van Bon also has several years of working experience as a configuration manager at KPN. • Mr. Erwin Hansen, who is a Senior Manager at KPMG IT Advisory in the business unit Security & Control. Mr. Hansen has over ten years experience in advising companies on the implementation of configuration management processes and processes for maintaining the quality of data in administrations.
2. How are the processes for updating application and support data in the various administrations currently organized and to what extent do they incorporate the best practices found in the previous sub question?
The aim of the second sub question is to clearly map the processes that currently exist for data registration. The processes are modelled using Actor Activity Diagrams (Schaap, 2007), because these are very easy to read and understand for people unfamiliar with the modelling technique. As the report is also intended for a varied audience, among which application specialists, this seems a suitable method. In order to produce these process models, both documents and persons are used as a source.
Documents are used because in Shell an enormous amount of documentation is available via the global intranet. Mainly the documents covering the existing update process, the so‐called
process documentation, is used, and information is obtained from them by qualitative content
analysis. Also the characteristics of the administrations involved and the data these administrations contain is derived from this documentation. However, finding the right documents and assessing the value of these documents may cause trouble. Therefore application specialists, process owners and documentation owners are interviewed, by using semi‐structured interviews, that can help clarify documents and focus the attention of the researcher to additional useful documentation. Also observation is used as a technique to identify how application specialists execute the processes in reality.
3. What does the data registration process design look like that improves the current situation for BAM MSD?
on the predetermined criteria, by using surveys and interviewing them to hear their experiences. Additionally the researcher also observes how the application specialists use the data registration process and its documentation in reality, which can give indications on whether the process is transparent and efficient enough.
4. Given the implementation of the data registration process proposed in sub question 3,
what more can be done to ensure the correctness, completeness and timeliness of application and support data in the administrations?
The aim of the final sub question is to provide recommendations on the deployment of a data quality management solution, based on the benchmark constructed in sub question 1. Sub question 2 identifies to what extent the specifications obtained from the framework are met. Based on the knowledge obtained from literature and experts, and from the outcomes of sub questions 2 and 3, advice is given for establishing the various elements in the framework that are not yet adopted in the organization. Hereby a high‐level solution is provided that prescriptively ensures the correctness, completeness and timeliness of application and support data.
3.4 Design approach
As mentioned before this research can be characterized as a design‐oriented research project, because it aims to design a process for data registration and a wider solution for data management in order to improve the quality of application and support data in various administrations. When designing something, regardless whether it involves a product, a service or a process, it is worthwhile to use a development process. The use of a well‐defined development process is useful for several reasons, among these are (Ulrich & Eppinger, 2003):
• Quality assurance: a development process specifies the phases a development project will pass through and the checkpoints along the way. Following the development process is one way of assuring the quality of the resulting design;
• Coordination: a clear development process acts as a master plan which defines the roles of each of the players on the team or stakeholders of the project. The plan informs the team or stakeholders when their contributions are needed and with whom they will need to exchange information;
• Planning: a development process contains milestones, corresponding to the completion of each phase. The timing of these milestones anchors the schedule of the overall development project.
As the goal of this research is to satisfy the requirements that were set at the start of this project, it is useful to build in checkpoints in order to assure the quality of the design. Additionally an overall project plan helps, as there is only a limited time available to realize the project and it helps to communicate to the project’s stakeholders (e.g. application specialists, project principal) at which points in time their input is needed. Therefore a development process is used as the method for designing the final solution.
Various authors have described a development processes (a.o. Crawford & Di Benedetto, 2006; Cooper & Kleinschmidt, 1993). However in this research Ulrich and Eppinger’s (2003) generic
product development process is used. Firstly, because this development process is generic,
useful considering the limited time available for the project. Nonetheless a few small design iterations are planned during the testing phase. Figure 8 Process flow diagram of the Generic Product Development Process (Ulrich & Eppinger, 2003) The activities that each phase entails for this design‐oriented research project are given: Planning: This phase involves the identification of a business need and states the overall goal of this project, as can be found in chapter 2.
Concept Development: In this phase the specifications of the final solution are determined.
This phase also concerns the collection and assessment of proven concepts, more specifically: best practices, obtained from literature and opinions of experts. The design specifications are also determined during this phase and can be found in chapter 3. Implicit specifications for the final data management solution are found in chapter 4.
System‐Level Design: For physical products this phase would imply the decomposition of
products into subsystems and components. In this research it covers the definition of the various elements or ‘tools’ that the application specialist will need to execute the data registration process. One can think of sets of instructions or documents visually representing the process, necessary for supporting the correct execution of the data registration process. It also includes the analysis of the elements that will be part of the final solution, the existing update processes, as can be found in chapter 5. Detail Design: Continuing on the previous phase, this phase involves the detailed design of all the various elements of which the final design exists. System‐level design and detail design in this research are performed as one general design phase. Testing and Refinement: This phase involves the testing and evaluation of a few prototypes of the data registration process for BAM MSD that are close to the final design already. A pilot is organized to have the end‐users (application specialists) test the process in practice. During the pilot phase the details are further refined, based on the input that participants provide during the pilot. At the end of the pilot, the participants are requested to fill in a survey based on their experiences, in which they assess the latest prototype on the predetermined criteria. Involving end‐users in the testing of prototypes is very useful when the final solution’s success is heavily dependent on user acceptance. With this input some final enhancements are made before the final design of the process is ready for implementation. The final outcome of the design process is presented in chapter 6.
Production Ramp‐Up: This phase involves the implementation of the data registration process
in the organization. This project only involves the first preparations for taking the data registration process in full ‘production’: It includes the training of the personnel and the launch of the process, by which it comes widespread available for all application specialists in BAM MSD that will have to start using it, as chapter 6 illustrates.
The different project phases are not executed in an exact sequential order, for reasons of efficiency, but the majority of the phases contains a milestone at which the product of each phase is critically assessed. To give an example: the list of design specifications could still grow during the phases of design and even during testing and refinement.
