ITIL : Contents Articles Configuration management Comparison of open source configuration management….

ITILITIL : Contents Articles Configuration management Comparison of open source configuration management….

Contents Articles Configuration management Comparison of open source configuration management software Accelops AccuRev SCM Augeas (software) Baseline (configuration management) Bcfg2 Belarc CA Software Change Manager CFEngine Chef (software) Component repository management Configuration item Engineering support Granular Configuration Automation ISconf LCFG M23 software distribution system Merge (revision control) MSConfig Opsi Physical configuration audit Professional Systems Associates Puppet (software) Quattor RANCID (software) Rational Synergy Security Technical Implementation Guide SmartFrog Software configuration management Sysedit Method engineering Axios Systems Competitive Engineering 1 5 14 16 17 18 20 22 23 25 28 29 31 32 33 35 35 35 37 40 42 45 46 48 49 52 53 54 55 56 58 59 65 66 Fagan inspection IBM Tivoli Unified Process (ITUP) Information Services Procurement Library Information Technology Infrastructure Library ITIL Planning to implement service management Market analysis for product software Marketing decision support systems Method Framework for Engineering System Architectures Technical architecture 66 70 75 87 102 109 112 112 113 References Article Sources and Contributors Image Sources, Licenses and Contributors 118 120 Article Licenses License 121 Configuration management 1 Configuration management Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system or product’s performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.[1] For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test Top level Configuration Management Activity model documentation throughout the life cycle of an information system.[2] CM for information assurance, sometimes referred to as Secure Configuration Management, relies upon performance, functional, and physical attributes of IT platforms and products and their environments to determine the appropriate security features and assurances that are used to measure a system configuration state.

For example, configuration requirements may be different for a network firewall that functions as part of an organization’s Internet boundary versus one that functions as an internal local network firewall. History Configuration management was first developed by the United States Air Force for the Department of Defense in the 1950s as a technical management discipline of hardware.

The concepts of this discipline have been widely adopted by numerous technical management functions, including systems engineering (SE), integrated logistics support (ILS), Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management methodology, COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and application lifecycle management.

Many of these functions and models have redefined configuration management from its traditional holistic approach to technical management.

Some treat configuration management as being similar to a librarian activity, and break out change control or change management as a separate or stand alone discipline.

However the bottomline is and always shall be Traceability. Configuration management 2 Software configuration management The traditional software configuration management (SCM) process is looked upon by practitioners as the best solution to handling changes in software projects.

It identifies the functional and physical attributes of software at various points in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle.

The SCM process further defines the need to trace changes, and the ability to verify that the final delivered software has all of the planned enhancements that are supposed to be included in the release.

It identifies four procedures that must be defined for each software project to ensure that a sound SCM process is implemented.

They are: 1. 2. 3. 4.

Configuration identification Configuration control Configuration status accounting Configuration audits These terms and definitions change from standard to standard, but are essentially the same. • Configuration identification is the process of identifying the attributes that define every aspect of a configuration item.

A configuration item is a product (hardware and/or software) that has an end-user purpose.

These attributes are recorded in configuration documentation and baselined.

Baselining an attribute forces formal configuration change control processes to be effected in the event that these attributes are changed. • Configuration change control is a set of processes and approval stages required to change a configuration item’s attributes and to re-baseline them. • Configuration status accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time. • Configuration audits are broken into functional and physical configuration audits.

They occur either at delivery or at the moment of effecting the change.

A functional configuration audit ensures that functional and performance attributes of a configuration item are achieved, while a physical configuration audit ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation.

Configuration management is widely used by many military organizations to manage the technical aspects of any complex systems, such as weapon systems, vehicles, and information systems.

The discipline combines the capability aspects that these systems provide an organization with the issues of management of change to these systems over time.

Outside of the military, CM is appropriate to a wide range of fields and industry and commercial sectors.[3] Computer hardware configuration management Computer hardware configuration management is the process of creating and maintaining an up-to-date record of all the components of the infrastructure, including related documentation.

Its purpose is to show what makes up the infrastructure and illustrate the physical locations and links between each item, which are known as configuration hardware configuration goes beyond the recording of computer hardware for the purpose of asset management, although it can be used to maintain asset information.

The extra value provided is the rich source of support information that it provides to all interested parties.

This information is typically stored together in a configuration management database (CMDB).

This concept was introduced by ITIL.

The scope of configuration management is assumed to include, at a minimum, all configuration items used in the provision of live, operational hardware configuration management provides direct control over information technology (IT) assets and improves the ability of the service provider to deliver quality IT services in an economical and effective manner. Configuration management Configuration management should work closely with change management.

All components of the IT infrastructure should be registered in the CMDB.

The responsibilities of configuration management with regard to the CMDB are: • • • • identification control status accounting verification 3 The scope of configuration management is assumed to include: • • • • • • • • • physical client and server hardware products and versions operating system software products and versions application development software products and versions technical architecture product sets and versions as they are defined and introduced live documentation networking products and versions live application products and versions definitions of packages of software releases definitions of hardware base configurations • configuration item standards and definitions The benefits of computer hardware configuration management are: • • • • • helps to minimize the impact of changes provides accurate information on CIs (Configuration Items) improves security by controlling the versions of CIs (Configuration Items) in use facilitates adherence to legal obligations helps in financial and expenditure planning Maintenance systems Configuration management is used to maintain an understanding of the status of complex assets with a view to maintaining the highest level of serviceability for the lowest cost.

Specifically, it aims to ensure that operations are not disrupted due to the asset (or parts of the asset) overrunning limits of planned lifespan or below quality levels.

In the military, this type of activity is often classed as “mission readiness”, and seeks to define which assets are available and for which type of mission; a classic example is whether aircraft on-board an aircraft carrier are equipped with bombs for ground support or missiles for defense.

A theory of configuration maintenance was worked out by Mark Burgess[4] [5] ,[6] with a practical implementation on present day computer systems in the software Cfengine able to perform real time repair as well as preventive maintenance. Preventive maintenance Understanding the “as is” state of an asset and its major components is an essential element in preventive maintenance as used in maintenance, repair, and overhaul and enterprise asset management systems.complex assets such as aircraft, ships, industrial machinery etc.

Depend on many different components being serviceable.

This serviceability is often defined in terms of the amount of usage the component has had since it was new, since fitted, since repaired, the amount of use it has had over its life and several other limiting factors.

Understanding how near the end of their life each of these components is has been a major undertaking involving labor intensive record keeping until recent developments in software. — 33 Workspace support Software configuration management (SCM) system is responsible for providing a workspace for each engineer in the right file system, at the right time to let users work independently, and to save or update the changes automatically when the job is done.

Sometimes, the later one is also said as change management.

Merge tools are widely used to facilitate workspace support.

The following chart provides a process flow of the merge tools which is based on a line by line comparison method.

The upper process flow digram presents the main principle of merge tools in software configuration management.

When a source file is required by a second workespace, the center DB will deliver a copy of that file to it.

And after submitting the 2 versions of the same file, merger tools will start to combine these two version into a new one.

It is based on a line by line process, which is: if There are new lines in the submitted version, add them to the source file, and if there are lines which do not exist in the new version, delete these lines in the source file.

After several times of iteration, a new version of the sources file, which contains all the changes created by the two (or more) authors, will be upload again to the central DB and acts as a new version of the source file. Granular Configuration Automation Granular Configuration Automation (GCA) is a specialized area in the field of Configuration Management which focuses on visibility and control of an IT Environment’s configuration and bill-of-material at the most granular level.

This framework focuses on improving the stability of IT environments by analyzing granular information.

It responds to the requirement to determine a threat level of an environment risk, and to allow IT organizations to focus on those risks with the highest impact on performance.[1] Granular Configuration Automation combines two major trends in configuration management: the move to collect detailed and comprehensive environment information and the growing utilization of automation tools.[2] Driving factors For IT Personnel, IT systems have grown in complexity [3] , supporting a wider and growing range of technologies and platforms.

Application release schedules are accelerating, requiring greater attention to more information.[4] The average Global 2000 firm has more than a thousand applications that their IT organization deploys and supports.[5] New technology platforms like cloud and virtualization offer benefits to IT with less server space, and energy savings, but complicate configuration management from issues like sprawl.[6] The need to ensure high availability and consistent delivery of business services have led many companies to develop automated configuration, change and release management processes.[7] Downtime and system outages undermine the environments that IT professionals manage.

Despite advances in infrastructure robustness, occasional hardware, software and database downtime occurs.

Dunn & Bradstreet reports that 49% of Fortune 500 companies experience at least 1.6 hours of downtime per week, translating into more than 80 hours annually.[8] The growing costs of downtime has provided IT organizations with ample evidence for the need to improve processes.

A conservative estimate from Gartner pegs the hourly cost of downtime for computer networks at $42,000, so a company that suffers from worse than average downtime of 175 hours a year can lose more than $7 million per year.[9] The demands and complexity of Incident Investigation have put further strain on IT professionals, where their current experience cannot address incidents to the scale of environments in their organizations.

The incident may be captured, monitored and the results reported using standardized forms, most of the time even using a help-desk or trouble tickets software system to automate it and sometimes even a formal process methodology like ITIL.

But the core activity is still handled by a technical specialist “nosing around” the system trying to “figure out” what is wrong based on previous experience and personal expertise.[10] Granular Configuration Automation 34 Potential applications • Release validation — validating releases and mitigating the risk of production outages • Incident prevention — identifying and alerting of undesired changes; hence avoiding costly environment incidents • Incident investigation — pinpointing the root-cause of the incident and significantly cutting the time and effort spent on investigation • Disaster Recovery Verification — the accurate validation of disaster recovery plans and eliminating surprises at the most vulnerable times • Security — identifying deviations from security policy and best-practices • Compliance — discovering non-compliant situations and providing a detailed audit-trail References [1] Risk Management Broken in Many Organizations, says Gartner, Government Technology, ” (http:/ / gt/ 324452)” [2] Ken Jackson, The Dawning of the IT Automation Era (http:/ / cm/ community/ features/ guestopinions/ blog/ the-dawning-of-the-it-automation-era/ ?cs=37375), IT Business Edge. [3] Bob Violino, Reducing IT Complexity (http:/ / articles/ 2007winter/ coverstory.

Jhtml), Smart Enterprise. [4] Change, Configuration, and Release: What’s Really Driving Top Performance? (http:/ / files/ ITPI_Executive_Snapshot_CCR Study.

Pdf), IT Process Institute. [5] Improving Application Quality by Controlling Application Infrastructure (http:/ / cm-journal-articles/ 6957-improving-application-quality-by-controlling-application-infrastructure), Configuration Management Crossroads. [6] Cameron Sturdevant, How to Tame Virtualization Sprawl (http:/ / c/ a/ IT-Infrastructure/ How-to-Tame-Virtualization-Sprawl/ ), eweek. [7] Challenges and Priorities for Fortune 1000 Companies (http:/ / pridham.

Files. 2007/ 06/ mvalent_survey_results_2007.

Pdf). [8] How Much Does Downtime Really Cost? (http:/ / infodirect/ 2009_133/ downtime_cost-10015855-1.

Html), Information Management. [9] How to quantify downtime (http:/ / careers/ 2004/ 0105man.

Html), NetworkWorld. [10] Root Cause Analysis for IT Incidents Investigation (http:/ / hosteddocs. GJ102105.

Pdf), IT Toolbox. ISconf 35 — Axios Systems Type Industry Privately held Enterprise software; IT Services and Management 1988 Founded Headquarters Edinburgh, United Kingdom Key people Products Website Tasos Symeonides, CEO Service Desk, IT Service Management and IT Asset Management products [1] Axios Systems is a provider of the Service Desk, IT Service Management and IT Asset Management software, founded in 1988[2] .

The assyst Enterprise application suite was one of the first to support IT Infrastructure Library (ITIL) best practices[3] .

Its customers include Aviva, Arab Bank, Canadian Tire, Gulf News, KPMG, Northgate Information Solutions, Royal Liver Friendly Society, Sears, Standard Bank, Swisscom and others. Location Axios Systems is a multinational firm trading in Europe, North America, Asia-pacific and the Middle East.[4] .

Their corporate headquarters are in Edinburgh, United Kingdom, with North American headquarters in Herndon, Virginia. References [1] http:/ / [2], (undated) “Bitpipe Data Center Research Library – Axios Systems” (http:/ / searchdatacenter. detail/ ORG/ 982891143_238.

Html) [3] Gliedman, Chip.

Forrester Research, (2/17/06) “Axios Systems Provides ITIL-Based Service Desk Management For Larger Enterprises” (http:/ / Research/ Document/ Excerpt/ 0,7211,38636,00.

Html) [4], (Undated) “Contact Axios” (http:/ / six/ en/ corporate/ contact/ index.

Html) Competitive Engineering 66 Competitive Engineering Competitive Engineering A Handbook for Systems Engineering, Requirements Engineering and Software Engineering using Planguage is a systems engineering book by Tom Gilb.

The primary focus of the book is documenting an engineering method called “Planguage”.

The book recommends implementing a “plan-language” to communicate management objectives and systems’ engineering requirements clearly and unambiguously.

The book provides extensive definitions of the terms which compose this specification language.

It also provides a thesaurus-like glossary which associates each “Planguage” word or phrase with a “Concept Number”.

Published in 2005 by Elsevier Butterworth-Heinemann. • • • • • Written by Tom Gilb Edited by Lindsey Brodie of Middlesex University Foreword by Erik Simmons, Requirements Engineering Practice Lead at Intel Corporation Endorsement by Roger S.

Pressman Ph.D, President, R.S.

Pressman & Associates, Inc.

Endorsement by Dr Mark W.

Maier, Distinguished Engineer at The Aerospace Corporation and Chair of the INCOSE Systems Architecture Working Group References Gilb, Tom (2005).competitive Engineering.

Elsevier Butterworth-Heinemann.

ISBN 0-7506-6507-6. Fagan inspection Fagan inspection refers to a structured process of trying to find defects in development documents such as programming code, specifications, designs and others during various phases of the software development process.

