Appendices
These appendices form an integral part
of the master thesis report
List of appendices
Appendix 1: Benchmark results for Downstream IT BAM
Appendix 2: Definition for process, procedure and work instruction
Appendix 3: Service Support processes as defined by ITIL V2
Appendix 4: ITIL V3 process model and service model
Appendix 5: ITIL criticism
Appendix 6: Actor Activity Diagramming
Appendix 7: Administrations-data matrix
Appendix 8: Quick Overview update processes
Appendix 9: Process flows of the End2End Data Administration process
Appendix 10: End2End process flow instructions
Appendix 1: Benchmark results for Downstream IT BAM
Appendix 2: Definition for process, procedure and work instruction
Process: a sequence of interrelated or interacting activities transforming inputs into outputs,
designed to accomplish a defined objective in a measurable and repeatable manner.
A process description defines what will be done, what input is required, and what output is
produced. A process can be detailed in one or more procedures, and subsequent work
instructions (Hoving & Van Bon, 2008).
A procedure is a specified way to carry out an activity or a process. It describes the “how” and
can also describe “who” carries out the activities. A procedure may include stages from different
processes and van very depending on the organization.
A set of work instructions defines how one or more activities in a procedure should be carried
out in detail, using technology or other resources.
The ISO 9001 quality model discriminates between processes, procedures and work instructions.
Appendix 3: Service Support processes as defined by ITIL V2
The descriptions of these processes are based on the textbook Foundations of IT Service
Management – op basis van ITIL (Van Bon (ed.), 2007).
Incident Management aims to restore (small) interruptions of the IT services as quickly as
possible. One should think in terms of days or hours of restoration time. All incidents are
registered. The incident administration supports the effectiveness of other ITSM processes, like
the Problem Management process for example.
If there is a presumption that a structural problem exists in the IT infrastructure that has to
deliver the service, then Problem Management will start an investigation to identify the root
cause of the problem. The presumption is often based on a number of incidents that have
occurred in the past. The aim is, however, to anticipate problems. If the root cause is found, it is
decided based on financial and business grounds whether a structural improvement of the IT
infrastructure is necessary. An improvement is realized by the implementation of a change.
Change Management is responsible for implementing changes to the IT infrastructure in a
controlled way. Changes are implemented following a trajectory of: definition, planning, build
and test, acceptance, implementation and evaluation. The purpose of this process is to
determine whether changes are necessary and align this with the other stakeholders in the
organization, to ensure a change does not have negative implications for the delivery of IT
services. Changes can be initiated by customers (end-users), Problem Management, or people
responsible for the Configuration Management processes.
Configuration Management has responsibility over the configuration control of the
ever-changing IT infrastructure, identification of IT service components, and the provision of
information on the current status of all IT infrastructure components to the other ITSM
processes. Configuration Management works closely together with Change Management and
Release Management.
Appendix 4: ITIL V3 process model and service model
ITIL V3 Service model
Appendix 5: ITIL criticism
ITIL in practice
Much of the ITIL scepticism comes from organizations who do not understand the use of ITIL.
Many think, by the claims of marketers, trainers, consultants and vendors, that ITIL is something
they can blindly adopt and implement (a.o. Van Bon & Hoving, 2008; Fry & Turbitt, 2007;
Marquis, 2006). Unfortunately for these organizations they will come to learn that this is
impossible. ITIL is not an out of the box solution, it simply describes the things one should take
into account when designing processes for an IT organization. It defines processes on a high
level, stating what organizations should do, not how to do it.
Processes versus functions
Nowadays, various ITSM practitioners argue that the V3 process model, consisting of at least 25
processes and activities, has become too extended and to complicated to use as a framework
for guidance on implementation (a.o. Van Bon, 2008i; Droog, 2007; Marquis, 2006). The reason
for the ITIL process model becoming so extensive, according to Hoving and Van Bon (2008), is
that ITIL does not clearly discriminate between processes and functions. ITIL publications are
very vague when describing whether the elements in the ITIL V3 process model are processes or
functions. The basic difference between a process and function is that they describe the same
organization along different dimensions. Processes only describe activities, while functions also
cover the people and product factors (Hoving & Van Bon, 2008). So functions consist of certain
capabilities: people that execute the activities using certain products or technology (Van Bon,
2008i). Processes only describe the order in which activities should be executed.
Figure A. 4 Separation of processes, procedures and work instructions (Hoving & Van Bon, 2008)
Appendix 6: Actor Activity Diagramming
General
Actor Activity Diagramming (AAD) is a tool for modelling business processes. By its design AAD is
especially useful for communication and discussion about business processes oriented issues
like performance or information technology enabled redesign (Schaap, 2007). AADs are
characterized by the little amount of available design elements (the syntax) and therefore
remain comprehensive.
Syntax
Actor Activity Diagrams must always be interpreted top-down: Activities and transactions are
modelled along the vertical lanes in a chronicle order. The vertical lanes represent the actors. A
dashed vertical lane represents an information system, in this report representing the
administrations. Grey boxes represent the activities performed by the corresponding actor.
White boxes connected by a horizontal line represent a transaction; e.g. the transfer of
information or an object, like a document, e-mail, product, etc. For a complete overview of
Actor
Activity
Diagramming
and
its
syntax
elements,
refer
to
the
website
http://www.aadmodeling.eu
.
Common elements in data update processes
AADs must always start with a transaction “à charge”, represented by the letter C in the first
white boxes. For this reason it was decided to include the “Requestor” always as a first actor in
the process. An example is give in figure A. The Requestor’s request represents the immediate
reason to initiate an update process. The update process itself is always started by Actor 1,
which is usually the application specialist and in some cases a Team Lead or a Delivery Manager.
The roles of Requestor and Actor 1 are in reality both very often taken on by the application
specialist, since he is the one responsible for the correctness and completeness of data in the
administrations.
Figure A Figure B
AADs should always end with transactions “à décharge”. In this case it represents a notification
of the successful execution of an update to the original requestor (figure B).
Triangles pointing to the left or right represent conditions: the process only follows that course
if a certain condition is met. A grey box including a the letter B represents a batch activity.
‘Cc’ refers to a copy of an e-mail to the second actor, while the original is sent to the third actor.
The similar action is shown in figure D, only this time it shows a backward transaction.
Figure C Figure D
Appendix 7: Administrations-data matrix
•
Sheet 1: Administrations-data matrix
•
Sheet 2: Supplement A
Administrations-data matrix
E-PIMS AssetCenter ServiceCenter Tier Finder Primus TW systems SAGE
Field Name Required Stream
Key Identification Details
Application ID M PM / 1 / 2 External ID* Application ID AssetCenter ID* Glotime code* Application ID
Instance ID M PM / 1 / 2 External ID* Instance ID AssetCenter ID* Instance ID
General Application Details
Application Name M PM / 1 / 2 Application Name Popular Application
Name*
Glotime code*
Business Area M PM / 1 Category
Portfolio Manager M PM / 1
Instance Details Mandatory (if applicable)
Instance Name M 1 / 2 Asset Tag* (for
Application Services)
Instance Name Common Application Name*
Application Name* (for script)
Version P 1 Version (number)
Manufacturer M 1
Supplier P 1 Supplier Name
Lifecycle Status M 1 Assignment*;
Status (Asset)*; Operating Mode*
Date Released M 1
Entity Owner M 1 Model*
Application Owner M 1 Application Owner
GI-D Number M 1a / 1 GI-D Number
M 1 Sold-to Code^ Sold-to Code^
M 1 Year-end Freeze
Disaster Recovery M 1
Reason for Decommission P 1 Reason for retirement
Retirement Date P 1 Retirement date
Instance Details Additional
ASPD ID P 1
Country of Origin P 1
Strategic Fit Override P PM / 1
Number of Users P 1
Covered In BCP Plan P 1
Comment (Instance) P 1
Countries & Sites used (per Instance)
Countries Used P 1
Sites Used P 1
Support Details (per Instance)
Handling Team M 1 Application Support
Handling team
Application Support
Handling team Support Organization*
Sub-handling Team M 1
M 3 Support group Support Group Support Group
M 3 Change approver Change Approval
Group
Focal Points (per Instance)
E-PIMS AssetCenter ServiceCenter Tier Finder Primus TW systems SAGE
Field Name Required Stream Corresponding data fields
Business Systems Manager M 1
Business Owner Contact M 1
Application Specialist M 1 / 3 Customer FP* Assignment group
member*
Application Specialist Application Specialist* Technical Focal Point
Service Management Details (per Instance)
SLA Reference ID M 2 Contract "Purpose"* Product Type* SLA Grouping* Product Type*
Link to Documentation 2
SLA Status 2
SLA Level 2
Support Level M 2 Contract "Purpose"* Product Type* Support Level Product Type*
Business Critical P 1 Business Critical
Sox Relevant P 1 Sox 11 Indicator
Information Classification P 1 Information
Classification
External Face to Application P 1
Third Party Access P 1 Third Party Accessible
ECCN for Instance M 1
ECCN Status for Instance M 1
ECCN for Data M 1
ECCN Status for Data M 1
M 4 Asset Tag* (for
Server/Environment)
M 4 / 1 ID# (Supervisor)*
M 4 / 1 Description/ Comment*
Costs (per Instance; sometimes per Application)
Comments P 1
Cost Source P 1
Offshore Personnel Costs P 1
Contractor Personnel Costs P 1
Third Party Hosting Costs P 1
Third Party Telecom Costs P 1
Third Party Professional Services Costs
P 1
License and Maintenance Costs
P 1
Other Third Party Costs P 1
Shell Personnel Costs P 1
Shell Telecom Costs P 1
Other Shell Costs P 1
Compliance Details (per Instance)
Administrations-data matrix: Supplement A
Data field Dependent on Source Pick list Value description
External ID Application ID
Instance ID
E-PIMS E-PIMS
No <Application ID>-<Instance ID> Asset Tag
(for Application Services)
Instance Name E-PIMS No <CoB>*-<Instance Name>
* CoB prefix is no longer required or recommended.
Asset Tag does not have to be completely similar to the Instance Name, as long as it is clear that they represent the same application service.
Asset Tag
(for Server/Environment)
No The server ID, as listed in the .../Server/ directory of the AssetCenter category list.
Assignment Lifecycle Status E-PIMS Yes Describes the assignment status of Application Service and must be aligned with the lifecycle status. Example values are <In use> or <Retired>.
Status (Asset) Lifecycle Status E-PIMS Yes Describes the current status of the Application Service and must be aligned with lifecycle status. Example values are <Supported>, <Customer supported> or <Third Party supported>.
Operating Mode Lifecycle Status Fallback Instance
E-PIMS E-PIMS
Yes Describes the operating mode of the Application Service and must be aligned with lifecycle status and fallback instance. Example values are <Acceptance>, <Backup> or <Fallback>.
Model Entity Owner
Handling Team Sub-handling Team
E-PIMS E-PIMS E-PIMS
Yes Describes the Class of Business within Downstream in which the Application Service is used, for example:
/Service/Application services/DS - Downstream/<xxx>
Customer FP Application Specialist E-PIMS No RacfID (ComputerID) of the application specialist responsible for the Application Service.
Contract "Purpose" Support Level SLA Reference ID
Tier Finder E-PIMS
No <SLA Reference ID>-<Support Level>
ID# (Supervisor) No Computer ID (RacfID) of an BAM CQAT member (Configuration Quality
Assurance Team). Example: Russell Guinn - RG184158 Description/Comment External ID
Instance Name
AC E-PIMS
No <External ID>-<Instance Name>
= <Application ID>-<Instance ID>-<Instance Name>
This value should be entered in the Description/Comment field in ServiceCenter.
Data field Dependent on Source Pick list Value description
Assignment group member Application Specialist E-PIMS No The application specialist's ComputerID (RacfID), of the application specialist or team lead that is a member of the respective assignment group. To have the have an assignment group member updated, one should follow stream 3.
Product Type Support Level
SLA Reference ID
Tier Finder E-PIMS
No The Product Type refers to the service level that is assigned to an application service in ServiceCenter/AssetCenter. It is based on the Support Level and SLA Reference ID.
Data field Dependent on Source Pick list Value description
SLA Grouping SLA Recerence ID E-PIMS No SLA Grouping is similar to the SLA Reference ID in E-PIMS. It defines the SLA category.
Relationships AssetCenter data fields
(Configuration Management process)Relationships ServiceCenter data fields
(ServiceCenter Master Data update process)Data field Dependent on Source Pick list Value description
AssetCenter ID Application ID Instance ID
E-PIMS E-PIMS
No The AssetCenter ID in Primus is exactly the same as the External ID in AssetCenter. Thus, the value that should be entered here is: <Application ID>-<Instance ID>
Popular Application Name Application Name Instance Name
E-PIMS E-PIMS
No The popular application name in Primus is the name of the application as it is known by the business end-users. The popular name is based on the
application and or instance name and can also be an abbreviation. Often multiple popular application names are stored in Primus.
Product type Support Level
SLA Reference ID
Tier Finder E-PIMS
No A copy of the Product Type value in Service Center is also stored in Primus. Additional information on Primus:
Contact Information Scripts: contain contact details of the application specialist and support handling teams responsible for support; Escalation and Information
Scripts:
contain the assignment groups to which an incident or change should be routed in ServiceCenter; Solution Scripts: contain basic solutions for known problems with the application or instance.
Data field Dependent on Source Pick list Value description
Glotime code Application ID
Application Name
E-PIMS E-PIMS
No The Glotime code is actually the timewriting code or "activity code" that can be activated in a timewriting tool to assign worked hours to a user. It is represented by the application name. All BAM supported applications should have 1:1 relation with a unique Glotime code. A list of these relations is maintained by Vasundhara Akella and Parul Singh (IBM Offshore staff).
Application Specialist Application Specialist E-PIMS No Computer ID (RacfID) of application specialist.
Data field Dependent on Source Pick list Value description
Application Name (for script) Application Name Instance Name
E-PIMS E-PIMS
No The Application Name for scripts can differ from the official application and or instance name, since often there exists not a 1:1 relation with applications or instances.
Support Organization Handling team E-PIMS No This field should contain exactly the same as the Handling Team field in E-PIMS. However over the years various names have been entered in SAGE, that are not fully aligned with the Handling Team names in E-PIMS.
Relationships Primus data fields
(Primus Script update process)Relationships Timewriting Systems data field
(Timewriting Systems Setup process )Relationships SAGE data fields
(Downstream Application Scripting process)Administrations-data matrix
Bold
Data fields in bold represent the master data source. There should only be one bold data field per row. Data fields in other administrations in the same row should contain the exact same value or have a certain kind of relationship with the master data source value. If there is no bold value in a row, then the master data is stored in another administration that is not the responsibility of BAM. *
Data fields marked with a * (star) are not direct copies of values in corresponding administrations, but have another relationship with values of data fields in the same row. These relations are explained in the Supplement A sheet.
^
The Sold-to Code is always linked to a person or an organizational entity. The Sold-to Code in AssetCenter is always linked to the corresponding application specialist (Customer Focal Point), who is responsible for the application or instance under consideration. The Sold-to Code in SAGE usually refers to the application specialist who requested the application script, but could also refer to the business owner of the application or the CoB in which the application is used.
Light Green filling
Data fields with a green filling can only be created or modified by the Portfolio Manager. This goes for all data fields which are stored on the application-level in E-PIMS. Update requests with respect to these fields should always be submitted to the responsible Portfolio Manager of that specific application.
Red filling
Data fields that have a red filling will get updated automatically once an update to the master data value in the same row has been requested. There is no need to request an update to this field as the misalignment will be detected by the monthly E-PIMS - Tier Finder audit. Values in a cell with red filling are the responsibility of the Global Service Management team (DS IT BAM-SLA Repository SIPC-OFI/19).
Tan filling
Data fields that have a tan filling will get updated automatically once an update to the master data value in the same row has been requested. There is no need to request an update to this field as any misalignment is detected during the bi-weekly E-PIMS - AC compliance data audit. Values in a cell with tan filling are the responsibility of the Global Configuration Management team (DS IT BAM Global Configuration Management).
Grey filling
It is not recommended to update the Asset Tag field, if caused by a name change of the Instance Name in E-PIMS. Updating the Asset Tag name involves retiring the asset and then re-creating it and thereby losing all the former asset's history. For further information please contact the Configuration Management team (DS IT BAM Global Configuration Management). PM
PM stands for Portfolio Manager. Updates to E-PIMS fields that have PM listed in the Stream column have to be authorized by the Portfolio Manager. In most cases the PM will modify the data himself. Only the PM is allowed to have data updated on application level in E-PIMS.
Quick Overview update processes
BAM MSD Instance Request template
This template should also be available at:
http://sww.shell.com/downstream/it/portfolio/e-pims/
Scope Change Request template
Mandatory approvers are listed in
Scope Change Management process documentation.
Request documentation at
CoB Compliance Focal Point
For the list of CoB Compliance Focal Points consult the
SIPC-BAM-Compliance-Office@shell.com Compliance Anchors Network document
This template should also be available at Documentation should also be available at Documentation should be available at
http://sww.shell.com/downstream/it/delivery/bam/app_compliance/ http://sww.shell.com/downstream/it/delivery/bam/app_compliance/ http://sww.shell.com/downstream/it/delivery/bam/compliance.html
BAM AssetCenter template
This template and three email templates that should be used to submit the AssetCenter template are available at:
http://sww.shell.com/downstream/it/delivery/bam/change/configuration.ht ml
ITSFE ServiceCenter Master Template
This template should be available at
GLL Workspace: Data Update Process & Templates attention to: Service Center User Admin (SCUA)
Business Systems Manager* Service Management Delivery Focal Points
Major Tier Changes need additional approvals from various people. Consult the Tier Change Procedure documentation.
Request the templates and slide pack at Request the documentation at
DS-IT-BAM-SLA-Repository@shell.com DS-IT-BAM-SLA-Repository@shell.com
Template and slide pack should also be available at Documentation shouls also be available at
http://sww.shell.com/downstream/it/delivery/bam/svce_mgt/ http://sww.shell.com/downstream/it/delivery/bam/svce_mgt/
Staff Movement form (WFA) Staff movement requests need to be submitted
by team leads or delivery managers DS-BAM-WFA-Mailbox@shell.com
TW Tool Code Setup form is available in Timewriting System Setup document
Timewriting code setup requests need to be submitted
by team leads or delivery managers Timewriting System Regional Focal Point**
GI-D Scripting Request template
Request template at
DS Global GI-D Scripting Coordinators
Send request to appropriate regional coordinator as stated on
DS-IT-BAM-Global-GID-Scripting-Coordinators@shell.com http://sww.shell.com/downstream/it/delivery/bam/script/
BAM Contact Information Script template BAM Escalation and Information Script template
BAM Solution Script template
These script templates are also available at
http://sww.shell.com/downstream/it/delivery/bam/asd/
* List of Business Systems Managers ** Timewriting Regional Focal Points:
Innate US: SOPUS US Timewriting Administration-IT SOPUS
WebTime AP: MALAYTR AP-Webtime-Support-ADP MALAYTR
WebTime EU & LA: SNV Webtime support ADPBAM EU SNV-SNV
If unsure about how to execute one of the update processes, please refer to the background documentation "Analysis of Data Update
Processes.doc". This document contains extended process flows of all the update processes.
Minor Tier Change template and Major Tier Change template
(can be found in the Tier Change Procedure v1.4 slide pack)
DS-Application-Support-Desk-Global@shell.com
Attention to the ASD analyst that is responsible for the script under consideration. None
Business Systems Manager*
SC Master Data update process ServiceCenter None
(Application Support Desk will obtain necessary approvals)
Configuration Management process AssetCenter None DS-IT-BAM-Global-Configuration-Management@shell.com
DS-Application-Support-Desk-Global@shell.com
E-PIMS Instance Request update process E-PIMS
TW Systems Setup process
Tier Finder E-PIMS AssetCenter ServiceCenter Primus Innate WebTime WFA administration SAGE
Downstream Application Scripting process Tier Change Procedure
Compliance Scope Management process E-PIMS
Submit to
Primus Script update process
Data Update Process Covers Templates Approvals
BAM MSD Delivery Manager
(Eddy, Fook-Seng, Marianne, Phillipe or Susan)
Note: Always use the latest templates available!!! Do not store templates on your own hard drive, but request the latest template at the focal point or process owner as listed in the table. Or find the latest template on the appropriate website or in Global LiveLink.
Primus
DS-BAM-MSD-EPIMS-Mailbox@shell.com
Americas and Oil Sands: Susan Shomette Global Distribution: Todd Wyborney Oceania Regional: Andrew Olennick Asia Regional: Fook-Seng Chee Global Supply: Yee-Tieng Chew Europe Regional: Marianne Van de Velde-Overweg
Appendix 9: Process flows of the End2End Data Administration process
•
Onboarding process flow
E-PIMS
* Start: Follow the flow and initiate the required update processes. 0. Before the application specialist can start to onboard an instance, an application entry in E-PIMS must exist. Only Portfolio Managers own the rights to create or modify E-PIMS entries on the application-level. 1. Request the creation of the instance in E-PIMS by starting the Instance Request update process. Fill all mandatory fields for data creation, as far as possible, in the Instance Request template. 2. Initiate the Compliance Scope Management process in order to have the compliance data fields filled in E-PIMS.
3. Request the creation of a new assignment group, only if no assignment group exists yet for the instance you are onboarding. A ServiceCenter assignment group must exist before you can create an application asset in AssetCenter and link it to the assignment group.
4. If no timewriting activity code is available for the application, or if timewriting codes should also be made available on the instance-level, initiate the Timewriting System Setup process for activity codes. In general, timewriting codes are assigned on the application level, however various instances also have specific timewriting codes defined on the instance level.
5. Request the creation of an application asset in Assetcenter by initiating the Configuration Management process.
All E-PIMS instances must have a corresponding application asset stored in AssetCenter. 6. Initiate the Tier Change Procedure to have the correct service level assigned to the instance in the relevant administrations.
An application and its instances should all be assigned the same service level.
7. Start the Downstream Application Scripting process, to request a new scripted software version, if the necessary software script is not yet available. The software script details are stored in SAGE.
8. Have the necessary support information for the instance stored in Primus by initiating the Primus update process.
* End: Continue at the verification step (step 4) of the End2End Data Administration process. Instance Request update process Tier Finder Tier Change Procedure ServiceCenter TW Systems AssetCenter Configuration Management process SC Master Data update process SAGE Primus Compliance Scope Management process Downstream Application Scripting process Primus update process Timewriting System Setup process End* Start* 4 1 2 3 6 5 7 8 0
ServiceCenter SC Master Data update process AssetCenter Configuration Management process Start*
Stream 1
* Start: Continue at stream 1(a), 2, 3 or 4 of the flow. * End: Continue at “Start” of the flow or proceed to the verification step (step 4) of the End2End Data
Administration process.
The Evergreening process flow contains four streams: 1. All data types, except for:
1a. New / changed GI-D script number 2. Service level/ SLA group updates 3. Assignment group updates 4. Server changes
** The Compliance Scope Management process is not yet in scope for Stream 2. However, in the future this could become a possibility.
AssetCenter Configuration Management process TW Systems Timewriting System Setup process SAGE Downstream Application Scripting process Primus Primus update process Tier Finder including: E-PIMS AssetCenter ServiceCenter Primus Tier Change Procedure AssetCenter Configuration Management process Primus Primus update process End* E-PIMS Compliance Scope Management process
**
E-PIMS Instance Request update process Compliance Scope Management processStream 2
Stream 3
Stream 4
S
tr
e
a
m
1
a
E-PIMS Tier Finder E-PIMS Instance Request update process Compliance Scope Management process SAGE Downstream Application Scripting process ServiceCenter SC Master Data update process Primus Primus update process End*
* Start: Follow the flow and initiate the required update processes
1. If the application instance currently is in Application Security Compliance scope (e.g. ISIP or SOx), a request to de-scope the application instance must be submitted by initiating the Compliance Scope Management process. 2. Submit a request to set the Lifecycle Status of the instance in E-PIMS to “planned decommission”. Also the fields Retirement Date and Reason for Retirement should be filled appropriately.
Nowadays instance entries are not physically deleted anymore.
3. Submit a request to retire the corresponding application asset* in the AssetCenter database by initiating the Configuration Management process. One should set the Assignment field to "retired” and Status field to “not supported” when filling in the AssetCenter CI Request template.
* Each application instance in E-PIMS should have a corresponding application asset in AC. 4. Submit a request to remove the application instance entry from the Tier Finder sheet by initiating the Tier Change Procedure.
5. Submit a request to remove the corresponding scripted software version from SAGE by initiating the Downstream Application Scripting process. Only do this if the software has become obsolete, thus is not in use anymore by other application instances on another location.
Before a removal request is submitted one should make sure that all users are disconnected from the software version that is currently ‘in production’. This can be checked in ActiveDirectory.
6. Submit a request to have the corresponding application script(s) removed from the Primus knowledge base by initiating the Primus update process. All application assets should have a separate corresponding entry in Primus.
7. If, by decommissioning the instance, an assignment group becomes obsolete, the assignment group should be deleted from ServiceCenter by initiating the SC Master Data update process.
8. If the instance has a corresponding timewriting activity code in one of the timewriting systems (Webtime and/or Innate), one should request to remove the timewriting activity codes (Glotime codes) by following the Timewriting System Setup process for timewriting activity codes.
In general, timewriting codes are assigned on the application level, however various instances also have specific timewriting codes defined on the instance level.
9. Finally, submit a request to set the Lifecycle Status in E-PIMS to “decommissioned”.
* End: Continue at the verification step (step 4) of the End2End Data Administration process. AssetCenter Configuration Management process Tier Change Procedure TW Systems Timewriting System Setup process Start* 1 2 3 4 5 6 7 8 Instance Request update process 9
End2End process flow instructions
The process steps
The End2End Data Administration process contains three main process steps in the
following order:
1. Identify the impacted data
2. Initiate the relevant update process(es)
3. Execute the data updates
4. Verify the modified data
Figure 1: Four basic steps of the End2End Data Administration process
The first and the last process steps always contain the same activities for every (set of)
update(s) one makes. The second step, however is variable, because based on the types of
data you wish to update you will have to choose the relevant process flow and possible
stream(s) in the process flow. The third step “execute” involves the actual modification of
data, which is never performed by an application specialist. It represents the execution of
various activities within the specific update process by other actors, e.g. global process
teams, database administrators and offshore staff.
Three application lifecycle phases
The End2End Data Administration process distinguishes three different phases. The three
phases correspond with the application lifecycle phases in which an application can
reside. Each of the phases has a separate process flow that should be followed.
Figure 2: End2End Data Administration lifecycle phases
Onboarding When an application is onboarded all mandatory data needs to be
registered in the relevant administrations for the first time. The application itself is not in
production yet.
Evergreening During the time the application is in production, changes and updates to
the application are made, and the data in the administrations needs to be updated
accordingly to reflect these changes.
Decommissioning
At some point in time the application will not be used anymore,
because it is replaced by a newer application and needs to be retired. The production
status of the application has to be set to a “decommissioned” or “retired” status in the
administrations. In some cases the applications need to be completely removed.
The Onboarding and Decommissioning process flows do not vary themselves. For
onboarding and decommissioning always the same data needs to be created, updated or
deleted. The Onboarding and Decommissioning process flows do contain optional update
processes, though.
The Evergreening process flow must be used during the time the application (instance) is
in production. Updates of application data during the ‘in production’ phase are caused by
changes in the application or because of inconsistencies in the data between the several
administrations. As the data that needs to be updated varies, the process flow for
Evergreening is variable.
Four streams
The Evergreening process flow distinguishes four streams. Every stream covers updates
to a predefined set of data types.
Stream 1: All data types that have E-PIMS as master data source.
Stream 2: Service level and SLA data, for which Tier Finder is the master data source.
Stream 3: Assignment group data, which is primarily stored in ServiceCenter.
Onboarding Evergreening Decommissioning
Stream 4: The mapping of “Server/Environment” assets to “application service” assets in
the AssetCenter CMDB.
Evergreening phase: Process/ procedure/ work instructions
Process steps
Process Activities
Instructions / Guidelines/ Tools
• Identify necessary data updates Identify the (set of) data fields that need to be updated using the
Administrations-data matrix. Clarifications on data relationships can be found in the Supplement A sheet.
• Determine relevant End2End Data Administration process stream
Look up the relevant process stream(s) for the data types in the “Streams” column of the Administrations-data matrix.
1 . Id e n ti fi c a ti o n
• Continue at relevant process stream(s) Continue one or multiple process streams in the given order. The End2End
Data Administration process flow shows the four separate streams. • Determine relevant E-PIMS update
process
The Compliance Scope Management process is exclusively used to update compliance data, as listed in the Administrations-data matrix under the Compliance Details (per Instance) header.
• Initiate E-PIMS update process(es) Initiate E-PIMS Instance Request process or Compliance Scope Management process or both. Use the Quick Overview to initiate update processes.
• Initiate other relevant update processes in given order
Use the Administrations-data matrix and Supplement A to identify the necessity of updates in AssetCenter, TW systems, SAGE and Primus respectively. If relevant: initiate corresponding process. If not relevant: continue following the process stream.
Stream 1
• Continue at next stream or progress to Confirmation phase (step 4).
If relevant, continue at Stream 2, 3 or 4. Otherwise progress to Confirmation step.
• Initiate Downstream Application Scripting process
Use the Quick Overview to initiate update processes. Stream 1a
• Continue process at start of Stream 1
• Initiate Tier Change Procedure The Service Management team handles the updates of corresponding service level and SLA data in Tier Finder, E-PIMS, AC, SC and Primus.
Use the Quick Overview to initiate update process.
2 . In it ia ti o n Stream 2
• Continue at next stream or progress to Confirmation phase.
• Initiate SC Master Data update process • Initiate other relevant update processes
in given order
Use the Administrations-data matrix and Supplement A to identify the necessity of updates in AssetCenter and Primus respectively. If relevant: initiate corresponding process. Use the Quick Overview to initiate update processes. If not relevant: continue process stream.
Stream 3
• Continue at next stream or progress to Confirmation phase.
If relevant, continue at Stream 4. Otherwise progress to Confirmation step. • Initiate Configuration Management
process
Use the Quick Overview to initiate update process. Stream 4
• Continue at Confirmation phase
• Confirm requested data modifications Once you receive an update notification, confirm in the administrations whether the update was made as you originally requested.
If you do not receive an update notification within a reasonable amount of time, please make inquiries yourself at the data modifier, process owner or relevant focal point.
4 . V e ri fi c a ti o n
• Communicate successful update to requestor
Notify the original update requestor of the update if you are not the original requestor yourself.
Appendix 11: Questionnaire
Questionnaire - Pilot: End2End Data Administrations process
Please choose one of the following answers*:
Strongly
agree Agree Disagree
Strongly disagree
1 I am confident that by following the End2End process sequence no data inconsistencies are introduced in the administrations.
2 I feel that the End2End process contributes to an increase in the overall quality of data in the administrations.
3 I feel that the End2End process provides me with the necessary ‘equipment’ to be able to take ownership of the application data in the administrations.
Completeness
4 By following the End2End process I am confident that necessary updates in all relevant administrations are covered.
5 By following the End2End process I am assuring that update requests are always executed as I originally intended.
Transparency
6 The End2End process provides me with a clear insight in which update process(es) I need to initiate for each data type that I wish to update.
7 I have a good understanding of my role and responsibility in the End2End process.
8 The ‘tools’ (documents, process flow, spreadsheets) that are provided to me are comprehensible and easy to use.
Efficiency
9 By using the End2End process I spend less of my weekly working hours on the maintenance of application data.
Appendix 12: Contacts
The following persons have been contacted throughout the research. Some of the people
mentioned have been involved in more than one interview.
Downstream IT: Business Applications Management
Marc-paul van Eijl Becky Fleming Peter Fraser-Smith Bob Masch Allison Reid Teun van der Vliet
Vasundhara Akella (IBM offshore) Parul Singh (IBM offshore)
BAM MSD Peter Beekmans Wolfgang Bock Cornelia Brand Andrew Gould René Jansen Ingo Klarner Thijs Minderhout Rolf Rath Steve Spreyer Vernon Thomason
Marianne van de Velde-Overweg
BAM MSD Europe
Russell Guinn BAM Global Configuration Management
Sharon Hresko
David Newton BAM Global Service Management
Aliya Tajol-Rosli
Amit Rawal (IBM offshore) BAM Compliance Office Abhinav Goel
Cory Goh Brigitta Knueppel
Ganesh Mudveeraiah (IBM offshore)
BAM Strategy and Programme Management
Mark Goodridge BAM Application Support Desk
Jo-Ling Wong BAM DSF
Downstream IT: Application Development & Projects
Shahran Azli Business Analyst - IT
Ronald de Boer Greenlight (SOx compliance)
Jess Buckmaster N-GARD (GI-Next Generation)
Shell IT International (SITI)
Marko Borst SITI Web, Database & Compute
Helynda Mohd-Anafiah SITI GI-D Scripting Services
External companies
Jan van Bon Inform IT, BHVB
