WO2004029767A2

WO2004029767A2 - Representing resources needed to provide a complex portfolio of offerings

Info

Publication number: WO2004029767A2
Application number: PCT/US2003/030366
Authority: WO
Inventors: Nigel P. Cresswell; James P. Kislanko; Garrett J. Supina; Charles D. Green; Holly S. Tullis; Alan Ray Young
Original assignee: Electronic Data Systems Corporation
Priority date: 2002-09-26
Filing date: 2003-09-25
Publication date: 2004-04-08
Also published as: WO2004029767A3; AU2003278960A8; AU2003278960A1

Abstract

An enterprise may offer a complex collection of product and service offerings for sale. The structure of resources (e.g., people, processes, and technology) by which the product and service offerings are delivered also may be complex. The complexity of offerings and resources used to deliver the offerings may make it difficult to understand what resources are used to deliver a particular offering. Techniques are described for representing the structure of resources and offering components by which a complex portfolio of offerings is delivered by an enterprise. The techniques include developing a model representative of the delivery structure from objects, containers, and relationships among objects. Examples of an object include an offering, an offering feature, a function, a delivery solution, and a solution component. A container may organize two or more objects into a group, and a relationship may associated two or more objects.

Description

REPRESENTING RESOURCES NEEDED TO PROVIDE A COMPLEX PORTFOLIO OF OFFERINGS

TECHNICAL FIELD

This description relates to techniques for representing the structure of resources and offering components by which a complex portfolio of offerings is delivered by an enterprise.

BACKGROUND

An enterprise may offer a variety of products and services for sale. The collection of products and services offered by an enterprise may be referred to as a portfolio of offerings. An enterprise may sell or otherwise fulfill a customer request or order by providing the requested products and services using a delivery structure of people, processes, technology, or other delivery resources. An enterprise may use an isolated delivery structure in which resources used to deliver a particular product or service are only used for the delivery of that particular product or service. A different set of resources may be used to provide a different service offering. In contrast, an enterprise may deliver product and services using an integrated delivery structure in which resources are shared among products and services. For example, an enterprise may offer for sale several types of personal computers and several types of mid-range computers.

The enterprise may offer a support service, such as a call center (which also may be referred to as a help desk), for both personal computers and mid- range computers purchased from the enterprise. An enterprise that uses an isolated delivery structure may have a call center to provide support to purchasers of personal computers and a different call center to provide support to purchasers of mid-range computers. An enterprise that uses an integrated delivery structure may have a single call center that provides support to purchasers of personal computers and purchasers of mid-range computers.

An integrated delivery structure in which resources are shared to deliver products and services offered by an enterprise may provide an advantage over an isolated delivery structure that dedicates enterprise resources to a particular product or service. For example, an integrated delivery structure may reduce the duplication of resources used by the enterprise and may be more efficient than an isolated delivery structure. An integrated delivery structure may be preferred by a customer of the enterprise, particularly when a customer purchases a variety of products or services from the enterprise. The ability of an enterprise to use an integrated delivery structure may provide a competitive advantage for an enterprise. An integrated delivery structure may be particularly useful to an enterprise that provides a complex portfolio of service offerings.

When an integrated delivery structure of shared resources is used to provide a complex portfolio of offerings, the complexity of the offerings and resources may make it difficult to understand the portfolio of offerings and what resources are used to deliver a particular offering. For example, many resources may be shared between many different service offerings. The number of resources and the number of service offerings involved may increase the complexity of the delivery structure needed to deliver a complex portfolio of offerings. The service offerings involved also may increase in complexity. For example, a service offering may be the establishment and management of a computer center. That service offering may include designing the computer center; purchasing, configuring, and installing the needed equipment; and operating the computer center. The resources involved in the delivery structure also may increase in complexity. For example, delivery of a complex portfolio of offerings may require a wide variety of different skills in personnel, a large number of complex processes, and many particular types of technology needed.

SUMMARY

In one general aspect, representing resources needed to provide a portfolio of offerings includes representing in a computer one or more resources used to provide one or more offerings to one or more customers. The offering components used to describe the offerings are represented in the computer. The computer also represents at least one relationship between two or more represented resources and offering components, and at least one container that associates two or more represented resources or offering components. The represented resources, offering components, relationship, and container are used to produce a model illustrating how a portfolio of offerings may be delivered. Implementations may include one or more of the following features. For example, the model may be used to determine whether one or more particular resources are overtaxed or underutilized, whether one or more new offerings may be provided using one or more of the represented resources, or whether a particular quantity of additional offerings may be provided using the represented resources. The model also may be used to determine the cost of providing a particular offering or the impact on a particular offering of a change in one or more particular resources. The change may include a technology change.

In one implementation, the offering components may be an offering object type, an offering object instance, an offering feature object type, an offering feature object instance, a function-in-context element object type, or a function-in- context element object instance. The resources may be a delivery solution object type, a delivery solution object instance, a solution component object type, or a solution component object instance. The relationship represented in the computer may be an is-a-component-of relationship, an includes relationship, a uses relationship, an is-used-by relationship, a supports relationship, an is-supported-by relationship, a classifies relationship, and an is-classified-by relationship.