It is named after Michael Fagan who is credited with being the inventor of formal software inspections. Definition — References [1] Fagan, M.E., Advances in Software Inspections, July 1986, IEEE Transactions on Software Engineering, Vol.

SE-12, No. 7, Page 744-751 (http:/ / pdfs/ aisi1986.

Pdf) [2] M.E., Fagan (1976). “Design and Code inspections to reduce errors in program development”.

IBM Systems Journal 15 (3): pp. 182–211. (http:/ / pdfs/ ibmfagan.

Pdf) [3] Eickelmann, Nancy S, Ruffolo, Francesca, Baik, Jongmoon, Anant, A, 2003 An Empirical Study of Modifying the Fagan Inspection Process and the Resulting Main Effects and Interaction Effects Among Defects Found, Effort Required, Rate of Preparation and Inspection, Number of Team Members and Product 1st Pass Quality, Proceedings of the 27th Annual NASA Goddard/IEEE Software Engineering Workshop 1. [Laitenberger, 1999] Laitenberger,O, DeBaud, J.M, 1999 An encompassing life cycle centric survey of software inspection, Journal of Systems and Software 50 (2000), Page 5-31 2. [So, 1995] So, S, Lim, Y, Cha, S.D., Kwon, Y,J, 1995 An Empirical Study on Software Error Detection: Voting, Instrumentation, and Fagan Inspection *, Proceedings of the 1995 Asia Pacific Software Engineering Conference (APSEC ’95), Page 345-351 3. [Doolan,1992] Doolan, E.P.. 1992 Experience with Fagan’s Inspection Method, SOFTWARE—PRACTICE AND EXPERIENCE, (FEBRUARY 1992) Vol. 22(2), Page 173–182 4. [Genuchten, 1997] Genuchten, M, Cornelissen, W, Van Dijk, C, 1997 Supporting Inspections with an Electronic Meeting System, Journal of Management Information Systems, Winter 1997-98/Volume 14, No. 3, Page 165-179 IBM Tivoli Unified Process (ITUP) 70 IBM Tivoli Unified Process (ITUP) IBM Tivoli Unified Process (ITUP) is a knowledge base of widely accepted industry best practices and the accumulated experience from IBM’s client engagements.

The knowledge base comprises detailed, industry-wide IT service management processes, and is an integral part of the IBM Service Management solution family.[1] The knowledge base is structured on the IBM Process Reference Model for IT[2] (PRM-IT).

PRM-IT[3] describes the processes for exploiting IT in support of a business or enterprise.

ITUP is a free offering from IBM.[4] Its purpose is to make the benefits of service management best practice frameworks, like Information Technology Infrastructure Library (ITIL), more attainable for organizations through integrated process modeling.

Thus ITUP is closely aligned with ITIL (a series of books outlining a set of concepts for managing IT) and provides the guidance on how to implement IT service management using proven, predefined solutions.

Detailed process diagrams and descriptions provide further explanations of IT processes, the relationships between processes, and the roles and tools involved in an efficient process implementation.

ITUP is also mapped to other leading process models.[5] Context IT service management represents an evolution from managing IT as a technology to managing IT as a business.[6] As businesses move toward on-demand environments, IT organizations are faced with the challenge of increasing the quality of services provided to business, while simultaneously addressing faster rates of change, rising technical complexity, cost pressures, and compliance issues.

With traditional resource and system management approaches, providing effective support for business and efficient use of IT resources is proving impossible.

IT service management provides for the effective and efficient delivery of IT services in support of changing business needs.

Implementing IT service management requires the optimal intersection of people, process, information and technology.

When all of these components come together, they can make IT more efficient and effective. Tivoli Unified Process tooling IBM Tivoli Unified Process (ITUP) Composer is the tool used to create tailored method libraries* using the ITUP knowledge base content.[7] Customization includes creating or modifying process definitions to extend and publish content to document an organization’s operational processes.

The Composer tool provides the option to select and deploy a comprehensive project, or only the process components needed for each stage of a project, so that those processes are consistently applied by all IT staff. (See ITUP Composer for development, this article.) • A method library is a container for method plug-ins and method configuration definitions.

A method library has one or more method configurations that filter the library and provide smaller working sets of library content.

All method elements are stored in a method library. Structure of the ITUP content knowledge database The knowledge base includes descriptions of and relationships between five significant elements: 1.

Process descriptions – detailed process diagrams and explicates to better understand processes and their relationships, making ITIL best-practice recommendations easier to implement.

This category also maps processes to other leading process models, such as Control Objectives for Information and related Technology (COBIT) and the enhanced Telecom Operations Map (eTOM). 2.

Work products – artifacts produced as outputs or required as inputs by processes.

Includes information such as definitions for key terms and concepts. IBM Tivoli Unified Process (ITUP) 3.

Roles – as associated with the execution of specific tasks by IT staff typically responsible for one or more roles.

Roles and job responsibilities are described in detail and cross-referenced to guidance on how staff can use tools to perform their roles more efficiently and effectively. 4.

Tools – in the form of tool mentors.

This category identifies products and solutions from IBM that can be used to automate or complete specific process activities. 5.

Scenarios, or real-life examples – are provided as catalysts to make process content more comprehendible.

A scenario can relate to specific issues, such as deploying a new server or responding to an outage.

Scenarios describe, in a step-by-step format, the process workflow, roles, work products and tools involved in solving a specific problem. 71 The ITUP framework of process categories Governance and Management System The Governance and Management System process category ensures that a framework is in place to integrate processes, technologies, people, and data in a manner consistent with the IT goals.

This category also monitors the framework against the broader enterprise goals and quality metrics.

When specific goals and quality metrics are consistently unmet, decisions are made regarding the overall framework: whether it will be modified or restructured to ensure future success.

Governance considers and sets the fundamental direction for the management framework.

Governance is a decision rights and accountability framework for directing, controlling, and executing IT endeavors in order to determine and achieve desired behaviors and results.

Governance involves defining the management model and creating the governing or guiding principles.

Processes: • • • • IT Governance and Management System Framework IT Governance and Management System Capabilities IT Governance and Management Operation IT Governance and Management Evaluation Customer Relationships The Customer Relationships process category gives IT service providers a mechanism to understand, monitor, perform and compete effectively in the marketplace they serve.

Through active communication and interaction with customers, this process category provides the IT enterprise with valuable, current information concerning customer wants, needs, and requirements.

Once these requirements are captured and understood, the process category ensures that an effective market plan is created to bring the various IT services and capabilities to the marketplace.

Further, customer satisfaction data is gathered and reported in order to find areas of the IT services that require improvement.

Overall, this process provides a means for the IT enterprise to understand customer requirements, market IT services to customers, ensure and monitor the quality of the delivered IT services, and contribute to the maximization of business value from technology usage.

Processes: • • • • • • • Stakeholder Requirements Management Service Marketing and Sales Service Catalog Management Service Level Management Demand Management IT Customer Transformation Management Customer Satisfaction Management Direction The Direction process category provides guidance on the external technology marketplace, aligns the IT outcomes to support the business strategy, minimizes risk exposures, and manages the IT Architecture and IT IBM Tivoli Unified Process (ITUP) Portfolio.

Using the business strategy, related business requirements, and overall technology trends as key inputs, this process category creates an IT Strategy within the manageable constraints of the existing architecture and portfolio.

In addition to the IT strategy, the IT Portfolio and IT Architecture are planned, created, implemented, monitored, and continuously improved within this process category.

Items put forward for inclusion in the IT Portfolio are managed throughout their life cycle using product management approaches well established in many industries.

