|
|
| (2 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| {|
| | #REDIRECT [[ITIL Implementation - Application Systems]] |
| ! align="right" width="80%"|
| |
| ! style="background:#DDDDDD;" align="right" width="20%"| [https://wiki.de.it-processmaps.com/index.php/ITIL-Implementierung_-_System-_und_Prozess-Implementierung diese Seite auf Deutsch]
| |
| |}
| |
| | |
| '''''Step 9: Implement Processes and Systems
| |
| | |
| If the processes are fully designed and documented in the form of Event-Driven Process Chains, their actual implementation can be initiated.
| |
| | |
| If new or changed application systems are needed in order to support the processes, these must first be procured or developed and implemented.
| |
| | |
| Finally, IT staff receives thorough training in order to be able to apply the new processes in practice, and clients or users might need to be informed - in so far as these are affected by the new processes.
| |
| | |
| | |
| == Define the System Requirements ==
| |
| | |
| ==== Objective of this Project Step ====
| |
| * Definition of the requirements for new or changed application systems
| |
| | |
| ==== Prerequisites ====
| |
| | |
| * Detailed process descriptions in the form of Event-Driven Process Chains (EPCs)
| |
| * Guidelines/ checklists
| |
| * Definitions of the process outputs
| |
| | |
| ==== Results/ Deliverables ====
| |
| | |
| * Requirements document for applications to be changed or procured
| |
| * Prioritised list of requirements
| |
| | |
| ==== Description ====
| |
| | |
| The functional requirements of the application systems are mainly derived from the detailed process descriptions – these illustrate which activities the application system is to support.
| |
| Further requirements may be added (example: „The creation of a new Incident must be possible from within the Outlook address book“).
| |
| | |
| The definitions of the process outputs describe which data are processed within the system. The process “Register an Incident” for example, generates an „Incident Record“ – the system must therefore be able to hold such a data structure and offer suitable user interfaces for viewing and editing.
| |
| | |
| Finally, all non-functional requirements are to be recorded, so that on the whole the following structure results for the requirements document:
| |
| | |
| * Functional requirements
| |
| ** Reference to the detailed process models
| |
| ** Additional requirements related to functionality
| |
| ** Definitions of the process outputs (data-structures)
| |
| ** Reporting functionality
| |
| | |
| * Non-functional requirements
| |
| ** Requirements related to capacities and quantities
| |
| ** Performance and turnover
| |
| ** Scalability/ Expansion
| |
| ** Availability
| |
| | |
| * Requirements from the operational viewpoint
| |
| | |
| * Requirements from the viewpoint of IT Security
| |
| | |
| * Interfaces with other systems
| |
| | |
| * Annex
| |
| ** Process models
| |
| ** Data to be imported from previously existing systems
| |
| | |
| Once the requirements are complete, an itemized and prioritised list is extracted from the requirements document, which is used as a matrix for the evaluation of suppliers. The requirements should be categorised, like in the following example:
| |
| | |
| * Knock-out criteria (Prio 1)
| |
| * Important requirements (Prio 2)
| |
| * Desirable requirements (Prio 3)
| |
| | |
| ==== Success Factors ====
| |
| | |
| It is important not to limit oneself to functional aspects when pinning down the system requirements. Operational aspects are equally important, as are possibilities to expand the system – especially if the introduction of further ITIL processes is to follow.
| |
| | |
| | |
| == Select System(s) to Support the To-Be Processes ==
| |
| | |
| ==== Objective of this Project Step ====
| |
| | |
| * Selection of suitable system(s) and supplier(s) for the application system due to be procured
| |
| | |
| ==== Prerequisites ====
| |
| | |
| * Requirements document for applications to be changed or procured
| |
| * Prioritised list of requirements
| |
| | |
| ==== Results/ Deliverables ====
| |
| | |
| * Evaluation of systems and suppliers
| |
| | |
| ==== Description ====
| |
| | |
| Suppliers of suitable systems are submitted to a systematic evaluation upon the basis of the list of requirements.
| |
| | |
| A three-stage approach has proved to be most efficient for this purpose:
| |
| | |
| * Firstly, a larger number of suppliers may be approached in writing; the aim here is to find suppliers which are able to fulfil the most important requirements
| |
| * This results in a short-list of suppliers, who are requested to submit a concrete offer that also contains information about licence fees and implementation costs
| |
| * The final decision is made after a visit by reference clients and possibly a test-installation by the leading contender
| |
| | |
| ==== Success Factors ====
| |
| | |
| The number of vendors included in the selection process should not be too large – the product surveys published by the Gartner or Forrester Groups provide excellent assistance when compiling a first list of possible candidates (check the Internet under www.gartner.com or www.forrester.com)
| |
| | |
| | |
| == Implement the Systems ==
| |
| | |
| ==== Objective of this Project Step ====
| |
| | |
| * Implementation of the new/ changed application system(s), so that they are ready to support the processes to be introduced
| |
| | |
| ==== Prerequisites ====
| |
| | |
| * Selected system supplier(s)
| |
| * Detailed process descriptions in the form of Event-Driven Process Chains (EPCs)
| |
| * Guidelines/ checklists
| |
| * Definitions of the process outputs
| |
| | |
| ==== Results/ Deliverables ====
| |
| | |
| * Fully implemented and operational application system(s)
| |
| | |
| ==== Description ====
| |
| | |
| Which individual steps are part of the implementation will depend in a great measure upon the type of application and its operational environment.
| |
| | |
| It is usually most efficient to make use of the system-suppliers' expertise when customizing and implementing the new application(s).
| |
| | |
| | |
| == Implement the To-Be Processes ==
| |
| | |
| After all conditions have been created, the new processes may be used.
| |
| | |
| As the process participants were continuously involved into the process design during the course of the project, their acceptance of the new working procedures should be ensured.
| |
| | |
| ==== Objective of this Project Step ====
| |
| | |
| * Making the new process a part of everyday working practice
| |
| | |
| ==== Prerequisites ====
| |
| | |
| * Structure of the Service Management processes to be introduced
| |
| * Process overviews (process breakdown)
| |
| * Interfaces of the ITIL processes to be introduced
| |
| * Measurements (KPIs) for the processes to be introduced
| |
| * Detailed process descriptions in the form of Event-Driven Process Chains (EPCs)
| |
| * Guidelines/ checklists
| |
| * Definitions of the process outputs
| |
| * Fully implemented and operational application system(s)
| |
| | |
| ==== Results/ Deliverables ====
| |
| | |
| * Processes, being executed according to ITIL principles
| |
| | |
| ==== Description ====
| |
| | |
| A coaching of the participants in the new processes might be required, if not all the affected members of IT staff were involved in the design of the processes.
| |
| | |
| ==== Success Factors ====
| |
| * If the process participants learn of the new processes only at this stage, a lack of acceptance will be inevitable. As many employees as possible should therefore be involved in the design of the processes during the earlier project phases
| |
| | |
| | |
| == Following Process Activity ==
| |
| ''Step 10:'' '''''[[ITIL Implementation - Training|Train IT Staff and Customers]]'''''
| |