The ability to represent the delivery structure of resources and offering components needed to provide a complex portfolio of offerings may be useful. For example, capacity planning for an enterprise may be performed to determine whether the enterprise has the required types and amount of resources needed to deliver a particular quantity of offerings. The potential impact of a technology change or a supplier change may be identified. The cost associated with delivering a particular service may be determined. The ability of an enterprise to deliver a new service offering may be assessed.

Implementations of the techniques discussed above may include a method or process, or computer software on a computer-accessible medium.

The details of one or more of the implementations are set forth in the accompanying drawings and description below. Other features will be apparent from the description and drawings, and from the claims. DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary computer system capable of implementing a process for representing the delivery structure for a complex portfolio of offerings. FIGS. 2 and 4 are flow charts of a process for representing the delivery structure of a complex portfolio of offerings.

FIG. 3 is a block diagram of a structure of object types, relationships, and containers used for representing the delivery structure of a complex portfolio of offerings. FIG. 5 is a block diagram of a representation of a delivery structure by which a complex portfolio of offerings is delivered by an enterprise.

FIG. 6 is a block diagram of the components of a software architecture for representing the delivery structure for a complex portfolio of offerings.

FIG. 7 is a block diagram of an exemplary delivery structure for a complex portfolio of service offerings.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Techniques are described for representing the structure of resources and offering components by which a complex portfolio of offerings is delivered by an enterprise. The techniques include developing a model representative of the delivery structure from objects, containers and relationships. Examples of an object include an offering, an offering feature, a function, a delivery solution, and a solution component. A container may organize two or more objects into a group, and a relationship may associate two or more objects. Referring to FIG. 1, a programmable system 100 for representing the delivery structure for a complex portfolio of offerings includes a variety of input/output (I/O) devices (e.g., mouse 103, keyboard 105, and display 107) and a computer 110 having a central processor unit (CPU) 120, an I/O unit 130, a memory 140, and a data storage device 150. Data storage device 150 may store machine-executable instructions, data, and various programs such as an operating system 152 and one or more application programs 154 for implementing a process for representing the delivery structures for a complex portfolio of offerings, all of which may be processed by CPU 120. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language. Data storage device 150 may be any form of non- volatile memory, including by way of example semiconductor memory devices, such as Erasable Programmable Read-Only Memory (EPROM),

Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and Compact Disc Read-Only Memory (CD-ROM).

System 100 may include one or more peripheral online storage devices 156 for storing delivery structure data. Peripheral online storage device 156 may use any storage media (including magnetic, optical or solid state storage media) or any type of storage device (including a drive, a microdrive, a compact disc (CD), a recordable CD (CD-R), a rewriteable CD (CD-RW), a flash memory, or a solid- state floppy disk card (SSFDC)). System 100 also may include a communications card or device 160 (e.g., a modem and/or a network adapter) for exchanging data with a network 170 using a communications link 175 (e.g., a telephone line, a wireless network link, a wired network link, or a cable network). Other examples of system 100 may include a handheld device, a workstation, a server, a device, a component, other equipment, or some combination of these capable of responding to and executing instructions in a defined manner. Any of the foregoing may be supplemented by, or incorporated in, ASICs (application-specific integrated circuits). In some implementations, system 100 may function as a server and provide access through network 170 to processes and data for representing a delivery structure for a complex portfolio of offerings.

System 100 may be referred to as a delivery structure analysis workbench. FIG. 2 depicts a process 200 for identifying objects, relationships, and containers that may be used to represent the delivery structure for a complex portfolio of offerings. As the delivery structure is better understood, additional information about the objects, relationships, and containers may become available. This information may be used to represent additional features of the delivery structure. The process 200 may be repeated as more information becomes available. The process 200 may be performed by a person working alone or as part of a group. The person or group may be referred to as a delivery structure architect, a delivery structure analyst, or a business process analyst (collectively, "analyst"). The analyst may gather information related to the delivery structure for a complex portfolio of offerings. The information may be gathered from documentation, such as web sites, advertising materials, procedure manuals, or policy materials. The information also may be gathered from individual interviews, business process design sessions, or other types of work group sessions. The analyst may use a delivery structure analysis workbench that may be similar to system 100 of FIG. 1 to perform process 200, or may use another computer-implemented process to do so. For example, the process 200 may include using Metis, an architectural modeling product available from Computas AS of Lysaker, Norway, or Rational Rose®, a visual modeling product available from Rational Software. The process 200 begins with adding an object instance to the representation of the delivery structure for a complex portfolio of offerings (step 210). An object instance may represent a particular offering, a component of a particular offering, a particular resource, or a component of a particular resource used in the delivery structure. An object instance may be added, for example, by selecting a particular object type. An object type may correspond to one of several types of offerings or one or several types of resources.

For example, a type of offering may be a service offering or a technology product offering. An object instance that corresponds to a service offering may be the management of a computer center. An object instance that corresponds to a technology product may be a particular computer application system, such as a computer-aided design system, a product lifecycle management system, or a financial management system.