Processes: • • • • • • • IT Strategy IT Research and Innovation Architecture Management Risk Management Product Management Portfolio Management Program and Project Management 72 — • Overview of Autonomic Computing ( • Autonomic Computing ( • Definition of autonomic computing External links • COBIT ( ContentDisplay.cfm&ContentID=15633) • Sarbanes-Oxley ( • CMMI ( • eSCM ( IBM Tivoli Unified Process (ITUP) • eTOM ( • ISO/IEC 17799 ( widely_used_standards_other/information_security.htm) • ISO/IEC 19770 ( • ISO/IEC 20000 ( • 27001 ( • RUP ( • Six Sigma ( 75 Information Services Procurement Library The Information Services Procurement Library (ISPL) is a best practice library for the management of Information Technology related acquisition processes.

It helps both the customer and supplier organization to achieve the desired quality using the corresponded amount of time and money by providing methods and best practices for risk management, contract management, and planning.

ISPL focuses on the relationship between the customer and supplier organization: It helps constructing the request for proposal, it helps constructing the contract and delivery plan according to the project situation and risks, and it helps monitoring the delivery phase.

ISPL is a unique Information Technology method because where most other Information Technology methods and frameworks focus on development (EG DSDM, RUP), ISPL focuses purely on the procurement of information services.

The target audience for ISPL consists of procurement managers, acquisition managers, programme managers, contract managers, facilities managers, service level managers, and project managers in the IT (Information Technology) area.

Because of ISPL’s focus on procurement it is very suitable to be used with ITIL (for IT Service Management) and PRINCE2 (for Project Management).[1] Benefits There are four main benefits of using ISPL. • • • • The customer can take advantage of the competitive market Proposals of suppliers become comparable The use of a strategy that really fits the situation The contract can be used as a control instrument These benefits are elaborated in the paragraphs below.

The customer can take advantage of the competitive market ISPL helps the customer organisation to construct the Request for Proposal (RFP).

It even provides the customer organisation with a table of contents.

A very important part of the ISPL request for proposal is the elaboration on the supplier evaluation approach.

The complete transparency of the supplier evaluation approach triggers the candidate supplier organisations to issue a really competitive proposal.

As a result the customer can take full advantage of the competitive market.

Proposals of suppliers become comparable ISPL specifies the table of contents of the candidate supplier organisation’s proposal.

It also supplies the customer and candidate supplier organisations with one clear terminology.

This makes the proposals of the candidate suppliers very easy to compare.

The use of a strategy that really fits the situation ISPL provides the user with a really extensive risk management process.

Based on best practices, it helps the management to design a delivery strategy that really fits the situation of both the customer and the supplier organizations.

This is a benefit for both the customer and the supplier organizations because selecting a suboptimal strategy obviously brings along higher costs.

The chapter #Service Planning describes the situation and risk analysis and the design of a service delivery strategy. Information Services Procurement Library Contract as a control instrument ISPL helps the customer and supplier organisations to set up a contract that specifies all critical aspects of the procurement.

For example the list of requirements, the budget and the delivery plan are all fixed in the contract.

This provides both customer and supplier organisation with a very powerful control instrument.

One of the benefits for the customer organisation is that the supplier organisation will be highly motivated to meet all the deadlines because otherwise the supplier commits contract breach.

One of the benefits for the supplier organisation is that it becomes much harder for the customer organisation to change the requirements which would slow down the development process.

In short, with ISPL there is a better control of costs and time-scales. 76 History ISPL is developed and published in 1999 by a consortium of five European companies: EXIN and ID Research (ORDINA) from the Netherlands, FAST from Germany, SEMA from France and TIEKE from Finland.

The development of ISPL was part of the SPRITE-S2 programme that was launched in 1998 by the European Commission.

ISPL is derived from Euromethod and based on the research of about 200 real-life acquisitions. Structure Although ISPL is a best practice library it does not only consist of books.

The structure of ISPL is displayed in Figure 1.

In this figure the books are represented by squares and the other tools are represented by circles.

The basis is formed by four practical books, the IS Procurement Management Essentials.

Additionally, a specific book addresses public procurement.

Plug-ins to the IS Procurement Management Essentials are provided for specific needs and situations.

Currently, three plug-ins are available for which there is a large market potential.

A fourth plug-in on the acquisition of product software is currently under construction.

Follow the links below to get more information on the different parts of ISPL. • #Managing Acquisition Processes • #Specifying Deliverables • #Managing Risks and Planning Deliveries — ISPL’s form of risk management is purely based on heuristics.

By describing and analysing the situation, critical risks can be identified and mitigated by selecting actions and an appropriate strategy.

ISPL provides heuristics that link risks and situational factors to mitigating actions and strategies.

This chapter is a summary of [3] and also includes information from [4]. Model The process of managing risks and planning deliveries is illustrated in Figure 6.

All the different steps in the process are described in detail in the paragraphs below. Information Services Procurement Library 81 Service Description The first step of the process is describing the service that is to be procured.

It is important to note the differences between a project and an ongoing service.

Both types of services are described differently.

ISPL provides the user with two separate sets of guidelines Description of ongoing services There are two steps in describing an ongoing service.

I will briefly elaborate on each of these steps in the following paragraphs.

Identify type of service ISPL proposes two methods for identifying the type of service: • ISO Life Cycle Processes (ISO-LCP) • Public domain service packages These methods can be used in a successive way where the ISO-LCP standard is used to identify the different process types and public domain service packages are used to refine the ISO-LCP processes.

An example of a publicly available description of service packages is the one that is present in ITIL.

Note that in ITIL, service packages are referred to as processes.

More info on the ISO-LCP standard can be found in the Wikipedia entry on ISO 12207.

Describe service properties The service can be described in more detail by its service properties.

All service properties can be divided into three groups: • Investment properties • Functional properties • Quality properties ISPL provides methods for describing all three groups of properties.

Description of projects Projects are described by an initial and a final state, IE the current and the desired situation.

This is done by specifying the operation items (the actual parts of the Information service to be procured), and specifying the descriptive items (documentation).

A short outline of documenting the initial and final state is given in the paragraphs below.

More information on describing operation and descriptive items is given in the chapter #Specifying Deliverables.

Document the initial state For each component of the Information Service, contents and quality of the operation items have to be described.

Secondary, an assessment has to be made on which already present descriptions of future operational items are relevant to use in the project. Information Services Procurement Library Document the final state All the operational items that will be in use at the final state have to be documented.

When describing these operation items the focus should be on: • • • • The difference between new operational items and ones that are adapted from initial operational items Specification of manuals and support documentation Conversion and migration of existing data into new operational items Specification of interfaces with new and already present operation items 82 Not only the operational items have to be described: Descriptions of the documentation of the Information Service that is to be procured are also necessary.

The client has to describe the profiles of the documentation needed for maintenance on, and further development of the Information service. Service Planning The service planning process consists of three sub-processes.

These are: • Situation and risk analysis • Delivery strategy design • Decision point planning In practice, these three sub-processes are followed by a process of risk monitoring that can give input to the situation and risk analysis process.complexity and uncertainty The terms complexity and uncertainty are used quite often in this chapter.complexity In the context of ISPL, complexity can be regarded as the difficulty encountered in managing the available knowledge.

Uncertainty In the context of ISPL, uncertainty can be regarded as the lack of available knowledge.

Situation and risk analysis The analysis sub-process is divided into a situation analysis followed by a risk analysis.

Situation analysis The situation of both the customer and supplier organisations has a lot of influence in the success of the Information Service acquisition process.

The situation analysis is all about identifying situational factors and their values.

A situational factor value says something about the relative contribution to the overall complexity or uncertainty of the service to be delivered.

For both complexity and uncertainty it can have one of the following values: high, low or medium.

The ISPL method provides a set of tables which aids the user in determining the situational factor values.

An example of a part of such a table can be found in Table 1.

The risk management strategy depends on the situation as is displayed in Figure 7.

When all the situational factor values are determined it is possible to determine the overall complexity and uncertainty of the service.

These two factors can be used by the manager for the Design of the service delivery strategy. Information Services Procurement Library Risk analysis In the #Situation analysis, complexity and uncertainty values have been attributed to each of the situational factors.

In the Risk Analysis, these values are used to identify the possible risks and their probability.

Examples of possible risks for the customer business are unpredictable/increased costs for the business, delays in system delivery and poor quality of service or system.

Examples of possible risks affecting the quality of the service to be delivered are demotivation of service actors, unclear requirements and uncertain interfaces with other services or systems.

ISPL provides tables that map situational factors to risks.

An example of such a table can be found in Table 2.

For each of the risks found, both the probability and impact, IE the consequence, are assessed.

The product of these two values is called the risk exposure.

The risk exposure value is used to identify the risks that are critical to service delivery.

The critical risks influence the #Delivery strategy design and the #Decision point planning.

Delivery strategy design This process uses the service description, the situation analysis and the risk analysis as inputs to define an optimal service delivery strategy.

The resulting service delivery strategy consists of three elements: • A list of actions to mitigate risks • Service execution approach • Service control approach.

Define actions ISPL provides heuristics on how to mitigate risks and change the individual situational factors that cause them.

An excerpt of these heuristics can be found in Table 3.

Service execution approach The service execution approach determines how the service is executed.

For projects, the service execution approach is referred to as the development approach.

It consists of a description approach, a construction approach and an installation approach.

ISPL provides the user with heuristics on what type of description, construction and installation approach fits best to the situational factors and critical risks found in the #Situation analysis and #Risk analysis.

For example, ISPL advises to use an evolutionary construction and installation approach when both overall complexity and uncertainty are high.

Service control approach The selection of a service control approach is based on the situational factors and overall complexity and uncertainty found in the #Situation analysis.

ISPL provides heuristics on which types of control are most suitable for various situational factors.

In total there are six types of control: development, quality and configuration in a formal and frequent variant.

Check consistency and analyse impact After defining a complete service strategy the consistency between the chosen strategy options has to be checked and possibly some choices have to be adjusted.

The impact of the chosen strategy should also be analysed by checking that all critical risks have been addressed.

It is also that some strategies cause new critical risks. 83 Information Services Procurement Library Decision point planning The goal of decision point planning is to determine a sequence of decision points and give a clear description on each of the decision points, using the #Delivery strategy design as input.

The sequence and contents of the decision points should reflect the chosen service delivery strategy.

The decision point planning is made in the following order: 1.

Derive basic sequence of decision points. 2.

Adapt basic sequence to accommodate actions. 3.

Describe decision points.

Derive basic sequence of decision points The basic sequence of decision points is based on the #Delivery strategy design.

ISPL provides heuristics on what basic sequences should be used for different delivery strategy options.

Adapt basic sequence to accommodate actions.

The basic sequence found is adapted to the list of actions to mitigate risks of the #Delivery strategy design.

Describe decision points ISPL gives information on what information elements should be in a decision point.

Think of for instance purpose and the pre-conditions.

For every decision has to be determined which deliverables are required.

General rule is that the deliverables must contain the right amount of information to be able to make the decision but no more than that.

Too much information is costly and blurs the focus of the decision makers.

More information about this topic can be found in the chapter on #Specifying Deliverables.

Risk monitoring Risk monitoring takes place after the #Decision point planning phase.

Its results can serve as input for the #Situation and risk analysis phase of service planning if necessary.

It involves the tracking, controlling and monitoring of risks and risk mitigating actions. — 86 In practice, descriptions of operational items often already present.

It is important to make the distinction between functional and quality properties.

Descriptive item A descriptive item captures knowledge about the target domain.

They can be used to describe business organisations, business processes, information services et cetera.

ISPL gives guidance on describing descriptive items by providing a descriptive item profile in which all properties of the descriptive item can easily be ordered. External links • ISPL Homepage [2] • Information Services Procurement Group (in Dutch) [3] References [1] This article is a part of the Method Engineering Encyclopedia of the Utrecht University. [2] http:/ / projekte.


De/ ISPL/ [3] http:/ / www.ispg.

Nl/ 1.

Halfhide, O.

Et al. (2003), ‘Procurement, projecten en processen in de praktijk, De samenhang tussen ISPL, PRINCE2 en ITIL’, IT Beheer Jaarboek 2003, chapter 5.4 (in Dutch) 2.

Franckson, M.

And Verhoef, editors (1999), ‘Managing Acquisition Processes’, Information Services Procurement Library, ten Hagen & Stam, Den Haag, The Netherlands, ISBN 978-90-76304-81-6 3.

Franckson, M.

And Verhoef, editors (1999), ‘Managing Risks and Planning Deliveries’, Information Services Procurement Library, ten Hagen & Stam, Den Haag, The Netherlands, ISBN 978-90-76304-83-0 4.

Verhoef, D.

And Franckson (1999), ‘Risk Management for IT in the large’, CAiSE’99, LNCS 1626, pp. 57–72 5.

Franckson, M.

And Verhoef, editors (1999), ‘Specifying Deliverables’, Information Services Procurement Library, ten Hagen & Stam, Den Haag, The Netherlands, ISBN 978-90-76304-82-3 Information Technology Infrastructure Library 87 Information Technology Infrastructure Library The Information Technology Infrastructure Library (ITIL) is an Information Technology (IT) management framework that provides practices for Information Technology Services Management (ITSM), IT development and IT operations.

ITIL gives detailed descriptions of a number of important IT practices and provides comprehensive checklists, tasks and procedures that any IT organization can tailor to its needs.

ITIL is published in a series of books, each of which covers an IT management topic.

The names ITIL and IT Infrastructure Library are registered trademarks of the United Kingdom’s Office of Government Commerce (OGC). History Responding to growing dependence on IT, the UK Government’s Central Computer and Telecommunications Agency in the 1980s developed a set of recommendations.

It recognised that without standard practices, government agencies and private sector contracts were independently creating their own IT management practices.

The IT Infrastructure Library originated as a collection of books, each covering a specific practice within IT Service Management.

ITIL was built around a process-model based view of controlling and managing operations often credited to W.

Edwards Deming and his plan-do-check-act (PDCA) cycle.[1] After the initial publication in 1989–1996, the number of books quickly grew within ITIL v1 to over 30 volumes.

In 2000/2001, to make ITIL more accessible (and affordable), ITIL v2 consolidated the publications into 8 logical “sets” that grouped related process-guidelines to match different aspects of IT management, applications, and services.

However, the main focus was known as the Service Management sets (Service Support and Service Delivery) which were by far the most widely used, circulated, and understood of ITIL v2 publications. • In April 2001 the CCTA was merged into the Office of Government Commerce (OGC), an office of the UK Treasury.[2] • In 2006, the ITIL v2 glossary was published. • In May 2007, this organisation issued the version 3 of ITIL (also known as the ITIL Refresh Project) consisting of 26 processes and functions, now grouped under only 5 volumes, arranged around the concept of Service lifecycle structure. • In 2009, the OGC officially announced that ITIL v2 certification would be withdrawn and launched a major consultation as per how to proceed.[3] Overview of the ITIL v2 library The eight ITIL version 2 books and their disciplines are: The IT Service Management sets 1.

Service Support 2.

Service Delivery Other operational guidance 3.

ICT Infrastructure Management 4.

Security Management 5.

The Business Perspective 6.

Application Management 7.

Software Asset Management Information Technology Infrastructure Library To assist with the implementation of ITIL practices a further book was published (Apr 9, 2002) providing guidance on implementation (mainly of Service Management): 8.

Planning to Implement Service Management And this has more recently (Jan 26, 2006) been supplemented with guidelines for smaller IT units, not included in the original eight publications: 9.

ITIL Small-Scale Implementation 88 Service Support The Service Support[4] ITIL discipline focuses on the User of the ICT services and is primarily concerned with ensuring that they have access to the appropriate services to support the business functions.

To a business, customers and users are the entry point to the process model.

They get involved in service support by: • • • • Asking for changes Needing communication, updates Having difficulties, queries Real process delivery The service desk functions as the single contact-point for end-users’ incidents.

Its first function is always to “create” an incident.

If there is a direct solution, it attempts to resolve the incident at the first level.

If the service desk cannot solve the incident then it is passed to a 2nd/3rd level group within the incident management system.

Incidents can initiate a chain of processes: Incident Management, Problem Management, Change Management, Release Management and Configuration Management.

This chain of processes is tracked using the Configuration Management Database (CMDB), which records each process, and creates output documents for traceability (Quality Management).

Service Desk / Service Request Management Tasks include handling incidents and requests, and providing an interface for other ITSM processes.

Features include: • • • • • • single point of contact (SPOC) and not necessarily the first point of contact (FPOC) single point of entry single point of exit easier for customers data integrity streamlined communication channel Primary functions of the Service Desk include: • incident control: life-cycle management of all service requests • communication: keeping the customer informed of progress and advising on workarounds The Service Desk function can have various names, such as: • Call Center: main emphasis on professionally handling large call volumes of telephone-based transactions • Help Desk: manage, co-ordinate and resolve incidents as quickly as possible at primary support level • Service Desk: not only handles incidents, problems and questions but also provides an interface for other activities such as change requests, maintenance contracts, software licenses, service-level management, configuration management, availability management, financial management and IT services continuity management The three types of structure for consideration: • Local Service Desk: to meet local business needs – practical only until multiple locations requiring support services are involved Information Technology Infrastructure Library • Central Service Desk: for organisations having multiple locations – reduces operational costs and improves usage of available resources • Virtual Service Desk: for organisations having multi-country locations – can be situated and accessed from anywhere in the world due to advances in network performance and telecommunications, reducing operational costs and improving usage of available resources Incident Management Incident Management aims to restore normal service operation as quickly as possible and minimise the adverse effect on business operations, thus ensuring that the best possible levels of service-quality and -availability are maintained. ‘Normal service operation’ is defined here as service operation within Service Level Agreement (SLA) limits.

Incident Management can be defined as : An ‘Incident’ is any event which is not part of the standard operation of the service and which causes, or may cause, an interruption or a reduction of the quality of the service.

The objective of Incident Management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price.

Problem Management Problem Management aims to resolve the root causes of incidents and thus to minimise the adverse impact of incidents and problems on business that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors.

A ‘problem’ is an unknown underlying cause of one or more incidents, and a ‘known error’ is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified.

The CCTA(Central Computer and Telecommunications Agency) defines problems and known errors as follows A problem is a condition often identified as a result of multiple incidents that exhibit common symptoms.

Problems can also be identified from a single significant incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant.

A known error is a condition identified by successful diagnosis of the root cause of a problem, and the subsequent development of a work-around.

Problem management differs from incident management.

The principal purpose of problem management is to find and resolve the root cause of a problem and thus prevent further incidents; the purpose of incident management is to return the service to normal level as soon as possible, with smallest possible business impact.

The problem-management process is intended to reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for the first-line and second line of the help desk.

The proactive process identifies and resolves problems before incidents occur.

Such processes include: • Trend analysis; • Targeting support action; • Providing information to the organisation The Error Control Process iteratively diagnoses known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.

The Problem Control Process aims to handle problems in an efficient way.

Problem control identifies the root cause of incidents and reports it to the service desk.

Other activities are: • Problem identification and recording • Problem classification • Problem investigation and diagnosis 89 Information Technology Infrastructure Library A technique for identifying the root cause of a problem is to use an Ishikawa diagram, also referred to as a cause-and-effect diagram, tree diagram, or fishbone diagram.

Alternatively, a formal Root Cause Analysis method such as Apollo Root Cause Analysis can be implemented and used to identify causes and solutions.

An effective root cause analysis method and/or tool will provide the most effective/efficient solutions to address problems in the Problem Management process.

Change Management Change Management aims to ensure that standardised methods and procedures are used for efficient handling of all changes, A change is “an event that results in a new status of one or more configuration items (CIs)” approved by management, cost effective, enhances business process changes (fixes) – with a minimum risk to IT infrastructure.

The main aims of Change Management include: • Minimal disruption of services • Reduction in back-out activities • Economic utilisation of resources involved in the change Change Management Terminology • Change: the addition, modification or removal of CIs • Request for Change (RFC) or in older terminology Change Request (CR): form used to record details of a request for a change and is sent as an input to Change Management by the Change Requestor • Forward Schedule of Changes (FSC): schedule that contains details of all forthcoming Changes.

Release Management Release Management is used by the software migration team for platform-independent and automated distribution of software and hardware, including license controls across the entire IT infrastructure.

Proper software and hardware control ensures the availability of licensed, tested, and version-certified software and hardware, which functions as intended when introduced into existing infrastructure.

Quality control during the development and implementation of new hardware and software is also the responsibility of Release Management.

This guarantees that all software meets the demands of the business processes.

The goals of release management include: • Planning the rollout of software • Designing and implementing procedures for the distribution and installation of changes to IT systems • Effectively communicating and managing expectations of the customer during the planning and rollout of new releases • Controlling the distribution and installation of changes to IT systems Release management focuses on the protection of the live environment and its services through the use of formal procedures and checks.

A Release consists of the new or changed software and/or hardware required to implement approved changes.

Release categories include: • Major software releases and major hardware upgrades, normally containing large amounts of new functionality, some of which may make intervening fixes to problems redundant.

A major upgrade or release usually supersedes all preceding minor upgrades, releases and emergency fixes. • Minor software releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes.

A minor upgrade or release usually supersedes all preceding emergency fixes. 90 Information Technology Infrastructure Library • Emergency software and hardware fixes, normally containing the corrections to a small number of known problems.

Releases can be divided based on the release unit into: • Delta Release: a release of only that part of the software which has been changed.

For example, security patches. • Full Release: the entire software program is deployed—for example, a new version of an existing application. • Packaged Release: a combination of many changes—for example, an operating system image which also contains specific applications.

Configuration Management Configuration Management is the management and traceability of every aspect of a configuration from beginning to end and it includes the following key process areas under its umbrella : Identification, Planning Change Control, Change Management, Release Management, Maintenance, process that tracks all individual Configuration Items (CI) generated by applying all of the key process areas in a system. — 92 IT Service Continuity Management IT service continuity management covers the processes by which plans are put in place and managed to ensure that IT Services can recover and continue even after a serious incident occurs.

It is not just about reactive measures, but also about proactive measures – reducing the risk of a disaster in the first instance.

Continuity management is regarded by the application owners as the recovery of the IT infrastructure used to deliver IT Services, but as of 2009 many businesses practice the much further-reaching process of Business Continuity Planning (BCP), to ensure that the whole end-to-end business process can continue should a serious incident occur (at primary support level).

Continuity management involves the following basic steps: • Prioritising the activities to be recovered by conducting a Business Impact Analysis (BIA) • Performing a Risk Assessment (aka risk analysis) for each of the IT Services to identify the assets, threats, vulnerabilities and countermeasures for each service. • Evaluating the options for recovery • Producing the Contingency Plan • Testing, reviewing, and revising the plan on a regular basis Availability Management Availability Management targets allowing organisations to sustain the IT service-availability to support the business at a justifiable cost.

The high-level activities are Realise Availability Requirements, Compile Availability Plan, Monitor Availability, and Monitor Maintenance Obligations.

Availability Management addresses the ability of an IT component to perform at an agreed level over a period of time. • Reliability: Ability of an IT component to perform at an agreed level at described conditions. • Maintainability: The ability of an IT component to remain in, or be restored to an operational state. • Serviceability: The ability for an external supplier to maintain the availability of component or function under a third-party contract. • Resilience: A measure of freedom from operational failure and a method of keeping services reliable.

One popular method of resilience is redundancy. • Security: A service may have associated data.

Security refers to the confidentiality, integrity, and availability of that data.

Availability gives a clear overview of the end-to-end availability of the system. Information Technology Infrastructure Library Financial Management for IT Services IT Financial Management comprises the discipline of ensuring that the IT infrastructure is obtained at the most effective price (which does not necessarily mean cheapest) and calculating the cost of providing IT services so that an organisation can understand the costs of its IT services.

These costs may then be recovered from the customer of the service.

This is the 2nd component of service delivery process. 93 ICT Infrastructure Management ICT Infrastructure Management[6] (“ICT” is an acronym for “Information and Communication Technology”) processes recommend best practice for requirements analysis, planning, design, deployment and ongoing operations management and technical support of an ICT Infrastructure.

The Infrastructure Management processes describe those processes within ITIL that directly relate to the ICT equipment and software that is involved in providing ICT services to customers. • • • • ICT Design and Planning ICT Deployment ICT Operations ICT Technical Support These disciplines are less well understood than those of Service Management and therefore often some of their content is believed to be covered ‘by implication’ in Service Management disciplines.

ICT Design and Planning ICT Design and Planning provides a framework and approach for the Strategic and Technical Design and Planning of ICT infrastructures.

It includes the necessary combination of business (and overall IS) strategy, with technical design and architecture.

ICT Design and Planning drives both the Procurement of new ICT solutions through the production of Statements of Requirement (“SOR”) and Invitations to Tender (“ITT”) and is responsible for the initiation and management of ICT Programmes for strategic business change.

Key Outputs from Design and Planning are: • • • • ICT Strategies, Policies and Plans The ICT Overall Architecture & Management Architecture Feasibility Studies, ITTs and SORs Business Cases ICT Deployment Management ICT Deployment provides a framework for the successful management of design, build, test and roll-out (deploy) projects within an overall ICT programme.

It includes many project management disciplines in common with PRINCE2, but has a broader focus to include the necessary integration of Release Management and both functional and non functional testing.

ICT Operations Management ICT Operations Management provides the day-to-day technical supervision of the ICT infrastructure.

Often confused with the role of Incident Management from Service Support, Operations has a more technical bias and is concerned not solely with Incidents reported by users, but with Events generated by or recorded by the Infrastructure.

ICT Operations may often work closely alongside Incident Management and the Service Desk, which are not-necessarily technical, to provide an ‘Operations Bridge’.

Operations, however should primarily work from documented processes and procedures and should be concerned with a number of specific sub-processes, such as: Output Management, Job Scheduling, Backup and Restore, Network Monitoring/Management, System Monitoring/Management, Database Monitoring/Management Storage Monitoring/Management.

Operations are responsible for the following: Information Technology Infrastructure Library • • • • • • A stable, secure ICT infrastructure A current, up to date Operational Documentation Library (“ODL”) A log of all operational Events Maintenance of operational monitoring and management tools.

Operational Scripts Operational Procedures 94 ICT Technical Support ICT Technical Support is the specialist technical function for infrastructure within ICT.

Primarily as a support to other processes, both in Infrastructure Management and Service Management, Technical Support provides a number of specialist functions: Research and Evaluation, Market Intelligence (particularly for Design and Planning and Capacity Management), Proof of Concept and Pilot engineering, specialist technical expertise (particularly to Operations and Problem Management), creation of documentation (perhaps for the Operational Documentation Library or Known Error Database).

There are different levels of support under the ITIL structure, these being primary support level, secondary support level and tertiary support level, higher-level administrators being responsible for support at primary level. Security Management The ITIL-process Security Management[7] describes the structured fitting of information security in the management organisation.

ITIL Security Management is based on the code of practice for information security management now known as ISO/IEC 27002.

A basic goal of Security Management is to ensure adequate information security.

The primary goal of information security, in turn, is to protect information assets against risks, and thus to maintain their value to the organisation.

This is commonly expressed in terms of ensuring their confidentiality, integrity and availability, along with related properties or goals such as authenticity, accountability, non-repudiation and reliability.

Mounting pressure for many organisations to structure their Information Security Management Systems in accordance with ISO/IEC 27001 requires revision of the ITIL v2 Security Management volume, and indeed a v3 release is in the works. Application Management ITIL Application Management[8] encompasses a set of best practices proposed to improve the overall quality of IT software development and support through the life-cycle of software development projects, with particular attention to gathering and defining requirements that meet business objectives.

This volume is related to the topics of Software Engineering and IT Portfolio Management. Software Asset Management Software Asset Management (SAM) is the practice of integrating people, processes and technology to allow software licenses and usage to be systematically tracked, evaluated and managed.

The goal of SAM is to reduce IT expenditures, human resource overhead and risks inherent in owning and managing software assets.

SAM practices include: • Maintaining software license compliance • Tracking inventory and software asset use • Maintaining standard policies and procedures surrounding definition, deployment, configuration, use, and retirement of software assets and the Definitive Software Library. Information Technology Infrastructure Library SAM represents the software component of IT asset management.

This includes hardware asset management because effective hardware inventory controls are critical to efforts to control software.

This means overseeing software and hardware that comprise an organisation’s computers and network. 95 Planning to Implement Service Management The ITIL discipline – Planning to Implement Service Management[9] attempts to provide practitioners with a framework for the alignment of business needs and IT provision requirements.

The processes and approaches incorporated within the guidelines suggest the development of a Continuous Service Improvement Program (CSIP) as the basis for implementing other ITIL disciplines as projects within a controlled program of work.

Planning to Implement Service Management focuses mainly on the Service Management processes, but also applies generically to other ITIL disciplines.components include: • • • • creating vision analyzing organisation setting goals implementing IT service management Small-Scale Implementation ITIL Small-Scale Implementation[10] provides an approach to ITIL framework implementation for smaller IT units or departments.

It is primarily an auxiliary work that covers many of the same best practice guidelines as Planning to Implement Service Management, Service Support, and Service Delivery but provides additional guidance on the combination of roles and responsibilities, and avoiding conflict between ITIL priorities. Overview of the ITIL v3 library ITIL v3 is an extension of ITIL v2 and will fully replace it following the completion of the withdrawal period on 30 June 2011 [11].

ITIL v3 provides a more holistic perspective on the full life cycle of services, covering the entire IT organisation and all supporting components needed to deliver services to the customer, whereas v2 focused on specific activities directly related to service delivery and support.

Most of the v2 activities remained untouched in v3, but some significant changes in terminology were introduced in order to facilitate the expansion.

Five volumes comprise the ITIL v3, published in May 2007: 1.

ITIL Service Strategy[12] 2.

ITIL Service Design[13] 3.

ITIL Service Transition[14] 4.

ITIL Service Operation[15] 5.

ITIL Continual Service Improvement[16] Service Strategy As the center and origin point of the ITIL Service Lifecycle, the ITIL Service Strategy volume[12] provides guidance on clarification and prioritisation of service-provider investments in services.

More generally, Service Strategy focuses on helping IT organisations improve and develop over the long term.

In both cases, Service Strategy relies largely upon a market-driven approach.

Key topics covered include service value definition, business-case development, service assets, market analysis, and service provider types.

List of covered processes: • Service Portfolio Management [17] • Demand Management • IT Financial Management [18] Information Technology Infrastructure Library 96 Service Design The ITIL Service Design volume[13] provides good-practice guidance on the design of IT services, processes, and other aspects of the service management effort.

Significantly, design within ITIL is understood to encompass all elements relevant to technology service delivery, rather than focusing solely on design of the technology itself.

As such, Service Design addresses how a planned service solution interacts with the larger business and technical environments, service management systems required to support the service, processes which interact with the service, technology, and architecture required to support the service, and the supply chain required to support the planned service.

Within ITIL v2, design work for an IT service is aggregated into a single Service Design Package (SDP).

Service Design Packages, along with other information about services, are managed within the service catalogues.

List of covered processes: • • • • • • • Service Catalogue Management Service Level Management Risk Management Capacity Management Availability Management IT Service Continuity Management Information Security Management • Compliance Management • IT Architecture Management • Supplier Management Service Transition Service transition, as described by the ITIL Service Transition volume,[14] relates to the delivery of services required by a business into live/operational use, and often encompasses the “project” side of IT rather than “BAU” (Business as usual).

This area also covers topics such as managing changes to the “BAU” environment.

List of processes: • • • • • • Service Asset and Configuration Management Service Validation and Testing Evaluation Release Management Change Management Knowledge Management Service Operation Best practice for achieving the delivery of agreed levels of services both to end-users and the customers (where “customers” refer to those individuals who pay for the service and negotiate the SLAs).

Service operation, as described in the ITIL Service Operation volume,[15] is the part of the lifecycle where the services and value is actually directly delivered.

Also the monitoring of problems and balance between service reliability and cost etc.

Are considered.

The functions include technical management, application management, operations management and Service Desk as well as, responsibilities for staff engaging in Service Operation.

List of processes: • Event Management • Incident Management • Problem Management. • Request Fulfilment Information Technology Infrastructure Library • Access Management 97 Continual Service Improvement (CSI) Aligning and realigning IT services to changing business needs (because standstill implies decline).

Continual Service Improvement, defined in the ITIL Continual Service Improvement volume,[16] aims to align and realign IT Services to changing business needs by identifying and implementing improvements to the IT services that support the Business Processes.

The perspective of CSI on improvement is the business perspective of service quality, even though CSI aims to improve process effectiveness, efficiency and cost effectiveness of the IT processes through the whole lifecycle.

To manage improvement, CSI should clearly define what should be controlled and measured.

CSI needs to be treated just like any other service practice.

There needs to be upfront planning, training and awareness, ongoing scheduling, roles created, ownership assigned,and activities identified to be successful.

CSI must be planned and scheduled as process with defined activities, inputs, outputs, roles and reporting.

List of processes: • Service Level Management • Service Measurement and Reporting • Continual Service Improvement Criticisms of ITIL ITIL has been criticised on several fronts, including: • The books are not affordable for non-commercial users • Implementation and credentialing requires specific training • Debate over ITIL falling under BSM or ITSM frameworks Rob England (also known as “IT Skeptic”) has criticised the protected and proprietary nature of ITIL [19].

He urges the publisher, OGC, to release ITIL under the Open Government Licence (OGL)[20] CIO Magazine columnist Dean Meyer has also presented some cautionary views of ITIL,[21] including five pitfalls such as “becoming a slave to outdated definitions” and “Letting ITIL become religion.” As he notes, “…it doesn’t describe the complete range of processes needed to be world class.

It’s focused on …

Managing ongoing services.” In a 2004 survey designed by Noel Bruton (author of “How to Manage the IT Helpdesk” and “Managing the IT Services Process”), organisations adopting ITIL were asked to relate their actual experiences in having implemented ITIL.

Seventy-seven percent of survey respondents either agreed or strongly agreed that “ITIL does not have all the answers”.

ITIL exponents accept this, citing ITIL’s stated intention to be non-prescriptive, expecting organisations to engage ITIL processes with existing process models.

Bruton notes that the claim to non-prescriptiveness must be, at best, one of scale rather than absolute intention, for the very description of a certain set of processes is in itself a form of prescription.[22] While ITIL addresses in depth the various aspects of Service Management, it does not address enterprise architecture in such depth.

Many of the shortcomings in the implementation of ITIL do not necessarily come about because of flaws in the design or implementation of the Service Management aspects of the business, but rather the wider architectural framework in which the business is situated.

Because of its primary focus on Service Management, ITIL has limited utility in managing poorly designed enterprise architectures, or how to feed back into the design of the enterprise architecture.

Closely related to the Architectural criticism, ITIL does not directly address the business applications which run on the IT infrastructure; nor does it facilitate a more collaborative working relationship between development and operations teams.

The trend toward a closer working relationship between development and operations is termed: Information Technology Infrastructure Library DevOps.

This trend is related to increased application release rates and the adoption of Agile software development methodologies.

Traditional service management processes have struggled to support increased application release rates – due to lack of automation – and/or highly complex enterprise architecture.

Some researchers group ITIL with Lean, Six Sigma and Agile IT operations management.

Applying Six Sigma techniques to ITIL brings the engineering approach to ITIL’s framework.

Applying Lean techniques promotes continuous improvement of the ITIL’s best practices.

However, ITIL itself is not a transformation method, nor does it offer one.

Readers are required to find and associate such a method.

Some vendors have also included the term Lean when discussing ITIL implementations, for example “Lean-ITIL”.

The initial consequences of an ITIL initiative tend to add cost with benefits promised as a future deliverable.

ITIL does not provide usable methods “out of the box” to identify and target waste, or document the customer value stream as required by Lean, and measure customer satisfaction. 98 Frameworks Related to ITIL A number of frameworks exist in the field of IT Service Management alongside ITIL. ITIL Descendants The Microsoft Operations Framework (MOF) is based on ITIL v2.

While ITIL deliberately aims to be platform-agnostic, MOF is designed by Microsoft to provide a common management framework for its products.

Microsoft has mapped MOF to ITIL as part of their documentation of the framework.[23] The British Educational Communications and Technology Agency (BECTA) used ITIL as the basis for their development of Framework for ICT Technical Support [24] (FITS).

Their aim was to develop a framework appropriate for British schools, which often have very small IT departments.

FITS became independent from BECTA in 2009. Other Frameworks ITIL is generally equivalent to the scope of the ISO/IEC 20000 standard (previously BS 15000).[25] While it is not possible for an organization to be certified as being ITIL compliant, certification of an organisation is available for ISO20000 [26].

COBIT is an IT governance framework and supporting toolset developed by ISACA.

ISACA view ITIL as being complementary to COBIT.

They see COBIT as providing a governance and assurance role while ITIL providing guidance for service management.[27] The enhanced Telecom Operations Map eTOM published by the TeleManagement Forum offers a framework aimed at telecommunications service providers.

In a joined effort, TM Forum and itSMF developed an Application Note to eTOM (GB921) that shows how the two frameworks can be mapped to each other.

It addresses how eTom process elements and flows can be used to support the processes identified in ITIL.[28] [29] IBM Tivoli Unified Process (ITUP) is aligned with ITIL, but is presented as a complete, integrated process model compatible with IBM’s products. Information Technology Infrastructure Library 99 Certification Individuals The certification scheme differs between ITIL v2 and ITIL v3 and bridge examinations let v2 certification owners transfer to the new program.

ITIL v2 offers 3 certification levels: Foundation, Practitioner and Manager.

These should be progressively discontinued in favour of the new ITIL v3 scheme.

ITIL v3 certification levels are: Foundation, Intermediate, Expert and Master.

The ITIL v3 certification scheme offers a modular approach.

Each qualification is assigned a credit value; so that upon successful completion of the module, the candidate is rewarded with both a certification and a number of credits.

At the lowest level – Foundation candidates are awarded a certification and 2 credits.

At the Intermediate level, a total of 15 credits must be earned.

These credits may be accumulated in either a “Lifecycle” stream or a “Capability” stream; or combination thereof.

Each Lifecycle module and exam is 3 An ITIL Foundation certificate pin.


Each Capability module and corresponding exam is 4 credits.

A candidate wanting to achieve the Expert level will have, among other requirements, to gain the required number of credits (22).

That is accomplished with two from Foundations, then 15 from Intermediate, and finally 5 credits from the “Managing Across the Lifecycle” exam.

Together, the total of 22 earned credits designates one as ITIL v. 3 Expert.[30] The ITIL Certification Management Board (ICMB) manages ITIL certification.

The Board includes representatives from interested parties within the community around the world.

Members of the Board include (though are not limited to) representatives from the UK Office of Government Commerce (OGC), APM Group (APMG), The Stationery Office (TSO), V3 Examination Panel, Examination Institutes (EIs) and the IT Service Management Forum International (itSMF) as the recognised user group.[31] Since the early 1990s, EXIN and ISEB have been setting up the ITIL based certification program, developing and providing ITIL exams at three different levels: Foundation, Practitioner and Manager.

EXIN[32] and BCS/ISEB[33] (the British Computer Society) have from that time onwards been the only two examination providers in the world to develop formally acknowledged ITIL certifications, provide ITIL exams and accredit ITIL training providers worldwide.

These rights were obtained from OGC, the British government institution and owner of the ITIL trademark.

OGC signed over the management of the ITIL trademark and the accreditation of examination providers to APMG in 2006.

Now, after signing a contract with EXIN,[32] BCS/ISEB and other certification bodies, APMG is accrediting them as official examination bodies, to offer ITIL exams and accredit ITIL training providers.

On July 20, 2006, the OGC signed a contract with the APM Group [34] to become its commercial partner for ITIL accreditation from January 1, 2007.[35] APMG manage the ITIL Version 3 exams.

APMG maintains a voluntary register of ITIL Version 3-certified practitioners at their Successful Candidate Register.[36] A voluntary registry of ITIL Version 2-certified practitioners is operated by the ITIL Certification Register.[37] Information Technology Infrastructure Library 100 ITIL® pins It has been a well-known tradition for years that passing an EXIN exam in IT Service Management (based on ITIL®) does not only result in a certificate, but is also accompanied by the presentation of a metal pin which can be attached to a shirt or jacket.

This distinguishing badge with basic gold colour is set in the form of the internationally well-known ITIL®-logo.

The ITIL® pins consist of small diamond like structure that is accepted worldwide.

The meaning and the shape of the diamond depicts coherence in the IT industry (infrastructure as well).

The four corners of the pin symbolises service support, service delivery, Infrastructure Management and IT Management.

There are three colours of ITIL® V2 pins: 1.

Green, for the Foundation Certificate 2.

Blue, for the Practitioner’s Certificate 3.

Red, for the Manager’s Certificate Exam candidates who have successfully passed the examinations for ITIL® version 2 will receive their appropriate pin from EXIN or their certification provider regional office or agent.

With the arrival of ITIL® V3, there are several new pins to display your achievements.

As of July 2008, EXIN and all certification providers will also provide ITIL® pins to exam candidates who have obtained ITIL® version 3 certificates.

The new pins are very similar to ITIL® V2 pins, but every level has a different color corresponding to the ITIL® V3 core books. Organisations Organisations and management systems cannot claim certification as “ITIL-compliant”.

An organisation that has implemented ITIL guidance in IT Service Management (ITSM), may however, be able to achieve compliance with and seek certification under ISO/IEC 20000.

Note that there are some significant differences between ISO/IEC20000 and ITIL Version 3[38] • ISO20000 only recognises the management of financial assets, not assets which include “management, organisation, process, knowledge, people, information, applications, infrastructure and financial capital”, nor the concept of a “service asset”.

So ISO20000 certification does not address the management of ‘assets’ in an ITIL sense. • ISO20000 does not recognise Configuration Management System (CMS) or Service Knowledge Management System (SKMS), and so does not certify anything beyond Configuration Management Database (CMDB). • An organisation can obtain ISO20000 certification without recognising or implementing the ITIL concept of Known Error, which is usually considered essential to ITIL. References [1] David Clifford, Jan van Bon (2008).

Implementing ISO/IEC 20000 Certification: The Roadmap.

ITSM Library.

Van Haren Publishing.

ISBN 908753082X. [2] Office of Government Commerce (UK) CCTA and OGC (http:/ / www.ogc.


Uk/ index.


Retrieved May 5, 2005. [3] Office of Government Commerce (UK) (http:/ / www.ogc.


Uk/ guidance_itil.


Retrieved August 19, 2009. [4] Office of Government Commerce (2000).

Service Support.

The Stationery Office.

ISBN 0113300158. [5] Office of Government Commerce (2001).

Service Delivery.

IT Infrastructure Library.

The Stationery Office.

ISBN 0113300174. [6] Office of Government Commerce (2002).

ICT Infrastructure Management.

The Stationery Office.

ISBN 0113308655. [7] Cazemier, Jacques A.; Overbeek, Paul L.; Peters, Louk M. (2000).

Security Management.

The Stationery Office.

ISBN 011330014X. [8] Office of Government Commerce (2002).

Application Management.

The Stationery Office.

ISBN 0113308663. [9] Office of Government Commerce (2002).

Planning to Implement Service Management.

The Stationery Office.

ISBN 0113308779. [10] Office of Government Commerce (2005).

ITIL Small Scale Implementation.

The Stationery Office.

ISBN 0113309805. [11] http:/ / www.ogc.


Uk/ itil_ogc_withdrawal_of_itil_version2.

Asp [12] Majid Iqbal and Michael Nieves (2007).

ITIL Service Strategy.

The Stationery Office.

ISBN 9780113310456. [13] Vernon Lloyd and Colin Rudd (2007).

ITIL Service Design.

The Stationery Office.

ISBN 9780113310470. [14] Shirley Lacy and Ivor Macfarlane (2007).

ITIL Service Transition.

The Stationery Office.

ISBN 9780113310487. [15] David Cannon and David Wheeldon (2007).

ITIL Service Operation.

The Stationery Office.

ISBN 9780113310463. Information Technology Infrastructure Library [16] George Spalding and Gary Case (2007).

ITIL Continual Service Improvement.

The Stationery Office.

ISBN 9780113310494. [17] http:/ / wiki.

En. index.

Php/ Service_Portfolio_Management [18] http:/ / wiki.

En. index.

Php/ Financial_Management [19] http:/ / free-itil [20] http:/ / www.nationalarchives.


Uk/ doc/ open-government-licence/ open-government-licence.

Htm [21] Meyer, Dean, 2005. “Beneath the Buzz: ITIL” (http:/ / web. web/ 20050404165524/ http:/ / leadership/ buzz/ column.

Html?ID=4186), CIO Magazine, March 31, 2005 [22] Survey: “The ITIL Experience – Has It Been Worth It”, author Bruton Consultancy 2004, published by Helpdesk Institute Europe, The Helpdesk and IT Support Show, and Hornbill Software. [23] Microsoft Operations Framework; Cross Reference ITIL v3 and MOF 4.0 (http:/ / go. fwlink/ ?LinkId=151991).

Microsoft Corporation.

May 2009. . [24] http:/ / [25] Van Bon, Jan; Verheijen, Tieneke (2006), Frameworks for IT Management (http:/ / books. books?id=RV3jQ16F1_cC), Van Haren Publishing, ISBN 9789077212905, [26] http:/ / newsletters/ DITYvol2iss3.

Htm [27] ISACA (2008), COBIT Mapping: Mapping of ITIL V3 With COBIT 4.1 (http:/ / Knowledge-Center/ Research/ ResearchDeliverables/ Pages/ COBIT-Mapping-Mapping-of-ITIL-V3-With-COBIT-4-1.

Aspx), ITGI, ISBN 9781604200355, [28] Brooks, Peter (2006), Metrics for IT Service Management (http:/ / books. books?id=UeWDivqKcm0C), Van Haren Publishing, pp. 76–77, ISBN 9789077212691, [29] Morreale, Patricia A.; Terplan, Kornel (2009), “ Matching ITIL to eTOM” (http:/ / books. books?id=VEp0aMmH3iQC), CRC Handbook of Modern Telecommunications, Second Edition (2 ed.), CRC Press, ISBN 9781420078008, [30] ITIL V3 Qualification Scheme (http:/ / Qualifications/ ITILV3QualificationScheme.


OGC Official Site. .

Retrieved 2011-05-02. [31] APMG (2008). “ITIL Service Management Practices: V3 Qualifications Scheme” (http:/ / nmsruntime/ saveasdialog.

Asp?lID=572& sID=86). .

Retrieved 24 February 2009. [32] “EXIN Exams” (http:/ / ).

EXIN Exams. .

Retrieved 2010-01-14. [33] “ISEB Professionals Qualifications, Training, Careers BCS – The Chartered Institute for IT” (http:/ / server.

Php?show=nav. 5732).

BCS. .

Retrieved 2010-01-14. [34] http:/ / [35] Office of Government Commerce (2006). “Best Practice portfolio: new contracts awarded for publishing and accreditation services” (http:/ / www.ogc.


Uk/ About_OGC_news_4906.

Asp). .

Retrieved 19 September 2006. [36] http:/ / www.apmgroup.


Uk/ ITILSCRquery.

Asp [37] http:/ / [38] Office of Government Commerce (2008). “Best Management Practice: ITIL V3 and ISO/IEC 20000” (http:/ / gempdf/ ITIL_and_ISO_20000_March08.

Pdf). .

Retrieved 24 February 2009. 101 External links • Official ITIL Website ( • The OGC website ( ITIL Planning to implement service management 102 ITIL Planning to implement service management The planning to implement service management is a set in the Information Technology Infrastructure Library (ITIL) framework.

This set is about the alignment of business needs and IT provision requirements.

Besides, this set describes how to implement or improve IT Service Management within an organization and it describes steps to ensure that business needs and IT provision requirements will be met.

Furthermore, the planning to implement service management set is mainly focused on the service management processes, but also generically applicable to other ITIL sets.

An approach to implement or improve service management is the Continuous Service Improvement Programme (CSIP).

A CSIP is defined as: “an ongoing formal programme undertaken within an organization to identify and introduce measurable improvements within a specified work area or work process.” OGC_book All the activities within a CSIP regarding one single improvement can be visualized generically by using the meta-modeling technique.

This results in a process-data diagram (figure 1), which does not describe the continuous improvement activity of the programme.

The process-data diagram shows the relationship between processes and artifacts and this diagram consists of two integrated diagrams.

The left-hand side of the process-data diagram describes the activities (processes) and is based on the UML activity diagram.

The right-hand side describes the data (artifacts) and is based on the UML class diagram.

Meta_modeling The table of concepts and the activity description regarding the process-data diagram can be found in the paragraph Process-data diagram descriptions.

The process-data diagram shows the following activities: • • • • • create vision analyze organization set goals implement IT service management measure goals First, a vision has to be created and the IT and business strategies should be aligned.

The second step consists of analyzing the organization and its current position.

In this step an answer has to be found on the question ‘where are we now?’ The following step is about setting goals and priorities regarding the improvement process.

The fourth step is the improvement of the service provision itself and during the fifth and final step the improvement will be measured to examine whether the goals have been met. ITIL Planning to implement service management 103 The planning to implement service management set Every activity in the planning to implement service management set, as depicted in figure 1, will be further explained. Create vision As figure 1 shows, the first step that needs to be taken in the process is creating a vision statement for a CSIP.

The vision statement describes the aim and purpose of the CSIP on a high level and should align the different strategies of business and IT.

Additionally, the vision statement should be well communicated to the stakeholder, to create commitment and buy-in for the CSIP. Figure 1: process-data diagram Analyze organization After having created a vision an IT organization should analyze itself, wherein the question ‘where are we now?’ has to be answered.

A useful technique to determine the current position is the IT organization growth model.

This model determines the maturity level of the IT organization and is based on the Process Maturity Framework (PMF), as well as on the Capability Maturity Model (CMM).

The maturity of the organization will be determined in terms of vision and strategy, steering, processes, people, technology and culture.

It is also required to understand who the stakeholders are, because stakeholders have an impact on the CSIP.

This can be achieved by defining, identifying and mapping the stakeholders.

Additionally, the specific needs of the stakeholders have to be identified and this can result in a stakeholder assessment report.

The third step of the organizational analysis in figure 1, consists of assessing the current report and measurement system.

Knowing the current way of using and producing reports, facts and figures gives insight in how well the organization is steered, but it also provides information about the next activity ‘set goals’.

The last step in analyzing the organization is conducting benchmarks.

A benchmark is a useful management technique to improve performance.

In a benchmark different parts of the organization can be compared, like units or processes.

But also organizations as a whole can be compared in a benchmark.

It is important to determine whether a service management process should be benchmarked or not.

A focus on the relevant service management processes is essential.

The results of the benchmarks can result in the identification of gaps. ITIL Planning to implement service management 104 Set goals The next activity in the CSIP is about the agreement between business and IT regarding the required and expected future roles and characteristics of the organization, which are based on the current maturity of the organization.

The first step that needs to be taken is the creation of a business case to describe the added value and the justification of the CSIP.

The business case is determined by the current maturity of the organization and the organizational strategy.

A stakeholder assessment, conducted in the previous activity, can also be a contribution to the focus on the results and the aim of the improvement programme.

Furthermore, risks should be identified and managed.

An approach to risk management should be applied during the CSIP.

Mainly the risks related to the business vision, existing processes and the environment and business constraints should be managed to reduce the effects of those risks.

After having created a business case, a gap assessment report should be completed.

A gap assessment report is used to compare the current state with the future state of the organization and this results in gaps to overcome (‘where do we want to be’).

It provides information about gaps, risks and the prioritization on where to start.

Once a gap assessment report has been completed, there is a need for understanding and clarity.

That means that the problems and the following steps have to be presented to the key stakeholders, to establish creditability for the assessment and support concerning the change.

The following step is the creation of a plan for quick wins.

A quick win is an early success during an improvement programme.

In the plan for quick wins short term wins should be identified and attained to keep the improvement programme running and to keep the commitment level high during the improvement programme.

The last step is setting the goals regarding the improvement programme in relation to the earlier defined stakeholder needs.

A management tool for setting goals and measuring performance is the balanced scorecard. Implement IT service management The first thing to consider regarding implementing or improving service management is finding an answer on where to start (‘which service management process?’).

Before identifying a process that need to be improved, the first condition that needs to be fulfilled is that the organization should have documented its current and desired state, which includes a completed gap assessment report. ‘Where to start’ also depends on the level of maturity and the strategic goals of the organization.

Besides these dependencies, it is important to understand the interrelationships between all the IT Service Management processes.

Another aspect which should be taken into consideration during the improvement programme is creating awareness of the change.

This can be done by making a communication plan, which will give an explanation about the IT policy to the stakeholders.

The next thing to consider is how the changes are going to be achieved.

Achieving changes requires a reliable change programme.

To prevent a CSIP from missing its intended goals the OGC recommends [1] the approach from J.P.

Kotter, called: ‘Eight steps to transforming your organisation’ in combination with project management such as PRINCE2.

The main reason for using this approach in combination with regular project management, is that this approach also takes the softer sides of change into account like resistance to change and creating commitment.


Kotter studied more than 100 companies with regard to their transformations in the past years.

This has resulted in eight main reasons why transformations succeed.

The duration of the studied transformations was quite long, about six to eight years.Transformation_fail The eight main reasons why transformations succeed are transformed into eight steps. 1.

Creating a sense of urgency 2.

Forming a guiding coalition 3.

Creating a vision 4.communicating the vision ITIL Planning to implement service management 5. 6. 7. 8. ‘Empowering’ to act on the vision Planning for and creating quick wins Consolidating improvements and producing more change Institutionalizing the change 105 These eight steps can be applied equally to a service management improvement programme.

The culture of the organization is a main issue to be taken into account during organizational change, because organizational change could support an implementation, and it can as well lead to resistance.

For that reason the organizational culture should be managed in order to avoid problems like resistance.

A critical success factor for a CSIP is the clear definition of accountability, roles and responsibility in relation to the new processes and the existing organizational structure.

New processes and working practices do often not fit within the existing organizational structure, because processes are often cross functional.

In other words, processes may run through the whole organization.

In this way new processes and working practices may introduce new roles, which may overlap the existing organizational structure.

The last aspect that has to be taken into account regarding the implementation of IT service management is training.

Training can contribute to a higher quality of service management and it can also lead to more productive and responsive employees.

Before setting up a training programme, questions like who to train, when to train, how to train and what to train should be answered.

For ITIL training see: ITIL Certification. Measure goals After the completion of each improvement process a Post Implementation Review (PIR) should be conducted to indicate if the objectives have been achieved.

This can be done by making a comparison between the achievement of the improvement and the goals earlier set in the programme.

When the results of the PIR are confirmed, new targets regarding improvement should be defined.During the improvement programme the Key Performance Indicators (KPIs), which are earlier created during setting the goals as a part of the balanced scorecard, are needed to be constantly monitored to confirm the PIR.

Also, the improvement of the customers perception (customer KPIs) during the CSIP needs to be surveyed.

This can be done by conducting a regular statistical survey regarding customer satisfaction, also called a Customer Satisfaction Survey (CSS). Process-data diagram descriptions Table of concepts Concept Assessment Balanced Scorecard Definition The classification of someone or something with respect to its worth. [6] An aid to organizational Performance management.

It helps to focus, not only on the financial targets but also on the internal processes, customers, and learning and growth issues. [1] A report that contains a comparison of performance between different organizations or between different units within an organization. [1] Information that describes the justification for setting up and continuing a PRINCE2 project.

It provides the reasons (and answers the question ‘Why?’) for the project.

It is updated at key points throughout the project. [7] A plan that describes how the IT policy will be explained to the stakeholders and as a result of this, it will create awareness in the organization. [1] The addition, modification or removal of the whole of the ideas, corporate values, beliefs, practices, expectations about behavior and daily customs that are shared by the employees in an organization. [1] Benchmark report Business case Communication plan Cultural change ITIL Planning to implement service management 106 Decision document A document which gives an answer on the question ‘Where should I start’ and depends on the completeness of the assessments conducted in the previous steps, like determining the maturity level of the organization, service processes and strategic goals. [1] A change management model, consisting of eight steps. [9] Gap analysis naturally flows from benchmarking or other assessments.

Once we understand what is the general expectation of performance in industry, we can then compare that with current capabilities, and this becomes the gap analysis. [10] The state of affairs that a plan is intended to achieve and that (when achieved) terminates behavior intended to achieve it. [5] A model that determines the current maturity of the IT organization in terms of vision and strategy, steering, processes, people, technology and culture. [1] The active employment of particular sets of measurement recommendations. [3] Measurable element of a service process or function. [1] Organizational change has two dimensions.

The first, OC involves a transformation of organizations between two points in time.

The second dimensions concerns the way the transformation occurs. [8] Responsibilities, authorities and relations organized in such a way as to enable the organization to perform its functions. [11] One or more reviews held after project closure to determine if the expected benefits have been obtained. [7] Eight step model Gap assessment report Goal IT Organizational growth model Measurement framework Metric Organizational change Organizational structure — Risk management Service improvement SM (service management) vision statement Stakeholder assessment Stakeholder goal Strategy Training programme Table 1: table of concepts with definitions References of table of concepts 1.

Office of Government Commerce (OGC). (2002).

Planning to Implement Service Management.

London : The Stationery Office. 2.

Raynor, M.E. (1998).

That vision thing: Do we need it?.

Long range planning, 31, 3. 3.

Folan, P., Browne, J. (2005), A review of performance measurement: Towards performance management.computers in industry, 56, 7. 4.

Mintzberg, H. (1978).

Patterns in Strategy Formation.

Management Science, 24, 9. 5.

WordNet Search – 2.1. (2006).

Retrieved March 8, 2006 from Princeton Website: perl/webwn?s=goal 6.

WordNet Search – 2.1. (2006).

Retrieved March 8, 2006 from Princeton Website: ITIL Planning to implement service management 7.

Best practice. (2006).

Retrieved March 8, 2006 from OCG Website: 8.

William P.

Barnett; Glenn R.

Carroll. (1995).

Modeling Internal Organizational Change.

Annual Review of Sociology, 21, pp. 217-236. 9.

Egan, R.W., Fjermestad, J. (2005).

Change and Resistance: Help for the Practitioner of Change.

Proceedings of the 38th Hawaii International Conference on System Sciences – 2005 10.

Definitions of Terms. (2006).

Retrieved March 8, 2006 from Balanced Scorecard Institute Website: http:// 11.

Development of Quality Assurance System in Higher Education(QUASYS). (2001).

Retrieved March 10, 2006 from University of Zagreb Website: 107 Activity description Activity Create vision Sub-activity Description Creating a VISION STATEMENT for service management which fits with the organization STRATEGY.

Evaluate current position Evaluating the current position can be done by assessing the , IT ORGANIZATION GROWTH MODEL.

This gives an indication of the maturity of the organization.

Assess stakeholders Defining and analyzing the stakeholders and their needs, which results in a STAKEHOLDER ASSESSMENT.

Assessing the current report and measure system results in a MEASUREMENT FRAMEWORK. Analyze organization Assess current report and measure system Conduct benchmark Benchmarking results in a few BENCHMARKS, which can be used as a steering instrument and can be categorised in four categories, which are not further explained.

The IT ORGANIZATION GROWTH MODEL and STRATEGY determine the BUSINESS CASE (current position) which describes not only measurable targets, but also the costs, effort, benefits sense of urgency etc.

Managing risks results the artifact RISKMANAGEMENT, which is required by the BUSINESS CASE.

BENCHMARKS lead to the analyses of gaps to determine the start.

This activity results in a GAP ASSESSMENT REPORT.

A PLAN OF QUICK WINS is based on the GAP ASSESSMENT REPORT and is needed to convince the stakeholders of the changes/implementation.

Results in STAKEHOLDER GOALS, which is a generalization of GOAL Set goals Create business case Manage risks Conduct gap analysis Create plan for quick wins Set stakeholder goals ITIL Planning to implement service management 108 Implement ITSM Select starting point Selecting a starting point can be done by creating a DECISION DOCUMENT, which initiates ORGANIZATIONAL CHANGE.

The decision to start the implementation is based on the completeness of the previous activities see: Non-described rule Adapt results previous activities Create awareness Awareness can be achieved by creating a COMMUNICATION PLAN that supports ORGANIZATIONAL CHANGE Managing org.

Change results in ORGANIZATIONAL CHANGE and can be done by using the EIGHT STEPS MODEL combined with PROJECT MANAGEMENT Managing cult.

Change results in the artifact CULTURAL CHANGE and is required by ORGANIZATIONAL CHANGE.

CULTURAL CHANGE encloses the soft side of the CHANGE.orgANIZATIONAL CHANGE involves the ORGANISATION STRUCTURE, which may change aspects like authority, tasks, functions, roles etc.orgANIZATIONAL CHANGE requires ITIL training (TRAINING PROGRAMME).

Which training is needed, depends on the change.

This activity results in a POST IMPLEMENT.

REVIEW, which includes a comparison of the set and achieved goals/targets Manage organizational change Manage cultural change Set roles Train employees Measure goals Table 2: description of activities and sub-activities Non-described rule • This activity will be started if no starting point can be selected.

In that situation, this activity will result in an adaptation of the already delivered incomplete products, such as a gap assessment report. References 1.

Office of Government Commerce (OGC). (2002).

Planning to Implement Service Management.

London : The Stationery Office. 2.

Weerd, I.

Van de (2005).

WEM: A design method for CMS-based web implementations.

UU-CS (Int.

Rep. 2005-043).

UU WINFI Informatica en Informatiekunde. 3.

Kotter, J.P. (1995).

Why transformation efforts fail.

Harvard Business Review, 59–67 In: Journal of Product Innovation Management. 13, 2 , March 1996, 170 4.

Hochtstein, A., Tamm, G., Brenner, W. (2005).

Service oriented IT management: benefit, cost and success factors.

Proceedings 13 European conference on information systems (ECIS 2005), Regensburg, Germany. External links • • • • • • The OGC website [1] IT Service Management Forum [2] The ITIL definition site [3] The ITIL Forum [4] The OGC successful delivery toolkit [5] OGC get best practice [6] ITIL Planning to implement service management 109 References [1] [2] [3] [4] [5] [6] http:/ / www.itil.


Uk/ http:/ / http:/ /

Uk/ http:/ / http:/ / www.ogc.


Uk/ sdtoolkit/ deliveryteam/ briefings/ ITIL/ index.

Html http:/ / www.get-best-practice.


Uk Market analysis for product software Market analysis for product software consists of a number of techniques that allow an organization to collect and disseminate information from their external environment of software products for use in determining their market strategy and actions.

For example, market analysis helps to determine critical strategies for new software products such as time-to-market length, creating product differentiation, creating and preserving supplier credibility, developing effective distribution channels, forming relationships with large customers, and managing market efforts (Igel & Islam, 2001).

This topic has its roots in marketing discipline.

Many types of market research techniques are used to gather this information.

Market analysis plays a large part in explaining the current situation of a marketing plan.

Marketing is very important to new product development because software products have a short average lifespan of five years and incur 75% of the costs during the research and development phase (Atkinson et al., 2004).

Therefore, including market analysis information early on in the product lifecycle can ensure resources are not wasted.

It’s a wide field so this article is a sample of scientific work that has linked the fields of marketing and product software.

This consists of research in the fields of general market, customer, and competitor analysis which can be seen as processes that are hierarchically grouped under market analysis in the meta-process model from the figure below.

There are many processes that can be used for each of these three processes to acquire information from the market.

This article only lists a selected few for each. General Market Characteristics for Product Software Analysis of general market characteristics should lead to information about the market such as definition, size, trends, and market segmentation.

This analysis is needed to help develop and maintain marketing strategies for product software and overall business strategies.

The covered methods and techniques to obtain this information are Porter’s five forces model, risk analysis, marketing intelligence, and marketing decision support systems.Porter’s five forces analysis is useful for software since it highlights many important factors that will be discussed in customer and competitor analysis such as switching costs, brand equity, product differentiation, and price of total purchase. • risk analysis for product software*marketing intelligence • marketing decision support systems Customer analysis for product software Customer analysis is needed to predict behavior and create demand forecasts for product software.

It is also necessary in the development of new products to help select the most profitable choice.

To analyze customers, aspects such as demographics, buying motivation, and expectations are studied.

Besides basing behavior on software only, customers also look at the network externalities from software packages, such as manuals, add-ons, and training courses, to make purchase decision.All of these subjects are useful for determining target groups (also known as market segments). Market analysis for product software Moreover, this information helps determine the optimal solution to the tradeoff between time-to-market and quality.

Market analysis results are important to help establish an optimal point between the tradeoff of time-to-market and quality.

While customers would love to have a short time-to-market with lots of features and high quality, it is impossible for the vendor to find financial success in this scenario.

Therefore, a managerial decision must be made on the resources and objectives for new product development.

Risk analysis techniques can be used to manage this trade-off decision (Carmel, 1995).

With the heavy competition in most software product markets, gaining early market acceptance is essential to achieving firm success (Trondsen, 1996).

This is not easy to do.

Product complexity and rapid changes in requirements increase the difficulty of rushing software products to market.

There are some ways to relieve this tension of time-to-market.The best way for a software company to remain competitive, is by finding ways to include quality assurance activities during software development and at the same time find ways to reduce the time-to-market.

This is one of the key management decisions during product development facing software companies.

Customers can be divided into two groups, consumers (an individual) and corporate buyers.

Consumers generally buy software for personal use on their home computer.

While they behave as individuals, they are influenced by the environment and the other people around them.

For consumers, psychological traits, such as risk-taker versus risk-avoider, play a great role in major decisions by the individual.

Many other factors play a role for corporate buyers of product software.

Businesses buy product software usually as an indirect material to help them increase the effectiveness of their process.

There is a complex interaction of individual and group goals working during the decision-making process that are constrained by available resources.

A technique for dealing with the buying process in a firm is the buying center.

Many techniques are used to provide information on customers.

Some examples are: • Customer satisfaction dimensions • Consumer surplus for software products • Database marketing technique for software products 110 Competitor analysis for product software — • Len Bass, Paul Clements, Rick Kazman, “Software Architecture in Practice”, Addison Wesley, 1998 ISBN 0-201-19930-0 • Tony Shan and Winnie Hua (2006).

Solution Architecting Mechanism ( 1109/EDOC.2006.54).

Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32. • Barbacci, M.

R., S.


Carriere, P.


Feiler, R.

Kazman, M.


Klein, H.


Lipson, T.


Longstaff, and C.


Weinstock, “Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis” • Ogush, M., D.

Coleman, and D.

Beringer, “A Template for Documenting Software Architectures”, March 2000. • Youngs, R., D.

Redmond-Pyle, P.

Spaas, and E.

Kahan, “A Standard for Architecture Description”, IBM Systems Journal, Vol 38 No 1.

Http:// Article Sources and Contributors 118 Article Sources and Contributors Configuration management  Source:  Contributors: .digamma, ALMGuru, AbsolutDan, Ahoerstemeier, AlistairMcMillan, Altenmann, AndrewLighten, Assadchaudhry, Bartosz, Becky 55, Bestofcm, Billscottmorri, Bonwag, CanisRufus, Capricorn42,, Chowbok, ChrisG, ChristianBk, Cloudz1, ComputerGeezer, Cuttysc, Danipen, David Biddulph, Dchem, DoBBers, DonYonce8912, Douga, Druiloor, DynamSoft, Ebyabe, Emanhattan, Encoreopus, Ericlee748, Esdaniel, Everything counts, Exexpat, Fleminra, Flockmeal, Fstop22, Geraldo Medrano, Gleesona 7, Gtewallace, Gurch, HBowie, Haakon, Harald Hansen, Huerlisi, Igfrace, Imroy, JTN, Jaylobb, Jdotscott, JordanSamuels, JoshRyan, Jpalm 98, Julian Mendez, JullyKitty, Keebrook, Kuru, LeeHunter, Lichen0426, Lmarinho, Ludootje, M.e, M4gnum0n, Mandarax, Marc Girod, Marcelo Pinto, Mdd, Mild Bill Hiccup, Mjviscomi, Moreschi, MrOllie, Nixdorf, Ohnoitsjamie, Optimist on the run, Orderud, Ouc, Oveja, Owain.wilson, Pascal666, PatrickEgan, Patrickegan, Pekowski, Pelerin2, Petra.hegarty, Pg133, PhilKnight, Phobius, Project2501a, R.castelo, Raven22, Rickranger, RoySmith, Rwwww, Régis Décamps, SMcCandlish, SQL, Sabri76, Sam Hocevar, Sigma 7, SimonP, Smack, Soarhead77, Stephen1121, SunCreator, The Anome, Tiago simoes, Tom2856, Ttesmer, Ventonegro, Vsion, Wessel 1560, Wile E.

Heresiarch, 287 anonymous edits Comparison of open source configuration management software  Source:  Contributors: Aftereight, Agujero Negro, Alfredodeza, Anastrophe, Antonielly, B2pi, B3rt0h, Carlp101, Dakol, David Gerard, Detlef.oertel, Djbclark, Dparrish, Earthsound, Firsfron, FleetCommand, Gkokmdam, Gudeldar, Haakon, Hugoduncan, Intgr, JLaTondre, Jerryobject, Jheiss, Jrouquie, Keithlard, LanceBrown NC, Larstobi, Lololololol12, Martinwind, Micah, MikhailGusarov, Mjquinn id, Moocha, Mortense, No1shah, Onno Zweers, Ouc, PaulParadise, Philipmather, Plathrop, Ptab, RandyFranklinSmith, Rchanter, Requestion, RobLa, Rouilj, Rrburke, Snarfdubois, Stephan Leeds, SteveLoughran, Stevegt, Swestrup, Thyrsus, Tithrion, Toutoune25, Umeditor, VladV, Zethradon, 133 anonymous edits Accelops  Source:  Contributors: Alpha Quadrant, Auntof6, DanielPharos, Enjaysea, Iqlas, John of Reading, Sadads, Scottgwikip, 2 anonymous edits AccuRev SCM  Source:  Contributors: Bearcat, Cs909, Inks.LWC, Katharineamy, Tedickey, Whimsicalgenius, 5 anonymous edits Augeas (software)  Source:  Contributors: Borkificator, Dawynn, Raphink Baseline (configuration management)  Source:  Contributors: .digamma, Andonic, Andreas Kaufmann, ChrisG, Craigwb, Dcpassarelli, Epolk, Iamatom, Imroy, Largoplazo, Lilac Soul, Mild Bill Hiccup, Mkoval, MrOllie, Nepenthes, Orderud, Scarian, T-dot, Uncle G, Walter Görlitz, 42 anonymous edits Bcfg2  Source:  Contributors: Carlp101, Dawynn, Djbclark, Fabian.a, Favonian, Glenn, Kathleen.wright5, Psychonaut, Rich Farmbrough, 40 anonymous edits Belarc  Source:  Contributors: BD2412, FleetCommand, GardenQuad, Rich Farmbrough, Standardfact, Steamroller Assault, Sumint, 5 anonymous edits CA Software Change Manager  Source:  Contributors: Alansohn, BlueAzure, Bonwag, Cascm, Harvestguy, Pzoxicuvybtnrm, Ric man, RickK, Rossami, SimonP, Uzume, 30 anonymous edits CFEngine  Source:  Contributors: Asav, Ayaham, Carlp101, CeciliaPang, CesarB, Csabo, DerekMorr, Djbclark, Druiloor, Emsearcy, Fiftyquid, Frap, Glenn, HopeSeekr of xMule, Joshr, Joy, Kb, Kenyon, Ketiltrout, Megateuf, MikhailGusarov, Minitrue, Moocha, NapoliRoma, NorwegianWikiMan, Ouc, Plasticity, RAFPeterM, Raffen, Rich Farmbrough, Shd, Tabletop, 51 anonymous edits Chef (software)  Source:  Contributors: Arto B, Carlp101, David Gerard, Fabrictramp, Jeffq, Jtimberman, Malcolma, Moocha, Moreati, Rayyung, Thomei08, 7 anonymous edits Component repository management  Source:  Contributors: Antonielly, BlueAzure, ChrisG, Cmdrjameson, Dtremenak, Ericnelson1, Hu Gadarn, Jpbowen, Lichen0426, Noveltyghost, R’n’B, RichardVeryard, Smack, Zscout370, 5 anonymous edits Configuration item  Source:  Contributors: BenFrantzDale, Bentogoa, Dasreiman, FuzzyBSc, Gonchibolso12, Haakon, JLaTondre, L Gran Gato, M.e, Nickcarr, Pearle, Persian Poet Gal, Ryanmcdaniel, Subash.chandran007, 29 anonymous edits Engineering support  Source:  Contributors: Canis Lupus, ChrisG, Esanchez7587, Everyking, Henry Delforn, Lichen0426, Lkinkade, Lord babba, Nick Number, Nycrdeary, The Thing That Should Not Be, Triploid, Truthanado, 3 anonymous edits Granular Configuration Automation  Source:  Contributors: Bearcat, Fetchcomms, Fstop22, Grafen, Jpbowen, My76Strat, Nick Number, SteveLoughran, 2 anonymous edits ISconf  Source:  Contributors: Carlp101, Dawynn, Moocha, Rwwww, Ukexpat, Wikiisawesome, Zethradon, 2 anonymous edits LCFG  Source:  Contributors: Bill37212, Carlp101, Cynical, Dawynn, Djbclark, Favonian, JonHarder, Nevilley, 7 anonymous edits M23 software distribution system  Source:  Contributors: Byramm, Charles Matthews, Detlef.oertel, FleetCommand, Hgsgh, Hhabermann, Ixfd64, Mboverload, Pissant, SF007, Tmassey, 8 anonymous edits Merge (revision control)  Source:  Contributors: .digamma, AllanBz, Amux, Btwied, Bulgrien, Chairman S., Deltawalker, Dneades, Dspattison, Geneffects, GeorgeBills, Jaxelrod, Jgrahn, Kevins, Liuxin4335, Metiscus, Neilc, Nigelj, Patrickegan, Pmyteh, Puppynose, Qz, Radagast83, RlyehRising, Rstockbower, Starwed, Stevemidgley, Sverdrup, Thomast15, Unenough, Will Beback Auto, 31 anonymous edits MSConfig  Source:  Contributors: 16@r, Ajfweb, Akerans, Anthall1991, Apokrif, Bevo, Bilky asko, Callidior, CliffC, Dfantom, Digita, Dustin gayler, Eightball, Elomis, FleetCommand, GSMR, GTAKIllerEric, Ghettoblaster, Gwern, Ishida639, Jamelan, Jzurbo77, Khinelay, Marshall Williams2, Materialscientist, Mentifisto, Mild Bill Hiccup, Mrzaius, Nbauman, Ngyikp, Niharika kant, Shape84, Silvergoat, Warren, Wasisnt, Xpclient, 38 anonymous edits Opsi  Source:  Contributors: BD2412, Bilbo-the-hobbit, Carlp101, Detlef.oertel, Drpickem, Eumolpo, Favonian, FleetCommand, Frap, GoneriLeBouder, LilHelpa, Mortense, Opsidoc, Tinjaw, Zundark, 3 anonymous edits Physical configuration audit  Source:  Contributors: Auntof6, Malcolma, Mcastellani, Mild Bill Hiccup, PamD, 3 anonymous edits Professional Systems Associates  Source:  Contributors: Emma.roach, MrOllie, Sphilbrick, Ukexpat, 3 anonymous edits Puppet (software)  Source:  Contributors: Ale jrb, Arto B, Brandorr, Carlp101, DanielPharos, David Gerard, DavidDouthitt, Demonkoryu, Gacq, Hulten, Joannaspark, Jonik, Kennethbarber, Klokie, Larstobi, Martarius, Martin Dluhos, Mike.lifeguard, Moreati, NoridelZeus, Ranamalo, SncBlue, Stephan Leeds, SteveLoughran, Stwalkerster, Thomei08, Thyrsus, Zundark, 25 anonymous edits Quattor  Source:  Contributors: Anrie Nord, Djbclark, Geniac, Ianpcollier, Jrha, Mattg82, Mjouvin, SteveTraylen, 17 anonymous edits RANCID (software)  Source:  Contributors: Ace Class Shadow, Adamathefrog, AlasdairM, BD2412, Druiloor, Icereaper, Kl4m-AWB, Krazycev13, Rjaf29, Sartan, ShakataGaNai, SiD3WiNDR, Totallygeek, Woohookitty, 14 anonymous edits Rational Synergy  Source:  Contributors: Bwpach, Chrylis, Condor77, Etaekema, GregHolmberg, Jancikotuc, Janesteeves, Llamascout, RHaworth, Willeyl, 9 anonymous edits Security Technical Implementation Guide  Source:  Contributors: Delmundo.averganzado, Ebyabe, Huns0004, Imaginary Pi Slicer, Marjomercado, Mortense, Munst, SouthLake, Woohookitty, 6 anonymous edits SmartFrog  Source:  Contributors: Aftereight, Akhilleus, Carlp101, D6, Julguinet, Malcolma, Moocha, Oscarthecat, SteveLoughran, 3 anonymous edits Article Sources and Contributors Software configuration management  Source:  Contributors: .digamma, Aaxiler, Adamantios, Andreas Kaufmann, Ankur.anil, Antaeus Feldspar, Arpit88dawda, Asdaqamin, Ashishapathak, Assadchaudhry, Bert.Roos, CMYanko, Casimir, Chris Wood, ClementSeveillac, Cloudz1, Craigwb, Danesaw, David Biddulph, David.alex.lamb, Dmsar, DougCuthbertson, ERcheck, Electrobins, Evarlast, Everything counts, Flopster2, GazRideGuide, Gil mo, Guruduttmallapur, Haakon, Hebrides, Huazheng, Imroy, Imz, JGFichte, JLaTondre, JTN, Jamelan, JoshRyan, Keebrook, M.e, M4gnum0n, Marc Girod, Marudubshinki, Master Bigode, Matt Crypto, Mav, Mdd, Mi.avataar, Michael Hardy, Michael Irwin, MrOllie, Nixdorf, PatrickEgan, Pedant17, Poccil, RHaworth, Rajeshkumarwiki, Rmbalk, RossPatterson, Ruud Koot, Sardanaphalus, Schaapr, Scottb1978, Shanem-vic-au, Simoncpu, SimplifyComplexity, Smee30, Starrymessenger, Stevertigo, Suruena, Techdoer, Technobadger, Tedickey, The Thing That Should Not Be, ThomasOwens, Thumperward, Typofixer76, Vipinhari, VladV, Wmahan, Zapraki, Zhenqinli, Zorgon7, ????????? ???????, 151 anonymous edits Sysedit  Source:  Contributors: Andrewpmk, Darklilac, Dawynn, Digita, Efitu, Elomis, Flarn2006, MDGx, Mrzaius, PamD, Warren, Wewsnu, Yutsi, 9 anonymous edits Method engineering  Source:  Contributors: CesarGon, DonFiresmith, Mdd, SEI Publications, 3 anonymous edits Axios Systems  Source:  Contributors: Aaditya 7, Cander0000, MGS1978, R’n’B, 8 anonymous edits Competitive Engineering  Source:  Contributors: ARAJ, Bwpach, ComputerGeezer, Elonka, Karpinski, R24in, SueHay, 2 anonymous edits Fagan inspection  Source:  Contributors: Altenmann, Arthena, Ash, Attilios, Bigbluefish, Can’t sleep, clown will eat me, ChrisG, Courcelles, Drbreznjev, Epeefleche, Gaff, Gaius Cornelius, Gimmetrow, Hockeyc, Icarusgeek, Iwearavolcomhat, JIP, Kezz90, MacGyverMagic, Mjevans, Mkjadhav, Nick Number, Okok, Pedro.haruo, Slightsmile, Tagishsimon, Talkaboutquality, Tassedethe, The Font, The Letter J, Zundark, 43 anonymous edits IBM Tivoli Unified Process (ITUP)  Source:  Contributors: Chowbok, Eustress, Giraffedata, IDefx, Kubanczyk, MikeDogma, MrOllie, Palbright, WeisheitSuchen, Woohookitty, 6 anonymous edits Information Services Procurement Library  Source:  Contributors: Betacommand, ChrisG, ESkog, Grenavitar, Greyskinnedboy, Jorrit, Jstruve, Malo, Mcalukin, Mdd, Niteowlneils, R’n’B, Ravedave, Spiritofdeaddog, Tagishsimon, The Thing That Should Not Be, Uncle G, 10 anonymous edits Information Technology Infrastructure Library  Source:  Contributors: A.

B., A3RO, AMe, Aberdeenwaters, Acm, Acpt22, ActiveSelective, Adrian.benko, Aerotheque, Aitias, Akbradford, Alanpc1, AlephGamma, Alexcuervo, Alimozcan, Allen4names, Andrea kempter, Andrzejkrajewski, Ankur onlyur, Anna Frodesiak, Antidoter, Aranel, AreJay, Ash, Aussieaubs, Avr, B Fizz, Barinder hothi, Baseball Bugs, Beland, BenAveling, BibTheLion, Bibikoff, Binarygal, Black Kite, Blehfu, Blroques, Bobrayner, Boekelj, Bradyn12, Brandguru, Brandon, Brianj hill, Butrain, CALR, CPrehn, Cain Mosni, Can’t sleep, clown will eat me, Canderson7, Captain panda, Cblanquer, Ccordray, Cgroberts, Charles T.

Betz, Chowbok, Chris.fischer, ChrisCork, ChrisG, Chzz, Cinfosys01, Cjdavis, Cmdrjameson, Coherers, Cometstyles, Credible58, Cuttysc, Damon, Dancter, Danialshazly, DanielPenfield, DanielVonEhren, Danielgwj, Darinkeir, Darth Panda, DaveWFarthing, Davebremer, David Biddulph, David.T.Bath, Davidbspalding, Dennisc68, Dia^, Discospinster, Dnblack, Dnicolaid, Docu, Doug Alford, Dpv, DragonflySixtyseven, Dritil, Eahiv, Edholden, Ehheh, Emba7 EilertE, Emesis, Epbr123, Estherschindler, Eugene-elgato, Evilmn, Excirial, Firsfron, Fortdj33, Fox, Frank, Freek Verkerk, Fstop22, Fudoreaper, Fustbariclation, Gaius Cornelius, Gcanyon, GerardM, Ghewgill, Ghw777, Goonies, Guigui NYC, Haakon, Halfgoku, Hengeloov, Hennek, Herbys, Hkroger, Hu12, Hulmem, IBM Press, IDefx, IET-Solutions, IIVQ, ITServiceGuy, Iness it, Itbeme, Itildude, Itsgeneb, IvanLanin, J.delanoy, J04n, JT72, Jammus, Jasenlee, JbRIV, Jclemens, Jlmata, JoeSmack, JonHarder, Jonik, Jovianeye, Jowanner, Jspurr01, KKuczko, Kaihsu, Kartisan, Keebrook, Keilana, Kevnosisyx, Kf4bdy, Kinu, Krackpot, Krusch, Kuru, Kycook, KyuuA4, Laug, Lehmannjl, Leirith, Lluinenb, MC MasterChef, MER-C, MMSequeira, Madman37, Magnus Manske, Majid iqbal, Malleus Fatuorum, Malo, Marcelo Pinto, Marcusmccoy, Markhoney, Martey, Martian, Materialscientist, Matthewedwards, Maximaximax, Mboverload, Mcsboulder, Mdd, Mellery, Metagraph, Mgillett, Michael Hardy, Michael J.

Cunningham, Michig, Michigan user, MikeDogma, Moeron, MrOllie, Mrehere, Mserge, Mudgen, Myszliak, Mzrahman, Najeh, Nasnema, NeilN, NickBush24, Nicoatridge, Niteowlneils, Nk, NoticeBored, Nslonim, Nuno Tavares, Nuujinn, Ocaasi, Oleh77, Olivier Debre, Omicronpersei8, OnePt618, OsvaldoCarvalho, Otto ter Haar, PRRfan, Panlm, Pansearch, Patchworker, Paulbruton, Paulbuchanan, Paulseatonsmith, Peterl, Pg133, Phil, Philip ea, Piano non troppo, Pion, Pocopocopocopoco, Pparazorback, Pukerua, RHaworth, RainbowOfLight, Ralphbk, Raspolsky, Ravizone2000, Raysonho, Rchandra, Rehan20784, Rich Farmbrough, Rnsimmons, Robocoder, Rockfang, Ron Richard, Ronz, Rpeasley, Rugops, Runefrost, Sam Hocevar, SamG1978, SamTheButcher, Sandy ts2k, SaulPerdomo, Sbrumpton, Scott McNay, ScottWAmbler, Sdr, Sharpner, Shawnse, Smulvih2, Snori, Soifranc, Some jerk on the Internet, Somnoliento, Srandaman, Sspecter, Stakfry526, Stephanobianco, Stevegregory79, StoneIsle, StuartR, SunSw0rd, Svetlev, Ta bu shi da yu, Tabletop, Takamaxa, Tandric, Tarun.Varshney, Tassedethe, Tbsdy lives, Tcwilliams, Technobadger, The Anome, The Letter J, The Thing That Should Not Be, Thecheesykid, Thingg, Thumperward, Ticaro, Tiptoety, Tjarrett, Tlaresch, Tobryant, Tpbradbury, TutterMouse, Twirligig, Twostardav, U11720, Uncle G, Vanbregt, Vashtihorvat, Veinor, VerdigrisP, Vince.meulle, VinitAdhopia, Vipinhari, Vlad, WECullen, Waggers, Watroba, Waturuochav, WebCoder11, WeeWillieWiki, West81, Wik, Wiki3 1415, WikiNickEN, Winterst, Woohookitty, Wren337, WxGopher, Xsmith, Zachlipton, Zsh, ??????, 1324 anonymous edits ITIL Planning to implement service management  Source:  Contributors: 9Nak, Allstar18, Amatriain, Annafriel, Lluinenb, Mdd, MikeDogma, Raysonho, Rjwilmsi, WeisheitSuchen, 22 anonymous edits Market analysis for product software  Source:  Contributors: Burkestar, ChrisG, Crazykake, JonHarder, Luna Santin, Mailer diablo, Maurreen, Niteowlneils, Pgrieg, Pratheepraj, Pumpkincat, Radagast83, Rich Farmbrough, Rl, Robofish, Rossami, Ruud Koot, Winterst, Woohookitty, 13 anonymous edits Marketing decision support systems  Source:  Contributors: ChrisG, Colonel Warden, Ep.morgan, I dream of horses, Jezhotwells, Pumpkincat, Robofish, TJRC, The Wordsmith, TheGrappler, Unara, 4 anonymous edits Method Framework for Engineering System Architectures  Source:  Contributors: Abductive, DonFiresmith, MLauba, Mdd, Minimac, Miyagawa, Rich Farmbrough Technical architecture  Source:  Contributors: Aasch, Allan McInnes, Aylahs, Barts1a, ChrisG, Dave Barnett, Denisarona, Discospinster, Diturriaga, FreplySpang, Gletiecq, Graham Berrisford, Horatio Huxham, Interested, Iterator12n, JaGa, Jarretinha, Maria C Mosak, Mdd, Mercurywoodrose, Nazrani, Norm”, Oicumayberight, OverlordQ, Promethean, Reade, Shadowjams, Skyezx, Sprigot, Steven Zhang, Svick, Tonyshan, Uncle G, Userid333, Vanished user 39948282, Wikip rhyre, ?, 66 anonymous edits 119 Image Sources, Licenses and Contributors 120 Image Sources, Licenses and Contributors Image:ConfiurationActivityModel.png  Source:  License: Public Domain  Contributors: Department of Defense Handbook Image:ao-logo-whitebg.jpg  Source:  License: Fair Use  Contributors: Iqlas, Melesse File:Cfengine logo.png  Source:  License: Fair Use  Contributors: MikhailGusarov Image:M23-logo.png  Source:  License: Creative Commons Attribution-Sharealike 2.5  Contributors: Hauke Goos-Habermann Image:Client add.png  Source:  License: Creative Commons Attribution-Sharealike 2.5  Contributors: Hauke Goos-Habermann Image:M23 Fdisk-extended0.png  Source:  License: Creative Commons Attribution-Sharealike 2.5  Contributors: Hauke Goos-Habermann File:Three-way-merge-parallelgram.svg  Source:  License: Creative Commons Attribution-Sharealike 3.0  Contributors: Dspattison Image:Msconfig icon.png  Source:  License: unknown  Contributors: Ishida639, Tuanese Image:MSConfig On Windows_Vista.png  Source:  License: unknown  Contributors: Dfantom, Ghettoblaster, Kathleen.wright5, Koman90, MasterProg, RyanGerbil10, SchmuckyTheCat, Warren File:Opsi-4-configed product configuration layout en.jpg  Source:  License: Creative Commons Attribution-Share Alike  Contributors: uib GmbH File:Method engineering process.jpg  Source:  License: Public Domain  Contributors: Richard J.

Mayer and others Image:Axios Systems logo.svg  Source:  License: Fair Use  Contributors: Aaditya 7 Image:Fagan Inspection Simple flow.gif  Source:  License: Public Domain  Contributors: Monkeybait, Okok, 1 anonymous edits Image:Wearer of an ITIL Foundation Certificate pin.jpg  Source:  License: Creative Commons Attribution-ShareAlike 3.0 Unported  Contributors: Tijmen Stam (User:IIVQ) Image:Procesdatadiagram planning to implement ITIL.png  Source:  License: Creative Commons Attribution-Sharealike 2.5  Contributors: L.

Luinenburg (Lluinenb) Original uploader was Lluinenb at en.wikipedia License 121 License Creative Commons Attribution-Share Alike 3.0 Unported http:/ / licenses/ by-sa/ 3. 0/

Read more about ITIL : Contents Articles Configuration management Comparison of open source configuration management….:

Accredited ITIL Foundation, Intermediate and Expert Certifications

Accredited ITIL Foundation, Intermediate and Expert Certifications, Learn more about ITIL HERE:

ITIL and ITIL : Contents Articles Configuration management Comparison of open source configuration management….

ITIL - ITIL : Contents Articles Configuration management Comparison of open source configuration management….

ITIL and ITIL : Contents Articles Configuration management Comparison of open source configuration management….

ITIL - ITIL : Contents Articles Configuration management Comparison of open source configuration management….