Библиотека процессов закупок информационных услуг (ISPL)

The Information Services Procurement Library (ISPL) is a best practice library for the management of Information Technology related acquisition processes (derived from Euromethod). 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 (e. g. 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).

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.

The ISPL Acquisition Process is the actual process of obtaining a system or service to achieve a goal contributing to business objectives and/or needs. It is one of the most important parts of the ISPL method. This chapter is a summary of [2].

The first process to be executed by the customer contract authority within an acquisition is the acquisition initiation process. It consists of two sequential process steps: acquisition goal definition and acquisition planning. The final result of the process is an acquisition plan reflecting an acquisition strategy, along with a clear understanding of systems and services requirements defining the acquisition goal. The acquisition initiation process is illustrated in Figure 5. A more detailed description of the Acquisition Initiation phase can be found here.

The result of this step is a sufficiently clear understanding of the requirements to the systems and services that are the goal of the acquisition and the costs and benefits for the business and its various stakeholders. This process step consists of four activities:
Define the target domain. Refine the definition of the acquisition goal in terms of systems and services requirements. Analyse costs and benefits. Analyse stakes and stakeholders. The input of business needs is ideally provided by Requirements management processes.

This process aims to monitor the services defined in the contract. It has to ensure that the deliverable and services conform to the requirements in the contract. The most important activity of the contract monitoring process is the execution of the decision points. In the decision point execution the customer organization makes judgments and decisions based on the status of the procurement at any given time.

The aim of this process is to ensure that all outstanding technical and commercial requirements in the procurement contract (that was written and signed in the tendering phase) have been met.

The acquisition manager has to check the completion of the different contracts by checking if each individual contract's completion phase has been achieved and the required reports are written. If necessary the acquisition manager has to trigger the contract completion process for contracts that need it.

Unfortunately, when all individual contracts’ goals are reached this does not automatically mean that the acquisition goal is achieved. In this activity of the acquisition completion the acquisition manager has to verify the customer company's business objectives have been met and there are no missing parts in the acquisition that have been overlooked.

Based on the assessment of the contract completions and the achievement of the acquisition goal the decision whether the acquisition is complete is made. This decision is generally made by the acquisition manager together with representatives of all the organizational authorities concerned with the acquisition. When one or more contracts are not completed or the acquisition goal is not reached this decision requires the involvement of the customer company's organizational authorities.

ISPL's form of risk management is purely based on heuristics. By describing and analyzing 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].

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.

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

There are two steps in describing an ongoing service. I will briefly elaborate on each of these steps in the following paragraphs.

Projects are described by an initial and a final state, i. e. 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.

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.

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

The situation of both the customer and supplier organizations 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.

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 demotivate 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, i. e. 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.

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.

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.

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.

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.

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:
Derive basic sequence of decision points. Adapt basic sequence to accommodate actions. Describe 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.

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

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 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.

ISPL focuses on the relationship between customer and supplier. It is very important that the communication between both parties is clear and unambiguous. A deliverable is a product that is exchanged between the supplier and customer organisations (both ways). Deliverables are exchanged in all phases of the acquisition process: e. g. the Request For Proposal during the tendering phase, the intermediate versions during the execution of the delivery plan, and the declaration of contract completion at the end of each contract. ISPL provides guidance for the specification of all deliverables needed in the acquisition process. This chapter is a summary of [5].

ISPL divides deliverables in various types, each with a defined set of properties. These properties characterise the knowledge that is captured by each type of deliverable. Figure 8 illustrates the different types of deliverables.

Contract domain deliverables are used to define and control all contracts in a procurement. There are two types of contract domain deliverables: the tendering deliverable and the decision point deliverable. In the following paragraphs each of these types is discussed in detail.

Service domain deliverables describe the service domain (see paragraph #Target domain and service domain for more information). They are delivered by both customer and supplier organisations to plan and control services. There are two types of service domain deliverables: service plans and service reports.

A service plan provides information on how to meet identifies goals in terms of service levels, deliverables, schedules, resources and costs. It can for instance give guidance on how to reach targets. ISPL describes the different properties that can be included in the service plan.

In contrast to the service plan, the service reports controls the service status by reviewing service levels and results. It records the service's productivity and proposes corrective actions. ISPL gives guidance on which information should be included for each property that is described in the service report.

The target domain is described using target domain deliverables. There are two different types of target domain deliverables: operational items and descriptive items. Both will be discussed in the following paragraphs.

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.