Types of resources may include people, processes and technology. A resource may be the type of personnel needed, such as a computer system architect, a computer programmer, or a call center manager. A resource also may be the procedures or processes used. In some cases, a process used may be generally described, such as a software development process that generally defines the major products produced (e.g., requirements document, specification document, source code, and user materials). In other cases, a process used may be specifically described giving step by step instructions to the operator on what to do. A resource also may be an integration of technology, such as a combination of hardware and software, that may be used by the personnel to deliver the offerings. In some cases, the resource may be a combination of people, procedures and technology. For instance, a particular engineering solution may be described that specifies the configuration of particular computing equipment required, software that runs on the computing equipment, and detailed operating procedures. A particular engineering solution may be, for example, the systems and processes used for operating a call center.

The analyst then determines whether more object instances are to be added to the delivery structure representation (step 220). If so, the analyst proceeds to add an object instance (step 210) as described previously.

When the analyst determines that no more object instances are to be added, the analyst may define a relationship between two object instances in the delivery structure representation (step 230). For example, the analyst may select two object instances from a list of object instances that have been added in step 210 and indicate that the selected objects are related, such as by drawing a line between the selected objects. In some implementations, the analyst may select one or more object instances from a list of object instances that correspond to a particular object type. The analyst may describe the relationship that exists between the object instances. The relationship may be described using a verb or a verb phrase. An example of a relationship may be when an object instance "is a component of another object instance. Similarly, a relationship may occur between an object instance that "includes" another object instance. Typically, when a first object instance "is a component of a second object instance, the second object instance "includes" the first object instance. Either or both of the relationships may be described in step 230. Describing both of the relationships may be beneficial. For example, when both of the relationships between two object instances are described, the relationship between the two object instances in the delivery structure representation may be traversed from either direction (e.g., from a first object instance to a second object instance or from a second object instance to a first object instance). Examples of other types of relationships include "uses," "is used by," "supports," "is supported by," "classifies," and "is classified by." In some implementations, the types of relationships may be stored in a relationship library from which the analyst selects.

The analyst then determines whether more relationships between object instances are to be added to the delivery structure representation (step 240). If so, the analyst proceeds to define a relationship (step 230) as described previously. When the analyst determines that no more relationships are to be added, the analyst may add a container that groups two or more object instances in the delivery structure representation (step 250). A container is a way to organize object instances by grouping two or more object instances that are related in some way. For instance, a container may be used to group object instances that share a purpose. A container also may be used to group object instances that correspond to the different object types. A container also may be used to visually group object instances that have a common classification. For example, object instances that represent types of procedures may be in one container, and object instances that represent types of application or computer systems may be in another container.

To add a container, the analyst may identify two or more object instances to be grouped and indicate that a container is to be added for the identified object instance. For example, the analyst may select two or more object instances from a list of object instances that have been added in step 210 and indicate that the selected objects are related, such as by drawing a box around the selected objects. In some implementations, a container that groups two or more containers may be added. A container contained within another container may be referred to as a sub-container. The analyst then determines whether more containers are to be added to the delivery structure representation (step 260). If so, the analyst proceeds to add a container (step 250) as described previously.

When the analyst determines that no more containers are to be added, the analyst may review the delivery structure representation (step 270). For example, the delivery structure representation, or a portion thereof, may be displayed or printed for review by the analyst. The analyst may determine that one or more elements (e.g., an object instance, a relationship, or a container) of the delivery structure representation are to be adjusted (step 280). If so, the analyst may make appropriate adjustments, such as by adding an object instance as in step 210, defining a relationship as in step 230, and adding a container as in step 250. The analyst may make other types of adjustments, such as deleting an object instance, a relationship, or a container.

For example, an analyst may determine that a different structure of containers and/or sub-containers may help present and provide an understanding of the delivery structure. The analyst may add one or more containers and redistribute one or more object instances to the one or more new containers. In some implementations, the steps performed in process 200 may be performed in a different order. For example, an analyst may begin by identifying containers to be used to group object instances. An analyst then may identify object instances for each container and the relationships between object instances. An analyst also may identify relationships between containers.

When the analyst is satisfied with the representation of the delivery structure, a representation of the delivery structure may be produced (step 290). For example, a printed version of the delivery structure may be produced.

FIG. 3 shows a model representative of a structure 300 of object types, relationships, and containers that may be used to represent a delivery structure of resources and offering components for a complex portfolio of offerings. The structure 300 includes an offering object type 310, an offering feature object type 320, a function-in-context element object type 330, a capability container 340, a delivery solution object type 350, and a solution component object type 360. One or more object instances may be identified, such as by using process 200, for one or more object types in structure 300. In general, offering object type 310, offering feature object type 320, and function-in-context element object type 330 relate to offerings. Delivery solution object type 350 and solution component object type 360 relate to resources used to deliver one or more offerings.

An instance of an offering object type 310 represents a service, a product, or a combination of a service and a product that is offered for sale to external customers by an enterprise. The offering may be identified by a trade name or another branding technique. For example, a service offering may be the management of a computer center. Another offering may be providing business process redesign services. In some implementations, a service offering may correspond to a particular named set of offerings that a client may select from the enterprise's portfolio of offerings. A service offering may be identified in marketing materials.

