| 词条 | Acquisition initiation (ISPL) |
| 释义 |
}} Acquisition Initiation is the initial process within the Information Services Procurement Library (ISPL) and is executed by a customer organization intending to procure Information Services. The process is composed of two main activities: the making of the acquisition goal definition and the making of the acquisition planning. During the acquisition initiation, an iterative process arises in which questions about the goal of the acquisition are usually asked. In response to these questions the Library provides details of the requirements, covering areas such as cost, feasibility and timelines. An example of such requirements is the "planning of the acquisition", a component that may also lead to more questions about the acquisition goal (thus, it is reasonable to state that a relationship exists between the acquisition goal and the acquisition planning). The process-data model shown in the following section displays the acquisition initiation stages. It shows both the process and the data ensuing from the process, and parts of the image will also be used as references in the body of this article.[1] The concepts and data found in the model are explained in separate tables which can be found in the section immediately following the model. A textual, and more thorough, explanation of the activities and concepts that make up the Acquisition Initiation process can be found in the remainder of this article. Draft acquisition goalThe draft acquisition goal is the description of the global goal that is to be achieved by starting procurement. It is inspired by the business needs or business strategy. It is similar, though simpler, to the concept of the project brief in PRINCE2. It is the first draft of the acquisition goal, containing at least a (short) problem definition and a (short) goal definition. The draft acquisition goal is meant to give the main reasons and the main goals to those people who will have to make the decision to actually start of the acquisition or not. It may thus also encapsulate items like a cost-benefit analysis, stakes & stakeholders and other items that will be further refined during the actual Acquisition Initiation. It is, in this sense, not an activity of the acquisition initiation process, but it is the input for starting the process. The problem definition is a statement about the problem that could be resolved by starting the acquisition process. E.g.: The production process is becoming increasingly inefficient, in part because of aged software The goal definition is a statement about the goal that will have to be reached when the acquisition is executed: E.g.: The production process will see a 20% increase in both cost and time efficiency, when the software that is used in the process is updated The draft acquisition goal can be made as short or as long as is needed by the organization, as long as it serves to be a good basis to make the initial decision to start of an acquisition process. Acquisition goal definitionWhen the decision is made to start an acquisition process, the first activity of the acquisition initiation is to define the acquisition goal. The acquisition goal is the whole of defined systems and services requirements, attributed by costs & benefits and stakes & stakeholders, with a defined target domain serving as the boundary. The acquisition goal is the basis of the acquisition process and for formulating the acquisition strategy during the acquisition planning. Input can be the draft acquisition goal and the business needs (of the target domain). The business needs can be derived from strategic business plans or information system plans. Defining the target domainThe target domain is that part of the customer organization that is involved in, or influenced by an information service. It is defined in terms of business processes, business actors, business information, business technology and the relations between these four aspects. The target domain is identified to ensure a fitting acquisition goal with fitting requirements for the systems and services to be acquired.
E.g.: the marketing-processes, intended to create and maintain a market for the products or services of the organization.
E.g.: sales figures, market researches etc; the marketing theories and methods used in the marketing process; a result of the process in the form of a new marketing strategy involving new types of advertising.
E.g.: a marketing-employee using a computer with tools used to execute the marketing-process.
E.g.: a marketing theory on how to approach new customers, a graphical tool to make posters, etc. A limited description of a target domain can thus be, for example: Refining the acquisition goal
E.g.: the new marketing software package will have to have a response time of between 0 and 3 seconds for a database query. The acquisition goal is then described by system descriptions and service descriptions:
A system is an integrated composite that consists or one or more of the processes, hardware, software, facilities and people that provide a capability to satisfy a stated need or objective (definition by ISO/IEC 12207).
A service is a process that a person or organization executes in favor of another. ISPL defines two types of services:
Projects are described by documenting:
Ongoing services are described by documenting:
When the requirements set in the (initial) system and service descriptions do not offer enough basis for:
a more thorough requirements analysis, using an acknowledged method, may be necessary. Other information on how ISPL defines the deliverables of the acquisition can be found in the general ISPL entry. Costs–benefits analysisCost–benefit analysis concerns the analysis of:
to successfully evaluate the investment issues of the acquisition. Benefits must be evaluated, even if they are not quantifiable, but preferably identified by using financial terms or other quantifiable metrics. e.g.: The software to be acquired will enable the marketing department to handle the data of past activities at a 10% more efficient rate as with the current system. Costs must be evaluated thoroughly, depending mostly, but not solely, on the systems and services requirements and the acquisition strategy that will be adopted. Costs are thus not only related to hardware or software purchase (or development), but with the costs of all activities within the acquisition. e.g.: Acquisition management, quality assurance and trainings for actors. Stakes and stakeholders analysis
It is important to identify all actors affected, and in what way they are affected (their stake), because a negative attitude of actors may negatively influence the success of the acquisition. ISPL proposes to perform a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats) for the actors involved to properly and thoroughly identify the stakes of the actors. The results of this analysis can serve as input for the situation & risk analysis. Acquisition planningThe information contained within the Acquisition Goal is used to produce the acquisition plan. The acquisition plan is the master plan of the entire acquisition. In this plan delivery scenarios are determined and the situation and risks evaluated. And upon the basis of the scenario’s, situation and risks, a strategy is formed to manage the acquisition, its situation and risks. Furthermore, the acquisition plan will hold the main decision points, in which decisions are made about the deliverables within the acquisition and the acquisition organization (similar to a project organization) is formed. Service delivery scenarioOn the basis of the acquisition goal, which contains among others the systems and services requirements and descriptions, scenarios can be formed for the deliveries of the information services to be acquired. Multiple scenarios may be built, which will then be evaluated and used in the design of the acquisition strategy. The scenarios are built with the priorities and interdependence of the deliverables in mind. PriorityPriorities are related to the importance of each delivery: which delivery has time-preference over another. Priorities can flow from:
DependencySome deliveries may be dependent on each other, requiring one services to be delivered before the next one can be. These dependencies may be:
E.g.: New hardware must installed before the software can be.
E.g.: Core-functionality of an ERP package has to be configured before modules can be activated and configured.
Example:E.g.: When the USB-port was thought up, the USB-port was probably first developed, before computers were developed that could make use of it. During a project to make ISPL more specific for generic product software implementations, a number of scenario’s were made. One of these was for an approach of a one-shot implementation. The below picture shows a diagram of the scenario that was made. An example of a scenario for the implementation of software is shown in the thumbnail on the right. In this example, the general deliverables within an implementation of software are mentioned, executed and delivered differently as time goes by, mainly because of dependencies between deliverables. For instance, the actual go for the delivery of the software and the other related deliverables are dependent on the outcome of the deliverable “Proeftuin”. “Proeftuin” is an agreed period in which the software is extensively tested by the customer organization, provided and supported by the supplier. The customer organization can get a feel for the use of the software in the target domain, to guarantee that the software is a “fit” within the organization. Situation and risk analysisISPL adheres to a situational approach to manage an acquisition. The situational approach takes into account properties of the problem situation, which are called situational factors. ISPL provides a number of these situational factors. Some of these situational factors affect events that have adverse consequences: the risks. Thus, the situational factors and risks within ISPL are related to each other. This makes it possible to provide a number of heuristics on which factors have an influence on certain risks. First the situation is analysed, then ISPL proposes a number of risks which may arise from the situation at hand. With this information, an acquisition strategy can be formed to mitigate both the situation and risks in a number of areas. Other information of the situation & risk analysis of ISPL can be found in the ISPL entry. SituationThe situation of the acquisition is first assessed. ISPL provides a checklist of situational factors to analyze the situation, the knowledge about the situation to effectively use the checklist is gained by the analysis of documents and by interviewing key actors within the acquisition. The checklist that ISPL provides is, of course, neither definitive nor exhaustive but gives an idea of some main points that may describe the situation at hand. The situation is described with two dimensions, which together can be used to assess the situation:
Both are grouped into four classes: process, information, actors, technology. An example of a situational factor related the complexity of processes in the target-domain (taken from the ISPL book: Managing risks and planning deliveries (see external links)) is found in the image below. After all situational factors have been analyzed for their measure or complexity or uncertainty, the overall situation must be evaluated:
The overall uncertainty and complexity is determined with expertise present within the organization. Service domain definitionFor the situation analysis to work and properly identify all possible risks concerned with the acquisition, knowledge is needed about the complexity and uncertainty involved with the service domain: the service provider. This is because the service domain may influence the success of the acquisition. The service domain is identified in a similar way as the target domain. It may be difficult in this early stage of the ISPL process to thoroughly identify the service domain though, because it may be that external suppliers will be attracted to deliver some of the deliverables. External suppliers are, at this point unknown. This is why, during the course of the acquisition, the situation & risk analysis must be repeated for re-evaluation. Risk;A risk :A risk is the possible occurrence of the adverse consequences of an event. Risk analysis is:
ISPL has determined a set of risks, divided over two classes:
The risks are related to the situational factors that ISPL provides. Example of a risk that is related to the example of the situational factor given above: When
then possible risks may be:
(taken from the ISPL book: Managing risks and planning deliveries (see external links)) Acquisition StrategyThe acquisition strategy within ISPL acts as the design of a risk management strategy. The risk management strategy provides choices for options that reduce the probability and/or effect of risks. ISPL provides several options, divided over four classes:
Options are chosen based on their efficiency, costs and the related delay for delivery. The following is very much a summary of ISPL, which is much more extensive in its explanations. For these, see the external links. Options for customer situationThree main options:
If possible, the organization may decide to change its situation, to delete possible risks related to the current situation
The requirement may have been too complex or too simple, or otherwise ineffective for the situation of the acquisition.
The customer organization may adopt certain standards to, for example, ensure openness within the organization and towards external parties, maximizing interoperability between services/systems, etc. Options for supplier relationsFive main options:
The choice depends, among others, the knowledge about the service, costs and time-efficiency of delivery, the actors needed and possible benefits of contracting.
Particular types of tendering may be chosen related to the required type of relationship with a supplier. Types of tendering are:
For more elaborate explanations of these types of tendering, see the external links.
Within complex and/or uncertain situations regarding the service domain, certain choices in the communications with a supplier may be made. E.g.: Decide to require information from a suppliers about its services before a ‘request for proposal’ is made.
When the situation for the service domain is complex or uncertain, certain contractual elements may be made less (or more) flexible to accommodate a healthy relationship with the supplier.
A decision may be made to split the acquisition into multiple contracts to make the situation for the customer organization more certain (although a bit more complex). Options for projectsTwo main options:
Decide to buy when for example: sufficient products are available, complexity of requirements are not high and/or the ability of actors is low. E.g.: buy an ERP product software like SAP.
The project delivery strategy concerns four approaches: installation, construction, description and project control. During the acquisition, at least the installation strategy can be set, the construction approach may also be set. The approaches for construction and installation that ISPL identifies are:
E.g.: Develop a program in one try and no successive installation are needed.
E.g.: An ERP package is bought for which the most basis module is first installed, after which successive functional modules are (bought and) installed when they are needed. This approach is somewhat related to the 'phased' approach for the adoption of software.
E.g.: A program is fully developed and installed. Then a second version of it is fully constructed (or the first version completely revised) and installed. This approach is somewhat related to the 'phased' approach for the adoption of software. Options for ongoing servicesTwo main options:
Choices are made concerning the services in relation to the supplier. E.g.: Agreement with supplier to share a service with other organization (helpdesk from supplier), the ownership of application server can be determined to lie with the supplier giving the responsibility for the machine with them.
Choices are made in what degree the customer organization want to have control over the delivery of ongoing services. E.g.: The required hours of availability of the helpdesk service are determined and set within a service level agreement over which the customer organization can take control. Decision points planningBased upon all the previous activities, the decision points planning is made. This is a time-set planning of decision points. Decision point
A decision point is a set point in time where the customer, with or without the supplier, makes a decision about the services and the deliverables bound to the services. A decision point is described by:
An example of a decision points planning can be found through the thumbnail on the right. In this planning the decisions points are planned through time (top to bottom, left to right). This planning was taken from a study to make ISPL more specific for product software implementations. The decision points planning is thus aimed at a part of the process of a software implementation. A shortened example of a decision point description can be found in the image below. This description was taken from the same study to make ISPL more specific for product software implementations. Acquisition organizationThe acquisition organization is set, which is similar to a project organization. Although the acquisition organization is more focused on the (legal) relationship that it has to maintain with the supplier organization.
Person with the authority to resolve issues with(in) a contract
Person with the authority to resolve issues with a (delivered) service
Person or group that, based on their expertise and abilities, can aid the authorities within the acquisition to form and founded opinion on legal matters.
Person or group that, based on their expertise and abilities, can aid the authorities within the acquisition to form a founded opinion on financial matters.
Person or group that, based on their expertise and abilities, can aid the authorities within the acquisition to form a founded opinion on technological matters. References1. ^The image was made by the author of this article for the method engineering course of Utrecht University. {{Refimprove|date=July 2009}}Further reading
External links
1 : Business terms |
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。