In some implementations, an instance of a service offering represented also may describe the attributes of the service offering, such as customer pricing, cost to provide the offering, marketing materials, or other documentation that describes the offering.

An offering object type 310 may be related to one or more offering feature object types 320. When an offering feature applies to a service, the offering feature may be referred to as a service feature. Examples of instances of an offering feature object type 320 that apply to the management of a computer center include providing a call center to provide support to users of the computer center, providing computers and associated equipment, providing a collection of software for the computer center, and managing the computer center. An example of an instance of an offering feature object type 320 that applies to a business process redesign offering is providing a consultancy report. An offering feature object type 320 may relate to one or more service offering object types 310.

In some implementations, a service feature may correspond to a particular line item in a description of a particular offering that is provided to a customer. A service feature may be more general than a service offering, which may represent a collection of service features that are marketed to customers. A service feature, for example, may be physical (such as call-in center support) or a document (such as a report on security for a particular customer). A service feature may be recognized by a customer as something that is desirable and from which the customer may benefit. An offering feature object type 320 may include one or more functions-in-context element object types 330. An instance of a function-in- context element object type 330 represents an activity that may be required to deliver an instance of an offering feature object type 320 in a particular circumstance or context. A function-in-context element may be defined to identify, for example, the type of people, the processes, and the technology needed.

An example of an instance of a function-in-context element object type 330 for providing computers and associated equipment for management of a computer center offering includes identifying the size and configuration of the computers needed, purchasing the computers, and installing the computers. In some implementations, a finer level of granularity may be needed. For example, a computer center may use both personal-computer-based servers and Unix- operating-system-based servers. The expertise and technology tools needed to size and configure a personal-computer-based server may be different from the expertise and technology tools needed to size and configure a Unix-operating- system-based server. In such a case, an instance of a function-in-context element may be sizing and configuring a personal-computer-based server and another instance of a functions-in-context element may be sizing and configuring a Unix- operating-system-based server. Examples of instances of a function-in-context element object type 330 for providing a consultancy report include gathering information, analyzing the gathered information, and writing the consultancy report. An instance of a function-in-context element object type 330 may apply to one or more instances of an offering feature object type 320. In some implementations, a function-in-context element may be an identifiable element of delivery and may represent the lowest level of offering in a represented delivery structure. The function-in-context element may represent what the enterprise does when a service feature is delivered. The "in-contexf aspect of a function-in-context element may permit the description that different types of delivery may occur under different circumstances. The ability to provide capability planning services may vary based on the type of capability (e.g., type of computer systems) needed.

A function-in-context element may identify the technology used to deliver or support delivery, may identify the organization unit responsible for delivery, or may identify the type of skills needed for delivery. A function-in-context element may be recognizable by the people who perform the activity. A function-in- context element may have a single metric to measure the performance of the function-in-context element (e.g., the number of files restored to a computer system, the number of calls received, or the hours of availability of a computer center). A function-in-context element also may be associated with an estimate of the staff hours and cost to deliver the function-in-context element.

The structure for a complex service portfolio may include a large number of function-in-context elements. For example, a large enterprise may offer 50 services that include 800 service features and 1500 function-in-context elements. In such a case, the ability to organize function-in-context elements into groups of function-in-context elements may be particularly beneficial A container may be used to group instances of function-in-context elements into an instance of a capability container 340. A capability may represent the type of skills needed, the processes used, and/or the technology required for a service offering in a particular context. A capability may bring together function-in-context elements that have a common basis, such as a type of technology or a type of activity. For example, a capability of an enterprise may be a "Unix capability" to provide services and other delivery elements relating to a computer based on the Unix operating system. An additional object type or the container 340 may be used to represent the capability with relationships to the function-in-context object instances the capability groups.

An instance of a delivery solution object type 350 may be identified for one or more function-in-context element object types 330. An instance of a delivery solution object type 350 represents how to deliver an instance of a function-in-context element object type 330. For example, in some implementations, a predetermined, usually reusable solution that the enterprise has produced to ensure it can deliver one or more function-in-context elements effectively may be represented. Optimally, an instance of a delivery solution obj ect type 350 represents ho to deliver a particular set of instances of function- in-context elements in an efficient manner such that the same result quality may be obtained each time the delivery solution is provided.

In some implementations, a delivery solution may represent a leveraged structure within an enterprise that may enable consistent and repeatable delivery. A delivery solution may act as a way of grouping (or wrapping) the detail components of a solution.

An instance of a delivery solution object type 350 may include one or more instances of a solution component object type 360. The instances of a solution component object that apply to a particular delivery solution object type 350 represent the components that are used to produce a delivery solution.

Different types of components may be used to describe a delivery structure. For example, a component type may be a procedure and the roles that execute the steps in a procedure. Another component may be a configuration for a particular type of computer equipment or software. Another component may be an external provider that is used to deliver a particular solution. A component type may be an architecture or other general description that may be used to deliver a particular delivery solution.

In some implementations, a solution component may identify a part of a delivery solution. A solution component, for example, may represent a procedure to be followed, an identification of an external supplier that delivers on behalf of the enterprise, or an integration of technology designed to support the procedures.

Each instance of an object type in structure 300 may relate to more than one object instance. That is, each relationship between two object instances in structure 300 may be a many-to-many relationship. Some implementations may restrict the degree to which object instances may be related to other object instances in the delivery structure representation.

In some implementations, the delivery structure, such as structure 300, may have a defined set of relationships between object types. For example, a service offering may include an offering feature, and an offering feature may be a component of an offering. An offering feature may use a function-in-context element, and a function-in-context element may be used by an offering feature. A function-in-context element may be supported by a delivery solution, and a delivery solution may support a function-in-context element. A delivery solution may include a solution component, and a solution component may be a component of a delivery solution.

In some implementations, the relationship between two object types may be a many-to-many relationship. For example, a particular object type may relate to many other object types, and one of the many other object types may relate to the particular object type and other object types.

In some implementations, a container may be defined for each object type represented, such as the object types 310, 320, 330, 350, and 360. A relationship between two containers also may be defined. Advantages may exist when a delivery structure represents a series of object types, a corresponding container is represented for each object type, and the same or similar relationships are defined between two or more object types and the two or more containers that correspond to the object types-.

Referring to FIG. 4, a process 400 may be used to represent the delivery structure of a complex portfolio of offerings. The process 400 includes techniques to describe the offerings and the resources used to deliver the offerings through the use of object instances, relationships between object instances, and containers that group related object instances, such as delivery solutions and solution components, used to deliver service offerings. When the various object instances in a delivery structure are identified, the object instances and the relationship between object instances may be entered into a delivery service analysis workbench, an architecture modeling tool, a data or object modeling tool, or another data storage system. The information needed during process 400 may be obtained, for example, from documentation available in the enterprise (such as procedure manuals, project plans, contracts for delivery of products or services, marketing literature, or financial reports), through analysis of publicly-available information (e.g., a public website for the enterprise or advertising materials), and through interviews with enterprise personnel.

The process 400 begins with determining service offerings included in an offering portfolio of an enterprise (step 410). The service offerings may be identified by reviewing advertising material or service descriptions provided by the enterprise to a customer or a potential customer. Typically, each service offering is created as an instance of a service offering object type, such as service offering object type 310 of FIG. 3. A particular service offering is selected (step 415) and the service features for the selected service offering are determined (step 420). The service features associated with one or more service offerings may be determined from advertising material or service descriptions provided by the enterprise to a customer or a potential customer. When more than one service offering is explored, a review of the resulting service feature object instances may be used to remove duplicates, which may occur when the same feature is included in two or more offerings. The service features may be associated with a particular service offering by answering the question, "What does the customer receive when a customer orders the particular service offering?" The service features and the relationship of each service feature to the service offering may be identified at the same time.

When the delivery structure representation represents an existing delivery structure in an enterprise, the function-in-context instances may be generated by reviewing the delivery structure used by the enterprise, which may may identify what the enterprise does at a detail level. A list or catalog of function-in-context elements may be generated. Guidelines on the verbs to use and the level of detail to elicit may provide improved results.

A particular service feature may be selected (step 425) and one or more function-in-context elements for the service feature may be determined (step 430). The function-in-context element may be identified serially for each service feature identified by interviews with individuals that represent the organization responsible for delivering the service feature. Guidelines on the verbs to use and the level of detail to elicit may provide improved results. For example, to relate the function-in-context element instances to service feature instances, the analyst may ask, "When the service feature is delivered, what does the enterprise do?" The use of function-in-context elements that have previously been identified should be considered and new instances only added when no suitable match is found. The results identify the relationships, but may also improve function-in- context elements definitions. When the delivery structure representation does not represents an existing delivery structure in an enterprise, function-in-context element instances may be identified that represent the activities that are anticipated to be needed to deliver an instance of an offering feature object type (e.g., function-in-context element instances are identified to represent the anticipated offering scope). A particular function-in-context element may be selected (step 435), and one or more delivery solutions for the selected function-in-context element may be determined (step 440). In some implementations, for example, the repeatability of a particular delivery solution may be improved when an enterprise creates one or more delivery solutions that may be deployed in more than one facility in the enterprise. The delivery solutions may be identified by a name (e.g., "The Call Center System"). When an analyst interviews individuals in the aspect of the enterprise responsible for developing the delivery solution, a particular delivery solution may be identified and may be represent as a delivery solution instance.

A particular delivery solution may be selected (step 445), and one or more solution components for the selected delivery solution may be determined (step 450). In some cases, a delivery solution and associated solution components may be identified readily. When a delivery solution or solution components are not readily identifiable, the analyst may ask, "How is the enterprise able to provide what has been promised to a customer?" In some cases, a process improvement analysis or other type of documentation may be available to identify delivery solutions and associated solution components.

A container may be added (step 455), and the one or more object instances for the container may be selected (step 460). The object instances that are grouped by the container may include two or more service offerings, two or more service features, two or more function-in-context elements, two or more delivery solutions, or two or more solution components. The object instances that are grouped by the container also may be a combination of service offerings, service features, function-in-context elements, delivery solutions, or solution components. If the delivery structure information is not complete (step 465), additional information about delivery structures and offerings may be gathered or information that has been gathered may be modified (step 470). For example, additional objects, relationships between objects, or containers may be identified (steps 410-460). In some implementations, when delivery solution instances and solution component instances have been identified, the analyst may interview individuals in the organization responsible for providing solutions to help identify relationships between delivery solution instances and function-in-context instances.

If the delivery structure information is complete (step 465), the representation of the delivery structure may be produced (step 475). The delivery structure represented may depict the object instances, the relationships between object instances, and the containers in the offering portfolio. The delivery structure produced may depict all or a portion of the delivery structure represented. The process 400 is repeated as more information about the delivery structure of the enterprise is determined. The process 400 also may be repeated when the service offerings of an enterprise are changed (e.g., additional service offerings are added or service offerings are discontinued).

The steps in process 400 may be repeated by an analyst until all aspects of delivering a service offering (or all aspects of delivering more than one service offering) are understood. For example, some analysts may identify all service features for a service offering (e.g., repeatedly performing step 420) before identifying a function-in-context element for a service feature (steps 425 and 430). Other analysts may identify all the function-in-context elements for a selected service feature (e.g., repeatedly performing step 430) before identifying other service features for a selected service offering (steps 415 and 420).

In some implementations, the delivery structure understood may be reviewed to determine how to improve the delivery of one or more service offerings or an aspect of a service offering.

In some implementations, the steps performed in process 400 may be performed in a different order. For example, an analyst may begin by identifying one or more containers to be used to group object instances, such as by repeatedly performing step 455 to add multiple containers. An analyst may identify a service offering container, a service feature container, a function-in-context element container, a delivery solution container, and a delivery solution component container. The analyst then may identify the objects in each container and the relationships between object instances. An analyst also may identify relationships between containers. The analyst also may repeat step 455 to add another container to represent the delivery structure.

FIG. 5 shows a representation of a delivery structure by which a complex portfolio of offerings is delivered by an enterprise. In general, the representation 500 includes various object instances related to and describing aspects of service offerings 505 and 510. Service offerings 505 or 510 may be understood as being composed of service features 512-515. Service features 512-515 may be understood as being delivered by function-in-context elements 520-525. The representation 500 also includes a container 530. Container 530 represents a capability of performing function-in-context elements 520-522.

The representation 500 also includes delivery solution objects and solution component objects. Delivery solution objects and solution component objects are related to resources used for delivering service offering 505 or service offering 510. Delivery solutions 540-543 may be understood as relating to function-in- content elements 521, 523, 524, and 525. Solution components 550-553 may be understood as relating to delivery solutions 540-543. The relationships between the objects included in representation 500 are indicated by relationship lines 560- 583.

More particularly, service offering 505 includes service features 512-514 (as indicated by relationship lines 560, 561 and 562, respectively). Service offering 510 includes service features 514 and 515 (as indicated by relationship lines 563 and 564, respectively). Service feature 514 relates to both service offering 505 and service offering 510 (as indicated by relationship lines 562 and 563, respectively).

Service feature 512 includes function-in-context elements 520 and 524 (as indicated by relationship lines 565 and 566, respectively). Service feature 513 includes function-in-context elements 521, 524, and 525 (as indicated by relationship lines 567, 568, and 569, respectively). Service feature 514 is delivered by function-in-context elements 522 and 525 (as indicated by relationship lines 571 and 570, respectively). Service feature 515 uses function- in-context element 523 (as indicated by relationship line 572). Function-in- context elements 524 and 525 each relate to more than one service feature (as indicated by relationship lines 566, 567, 569 and 570).

Delivery solutions 540, 541, 542, and 543 relate to function-in-context elements 524, 521, 525, and 523, respectively. The relationship between each delivery solution 540, 541, 542, or 543 and function-in-context elements 524, 521, 525 or 523 is indicated by relationship lines 575, 573, 576, and 574, respectively.

Delivery solution 540 includes solution components 550 and 551 (as indicated by relationship lines 577 and 578, respectively). Delivery solution 541 includes solution components 551 and 552 (as indicated by relationship lines 579 and 580, respectively). Delivery solution 542 indicates solution components 551 and 552 (as indicated by relationship lines 581 and 582, respectively). Delivery solution 543 includes solution component 553 (as indicated by relationship line 583).

For brevity, only a few illustrative elements are included in representation 500. A complex portfolio of service offerings may include many additional objects, containers, and relationships. For example, only some of the relationships between the objects shown in representation 500 are illustrated.

FIG. 6 depicts the components of a software architecture for representing the delivery structure for a complex portfolio of offerings. The software may operate on a computing device, such as system 100 of FIG. 1. The software architecture has a processing component 610 and a data component 620. The processing component 610 includes a user interface generator 630 and a delivery structure processor 640. The data component 620 includes object information 650, relationship information 660, and container information 670. Object information 650 may include object types and object instances for the objects used to represent a delivery structure. Examples of object types for which object information 650 is stored include offering object type 310, offering feature object type 320, function- in-context element object type 330, delivery solution object type 350, and solution component object type 360 as described previously with respect to FIG. 3. Object instances may be stored in object information 650, may correspond to one or more object types in FIG. 3, or may correspond to other object types. Relationship information 660 may include which object instances in object information 650 are related to other object instances. Relationship information 660 also may include a description of the relationship, such as the types of relationships described with respect to FIG. 2. Container information 670 includes information describing a container that organizes a group of object instances. For example, the capability container 340 of FIG. 3 organizes a group of function-in-context element instances 330 of FIG. 3.

A user interface may be generated by the user interface generator 630. The user interface may permit a user to interact using a process, such as the process 200 of FIG. 2, for representing the delivery structure for a complex portfolio of offerings.

The delivery structure processor 640 retrieves information from the data components 650, 660 and 670, sends the information to the user interface generator 630 for presentation to the user, and stores in data components 650, 660 or 670 information received from the user through the generated user interface. In some implementations, the delivery structure processor 640 may perform other functions, such as the transformation of data received from the user and the generation of reports that organize the information stored in data components 650, 660, or 670.

FIG. 7 shows an exemplary delivery structure 700 for a complex portfolio of service offerings. The delivery structure 700 is represented using objects, relationships, and containers and extends structure 300 of FIG. 3. For brevity, only a few illustrative elements are included in delivery structure 700.

The delivery structure 700 includes service offerings 705, service features 710, function-in-context elements 715, a capability 720, delivery solutions 725, and solution components 730. Service offerings 705 includes a service line 733, offerings 734 and 735, and packages 736 and 737. The service line 733 represents a collection of service offerings included in a portfolio. Here, service line 733 includes the particular offerings 734 and 735. Offering 734 includes packages 736 and 737. Each package 736 or 737 represents a level of features or quality of service offered for offering 734. For example, an offering that represents the management of a computer center may include two packages of service. One package may represent basic features for computer center management. Another package may represent a computer center with more services, such as a higher expected level of computer availability, additional hours of available support, and additional management services. Here, packages 736 and 737 both include features 743 and 744. Feature 745 is only included in package 737.

Function-in-context elements 715 include functions 753-755. Functions 753 and 754 are related to capability 720. Here, each function 753, 754 or 755 relates to a particular feature 743, 744 or 745 and a particular delivery solution 763, 764 or 765.

Solution components 730 include a reference architecture 773, roles 774 and 775, an engineering solution 776, a procedure 777, and an external provider 778. The reference architecture 773 is an approach that provides general guidance on performing a service offering or a component of a service offering. For example, a reference architecture may describe how to develop software by identifying a set of tasks. Role 774 or 775 identifies the type of people (e.g., a software designer, a system architect, or a call center manager) that may be involved in a delivery solution. In some cases, a role may be associated with a skill, and a skill may be associated with a particular technology. For example, a software designer may need to have design skills on a Unix-based computer. A role may be associated with a logical process that represents an approach to accomplishing a particular type of work. For example, a role may use a logical process for general problem solving. The logical process may include identifying the problem, analyzing the problem, generating a solution to the problem, and applying the solution to the problem.

Engineering solution 776 is a set of solution components that address a particular delivery solution. An engineering solution may include both a computing device component, a software component, and detailed procedures for using the computing device and the software. For example, a turn-key solution of a providing computer center may be an engineering solution. In some cases an engineering solution may be composed of product assembly steps that relate to particular technology products. Procedure 777 is a document that guides one or more roles in performing a function. Procedures may vary in detail with some procedures providing only general guidance. Other procedures may provide specific documentation of how to accomplish a function or perform a task.

External provider 778 is an external organization that provides delivery solution 765. For example, an external provider may provide telecoimiiunications equipment, services and support to a call center offering or a computer center offering. In some cases, an external provider may provide only a portion of a delivery solution. For example, when an computer center offering includes computer maintenance as a service feature, the delivery of computer maintenance by the enterprise may be provided using an external provider and the remainder of the delivery requirements related to the computer center offering may be provided using the enterprise's own resources.

Implementations may include a method or process, an apparatus or system, or computer software on a computer medium. It will be understood that various modifications may be made. For example, advantageous results still could be achieved if steps of the disclosed techniques were performed in a different order and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components.

Other implementations are within the scope of the following claims

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method for representing resources needed to provide a portfolio of offerings, the method comprising: representing in a computer one or more resources used to provide one or more offerings to one or more customers; representing in the computer one or more offering components used to describe the one or more offerings; representing in the computer at least one relationship between two or more represented resources and offering components; representing in the computer at least one container that associates two or more represented resources or offering components; and using the represented resources, offering components, relationship, and container, producing a model illustrating how a portfolio of offerings may be delivered.

2. The method of claim 1 further comprising using the model to determine whether one or more particular resources are overtaxed.

3. The method of claim 1 further comprising using the model to determine whether one or more particular resources are underutilized.

4. The method of claim 1 further comprising using the model to determine whether one or more new offerings may be provided using one or more of the represented resources.

5. The method of claim 1 further comprising using the model to determine whether a particular quantity of additional offerings may be provided using the represented resources.

6. The method of claim 1 further comprising using the model to determine the impact on a particular offering of a change in one or more particular resources.

7. The method of claim 1 further comprising using the model to determine the cost of providing a particular offering.

8. The method of claim 1 wherein the one or more offering components may be one or more of an offering object type, an offering object instance, an offering feature object type, an offering feature object instance, a function-in-context element object type, or a function-in-context element object instance.

9. The method of claim 1 wherein the one or more resources may be one or more of a delivery solution object type, a delivery solution object instance, a solution component object type, or a solution component object instance.

10. The method of claim 1 wherein representing in the computer at least one relationship comprises representing in the computer at least one of the one or more of an is-a-component-of relationship, an includes relationship, a uses relationship, an is-used-by relationship, a supports relationship, an is-supported-by relationship, a classifies relationship, and an is-classified-by relationship.

11. A system for representing resources needed to provide a portfolio of offerings, the system comprising a processor connected to a storage device and one or more input/output devices, wherein the processor is configured to: represent in a computer one or more resources used to provide one or more offerings to one or more customers; represent in the computer one or more offering components used to describe the one or more offerings; represent in the computer at least one relationship between two or more represented resources and offering components; represent in the computer at least one container that associates two or more represented resources or offering components; and use the represented resources, offering components, relationship, and container to produce a model illustrating how a portfolio of offerings may be delivered.

12. The system of claim 11 wherein the processor is further configured to use the model to determine whether one or more particular resources are overtaxed.

13. The system of claim 11 wherein the processor is further configured to use the model to determine whether one or more particular resources are underutilized.

14. The system of claim 11 wherein the processor is further configured to use the model to determine whether one or more new offerings may be provided using one or more of the represented resources.

15. The system of claim 11 wherein the processor is further configured to use the model to determine whether a particular quantity of additional offerings may be provided using the represented resources.

16. The system of claim 11 wherein the processor is further configured to use the model to determine the impact on a particular offering of a change in one or more particular resources.

17. The system of claim 11 wherein the processor is further configured to use the model to determine the cost of providing a particular offering.

18. The system of claim 11 wherein the one or more offering components may be one or more of an offering object type, an offering object instance, an offering feature object type, an offering feature object instance, a function-in-context element object type, or a function-in-context element object instance.

19. The system of claim 11 wherein the one or more resources may be one or more of a delivery solution object type, a delivery solution object instance, a solution component object type, or a solution component object instance.

20. The system of claim 11 wherein the processor configured to represent in the computer at least one relationship comprises a processor configured to represent in the computer at least one of the one or more of an is-a-component-of relationship, an includes relationship, a uses relationship, an is-used-by relationship, a supports relationship, an is-supported-by relationship, a classifies relationship, and an is- classified-by relationship.

21. A computer-readable medium or propagated signal having embodied thereon a computer program configured to represent resources needed to provide a portfolio of offerings, the medium or signal comprising one or more code segments configured to: represent in a computer one or more resources used to provide one or more offerings to one or more customers; represent in the computer one or more offering components used to describe the one or more offerings; represent in the computer at least one relationship between two or more represented resources and offering components; represent in the computer at least one container that associates two or more represented resources or offering components; and use the represented resources, offering components, relationship, and container to produce a model illustrating how a portfolio of offerings may be delivered.

22. The medium or signal of claim 21 further comprising one or more code segments configured to use the model to determine whether one or more particular resources are overtaxed.

23. The medium or signal of claim 21 further comprising one or more code segments configured to use the model to determine whether one or more particular resources are underutilized.

24. The medium or signal of claim 21 further comprising one or more code segments configured to use the model to determine whether one or more new offerings may be provided using one or more of the represented resources.

25. The medium or signal of claim 21 further comprising one or more code segments configured to use the model to determine whether a particular quantity of additional offerings may be provided using the represented resources.

26. The medium or signal of claim 21 further comprising one or more code segments configured to use the model to determine the impact on a particular offering of a change in one or more particular resources.

27. The medium or signal of claim 21 further comprising one or more code segments configured to use the model to determine the cost of providing a particular offering.

28. The medium or signal of claim 21 wherein the one or more offering components may be one or more of an offering object type, an offering object instance, an offering feature object type, an offering feature object instance, a function-in-context element object type, or a function-in-context element object instance.

29. The medium or signal of claim 21 wherein the one or more resources may be one or more of a delivery solution object type, a delivery solution object instance, a solution component object type, or a solution component object instance.

30. The medium or signal of claim 21 wherein the one or more code segments configured to represent in the computer at least one relationship comprises one or more code segments configured to represent in the computer at least one of the one or more of an is-a-component-of relationship, an includes relationship, a uses relationship, an is-used-by relationship, a supports relationship, an is-supported-by relationship, a classifies relationship, and an is-classifϊed-by relationship.