Guidelines for Building an Order to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4

Transcription

1 Guidelines for Building an to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4 An Oracle White Paper June 2009

2 Using AIA for Communications Foundation Pack 2.4. Copyright 2009, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR , Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services. This documentation is in prerelease status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation. The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle. This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Software License and Service Agreement, which has been executed and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

3 Table of Contents Guidelines for Building an to Activate Integrated Business Process Using AIA for Communications Foundation Pack Getting Started... 6 Business Benefits Drive Design Criteria... 7 to Activate Business Process Flows... 8 Understanding the Capture Sub-Flow... 9 Understanding the Deliver Customer Sub-Flow Understanding the Qualify Customer Sub-Flow to Activate Design Considerations to Activate Deployment Topology Design Considerations Product Definition and Mapping Design Considerations Update Design Considerations Revision s Design Considerations Billing Fulfillment Design Considerations Multiple Features Design Considerations Management Integration Design Considerations to Activate Integration Components to Activate Sample Use Cases Use Cases Setup Double Play Promotion First-Time Purchase Double Play Change Double Play Revision Communications s Dictionary Communications s - Header Component Attributes Communications s - Line Component Attributes

4

5 Guidelines for Building an to Activate Integrated Business Process Using AIA for Communications Foundation Pack 2.4 This white paper provides design guidance for building an integrated to Activate business process based on the following components: 1. AIA for Communications Foundation Pack AIA for Communications to Billing Process Integration Pack Any Customer Management system 4. Any Service Management (also know as Provisioning) system We attempted to align this guidance with Oracle s implementation of the to Activate Process Integration Pack (PIP) part of a future release of AIA for Communications. Oracle s solution uses Oracle and Service Management (OSM) for both customer order management and service order management (provisioning). This white paper was authored while Oracle s solution was being developed, therefore, we cannot guarantee 100 percent alignment. This white paper assumes basic knowledge of AIA, Siebel and Management functionality and terminology. 5

6 CRM Service WFM All Shipping InHouse Shipping PartnerInc Guidelines for Building an to Activate Integrated Business Process Getting Started The to Activate business process is at the core of business and operational support systems for any Communications Service Provider (CSP), and it directly affects the provider s bottom line. The process extends from the time a quote or order is created to the time when the services and goods are delivered and properly billed. The to Activate process also has strong ties to product and service life cycle management. A central piece of the to Activate solution is the Lifecycle Management system. Traditionally, CSPs deployed stovepipe BSS and OSS solutions with middleware-based custom order orchestration solutions. Deployment consolidation for cost savings, convergent bundling, and time to market demands are fostering increasingly complex requirements for the orchestration solution. These requirements include sophisticated order mapping, order decomposition, status composition, fallout management, changes to in-flight orders, future-dated orders, and cross order dependencies, among others. All of these requirements cannot be easily achieved through middleware-based custom solutions. Oracle, along with a large group of leading CSPs, concluded that a prominent and distinct role exists for a commercial off-the-shelf (COTS) Lifecycle Management solution. This concept is what this white paper recognizes as the Management solution responsible for the Central Fulfillment functionality. The following chart illustrates a typical to Activate deployment topology. The Management system is at the center of this topology. CRM Capture General Ledger Payment & Collections BRM-WLS (Wholesale) BRM-REZ (Residential) General Ledger Payment & Collections BRM-BIZ (Business) Management (Central Fulfillment) Provisioning VoIP Provisioning UK DSL Provisioning DSL Activation VoIP Activation UK DSL Activation DSL Network Inventory Network Inventory DSL 6

7 The topology shown is typical of most CSPs, although many could include more fulfillment system types and fulfillment system stacks. Management is at the center of the to Activate Deployment with one or more Capture systems passing orders to the Management system. The Management system decomposes the order into sub-orders, each of which targets a particular fulfillment provider (that is, system instance); we call these order components. The topology shown uses three billing providers based on customer segment: Wholesale, Residential, and Business. It uses three provisioning stacks based on service family and geography: VoIP, UK DSL, and DSL. It uses two SCM providers, one for in-house products and another for partner supplier products. Finally, it uses one Work Force Management provider and one separate CRM Service provider (for trouble ticketing). Business Benefits Drive Design Criteria to Activate design should match the sought after business benefits. Oracle s extensive work with customers and prospects revealed the following business drivers. The business drivers are reflected directly in the design criteria adopted by Oracle. Business Benefits / Driver Fast time-to-market Once identified, introduce more of the same commercial offerings within hours. Once identified and the infrastructure is ready, introduce new services within days. Low-cost, agile deployment Superior visibility and experience Lower cost of fallouts and enhanced customer experience Design Criteria Decouple commercial offerings and fulfillment flows. Enable product- and order-driven fulfillment flows. Decouple fulfillment topology and fulfillment flows. Enable a configurable and streamlined order fulfillment status. Control fallout conditions. Manage fallout incidents. These business drivers vary in priority among CSPs as a reflection of deficiencies in current deployments. The design criteria elements listed are described in detail in the to Activate Design Considerations section of this white paper. 7

8 to Activate Business Process Flows Logically and for ease of understanding, the to Activate business process is described in the following subsections: Understanding the Capture Sub-Flow Understanding the Deliver Customer Sub-Flow Understanding the Qualify Customer Sub-flow This white paper focuses on the elements of the to Activate business process flow that are relevant to its integration with Management. It describes: Inbound and outbound integration points with Management for deliver and qualify customer order sub-processes. Functional expectations for product model and product mappings to facilitate order fulfillment. Functional methodology governing the distribution of roles across Siebel, Management, and key fulfillment systems, primarily Billing and Provisioning. Available AIA assets to leverage for building the to Activate business process. 8

9 Understanding the Capture Sub-Flow The following chart illustrates a typical Capture flow. This flow varies by CSP and may vary by service family, customer segment, line of business, and others. Two important integration points between CRM and Management are shown for Qualify Customer and Deliver Customer. In Siebel, the Customer is known as the Sales. In general, orderbased system interactions between different BSS and OSS systems require that order decomposition and orchestration go through the Management layer. For the to Activate flow, at least two system interactions exist: Qualify Customer to validate the availability of a service design and the capacity to fulfill the customer order; and Deliver Customer to fulfill the products and services purchased by the customer. AIA for Comms: to Activate Functional Flow ORDER CAPTURE SUB-FLOW CRM Check / Create Account Run Credit Check Make Product Choices Product Validation Pricing Physical Good ATP Inventory Resource Reservation Technical Service Qualification Schedule Appointment (WFM) Submit Lifecycle Management Legend Application Activity Optional Application Activity AIA Based Integration Points Within Product Flow Qualify Customer Deliver Customer How to read this Capture Sub-Flow chart: This chart shows two swim lanes, one for CRM and another for Management. Each swim lane includes the typical application activities and user interactions part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. See the legend on the chart for other details. A typical flow starts with creating new customers and updating existing customer information. Depending on customer segment or line of business, among other considerations, customer information may be captured earlier, for example when an opportunity or quote is created, and then updated during order capture. Depending on its business policy, some customers may pass through a credit check before starting the process of making product choices. While making product choices and at other points in the process, such as while capturing an order, the CRM system performs several validations. Selected products and product options are priced following relevant pricing logic. When physical goods are involved, the order capture process typically checks availability to purchase. For some services, resource reservation (for example, a phone number) also occurs during order capture. Before an order is submitted and depending on the business practices of the CSP, the order may need to pass a technical service qualification. Some CSPs also require scheduling an engineer (when needed) at the time of order capture to synchronize both the availability of an engineer and a customer. When an order is complete and validated, it is submitted to start the delivery process. 9

10 Understanding the Deliver Customer Sub-Flow The following chart illustrates a typical Deliver Customer flow: AIA for Comms: to Activate Functional Flow DELIVER ORDER SUB-FLOW CRM Capture Submit (New, Revision, Follow-on) Create/Update Trouble Ticket Update & Status Create/Update Customer Assets A+B O2A A+B Orchestrate : Transform / Enrich ; Decompose & Route Components Lifecycle Management Transform / Enrich Sample Central Fulfillment Deliver Flow Decompose, Route Components & Listen to Responses and Updates Sync Customer Initiate Billing Provision Manage Fallout Update Status Management Fulfill Billing Update & Status O2B O2B O2A O2B Billing Sync Customer Various APIs Various APIs O2A Provisioning * Deliver Service involves execution of a provisioning flow Provision : Transform & Enrich ; Decompose and Provision Services Transform / Enrich Decompose Design Service Deliver Service * Status Management Network Inventory Activation Legend Application Activity AIA Based Integration Points Application APIs Within Product Flow Flow Activity SI Provided Point to Point Integrations Optional Activity O2A To Activate Integration Point O2B To Bill Integration Point A+B To Bill & To Activate Common AIA Integration Point Design Service Various APIs How to read this Deliver Customer Sub-Flow chart: This chart shows six swim lanes, one for each of the following applications: CRM, Management, Billing, Provisioning, Network Inventory, and Activation. Each swim lane includes the typical application activities and user interactions that are part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. The AIA diamonds between swim lanes represent Oracle s existing or planned AIA-based integration points. The diamonds are labeled O2A for integration points that are part of To Activate, O2B for integration points that are part of To Bill and A+B for integration points that are common to both. See the legend on the chart for other details. There are three kinds of customer orders that an order management need to recognize: 1. New orders: orders for new purchases or changes to already delivered products. Already delivered products are known as customer assets. 2. Revision orders: amended version of an already submitted to fulfillment order. Revision orders can be submitted to fulfillment while the amended order is in a fulfillment state that allow for order amendments. 3. Follow-on orders: orders that has fulfillment completion dependency on other orders. 10

11 This flow starts with a new order, a revision to an order, or a follow-on order submitted from CRM to Management. Management performs these key functions: 1. Transforms and Enriches the. It maps order lines to fulfillment flows and enriches with fulfillment metadata and other relevant data. 2. Decomposes and Routes the. It divides the order into sub-orders, called order components, which have cross order component, cross order line and cross order dependencies, to reflect the specific demands of the CSP. The outcome is an Orchestration Plan that is executed at the computed Fulfillment Start Time to meet the Requested Delivery Date. This chart shows a simple flow; a typical flow is more complex, as shown in the Sample Use Cases section of this white paper. The produced fulfillment flow orchestrates fulfillment requests to different fulfillment providers using preconfigured fulfillment functions, such as Sync Customer into Billing, Initiate and Fulfill Billing, Provision, Ship, and Install. The Decompose and Route function of Management also generates compensation plans associated with revision orders. 3. Manages Fallout: It provides for detection, reporting, and resolution of order fulfillment fallout conditions such as system, validation, and fulfillment errors. Oracle s approach creates Trouble Tickets in CRM to take advantage of the rich notification, reporting, and management capabilities of CRM. 4. Manages Status: It maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. The status management capability updates CRM with relevant customer status and milestone values. It also updates CRM when order lines reach their point of no return to prevent the submission of new revisions. 11

12 Understanding the Qualify Customer Sub-Flow The following chart illustrates a typical Qualify Customer flow: AIA for Comms: to Activate Functional Flow QUALIFY ORDER SUB-FLOW Lifecycle Billing CRM Management Provisioning A+B Capture Orchestrate : Transform / Enrich ; Decompose & Route Components Transform / Enrich Technical Service Qualification (via submit order API) Decompose, Route Components & Listen to Responses and Updates Sample Central Fulfillment TSQ Flow Provision : Transform & Enrich ; Decompose and Provision Services Transform / Enrich Provision O2A Decompose Create/Update Trouble Ticket O2A Manage Fallout Design Service Update Update & Status A+B Status Management Status Management Update & Status O2A Network Inventory Activation Legend Application Activity AIA Based Integration Points Application APIs Within Product Flow Flow Activity SI Provided Point to Point Integrations O2A To Activate AIA Integration Point A+B To Bill & To Activate Common AIA Integration Point Design Service How to read this Deliver Customer Sub-Flow chart: This chart shows six swim lanes, one for each of the following applications: CRM, Management, Billing, Provisioning, Network Inventory, and Activation. Each swim lane includes the typical application activities and user interactions as part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. The AIA diamonds between swim lanes represent Oracle s existing or planned AIA-based integration points. The diamonds are labeled O2A for integration points that are part of To Activate and A+B for integration points that are common to To Activate and To Bill. See the legend on the chart for other details. This flow starts with a request to qualify the technical validity of a customer order submitted from CRM to Management. Management performs the same four functions detailed for the Deliver Customer with one key distinction: the metadata used and the fulfillment flow produced is for qualifying the customer order rather than delivering the customer order. Of course, Deliver and Qualify flows produce different order and order line status updates. 12

13 CRM Service WFM All Shipping InHouse Shipping PartnerInc Guidelines for Building an to Activate Integrated Business Process to Activate Design Considerations The following sub-sections provide general design considerations for choosing an Management solution and for implementing an to Activate business flow. These design considerations align with the design criteria and business drivers described in the Getting Started section. to Activate Deployment Topology Design Considerations One key design criterion for the to Activate topology is to decouple fulfillment topology from products and fulfillment flows. Thereby increasing the agility of the CSP solution, reducing costs for maintaining fulfillment flows, and decreasing the time to market when introducing new products. The following diagram shows a simplified but typical CSP fulfillment topology suitable for this discussion: CRM Capture General Ledger Payment & Collections BRM-WLS (Wholesale) BRM-REZ (Residential) General Ledger Payment & Collections BRM-BIZ (Business) Management (Central Fulfillment) Provisioning VoIP Activation VoIP Network Inventory Provisioning UK DSL Activation UK DSL Network Inventory DSL Provisioning DSL Activation DSL The Management system must be able to recognize the source of the order and respond to the source system with order status and data updates. In this diagram, the source system is the CRM Capture system. 13

14 CRM Service WFM All Shipping InHouse Shipping PartnerInc CRM Service WFM All Shipping InHouse Shipping PartnerInc Guidelines for Building an to Activate Integrated Business Process The Management system recognizes fulfillment systems by type. The following diagram overlays system types on the topology we are discussing: CRM Capture General Ledger Payment & Collections BRM-WLS (Wholesale) BRM-REZ (Residential) General Ledger Payment & Collections BRM-BIZ (Business) Management (Central Fulfillment) Provisioning VoIP Provisioning UK DSL Provisioning DSL Activation VoIP Activation UK DSL Activation DSL Network Inventory Network Inventory DSL For each fulfillment system type, the Management system recognizes the fulfillment functions available for orchestration. The following diagram overlays the fulfillment functions (abstracted as numbers) and shows a sample fulfillment flow: CRM Capture General Ledger Payment & Collections BRM-WLS (Wholesale) BRM-REZ 1(Residential) 2 General Ledger Payment & Collections BRM-BIZ (Business) Management (Central Fulfillment) Provisioning 3 VoIP Provisioning 4 5 6Provisioning UK DSL DSL Activation VoIP Activation UK DSL Activation DSL Network Inventory Network Inventory DSL 14

15 CRM Service WFM All Shipping InHouse Shipping PartnerInc Guidelines for Building an to Activate Integrated Business Process When executing the fulfillment flow, the system uses routing rules to route a fulfillment function request to the relevant fulfillment system provider, as shown in the next diagram: CRM Capture General Ledger Payment & Collections BRM-WLS (Wholesale) BRM-REZ 1(Residential) 2 General Ledger Payment & Collections BRM-BIZ (Business) Management (Central Fulfillment) Provisioning 3 VoIP Provisioning 4 5 6Provisioning UK DSL DSL Activation VoIP Activation UK DSL Activation DSL Network Inventory Network Inventory DSL This approach abstracts the fulfillment topology such that fulfillment flows either are not affected or only minimally affected by fulfillment topology changes that are bound to occur over time as a result of deployment consolidation, transformation from legacy to new systems, mergers and acquisitions, or spin-offs. This approach enables use cases such as these to be accomplished with ease: Add a new fulfillment provider; such as adding a new IPTV provisioning stack. Collapse two or more fulfillment providers into a smaller number of providers; such as collapsing billing systems for two service type or customer segments. Change the domain for a particular provider; such as limiting use for a legacy system to a particular set of customers or set of services. Change the physical topology; such as switching from a legacy system to a new system. Adding fulfillment system types and new fulfillment functions has the greatest effect on fulfillment flows. If the additions are relevant to existing fulfillment flows, then flows would need to be extended accordingly; however, this design approach is more efficient than any other known approach. This is the case for example if workforce management was not orchestrated part of fulfillment flows and it was decided to start orchestrating installation tasks through order management. This constitutes the addition of a new fulfillment system type for the first time. Adding a second workforce management system doesn t constitute a different system type and can be handled through simple configuration. 15

16 Service Fulfillment Customer Fulfillment Commercial Offerings Guidelines for Building an to Activate Integrated Business Process Deployment Topology Guidance Summary This table summarizes this deployment topology consideration and guidance: # 1 Consideration Fulfillment Topology Guidance Management should abstract fulfillment topology such that fulfillment flows and product specifications aren t affected by common changes to fulfillment topology. Product Definition and Mapping Design Considerations The Product and Service Definition methodology has the greatest effect on time to market and on the cost of an to Activate deployment. Often, products and services are defined in different network, IT, and business departments to serve the best interests of individual departments. This approach creates a challenge for bridging the gaps at runtime. We recommend a balanced approach that would require departments to make calculated compromises that would result in simplified overall Product Life Cycle and Life Cycle business flows. The Product Model diagram aligns with TMF (Tele Management Forum) terminology and guidelines. This diagram takes a step further to provide guidance about the mechanics of achieving a balanced product definition model. The Product Model, which is illustrated inside an hourglass shape, indicates the typical number of each element in the model. The model shows Product Specification at the narrowest part of the hourglass, and Commercial Offer and Resource are at the widest parts of the hourglass. The Product Model shown covers the three TMF SID key entities: Product, Service, and Resource. The diagram maps the Product Model to the three layers that are relevant for the to Activate process: Commercial offerings Product specifications Services and resources Commercial Offerings Commercial offerings represent the simple and compound product offerings available for ordering. Commercial products are core sellable entities. Commercial Bundles and Commercial Offers are a packaging of Commercial Products to achieve reusability and marketing goals. Commercial bundles group products and discounts together either for direct sales or for reuse in multiple commercial offerings. Commercial offerings group commercial products and commercial bundles to create offerings bound by contract terms or time. 0..n Product Model Commercial Offer 1..n Commercial Bundle Commercial Product 0..n 1 Product Specification n Technical Service 0..n 1..n 0..n Resource 0..n 0..n 0..n 0..n 0..n 16

17 You can manage introduction of commercial offerings starting in Siebel or a PIM (Oracle product master application). Oracle s adopted methodology is to associate commercial products with a product class in Siebel or PIM. You do not need to associate offers, bundles, discounts, and other well-identified order line subjects with a product class. Product Specifications Product specifications represent core product definitions and the anchor point for mapping order lines to fulfillment actions and for mapping order lines to service specifications in the Service Fulfillment layer. We recommend that you nest product specifications in a class hierarchy for best optimization. Oracle s adopted methodology is to support Line to Product Specification mappings in OSM based on a prepopulated Fulfillment Item Code attribute in the order line. The Fulfillment Item Code attribute should be populated by the Product Administrator. For CSPs that adopt a commercial to technical (top-down) mapping approach, the Fulfillment Mode can be populated with a Product Class name. For CSPs that adopt a technical to commercial (bottom-up) mapping approach, the Fulfillment Mode can be populated with a code reference to the Product Specification in the Management system. When Fulfillment Mode is not populated, mapping rules rely on the Product Type Code and the Billing Type attribute values to map common order line subjects, such as offers and discounts, and pure billing products to respective common product specifications. To simplify mappings in the Customer Fulfillment layer, Oracle s approach is that 0..n product classes map to one and only one product specification. Services and Resources In the Service Fulfillment layer, a product specification can map to one or more technical services. A technical service is composed of one or more technical services and resources. The mapping from a customer order to a service order requires specific metadata modeled on products, product specifications, and service and resource configurations. Oracle s adopted methodology is to leverage UIM, Oracle s network inventory application, to host service and resource configurations and capabilities to assist OSM Provisioning in the translation process of a customer order to a service order. To facilitate this mapping, product specifications should have attribution as to whether the product specification maps to an Access (Primary) Service, Service Feature, Capacity, Network Access, Network Node, and so on. Customer order lines include information about deterministic mapping between subjects of order lines and service instances. Oracle s approach is to leverage order line hierarchy and other attributes, such as Service Instance Indicator (planned for a future release of AIA for Communications Foundation Pack), Parent Line, and Root Line. Details about the Service Fulfillment layer are not in the scope of this white paper. Therefore, the sample use cases included in the following section do not reach this level of detail. 17

18 The following diagram shows how the Management system takes advantage of the Product Model to map customer order lines to fulfillment flows. Header Identification: ID; Number + Revision Fulfillment Mode Priority Job Parent... Fulfillment Design Time Metadata Lines Identification: Line ID Action Code Fulfillment Item Code Product Type Code Billing Type... Identification: Line ID Action Code Fulfillment Item Code Product Type Code Billing Type... At runtime, order capture copies key commercial offering attributes to each order line. These attributes include Fulfillment Item Code, Product Type Code and Billing Type. Management uses these attribute values to determine the corresponding product specification. The order header Fulfillment Mode attribute value determines the fulfillment requested type (e.g. Deliver, Qualify). The intersection of a product specification and fulfillment request type determines the fulfillment actions and dependencies involved. When combined for all order lines in an order, an order fulfillment plan is generated dynamically. Product Model Guidance Summary # 1 Consideration Product Model has critical impact on sought Fulfillment business benefits Guidance Adopt a compatible product model. Leverage Fulfillment Item Code for mapping Commercial Products to Product Specifications or vice versa. Use Product and Line attributes to determine the common mappings. Keep Commercial Product to Product Specification mappings simple (a product maps to a single product specification). 18

19 Update Design Considerations Superior visibility and experience is a key business driver for the to Activate process. The Management system should facilitate configurable and streamlined order fulfillment statuses and propagation across the fulfillment systems and CRM. Decomposition of an order into order components, as well as multiple fulfillment steps, place extra burden on the Management system to manage the translation of Fulfillment Function responses to common status attribute values. Each response may contribute to different order line and order header status values, which is also the responsibility of the Status Management function of the Management system. A single status attribute is not sufficient to provide comprehensive visibility into the fulfillment process. Oracle adopted the extended set of attributes shown in the following table as part of its methodology to implement to Activate. See the Communications s Dictionary topic in this white paper for more information. # Functional Attribute Name 1 Line / Status 2 Line / Milestone Usage Provides high-level update of the current status of order line fulfillment to Management and CRM. The last reached fulfillment milestone. 3 Line / Status Context 4 Line / Point-of-noreturn 5 Header / Status 6 Line / Actual Delivery Date Provides details about the current status. An implementer can configure this value. You can use Context Text to indicate: Required Customer interaction If delivery is expected to be delayed Milestone/fulfillment function in which failure occurred Cause or of a cancellation or who canceled an order Indicates if Siebel should allow revisions to an order line or submission of previously-created revisions to an order line. OSM Fulfillment flows allow configuration of setting a Hard Point-of-no-return when a condition is met for a particular service. When a Hard Point-of-no-return is established for an Line in OSM an update is issued to reflect the same in CRM. With AIA for Communications 2.4, Siebel uses the Point-of-no-Return to block submission of new revisions, but it doesn t block creation of new revisions yet. Updates CRM updated on the current status of order fulfillment at a high level. Determines the date when the purchased product or service is considered available to the customer by the CSP. This may be the date physical goods are shipped, delivered, or their receipt acknowledged. For service-based products, this is the date the service is activated. This date is computed in the Fulfillment flow. 7 Expected Provides the due date expected by the system as result of Design and Assign. Customers can change this value if they amend the order. When 19

20 # Functional Attribute Name Delivery Date 8 Header / Status Context Usage CRM creates the order, this value is provided by default. OSM uses this date to communicate changes to specific order line dates to CRM. Provides details about the current status. The implementer can configure this value. When referring to order or order line status in this white paper, we are referring to values for all of the previous attributes. Some CSPs don t realize the processing complexity that is introduced when different fulfillment status values are used for different services. Users may need to configure additional status values, but we recommend they use a streamlined set of status values across Product Specifications. This practice has two advantages: 1. To enhance the CSR s and the customer s understanding. 2. To maximize fulfillment flow reusability and enhance the time to market. In addition to using streamlined statuses, the Management system should optimize the propagation of status changes as follows: 1. Not all status changes are relevant to the CSR or the Customer in CRM. Therefore, not all changes should be propagated to CRM. 2. Not all status changes need to be reflected instantly, therefore, a throttling mechanism should be provided. Some statuses, however, should be reflected instantly, such as Point-of-No-Return being reached. Careful analysis is required to determine which status changes require instant propagation and which can wait. Too many status updates may cause performance and throughput problems. Some Status attribute values drive specific logic in CRM and should be preserved. For Siebel, these values are Complete and Canceled. Both affect the Asset Maintenance logic in Siebel. The Complete status value drives the logic to create and update Siebel Assets. The Management system should turn the status value to Complete for a parent order line only after the order line and all of its subordinate order lines (within the order hierarchy) have completed fulfillment successfully. A Canceled order status excludes the order from a Siebel calculation of the future state of the asset when creating follow-on or future-dated orders. When making data updates to an order line in CRM, Management should avoid sending the data updates before the order line reaches the Point-of-No-Return. If a revision was created before the data update was sent to CRM and then the revision was submitted, the data updates may be lost. Fulfillment flows in Management should delay sending data updates as long as possible but no later than when the Complete status value is sent to Siebel. If any data update occurs after the Complete status value is propagated to Siebel, then the updated data would not be saved on the Asset. If significant changes made to an order during fulfillment compromise the customer s intent, then the Management system should set the Changed flag to signal Siebel to make a copy of the customer order before updating it. 20

21 Update Guidance Summary: # Consideration Fulfillment Visibility in CRM Update Data in CRM Updates from Fulfillment Systems to Management Guidance Use the extended set of status attributes adopted by O2A FP. Streamline statuses across product specifications. Send updates that are significant to CSR or customer. Preserve Siebel significant statuses (such as Canceled, Complete). Establish Complete order line status for a parent line only after all children order lines status is Complete Avoid sending order data updates prior to point of no return Make data updates with or before updating CRM with Complete order line status Set the Changed Flag when order changes contravene customer intent. Channel all updates through the provided single AIA service operation. Map updates to common lifecycle, status and fallout conditions. Revision s Design Considerations The fulfillment of certain services may take days and weeks, and some B2B and infrastructure projects may take months to complete. During this period, customers change their minds and request changes to their orders that become revision orders in Siebel. In many cases, continuing the base order when a revision is submitted is costly for the CSP, and sometimes the operation cannot be fully undone. For these reasons, support for revision orders provides the following benefits: Enhances customer satisfaction by allowing customers to change their orders within an agreed-upon limit. Reduces the costs associated with fulfilling unwanted goods and services requests and wasting system capacity, unrecoverable resources, acquired stock, and so forth. Reduces human intervention to manually retrofit data records when recovery cannot be automated. A CSP can attain these benefits by adopting a balanced order revision policy. A point-of-no-return (PONR) must be established in the fulfillment flow of each service so that either an order revision is technically impossible or the cost of doing so outweighs the benefit of allowing a revision. Siebel allows order line revisions as long as the order line did not complete. With AIA for Communications 2.4, Siebel was enhanced to block the submission of an order line revision when it reached the PONR. Despite this enhancement, the possibility exists that a revision order is submitted at the same time an order line reaches the PONR. The Management system is required to reject revisions that violate the PONR, placing them in fallout. To avoid problems associated with staled revisions (that is, revisions that do not progress in Siebel and become out of sync with their underlying asset) Siebel was enhanced to allow only one pending revision for each order. 21

22 A PONR should be configured in the fulfillment flow of each Product Specification and propagated to CRM at runtime. After a revision is submitted, the Management system should be able to recognize a revision of an in-flight (being fulfilled) or pending order (waiting turn to be fulfilled), and it will ignore older revisions that may be out of date because of slow messaging queues or system outages. The Management system is responsible for suspending the revised order, computing a compensation plan, and considering the revision order changes when fulfilling the order. The Management system should expect to receive a complete revision order, not a delta order with changes from the original order. Revisions may include new order lines, modified order lines, and cancelled order lines. The Management system should support these cancellation patterns: 1. Cancel the entire order. Siebel will set the Fulfillment Mode order header attribute value to CANCEL. 2. Drop an order line. When an ADD for a new product is dropped, Siebel will drop the order line from the revision order. 3. Revert the order line Service Action Code to NONE. When a change to an existing asset is reverted, Siebel will revert the order line Service Action Code. 4. Revert changes to an order line some times produces an Update order line that has no changes. In other words this is a false update case. For product attributes that are saved to the asset in Siebel (see the Communications s Dictionary topic in this white paper for information about assetable attributes), the order message includes Prior Value for changed attributes. Management and fulfillment systems take advantage of these attributes to determine the changes and to undo unwanted actions. The Management system is responsible for maintaining correct Prior Values when attribute values change during fulfillment. The Management system should pass Prior Values to systems with the capability to process revisions. Compensation for provisioning typically involves technical knowledge, and we recommend that you keep that knowledge out of the Management layer. The Management system should delegate to the Provisioning stack for any Provisioning-specific compensation by passing the revision order component as is to the Provisioning system. The Provisioning system, in turn, is responsible for computing delta changes, computing a compensation plan, and executing the revision. This table lists the Sales attributes that are used to identify revisions and order lines across revisions. When a revision cancels an entire order, the Fulfillment Mode attribute CANCEL value is used. # Functional Attribute Name 1 Header / ID 2 Header / Number 3 Header / Revision Usage Alphanumeric identifier for the order. This value is unique for each revision. The Management System should preserve this ID and pass it to fulfillment systems. Alphanumeric identifier for the order. This value does not change across revisions. This value and the Revision attribute are used to identify order revisions in Management. Numeric identifier of order revisions made during the fulfillment process. 22

23 # Functional Attribute Name 4 line / Line Item ID 5 line / Base Line Item ID 6 Header / Fulfillment Mode Usage Unique, auto-generated identifier of the order line across orders and order revisions. Reference to the revised order line ID from the base order. Management uses this attribute to match order lines across revisions of the same order. Fulfillment request type. The Cancel value is a special case used to cancel an entire order. Revision s Guidance Summary # Consideration Point-of-No_Return (PONR) Staled revisions Computing changes Canceled order, order line Compensation Guidance Manage through a separate attribute. Propagate value from Management to Siebel to enable Siebel and should be propagated to Siebel. Avoid side effect of possible race condition; Management should validate revisions against PONR. Find alternatives to keeping more than one pending revision in Siebel. For AIA 2.4 this is blocked by Siebel. Send complete order revisions as opposed to incremental changes to Management. Maintain Prior Values in Management to pass to fulfillment functions as needed. Support four patterns: level cancel (Fulfillment Mode = CANCEL) line dropped line s Action Code reverts to no action False updates Adhere to order compensation specifications for BRM AIA interfaces. Delegate revisions to Provisioning to avoid bringing technical knowledge to Management. 23

24 Billing Fulfillment Design Considerations Billing fulfillment scenarios lead to one of two fulfillment patterns, each of which must be supported by the Management system. Two-Phase Billing In this pattern, a service is interfaced to Billing twice: 1. Initiate Billing. The service and purchased products are interfaced in early in the fulfillment flow and before actual delivery dates are known. 2. Fulfill Billing. Accurate billing dates are updated in Billing after the order is delivered and the actual delivery date is known. Two scenarios require this pattern. Billing Scenario #1: Phased for Time Latency In this scenario, the CSP has these concerns: Operational or deployment conditions produce a time lag between the time a service is made available for customer use and the time the service is interfaced into Billing. As a result, usage records can go into error logs and the CSP may lose revenue. CSPs attempt to plan fulfillment of future dated orders to meet the requested delivery date, often using a safe margin that produces a time lag between the time a service is made available for customer use and the requested delivery date. In these cases, the usage cycle needs to start sooner than the billing cycle date. The fulfillment flow should be constructed such that the Usage Start Date is set to the current date during Initiate Billing, and the Cycle Start Date is set to a distant future date. At the time of Fulfill Billing, the Cycle Start Date is then reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements. Billing Scenario #2: Phased for Validation In this scenario, the CSP has these concerns: Inadequate controls are in place to guarantee that valid orders interface to Billing. As a result, the CSP faces a high rate of invalid orders. The costs associated with delaying order line validation for interfacing to Billing are prohibitive. In these cases, orders need to be interfaced to Billing early in the fulfillment flow to prove that the order can be interfaced successfully. The fulfillment flow should be constructed such that the Usage Start Date and the Cycle Start Date are set to a distant future date during Initiate Billing. At the time of Fulfill Billing, the Usage Start Date and Cycle Start Date can be reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements. Single-Phase Billing In this pattern, a service is interfaced to billing through Fulfill Billing towards the end of the fulfillment flow, after the order is delivered and the actual delivery date is known. Two scenarios require this pattern. 24

25 Billing Scenario #3: All at Once (most common scenario) In this scenario, the CSP does not have the concerns mentioned previously; interfacing to Billing takes place after the service or product is made available to the customer. The interpretation of made available may vary among CSPs, based on jurisdiction, and based on whether the subject is a service or a physical good. For example, physical goods that require no network activation or onsite installation might be billed immediately after the goods are shipped. The exact timing is built into the fulfillment flows associated with the underlying Product Specification through the Actual Delivery Date and other billing date attributes. Billing Scenario #4: On First Usage In this scenario, the CSP predelivers certain types of services (typically IP-based services), markets the availability of the services to the customer, and initiates billing only at the time of first usage. Interfacing Line to Billing for this pattern is done in a single phase, similar to the All at Once pattern except that billing starts only after first usage of the service. In all of the previous cases, BRM requires that the Purchase Date be set to the earliest Usage Start Date or Cycle Start Date interfaced to Billing. The BRM ABCS enforces this constraint by overriding the Purchase Date value. For all of the previous cases, the Management fulfillment flow should maintain accurate Prior Values for the date attributes. This table lists the key attributes used to support Billing fulfillment patterns: # Functional Attribute Name 1 Line / Usage Start Date 2 Line / Cycle State Date 3 Line / Purchase Date 4 Line / Actual Delivery Date 5 Line / Requested Delivery Date 6 Line / Start Billing on First Usage Usage Determines the date when usage events should start being rated. The value for this attribute is populated by CRM, Management fulfillment flows, or set to Null for BRM to provide the current date by default. Determines the date when cycle charges should start being billed. The value for this attribute is populated by CRM, Management fulfillment flows, or set to Null for BRM to provide the current date by default. Determines the date when one-time purchase charges should be billed. The value for this attribute is populated by CRM, Management fulfillment flows, or set to Null for BRM to provide the current date by default. Determines the date when the purchased product or service are considered available to the customer by the CSP. This date may be when a physical good is shipped, delivered, or its receipt acknowledged. For service-based products, this date is when service is activated. This date is computed in the Management fulfillment flow. A Null value means that the requested delivery date for the good or service is ASAP; otherwise, it is the specified date. This date is not guaranteed. When this value is set to Yes by CRM or Management, the request is passed along to BRM. In this case, Usage Start Date, Cycle Start Date, and Purchase Date should have no effect because the integration does not support this attribute when first delivered; an extension to the BRM ABCS is required. 25

26 Note that resetting the Usage Start Date, Cycle Start Date, or Purchase Start Date value requires passing a corresponding Prior Value. The BRM ABCS uses Prior Values to determine appropriate action and BRM API to use. Billing Fulfillment Guidance Summary # 1 Consideration Billing fulfillment patterns Guidance Support for single-phase and two-phase billing patterns. Determine Actual Delivery Date by Product Specification on fulfillment flows to meet provider s business needs or legal requirements. Compute correct billing Cycle, Usage and Purchase dates based on values provided in Siebel and Actual Delivery Date part of fulfillment flow. Maintain and pass proper Prior Values for all changing attributes when invoking Initiate or Fulfill billing. Multiple Features Design Considerations This topic describes design considerations for Management system features. Future-Dated s Future-dated orders facilitate convenient order capture and accommodate customer requirements for activating or deactivating services while away. Support for future-dated orders ranges from a necessity to a convenience for CSPs. It enables CSPs to comply with requested delivery, update, move, or cancellation dates. It also enables CSPs to manage customer-initiated or CSP-initiated periods of Suspend and Resume of services. The Management system should accept orders with future Requested Delivery Dates at any time after the order is captured in Siebel. The Management system is expected to compute a fulfillment start time that allow for services and goods to be delivered as close as possible to the requested delivery date. Determination of a fulfillment start time constitutes a timebased dependency for the start of fulfillment flow. Avoid creating multiple future-dated orders against the same asset. They create a complex future asset state that is difficult for both the CSR and the customer to comprehend. We recommend that only a trained CSR be allowed to enter multiple future-dated orders against the same asset and only when required. When introducing an order line against the same asset with a Requested Delivery Date sooner than another already created order, you should revise the latter to ensure that the order is based on an updated future state of the asset. Follow-On s The fulfillment of some services may take days and weeks, and some B2B and infrastructure projects may take months to complete. During this period, customers change their minds and request order changes that become revision orders in Siebel if the subject order lines did not reach the PONR or become follow-on orders otherwise. In many cases, not taking an order pending the completion of in-flight orders is not acceptable; hence, Siebel simulates the future state of in-flight orders and allows for the creation and submittal of follow-on orders that are nothing more than change orders based on the projected future state of a customer s assets. 26

27 Follow-on orders are change orders that involve a dependency on the future fulfillment of at least one other order line in an order that is currently in-flight. The Follow-On order line may change another in-flight order line that is beyond the hard PONR or that depends on the future asset state of that line, as through an explicit dependency established in Siebel. Follow-on orders are created and submitted to Management immediately, and Management is responsible for managing the fulfillment dependency between the follow-on order and other base orders. This responsibility is similar to the responsibility for determining the correct processing time for future-dated orders. This table lists the attributes through which follow-on orders can establish cross-order dependencies at the order line level: # Functional Attribute Name 1 Line / Depends On Line Item ID 2 Line / Depends On ID Usage Line Item ID of a base order line item that is changed by this order. Used to establish dependency between order line on follow-on order and order line on base order. ID of an in-flight order. It is the basis for this follow-on order line item. Cross- Dependencies In addition to follow-on orders, another kind of order produces a cross-order fulfillment dependency: an explicit parent-child order hierarchy. For example, multi-site B2B projects for which the customer and CSP agree on a project sequence that specifies that work on one side will finish before work on the other side starts. In this case, the dependency is captured through the following order header attribute: # Functional Attribute Name 1 Header / Parent ID Usage Establishes cross-order dependencies between a child and parent order. The child order starts fulfillment only after the parent order fulfillment is complete. The Management system is expected to honor cross-order dependencies both at the order line and order header levels. Priorities Fulfillment Priorities reflect business factors such as customer experience and revenue recognition, as well as operational factors such as deployment throughput capacity and fluctuation. Fulfillment Priority is specified in CRM or provided by default in fulfillment, and it should be honored by the Management system along with the entire fulfillment deployment. Message queues should be configured to honor priorities. When two orders with different priorities are submitted by CRM, we expect whenever the two orders are within the same system waiting for service that the higher priority order will be given precedence over the lower priority order. 27

28 This table describes Priority attributes and values: # Functional Attribute Name 1 Header / Fulfillment Priority Usage Relevant priority of order fulfillment across orders. A lower value indicates a higher priority. The Priority attribute takes a value between 0 and 9, with 0 being the highest and 9 being the lowest priority, as follows: 0: Urgent (Use for expedited orders.) 1: Highest (Usage defined by CSP.) 2: Very High (Usage defined by CSP.) 3: High (Usage defined by CSP.) 4: Medium High (Usage defined by CSP.) 5: Medium (Usage defined by CSP.) This is the default. 6: Medium Low (Usage defined by CSP.) 7: Low (Usage defined by CSP.). Recommended for Job orders. 8: Very Low (Usage defined by CSP.) 9: Lowest (Usage defined by CSP.) Job (Batch and Bulk) s Job orders are of two types: A single-order job is a single order with a large number of line items that should be treated as one job. For example, if a business customer wants to upgrade phone subscriptions for its 20,000 employees, then a single order is produced with 20,000 lines. A multi-order job is a single job with a large number of correlated orders. For example, a campaign to add 100 SMS free messages to all subscribers whose date of birth is tomorrow produces 25,000 orders. Siebel bulk ordering was extended to tag orders within a job with a common Job ID. The Job ID is passed on the EBM as follows: # Functional Attribute Name Usage 1 Header / Job ID Uniquely identifies a job to the orchestration plan. This value should be long enough to allow reasonable coding of information into the ID, such as a campaign name. An ID should be generated automatically and an override is allowed. If no Job ID is provided for a single-order job, then it is treated like a regular order. The Job ID allows Management to vary processing for job orders and to report on job orders. For example, Management should allow for bulk Suspend or Resume of all orders included in a job. 28

29 Qualify Sub-Flow AIA for Communications 2.4 uses the order header Fulfillment Mode attribute to determine the characteristics of the fulfillment request. # Functional Attribute Name Usage 1 Header / Fulfillment Mode Qualifies the orchestration required for a particular sales order submission. As delivered, AIA for Communications 2.4 and Siebel extensions support Deliver, Cancel, and Get Provider values. See the Communication s Dictionary topic in this white paper for details. The value TSQ is planned for a future release of AIA for Communications and used to support the Qualify customer order request. The System Integrator must add the Fulfillment Mode value TSQ to the ProcessSalesFulfillment and ProcessProvisioning EBMs. In addition, the System Integrator must extend the Siebel user interface to include a TSQ button next to the Submit button to enable order submission when the Fulfillment Mode attribute value is set to TSQ. Note that TSQ relies on integration between the Provisioning system and the Network Inventory system; this topic is not covered in this white paper. Multiple Features Guidance Summary # Consideration Future-Dated s Follow-On s Cross- Dependencies Priority Priority and Job s Qualify Customer Guidance Compute fulfillment start date in Management. Start fulfillment of an order ASAP, if the fulfillment start date is current or in the past. Support order cross-order-line dependencies to support follow-on orders. Support order level (parent-child) dependencies. Honor order priority values 0 to 9. Default order priority for job orders to 7 (Low in Siebel). Default order priority for expedited orders = 0 (Urgent in Siebel). Use Job Id to correlate identify individually submitted orders to a Job. Support reporting and bulk actions on Job s. Extend Siebel and integration to support Technical Service Qualification, if required. 29

30 Management Integration Design Considerations System Interactions The core orchestration activities of the Management system are System Interactions to Fulfillment Systems. The Management system should honor the system interaction contracts for all fulfillment functions, including the request and response messages, as applicable. The Management System should also honor the compensation logic for each fulfillment function. A critical element of System Interactions is that it honors processing granularity for each fulfillment function separately. Processing granularity determines the grouping of order lines that should be processed together into a fulfillment function. This grouping preserves the minimal context required by the fulfillment function and honors the business requirements. It may relate to the number and frequency of system, engineering, and customer interactions. When decomposing an order, the Management system must recognize and honor both explicit and implicit order line hierarchies and relationships. For example, one-time charges, such as Downgrade Charge and Early Termination Fee, have relationships (such as the cause for the charge) to the order line. These should be considered as part of the order line when it is processed through Billing. An Management implementation of a System Interaction should also account for all possible responses and should allow for multiple updates in the course of a single fulfillment function, including mapping of responses to an order line and order status updates. Mapping of errors to fallout conditions is also included. The System Interaction should also account for two kinds of attributes on an EBM: First Class Attributes (FCA) coded directly and explicitly on the EBM such as Product Name and User- Defined Attributes (UDAs) such as Bandwidth. UDAs are equivalent to Siebel extended (XA) attributes. UDAs are modeled as Name-Value pairs on EBMs in different places. UDAs also have Action Codes for ADD, DELETE, and UPDATE. In addition to preserving Prior Values, the Management system is expected to preserve Action Codes and set them properly if a UDA is changed during fulfillment. -based EBMs can become large and inefficient. To reduce the burden, EBMs should only include required and populated optional attributes. Do not assume that the Management and Fulfillment systems will receive all item or order line attributes. Similarly, update messages should include key identification attributes along with changed attributes. Fallout Management Fallout conditions could arise as a result of internal conditions in Management and the fulfillment flow, such as a validation error or unknown Product Specification, respectively. In addition, AIA Error Handling is another channel for fallout conditions. It captures System Interaction errors. The Management system must integrate with the AIA Error Handling message queue and process such errors as fallout conditions. Create Trouble Tickets in Siebel to facilitate automatic assignment, notification, reporting, and management of fallout incidents across systems and departments. 30

31 Management Integration Guidance Summary # 1 2 Consideration Management System Interactions Fallout Management Guidance Honors system interaction contracts for fulfillment functions, including compensation logic. Map system interaction responses to status and fallout conditions. Preserve minimal context for each fulfillment function when decomposing an order. Support both explicit and implicit order line hierarchies and relationships. Pass only changed attributes (relative to asset state) on AIA messages. Maintain Prior Values and pass them as needed. Support UDAs and preserve their Prior Values and Action Codes. Consume AIA Errors off AIA Error Handler into Management fallout handling. Create Siebel Trouble Tickets for fallout incidents. 31

32 to Activate Integration Components Building to Activate to incorporate any Management system and any Provisioning system could leverage the AIA for Communications Foundation Pack along with the to Bill PIP components. Always use the latest AIA for Communications version, as newer versions are enhanced with richer objects and services. At a minimum, we recommend that you start with AIA for Communications 2.4, which is the latest release available at the time of authoring this white paper. Please refer to the AIA for Communications respective guides and documentation for general architecture and deployment-specific information. This section summarizes the various AIA components that are available to integrate Siebel and BRM to any Management system and to any Provisioning system. 32

33 The following diagram shows the available integration resources. Tasks and details about the components are listed following the diagram. AIA for Comms 2.4: to Activate Integration Components Billing CRM Lifecycle Management AIA Error Handling Orchestrate Customer Sync Customer Sync Customer Capture Submit (DELIVER or QUALIFY : New, Revision or Follow-on) Initiate Billing Initiate Billing PIP Provision Fulfill Billing Fulfill Billing Update & Status Update Customer & Status Update Fulfillment Create Trouble Ticket Create Trouble Ticket Read AIA Errors Error Queue Suspend Provisioning Resume Provisioning Cancel Provisioning PIP PIP FP PIP FP FP FP FP PIP PIP Provisioning Provision Update Suspend Resume Cancel Legend Application APIs Flow Activity AIA Based Integration Points FP Foundation Pack Components PIP PIP Components 33

34 The following AIA integration components are available to build to Activate. 1. Submit Sales from CRM to Management: System Component Type Component Name Outbound Payload Usage Remarks Siebel Queue AIA_SALESORDERJMSQUEUE SalesABM Ready to use FMW Consumer ProcessSalesFulfillmentSiebelCommsJMSConsumer SalesABM per Oracle methodology. FMW ABCS ProcessSalesFulfillmentSiebelCommsReqABCSImpl ProcessSalesFulfillmentEBM FMW EBS CommunicationsSalesEBSV2.ProcessSalesFulfillment ProcessSalesFulfillmentEBM FMW Producer ProcessSalesFulfillmentOSMCFSCommsJMSProducer Create Samples are Queue AIA_CRTFO_IN_JMSQ Create specific to Management each Management system. 2. Update Sales from Management to CRM: System Component Type Component Name Outbound Payload Usage Remarks Queue AIA_UPDSO_OUT_JMSQ UpdateFulfillment Samples are specific Management to each FMW Consumer UpdateSalesOSMCFSCommsJMSConsumer UpdateSalesEBM Management system. FMW EBS CommunicationsSalesEBSV2.UpdateSales UpdateSalesEBM Ready to use per FMW ABCS UpdateSalesSiebelCommsProvABCSImpl SalesABM Oracle methodology. Siebel Web Service NA NA Not relevant. 3. Sync Customer from Management to BRM and Response: System Compone nt Type Component Name Outbound Payload Usage Remarks Queue AIA_CRTCUST_OUT_JMSQ CreateFulfillment Samples are 34

35 System Managemen t Compone nt Type Component Name Outbound Payload Usage Remarks FMW Consumer ProcessFulfillmentBillingAccountListO SMCFSCommsJMSConsumer FMW EBS CommunicationsBillingEBSV1.ProcessFulfil lmentbillingaccountlist FMW EBF CommsProcessFulfillmentBillingAcco untlistebf FMW EBS CommunicationsBillingResponseEBSV1. ProcessFulfillmentBillingAccountListR esponse FMW Producer ProcessFufillmentBillingAccountListR esponseosmcfscommsjmsproducer Managemen t ProcessFulfillmentBillingAccountListEBM ProcessFulfillmentBillingAccountListEBM ProcessBillingAccountListEBM ProcessFulfillmentBillingAccountListRes ponseebm ReceiveFulfillmentUpdate Queue AIA_UPDCUST_IN_JMSQ ReceiveFulfillmentUpdate specific to each Management system. Ready to use per Oracle methodology. Samples are specific to each Management system. 4. Initiate Billing and Fulfill Billing from Management to BRM and Response. Initiate and Fulfill are determined based on the value of the Fulfillment Mode attribute: System Managem ent Compone nt Type Component Name Outbound Payload Usage Remarks Queue AIA_CRTBO_OUT_JMSQ CreateFulfillment Samples are specific to each FMW Consumer CreateFulfillmentOSMCFSCommsJMSCons umer FMW EBS CommunicationsBillingEBSV1.ProcessFulfillment Billing FMW ABCS ProcessFulflilmentBillingBRMCommsProvA BCSImpl ProcessFulfillmentBillingEBM ProcessFulfillmentBillingEBM Several opcodes Management system. Ready to use per Oracle methodology. 35

36 System Compone nt Type Component Name Outbound Payload Usage Remarks BRM OpCodes Several Several responses FMW ABCS ProcessFulflilmentBillingBRMCommsProvA BCSImpl FMW EBS CommunicationsBillingEBSV1.ProcessFulfillment BillingResponse FMW Producer ProcessFufillmentBillingResponseOSMCFS CommsJMSProducer Managem ent ProcessFulfillmentBillingResp onseebm ProcessFulfillmentBillingResp onseebm ReceiveFulfillmentUpdate Queue AIA_UPDBO_IN_JMSQ ReceiveFulfillmentUpdate Samples are specific to each Management system. 5. Provision from Management to Provisioning: System Manageme nt Componen t Type Component Name Outbound Payload Usage Remarks Queue NA NA Specific to each Management System. SI build. FMW Consumer NA ProcessProvisioningEBM FMW EBS CommunicationsProvisioningEBSV 1.ProcessProvisioning ProcessProvisioningEBM Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning Provisioning Queue NA NA System. SI build. 6. Cancel Provisioning from Management to Provisioning: System Manageme Componen t Type Component Name Outbound Payload Usage Remarks Queue NA NA Specific to each 36

37 System nt Componen t Type Component Name Outbound Payload Usage Remarks FMW Consumer NA CancelProvisioningEBM FMW EBS CommunicationsProvisioningEBSV 1.CancelProvisioning CancelProvisioningEBM Management System. SI build. Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning Provisioning Queue NA NA System. SI build. 7. Suspend Provisioning from Management to Provisioning: System Manageme nt Componen t Type Component Name Outbound Payload Usage Remarks Queue NA NA Specific to each Management System. SI build. FMW Consumer NA SuspendProvisioningEBM FMW EBS CommunicationsProvisioningEBSV 1.SuspendProvisioning SuspendProvisioningEBM Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning Provisioning Queue NA NA System. SI build. 8. Resume Provisioning from Management to Provisioning: System Manageme nt Componen t Type Component Name Outbound Payload Usage Remarks Queue NA NA Specific to each Management System. SI build. FMW Consumer NA ResumeProvisioningEBM FMW EBS CommunicationsProvisioningEBSV 1.ResumeProvisioning ResumeProvisioningEBM Ready to use per Oracle methodology. 37

38 System Componen t Type Component Name Outbound Payload Usage Remarks FMW Producer NA NA Specific to each Provisioning Provisioning Queue NA NA System. SI build. 9. Update Fulfillment from Provisioning to Management: System Componen t Type Component Name Outbound Payload Usage Remarks Provisioning Queue NA NA Specific to each FMW Consumer NA ReceiveFulfillmentUpdateEB Management System. SI M build. FMW EBS CommunicationsFulfillmentEBSV1. ProcessFulfillmentUpdate ReceiveFulfillmentUpdateEB M Ready to use per Oracle methodology. FMW Producer NA NA Specific to each Provisioning Manageme nt Queue NA NA System. SI build. 10. Create Trouble Ticket from Management to Siebel: AIA TOPIC is configured part of O2B and comes with the consumer. An O2A implementer could use the consumer directly or push the message into a Queue for Management to consume. System Component Type Component Name Outbound Payload Usage Remarks Queue NA NA Specific to each Management Management System. FMW Consumer NA CreateTroubleTicketEBM SI build. FMW EBS CommunicationsTroubleTicketEBSV1.Create CreateTroubleTicketEBM Ready to use per Oracle FMW ABCS CreateTroubleTicketSiebelCommsProvABCSImpl TroubleTicketInsert_input methodology. Siebel Web Services NA Not relevant 38

39 to Activate Sample Use Cases This section provides sample use cases for the to Activate business process. The sample use cases illustrate data modeling and fulfillment solutions for real life order fulfillment scenarios. Use Cases Setup Broadband-VoIP Double Play Commercial Offering # Siebel Object {parent line #} 1 Bundled Promotion {} Relationship Type Cardinality (min, max, default) Name On Top of the World Broadband-VoIP Price Type List Price 2 CP {} High Speed Internet Service Bundle Subject Type (computed during fulfillment) 3 CP {2} Product (1,1,1) Internet Service Service Bundle 4.SP {3} Dynamic Class (1,1,1) Internet Service DClass NA 5.SP {3} Product (0,1,0) Internet Secure Firewall MRC $0 Product 6.CP {3} Product (1,1,1) Internet Service Bundle 7.SP {6} Product (1,1,1) Internet MRC $0 Product 8.CP {3} Product (1,1,1) Internet Media Service Bundle 9..SP {8} Product (1,1,1) Internet Content on Demand MRC $0 Product 10..SP {8} Product (1,1,1) Internet Video on Demand MRC $0 Product 11.SP {2} Dynamic Class (1,1,1) Internet Modems DClass NA 12.SP {2} Product (0,1,0) Wireless Router OTC $75 Product 13.SP {2} Product (1,1,1) High Speed Internet Installation OTC $0 Product 14.SP {2} Product (1,1,1) High Speed Internet Activation OTC $30 Product 15 CP {} VoIP Service Bundle 16.CP {15} VoIP Service Plan Service Bundle Offer 39

40 # Siebel Object {parent line #} 17.. Dynamic Class {16} Relationship Type Cardinality (min, max, default) Name Dynamic Class (1,1,1) VoIP Service Plan DClass Price Type List Price 18..SP{16} Product (0,1,0) VoIP Voic MRC $0.00 Product 19..SP{16} Product (0,1,0) VoIP Caller ID MRC $0.00 Product 20.SP {15} Product (0,1,0) VoIP Adaptor OTC $45.00 Product 21. SP {15} Product (0,1,0) VoIP Phone OTC $50.00 Product 22 SP {} Product (1,1,1) High Speed Internet First Month Free Discount 23 SP {} Product (1,11) High Speed Internet Activation Discount Subject Type (computed during fulfillment) MRC 100% Discount OTC 100% Discount 24 SP {} Product (1,1,1) VoIP Recurring Discount MRC $10.00 Discount 25 SP {} Product (1,1,1) VoIP First Month Free Discount MRC 100% Discount The following tables provide product details about the dynamic classes shown in the double play offering in the previous table. Siebel dynamic classes enable flexibility to reuse product alternatives across offering and update all offerings when the dynamic class changes to add or remove alternatives. VoIP Service Plan DClass: Dynamic Class that includes two VoIP access alternative products is created for dynamic reusability: # Siebel Object {parent line #} Name Price Type List Price Subject Type (computed during fulfillment) 1 Dynamic Class {} VoIP Service Plan DClass NA 2.SP {1} Basic VoIP MRC $15 Product 3.SP {1} VoIP w/ unlimited calls MRC $60 Product 40

41 Internet Service Dynamic Class that includes the three high-speed internet alternative products is created for dynamic reusability: # Siebel Object {parent line #} Name Price Type List Price Subject Type (computed during fulfillment) 1 Dynamic Class {} Internet Service DClass NA 2.SP {1} Basic High Speed Internet - 1Mbps MRC $15 Product 3.SP {1} Premium High Speed Internet - 3Mbps MRC $60 Product 4.SP {1} Elite High Speed Internet - 15Mbps MRC $80 Product Internet Modems Dynamic Class that includes the three high-speed internet alternative products is created for dynamic reusability: # Siebel Object {parent line #} Name Price Type List Price Subject Type (computed during fulfillment) 1 Dynamic Class {} Internet Modems DClass NA 2.SP {1} Motorola Modem OTC $0 Product 3.SP {1} Dynex Modem OTC $0 Product 41

42 Typical Fulfillment Topology This diagram shows a typical fulfillment topology: CRM Capture BRM-VOIP (VOIP Services) BRM-REZBDB (Residential Broadband) General Ledger Payment & Collections BRM-BIZBDB (Business Broadband) CRM Service Central Fulfillment Process Shipping InHouse Shipping PartnerInc Provisioning VoIP Activation VoIP Provisioning UK DSL Activation UK DSL Provisioning DSL Activation DSL WFM All Network Inventory Network Inventory DSL The following topics provide additional details about fulfillment system types and the fulfillment functions supported by each fulfillment system type. Common Fulfillment Topology Definition This table details the fulfillment topology metadata required to define the previous topology: # Fulfillment System Type Provider Determinants Billing VoIP Header Customer Segment AND Product Specs Product Family Residential Broadband Business Broadband 2 Provisioning VOIP Line s Service Address Country AND Product Specs Product Family UK DSL DSL 3 WFM ALL NA 42

43 # Fulfillment System Type Provider Determinants 4 SCM InHouse Vendor on order line s Item Reference component PartnerInc 5 CRMService ALL NA 6 CRMSales ALL NA This table lists the Fulfillment system functions available for Orchestration: # System Interaction Action AIA Service Operation Fulfillment System Type Processing Granularity Milestones 1 SyncCustomer ProcessFulfillmentAccountListEBF Billing Start, Complete 2 InitiateBilling ProcessFulfillmentBilling (FulfillmentMode= Initiate ) 3 FulfillBilling ProcessFulfillmentBilling (FulfillmentMode= Fulfill ) Billing Start, Complete Billing Subject Type = Service Bundle Start, Complete 4 Provision ProcessProvisioning Provisioning Start, Designed, Complete 5 CreateTT CreateTroubleTicket CRM-Service Any Start, Complete 6 UpdateTT UpdateTroubleTicket CRM-Service Any Start, Complete 7 Install ProcessInstall WFM Start, Planned, Committed, Complete 8 Ship ProcessSCM Shipping : when Customer Segment = Residential Any: otherwise Start, Planned, Shipped, Complete 9 UpdateSales UpdateSales CRMSales Any Start, Complete 10 UpdateSalesStatus UpdateSales CRMSales Any Start, Complete 11 UpdateFulfillment ProcessFulfillmentUpdate Orchestration Any Start, Complete 43

44 Double Play Fulfillment Flow Sample Note: For quick reference, we call this the Nile flow. Fulfillment Item Code or Subject Type (*) Product Specification Intended Fulfillment Flows VoIP Service Plan Class VoIP Service Feature Class Service.VoIP VoIP Equipment Class Service.CPE.VoIP High Speed Internet Service Class High Speed Internet Service Feature Class Internet Media Class Service.Broadband Broadband Modem Class Wireless Router Class Service.CPE.Broadband High-Speed Internet Installation Class Service.Install Offer (*) Pricing Event Class Discount (*) Bundle (*) SpecialRating (*) NonService.Offer NonService.BillingItem Describing the Double Play Fulfillment Flow The first column shows the Fulfillment Item Code or Subject Type values for double-play offering subjects depending on which one is relevant. To distinguish the two Subject Type values are followed by (*). Management uses the values in the first column to map order lines each to the corresponding product specification on the second column. 44

45 The second column shows the product specifications that map to fulfillment flows in the third column. Each product specification and order type (deliver, qualify) combination map to a single fulfillment flow. The third column graphically shows the fulfillment flow associated with each product specification, including cross-product specification dependencies. The fulfillment flow for a product specification represents an orchestration of fulfillment functions in a particular order. For example, the VoIP Service Plan Class maps to the Service.VoIP product specification, which has the following fulfillment flow: 1. Sync Customer. 2. When complete Initiate Billing, unless the order line is part of an offer on the same order then wait for the offer to complete Initiate Billing. 3. When Sync Customer is complete and if the same order has a line that maps Service.Broadband.Access product specification and its provisioning is complete, then start Provisioning. 4. When both Initiate Billing and Provision are complete, start Fulfill Billing. 45

46 Double Play Promotion First-Time Purchase Sales Customer places an order for On Top of the World Broadband-VoIP (Double Play) offer as follows: # Siebel Object {parent line #} 1 Bundled Promotion {} Action Name Price Type List Price Prom ID Subject Type Remarks ADD On Top of the World Broadband-VoIP Offer Billing Profile = VISA 2 CP {} ADD High Speed Internet Service ID (1) Bundle Billing Profile = VISA 3 CP {} ADD Internet Service ID (1) Service Bundle 4.SP {3} ADD High Speed Internet Basic MRC $15 ID (1) Product 5.SP {3} ADD Internet Secure Firewall MRC $0 ID (1) Product 6.CP {3} ADD Internet ID (1) Service Bundle 7.SP {6} ADD Internet MRC $0 ID (1) Product 8.CP {3} ADD Internet Media ID (1) Service Bundle 9..SP {8} ADD Internet Content on Demand MRC $0 ID (1) Product 10..SP {8} ADD Internet Video on Demand MRC $0 ID (1) Product 11.SP {2} ADD Dynex Modem OTC $0 ID (1) Product 12.SP {2} ADD Wireless Router OTC $75 ID (1) Product 13.SP {2} ADD High Speed Internet Installation OTC $0 ID (1) Product 14.SP {2} ADD High Speed Internet Activation OTC $30 ID (1) Product Service ID = Null* Billing Profile = VISA Service ID = Null* Service ID = Null* Service ID = Null* 15 CP {} ADD VoIP Service ID (1) Bundle Billing Profile = VISA 16.CP {15} ADD VoIP Service Plan ID (1) Service Usage Start Date = 46

47 # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type Bundle Remarks Null Cycle Start Date = Null Purchase Date = Null Service ID = * 17.. SP {16} ADD VoIP Basic MRC $15 ID (1) Product Usage Start Date = Null 18..SP{16} ADD 19..SP{16} ADD VoIP Voic VoIP Caller ID Cycle Start Date = Null Purchase Date = Null MRC $0.00 ID (1) Product Usage Start Date = Null MRC $ SP { 15} ADD VoIP Adaptor OTC $45.00 ID (1) Product 21. SP {15} ADD VoIP Phone OTC $50.00 ID (1) Product 22 SP {} ADD High Speed Internet First Month Free Discount 23 SP {} ADD High Speed Internet Activation Discount Cycle Start Date = Null Purchase Date = Null ID (1) Product Usage Start Date = Null Cycle Start Date = Null Purchase Date = Null MRC 100% ID (1) Discount Billing Profile = VISA OTC 100% ID (1) Discount Billing Profile = VISA 24 SP {} ADD VoIP Recurring Discount MRC $10.00 ID (1) Discount Billing Profile = VISA 25 SP {} ADD VoIP First Month Free Discount MRC 100% ID (1) Discount Billing Profile = VISA 47

48 First Time Purchase Double Play Fulfillment Flow This diagram shows the order decomposition and Orchestration Plan that the Management system will generate: Provision [DSL] Internet Service (A) Ship [InHouse] Dynex Modem (A) FulfillBilling (BRM-REZBDB) SyncCustomer [BRM-REZBDB] On Top of The World Broadband- VoIP (A) High Speed Internet Service (A) Internet Service (A) High Speed Internet Basic (A) Internet Secure Firewall (A) Internet (A) Internet (A) Internet Media (A) Internet Content on Demand (A) Internet Video on Demand (A) Dynex Modem (A) Wireless Router (A) High Speed Internet Installation (A) High Speed Internet Activation (A) High Speed Internet First Month Free Discount (A) High Speed Internet Activation Discount (A) High Speed Internet Basic (A) Internet Secure Firewall (A) Internet (A) Internet (A) Internet Media (A) Internet Content on Demand (A) Internet Video on Demand (A) Dynex Modem (A) Wireless Router (A) InitiateBilling [BRM-REZBDB] On Top of The World Broadband-VoIP (A) Wireless Router (A) Install [All] High Speed Internet Installation (A) Dynex Modem (A) Wireless Router (A) High Speed Internet Installation (A) Internet Service (A) High Speed Internet Basic (A) Internet Secure Firewall (A) Internet (A) Internet (A) Internet Media (A) Internet Content on Demand (A) Internet Video on Demand (A) High Speed Internet Activation (A) On Top of the World Broadband-VoIP (A) High Speed Internet First Month Free Discount (A) High Speed Internet Activation Discount (A) High Speed Internet Service (A) FulfillBilling (BRM-VoIP) SyncCustomer [BRM-VOIP] On Top of The World Broadband- VoIP (A) VoIP Service (A) VoIP Service Plan (A) VoIP Basic (A) VoIP Voic (A) VoIP Caller ID (A) VoIP Adaptor (A) VoIP Phone (A) VoIP First Month Fee Discount (A) InitiateBilling [BRM-VOIP] On Top of The World Broadband-VoIP (A) VoIP Service Plan (A) VoIP Basic (A) VoIP Voic (A) VoIP Caller ID (A) Provision [VOIP] VoIP Service Plan (A) VoIP Basic (A) VoIP Voic (A) VoIP Caller ID (A) VoIP Adaptor (A) VoIP Phone (A) Ship [PartnerInc] VoIP Adapter (A) VoIP Phone (A) On Top of The World Broadband-VoIP (A) VoIP Recurring Discount (A) VoIP First Month Fee Discount (A) VoIP Service (A) VoIP Adaptor (A) VoIP Phone (A) VoIP Service Plan (A) VoIP Basic (A) VoIP Voic (A) VoIP Caller ID (A) 48

49 Describing the First Time Purchase Double Play Fulfillment Flow Each box represents an activity (fulfillment function) within the fulfillment flow. The first bold underlined line in each box indicates the name of the activity. The activity name is followed by the name of the target fulfillment provider enclosed in square brackets. Note that, in the last column, the large number of order components leaves little room for repeating the activity name as the first line for each activity; instead, it appears once, at the top and outside of each group of activity boxes with the same target. Lines within each order component represent order lines with action code abbreviation between parentheses at the end of each line as follows: A for ADD, D for Delete, U for UPDATE, E for EXISTING (i.e. no action required). The arrows represent a dependency for the start and end of the activities. Dependencies are established at the Line level. For readability purposes, the flowchart combines all dependencies between two order components into a single arrow. For the exact dependencies, please review the fulfillment flow definition. These considerations apply to this scenario: Broadband and VoIP services are sent separately to Provision because they go to different provisioning instances. VoIP services have a dependency on InitiateBilling of VoIP services and Provision of Broadband services. Notice that technical dependency is managed in fulfillment when the dependency spans different fulfillment providers. FulfillBilling processing granularity is set to Service Bundle, which means that an order will be interfaced into Billing one Service Bundle at a time. Note that, despite processing granularity, only relevant order lines are sent to the target fulfillment provider. SyncCustomer takes all line items. InitiateBilling takes only VoIP service-based order lines and Commercial Offer order lines. Provision does not take billing only line items, but it takes everything else in the domain of the target provisioning provider. The On Top of the World Broadband-VoIP commercial offer is applicable to both billing systems, and it is assumed to be defined in both. 49

50 Double Play Change Sales 10030: Customer wants to change internet access from Basic to Premium, and VoIP from Basic to VoIP with unlimited calls, CSR places the following change order: # Siebel Object {parent line #} 1 Bundled Promotion {} Action Name Price Type List Price Prom -- On Top of the World Broadband-VoIP Offer ID Subject Type 2 CP {} -- High Speed Internet Service ID (1) Bundle 3 CP {2} -- Internet Service ID (1) Service Bundle 4.SP {3} DELETE High Speed Internet Basic MRC $15 ID (1) Product 5.SP{3} ADD Premium High Speed Internet MRC $25 ID (1) Product 6.SP {3} -- Internet Secure Firewall MRC $0 ID (1) Product 7.CP {3} -- Internet ID (1) Service Bundle 8.SP {7} -- Internet MRC $0 ID (1) Product 9.CP {3} -- Internet Media ID (1) Service Bundle 10..SP {9} -- Internet Content on Demand MRC $0 ID (1) Product 11..SP {9} -- Internet Video on Demand MRC $0 ID (1) Product 12.SP {2} -- Dynex Modem OTC $0 ID (1) Product 13.SP {2} -- Wireless Router OTC $75 ID (1) Product 14.SP {2} -- High Speed Internet Installation OTC $0 ID (1) Product 15.SP {2} -- High Speed Internet Activation OTC $30 ID (1) Product 16 CP {} -- VoIP Service ID (1) Bundle 17.CP {16} -- VoIP Service Plan ID (1) Service Bundle 18.. SP {17} DELETE VoIP Basic MRC $15 ID (1) Product 19.. SP {17} ADD VoIP w/ unlimited calls MRC $60 ID (1) Product 20..SP{17} -- VoIP Voic MRC $0.00 ID (1) Product Remarks 50

51 # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type 21..SP{17} -- VoIP Caller ID MRC $0.00 ID (1) Product 22.SP {16} -- VoIP Adaptor OTC $45.00 ID (1) Product 23. SP {16} -- VoIP Phone OTC $50.00 ID (1) Product 24 SP {} -- High Speed Internet First Month Free Discount MRC 100% ID (1) Discount 25 SP {} -- High Speed Internet Activation Discount OTC 100% ID (1) Discount 26 SP {} -- VoIP Recurring Discount MRC $10.00 ID (1) Discount 27 SP {} -- VoIP First Month Free Discount MRC 100% ID (1) Discount Remarks 51

52 Change Fulfillment Flow The following diagram shows the order decomposition and Orchestration Plan that the Management system will generate: 52

53 Describing the Change Fulfillment Flow Each box represents an activity (fulfillment function) within the fulfillment flow. The first bold underlined line in each box indicates the name of the activity. The activity name is followed by the name of the target fulfillment provider enclosed in square brackets. Note that, in the last column, the large number of order components leaves little room for repeating the activity name as the first line for each activity; instead, it appears once, at the top and outside of each group of activity boxes with the same target. Lines within each order component represent order lines with action code abbreviation between parentheses at the end of each line as follows: A for ADD, D for Delete, U for UPDATE, E for EXISTING (i.e. no action required). The arrows represent a dependency for starting the activity and ending the activity. Dependencies are established at the Line level. For readability purposes, this flowchart combines all dependencies between two order components into a single arrow. For the exact dependencies, please review the fulfillment flow definition. These considerations apply to this scenario: Broadband and VoIP services are sent separately to Provision because they go to different provisioning instances. VoIP services have a dependency on InitiateBilling of VoIP services and Provision of Broadband services. Note that technical dependency is managed in fulfillment when the dependency spans different fulfillment providers. FulfillBilling processing granularity is set to Service Bundle, which means that an order will be interfaced to Billing one Service Bundle at a time. Note that, despite processing granularity, only relevant order lines are sent to the target fulfillment provider. SyncCustomer takes all line items. InitiateBilling takes only VoIP service-based order lines. Provision does not take billing only line items, but it takes everything else in the domain of the target provisioning instance. No components exist for install and ship orders because no equipment is required to ship or install for this change order scenario. 53

54 Double Play Revision Customer calls on day following placing change order 10030, the customer calls with a change. Customer wants to add the optional VoIP Laptop Phone product. The CSR creates the following revision order R4: # Siebel Object {parent line #} 1 Bundled Promotion {} Action Name Price Type List Price Prom -- On Top of the World Broadband-VoIP Offer ID Subject Type 2 CP {} -- High Speed Internet Service ID (1) Bundle 3 CP {} -- Internet Service ID (1) Service Bundle 4.SP {3} DELETE High Speed Internet Basic MRC $15 ID (1) Product 5.SP{3} ADD Premium High Speed Internet MRC $25 ID (1) Product 6.SP {3} -- Internet Secure Firewall MRC $0 ID (1) Product 7.CP {3} -- Internet ID (1) Service Bundle 8.SP {7} -- Internet MRC $0 ID (1) Product 9.CP {3} -- Internet Media ID (1) Service Bundle 10..SP {9} -- Internet Content on Demand MRC $0 ID (1) Product 11..SP {9} -- Internet Video on Demand MRC $0 ID (1) Product 12.SP {2} -- Dynex Modem OTC $0 ID (1) Product 13.SP {2} -- Wireless Router OTC $75 ID (1) Product 14.SP {2} -- High Speed Internet Installation OTC $0 ID (1) Product 15.SP {2} -- High Speed Internet Activation OTC $30 ID (1) Product 16 CP {} -- VoIP Service ID (1) Bundle 17.CP {16} -- VoIP Service Plan ID (1) Service Bundle 18.. SP {17} DELETE VoIP Basic MRC $15 ID (1) Product 19.. SP {17} ADD VoIP w/ unlimited calls MRC $60 ID (1) Product 20..SP{17} -- VoIP Voic MRC $0.00 ID (1) Product Remarks 54

55 # Siebel Object {parent line #} Action Name Price Type List Price Prom ID Subject Type 21..SP{17} -- VoIP Caller ID MRC $0.00 ID (1) Product 22.SP {16} -- VoIP Adaptor OTC $45.00 ID (1) Product 23. SP {16} -- VoIP Phone OTC $50.00 ID (1) Product 24. SP {16} ADD VoIP Laptop Phone OTC $50.00 ID (1) Product 25 SP {} -- High Speed Internet First Month Free Discount MRC 100% ID (1) Discount 26 SP {} -- High Speed Internet Activation Discount OTC 100% ID (1) Discount 27 SP {} -- VoIP Recurring Discount MRC $10.00 ID (1) Discount 28 SP {} -- VoIP First Month Free Discount MRC 100% ID (1) Discount Remarks These considerations apply to this Revision R4 scenario: This revision incurs no additional charge, R4 is the first revision submitted, and change order was in-flight and did not reach the hard PONR. The CSR starts with 10030, and then selects the Revise action and ADD new line item VoIP Laptop Phone on VoIP Service Plan. 55

56 The following chart shows the change order fulfillment plan along with an overlay of immediate revision 4 effects: 56

57 Describing the Double Play Revision Flow Each box represents an activity (fulfillment function) within the fulfillment flow. The first bold underlined line in each box indicates the name of the activity. The activity name is followed by the name of the target fulfillment provider enclosed in square brackets. Note that, in the last column, the large number of order components leaves little room for repeating the activity name as the first line for each activity; instead, it appears once, at the top and outside of each group of activity boxes with the same target. Lines within each order component represent order lines with action code abbreviation between parentheses at the end of each line as follows: A for ADD, D for Delete, U for UPDATE, E for EXISTING (i.e. no action required). The arrows represent a dependency for starting the activity and ending the activity. Dependencies are established at the Line level. For readability purposes, the previous flowchart combines all dependencies between two order components into a single arrow. For the exact dependencies, please review the fulfillment flow definition. A light blue flag and the text Revision Received identifies the time that a revision order was received. The part of the fulfillment plan executed until revision cutoff is highlighted with a dashed red line and a flag on the same side as the Base Cut Off text. Two vertical pattern ( ) stripes create an envelope for this section. The balance of the base order fulfillment plan that would be cut off is dimmed and turned into light gray background. Two X pattern stripes create an envelope for this part of the flow. 57

58 Revision Fulfillment Flow The following diagram represents the order decomposition and orchestration plan that the Management system will generate. Note: The following plan is different from others in that it overlays the revision plan over the base order fulfillment plan not affected by the revision. This diagram shows the dependencies of a revision order plan on base order milestones. 58

59 Describing the Revision Fulfillment Flow Each box represents an activity (fulfillment function) within the fulfillment flow. The first bold underlined line in each box indicates the name of the activity. The activity name is followed by the name of the target fulfillment provider enclosed in square brackets. Note that, in the last column, the large number of order components leaves little room for repeating the activity name as the first line for each activity; instead, it appears once, at the top and outside of each group of activity boxes with the same target. Lines within each order component represent order lines with action code abbreviation between parentheses at the end of each line as follows: A for ADD, D for Delete, U for UPDATE, E for EXISTING (i.e. no action required). The arrows represent a dependency for starting the activity and ending the activity. Dependencies are established at the Line level. For readability purposes, the previous flowchart combines all dependencies between two order components into a single arrow. For the exact dependencies, please review the fulfillment flow definition. The revision order plan is divided into two parts: a compensation part for deltas between already executed fulfillment steps for the base order and required fulfillment steps for the revision order; and a part for the balance of the plan to complete fulfillment of the revision. The compensation part of the fulfillment plan is highlighted with a dashed purple line and a flag on the same side as the Compensation text. Two forward slash (///) pattern stripes create an envelope for this part. The balance fulfillment plan is shown on the opposite side of the compensation plan; it has two vertical line ( ) pattern stripes that create an envelope for this part. These considerations apply to this scenario: The revision was received while the VoIP order component was still in provisioning; therefore, the compensation sends the revised order component to provisioning because provisioning is assumed to be capable of computing its compensation. VoIP Laptop Phone (Software CD) will be shipped to the customer location through the ship order component. 59

60 Communications s Dictionary The following tables provide a snapshot of the Communications s Dictionary at the time this white paper was created. Communications s include EBOs and Sales, Fulfillment, and Provisioning. We refer to any of the three orders using the token <Comms>. To understand the following tables, you must be familiar with these terms: Assetable This term indicates if an attribute value is saved on the corresponding asset in Siebel. Prior Value This term indicates if, when the attribute changes, a prior value is also sent on the order message. Prior Values sometimes are used to determine if a change occurred and sometimes used to roll back changes. Communications s - Header Component Attributes Functiona l Attribute Name Attribute Usage (Semantics) Seeded Values Ass et able Prior Value Available Remarks ID Uniquely identifies each order. NA No None Produces a unique identifier for all orders, including revision orders. Unlike Number, ID is different for revisions of the same base order. Used by AIA for cross-reference. EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning SaleEBO/Identification/BusinessCompon entid 60

61 Functiona l Attribute Name Number Revision Success Dependen cy Attribute Usage (Semantics) Identifies an order across revisions. A revision sequence number that, together with the order number, represents the user key to an order. Declares if all order lines must fulfill successfully or else the whole order fails (all or none). When the order level Success Dependency is set to All or None, it takes precedence over Line Success Dependency designations because it is more restrictive. Seeded Values Ass et able Prior Value Available Remarks NA No None A revision number >1 doesn't necessarily mean that this is a revision order from OM Fulfillment. You can create an order in Siebel and revise it several times before submitting it. If an Number matches an already in-flight order, then the order is treated as a revision order. When an order is revised, this number stays the same. OM uses this number to identify the base order. If the same order number with the same revision is submitted, then OM would reject the revision order and place it in fallout. NA No None If an order is received with an Number equal to that of an in-flight order and the newly received order has a higher revision number, then OM assumes the order is a revision order and proceeds to analyze the Lines. If the revision number is equal or lower than that of the base order, the revision is rejected. DEFAULT, ALL OR NONE EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning <Comms>EBO/Identification/ID <Comms>EBO/Identification/Revision/Nu mber No None <Comms>EBO/PartialFulfillmentAllowedI ndicator 61

62 Functiona l Attribute Name Fulfillment Mode Attribute Usage (Semantics) Qualifies the nature of orchestration required for submission of a particular sales order. * Get Provider supports the Get Target Fulfillment Provider through Management for use outside Management. * Cancel is a special case used when a revision intends to cancel an entire order. Seeded Values DELIVER, CANCEL, INITIATE BILLING, FULFILL BILLING, GET PROVIDER Ass et able Prior Value Available Remarks No None CSPs may extend support to other modes, such as Qualify for TSQ. Oracle is planning TSQ support part of a future release. Siebel is providing a mechanism to create a revision order to cancel an entire order by sending a revision with Fulfillment Mode = Cancel. OM is expected to honor this mechanism, along with the scenario, when a revision is submitted with no line items or when all line items have no actions. EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning <Comms>EBO/FulfillmentModeCode Customer Class Organizati on ID Sales Channel Job ID Sequence in Job Job Type Job Cardinality This attribute is also used for Billing EBMs to determine the type of Billing request: Initiate or Fulfill. Identifies type of customer: RESIDENTIAL No None <Comms>EBO/CustomerPartyReference Residential, Business, and so on BUSINESS /CustomerPartyAccountTypeCode Identifies the organization/lob NA No None No cross-reference.om should <Comms>EBO/BusinessUnitReference/ generating the order. No crossreference use the application-specific ID if BusinessUnitIdentification/ID exists. needed in any of the rules. Identifies the sales channel. NA No None <Comms>EBO/SalesChannelCode A string or number that uniquely identifies the job to orchestration. A number that identifies the order sequence within the job. Identifies the type of job. This information identifies the threshold for creating a consolidated SR for Bulk or Batch s. This value is optional for orders whose Job Cardinality is 1. By default, this value is HETROGENEOUS. Indicates the total number of orders within the job. NA No None Track orders that belong to a bulk or batch job. NA No None Siebel is not providing a value in 2.4. HETEROGEN No None Siebel is not providing a value in EOUS,HOMO 2.4. GENEOUS, 3RD PARTY HOMOGENE OUS, 3RD PARTY HETEROGEN EOUS, CORRELATE D NA No None Siebel is not providing a value in 2.4. <Comms>EBO/ProcessingNumber <Comms>EBO/ProcessingSequenceNu mber <Comms>EBO/ProcessingTypeCode <Comms>EBO/ProcessingQuantity 62

63 Functiona l Attribute Name Parent ID Fulfillment Priority Type Requested Delivery Date Status Attribute Usage (Semantics) ID of another order that indicates the fulfillment for this order will not start before the parent order fulfillment completes. Indicates relevant priority of order fulfillment across orders. A lower value indicates a higher priority. Accepts values 0 to 9 in accordance with JMS Queue support. Sometimes indirectly determines sales channel to drive compensation process. Overall order level due date that provides the default due date at each line level. Can be overridden at each line. Reports aggregate order fulfillment status. Seeded Values Ass et able Prior Value Available Remarks NA No None This attribute applies to explicit order-to-order dependencies and is not limited to follow-on orders. For example, in a B2B scenario, a large order can be divided into a number of smaller orders, with one order acting as the root order for all other orders and the remainder of the orders chained using the parent order ID attribute. 0,3,5,7 No None EBM value: Siebel value 0: Urgent. Used for expedited orders. 3: High. CSP determines its use. 5: Medium. CSP determines its use. 7: Low. Recommended for job orders. SALES ORDER EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning <Comms>EBO/Parent<Comms>R eference/<comms>identification/busines scomponentid <Comms>EBO/FulfillmentPriorityCode No None <Comms>EBO/TypeCode NA Yes None <Comms>EBO/RequestedDeliveryDateT ime (Canonical / Siebel): (OPEN / Open), (IN PROGRESS / In Progress), (FAILED / Failed), (CANCELLED / Cancelled), (COMPLETE / Complete) Yes None <Comms>EBO/Status/Code 63

64 Functiona l Attribute Name Status Context Owner Account ID Owner Account Name Owner Account Number Account Contact ID Account Contact Address (compone nt) Project ID Attribute Usage (Semantics) Provides details about the current status. The implementer configures this value. Seeded Values Ass et able Prior Value Available Remarks NA Yes None OM can used this to track the milestone causing the status change along with context details such as error message, cause for cancel, etc. One primary scenario that the Header / Status Context is populated: with revision orders that cancels Lines by dropping them from the revision and if the revision is rejected. In that case the orchestration system doesn t have a line on the revision order to provide fallout status and context for and the header level status context is used to indicate the base line the cause for the fallout. EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning <Comms>EBO/Status/Description Identifies the owner account. NA Yes None Cross-referenced. <Comms>EBO/CustomerPartyReference /CustomerPartyAccountIdentification/Business ComponentID Identifies the Account Name. You can enter or derive this value from contact first name + last name of primary contact associated with the account. Identifies account number to customer. Foreign key to contact record that holds personal and contact details of the customer/company representative who is placing the order and is the contact person for anything related to the order process. Identifies the address used to communicate with the Contact ID. Identifies project record if the order to be delivered is part of a project that contains related orders. Foreign key reference. No cross-reference. NA Yes None Required for network inventory tracking of service owner. <Comms>EBO/CustomerPartyReference /CustomerPartyAccountName NA Yes None <Comms>EBO/CustomerPartyReference /CustomerPartyAccountIdentification/ID NA Yes None <Comms>EBO/CustomerPartyReference /CustomerPartyAccountContactIdentification/B usinesscomponentid NA Yes None <Comms>EBO/CustomerPartyReference /CustomerPartyAccountContactAddressComm unication/addresscommunication/address NA Yes None No cross-reference for 2.4. <Comms>EBO/ProjectReference/Project Identfication/ID 64

65 Functiona l Attribute Name Fulfillment System Type Target Instance Changed Indicator Sales Represent ative ID Owner Account Contact (multiple fields) Attribute Usage (Semantics) For the Get Target Fulfillment Provider utility service, determines the logical identifier for appropriate target system instance among those serving this Fulfillment System Type. For the Get Target Fulfillment Provider utility service returns the logical identifier for appropriate target system instance among those serving this Fulfillment System Type. OM sets this attribute to Yes if the order changed significantly such that CRM should make a copy of the customer order to preserve the customer intent before updating the working version of the order. CRM User ID that identifies the sales representative who entered the order. Identifies if the address is used to communicate with the contact ID. Includes these fields: First Name, Last Name, Phone Number, and . Seeded Values Ass et able Prior Value Available Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA No None FulfillmentEBO/FulfillmentSystemTypeCo de NA No None FulfillmentEBO/FulfillmentTargetSystemI D TRUE, FALSE No None Allows Siebel to make a copy of the order if the order changed to the extent that the customer s intent is compromised. NA No None No cross-reference. Use the application ID. <Comms>EBO/ChangedIndicator <Comms>EBO/SalespersonPartyRefere nce/partyidentification/id NA No None <Comms>EBO/CustomerPartyReference /CustomerPartyAccountContact/FirstName <Comms>EBO/CustomerPartyReference /CustomerPartyAccountContact/LastName <Comms>EBO/CustomerPartyReference /CustomerPartyAccountContactPhoneCommu nication/phonecommunication/completenumb er <Comms>EBO/CustomerPartyReference /CustomerPartyAccountContact Communi cation/ communication/ 65

66 Communications s - Line Component Attributes Functional Attribute Name Line ID Base Line ID Asset Integration ID Line Number Parent Line Root Line Related Line ID Attribute Usage (Semantics) Uniquely identifies the order line item across orders and order revisions. Automatically generated. References base order line revised by this order line. Uniquely identifies an instance of a product that was or is being purchased. Identifies the line with respect to its position in the line item tree. References parent order line in the line items tree instantiated as per the product model definition. Points to itself if the item does not have an associated parent item. References the root order line in the line item tree instantiated as per the product model definition. Points to itself if the item is a root item itself. Links one-time charges to Suspend/Resume order lines. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks NA No None Cross-referenced. Produces a unique identifier for all Lines, including revision Lines. EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning <Comms>EBO/<Comms>Line/Identific ation/businesscomponentid NA No None Uses a cross-reference. <Comms>EBO/<Comms>Line/Original <Comms>LineReference/<Comms>Li neidentification/businesscomponentid NA Yes AIA2.0 Cross-referenced Assumption: The Asset Integration ID will continue to be populated on all Lines, regardless of the Assetable state on the subject of the Line or whether the Line is for a new or existing service. A revision should never change the Asset Integration ID. When a product is dropped as part of one product hierarchy (CP or Promotion) and then added through another product hierarchy (CP or promotion), the Asset Integration ID for the two line items is different, although for the same product. NA No None Line number establishes the parent child relationship between Lines of the same order, but it may vary across revisions. Therefore, do not rely on it for matching Lines across revisions. <Comms>Line/InstalledProductReference/In stalledproductidentification/businesscomponenti D <Comms>EBO/<Comms>Line/Identific ation/id NA No None <Comms>EBO/<Comms>Line/Parent <Comms>LineIdentification/BusinessCompo nentid NA No None <Comms>EBO/<Comms>Line/RootPa rent<comms>lineidentification/businessco mponentid NA No None <Comms>EBO/<Comms>Line/Related <Comms>LineIdentification/BusinessCompo nentid 66

67 Functional Attribute Name Charge Parent Line ID Related Asset Integration ID Depends On Line ID Depends On ID Promotion Line ID Promotion Asset Integration ID Product ID Quantity Action Code Attribute Usage (Semantics) BRM adaptors use to relate onetime charges to base line ID. Links Move-Add to Move-Delete line items. Indicates order line item ID of a previous order line item that is changed by this order. Follow-on orders use this value to capture dependencies of the order line items in the follow-on order-toorder line items of original orders. Identifies order ID of an in-flight order, which is the basis for this follow-on order line item. References an order line that represents the promotion/marketing offer under which the order line is being purchased. References an asset that represents the promotion/marketing offer under which the order line is being purchased. References product record based on which order line is instantiated. Foreign key reference. Identifies the quantity of the item requested by a customer. Default is 1. Specify action required to meet customer request Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA No None <Comms>EBO/<Comms>Line/Charge ParentLineIdentification/BusinessComponentID NA No None <Comms>EBO/<Comms>Line/Installe dproductreference/priorinstalledproductidentifica tion/businesscomponentid NA No None Cross-referenced. <Comms>EBO/<Comms>Line/Depend ing<comms>linereference/<comms >LineIdentification/BusinessComponentID NA No None Cross-referenced. <Comms>EBO/<Comms>Line/Depend ing<comms>reference/<comms>ide ntification/businesscomponentid NA No AIA2.0 <Comms>EBO/<Comms>Line/Promoti on<comms>linereference/promotion<com ms>lineidentification/identification/business ComponentID NA Yes AIA2.0 <Comms>EBO/<Comms>Line/Promoti on<comms>linereference/installedproduct Reference/InstalledProductIdentification/Business ComponentID NA Yes None <Comms>EBO/<Comms>Line/ItemRef erence/identification/businesscomponentid NA Yes AIA2.4 <Comms>EBO/<Comms>Line/Q uantity NONE,ADD,UP DATE,SUSPEN D,RESUME,DE LETE,MOVE- ADD,MOVE- DELETE No None <Comms>EBO/<Comms>Line/Service ActionCode 67

68 Functional Attribute Name Requested Delivery Date Deliver To Address Usage Start Date Cycle State Date Purchase Date Service Start Date Earliest Delivery Date Attribute Usage (Semantics) When Null, the requested date for delivery of the goods or service is ASAP; otherwise, it is the specified date. This date is not guaranteed. Typically, it is a future date; if it is a past date, then the default behavior is the same as a Null value. Address record that represents the delivery/service installation address. Determines the date when usage events should start being rated. The value for this attribute is populated by CRM, OM Fulfillment flows, or kept to Null for BRM default to the current date. Determines the date when cycle charges should start being billed. The value for this attribute is populated by CRM, OM Fulfillment flows, or kept to Null for BRM default to the current date as per previous patterns. Determines the date when onetime purchase charges should be billed. The value for this attribute is populated by CRM, OM Fulfillment flows, or kept to Null for BRM default to current date as per above patterns. Indicates effective start date of service. Identifies the date when the work associated to the order provision can start. If a client goes on vacation and needs to be at his premises for the service to be installed, then the start date can be set to a later date. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<Com ms>schedule/requesteddeliverydatetime NA Yes AIA2.4 <Comms>EBO/<Comms>Line/Service Address/Address NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<Com ms>schedule/serviceusagestartdate NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<Com ms>schedule/cyclestartdate NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<Com ms>schedule/purchasedate NA Yes None Initially computed by Siebel based on Due Date and then updated by Management based on Actual Delivery Date. Siebel support is planned for a future release. <Comms>EBO/<Comms>Line/Effectiv etimeperiod/startdatetime NA No None <Comms>EBO/<Comms>Line/<Com ms>schedule/earliestdeliverydatetime 68

69 Functional Attribute Name Service End Date Actual Delivery Date Expected Delivery Date Status Attribute Usage (Semantics) Indicates the effective end date of service. Applies to services with a specified duration. Determines the date when the purchased product or service is considered available to the customer by the CSP. This date may be when physical goods are shipped, delivered, or their receipt is acknowledged. For servicebased products, the service is activated on this date. This date is computed in the OM Fulfillment flow as per previous patterns. Indicates the due date expected by the system as a result of Design and Assign. The default is the Due Date when the order is created by CRM. Updates orchestration and CRM as to the current status of order line fulfillment at a high level. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks NA Yes None Initially computed in Siebel and then updated by Management. Update is sent to Siebel. Siebel support is planned for a future release. NA Yes None BRM does not allow for starting any charges before the Purchase Date; therefore, the ABCS for BRM will always override the Purchase Date if it is later than any of the Cycle or Usage start dates. OM should facilitate calculation of Line level Actual Delivery Date as well as Line attributes for billing Usage Start Date, Cycle Start Date, and Purchase Date. NA No None Computed by OM based on preconfigured time estimates on fulfillment actions. Used by OM to communicate to CRM changes to expected delivery date of specific Lines. In addition to statuses used during Capture: (Canonical / Siebel): (OPEN / Open), ( IN PROGRESS/ In Progress), (FAILED / Failed), (CANCELLED / Cancelled ), (COMPLETE / Complete) Yes None At the time CRM submits an order, the Line status is set to Open. An order will always be accepted; guaranteed delivery is mandatory, therefore, no need to track. After orchestration starts, OM updates CRM Status to In Progress and it stays so until one of the following conditions occurs: Fulfillment is failed due to a given condition, such as insufficient data, administrative intervention, and so on. Status is updated to Failed with a Status Context indicating the milestone and context. is cancelled either through revision or administrative intervention, and Status is updated to Canceled with a Status Context indicating the milestone and context. Fulfillment of Line and all of its children are complete. Status is updated to Complete. EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning <Comms>EBO/<Comms>Line/Effectiv etimeperiod/enddatetime <Comms>EBO/<Comms>Line/<Com ms>schedule/actualdeliverydatetime <Comms>EBO/<Comms>Line/<Com ms>schedule/expecteddeliverydate <Comms>EBO/<Comms>Line/Status/ Code 69

70 Functional Attribute Name Milestone Status Context Attribute Usage (Semantics) Fulfillment passes the last reached milestone into this field. Provides details about the current status of the order line. The implementer configures this value. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA No None <Comms>/<Comms>Line/MilestoneCo de NA Yes None OM could include the reached <Comms>EBO/<Comms>Line/Status/ milestone (from the fulfillment system, Description the cause for the status update that is necessary because of dynamic nature of fulfillment plan) and a textual string for context per current status as follows (canonical Status / status context): Submitted / NA In Progress / <milestone>: context text Failed / <milestone>: reason text Cancelled / <milestone>: reason text Complete / NA Point-of-noreturn Billing Account Billing Profile Payment Profile Determines if Siebel should allow order line revisions to be submitted. References an account record that represents the bill payer or the branch of a company responsible for bill payment. This value may be a customer account or an account from the account hierarchy. References the billing profile record that holds the customer s billing/payment preferences. This value may be associated to the customer account or to a separate billing account. NOT YET, HARD In Progress: Context Text could be used to indicate any of the following among others: Requires customer interaction Delivery is expected to be delayed No None OM Fulfillment flows allow configuration of setting a hard PONR when a condition is met for a particular service. When a hard PONR is reached for an Line in OM, a status update is issued to reflect the same in CRM. <Comms>EBO/<Comms>Line/Revisio npermissiblecode NA Yes AIA2.0 <Comms>EBO/<Comms>Line/<Com ms>schedule/billtopartyreference/custom erpartyaccountidentification/businesscomponenti D NA Yes AIA2.0 <Comms>EBO/<Comms>Line/<Com ms>schedule/billtopartyreference/billingpr ofilereference/billingprofileidentification/business ComponentID Identifies the Payment Profile. NA No None <Comms>EBO/<Comms>Line/<Com ms>schedule/billtopartyreference/billingpr ofilereference/paymentprofilereference/payment ProfileIdentification/BusinessComponentID 70

71 Functional Attribute Name Service Account Owner Contact Shipping Contact Node To Node Network ID Port Number To Port Number Attribute Usage (Semantics) References an account record that represents a service user or the branch of the company where service is installed. This value may be customer account or an account from the account hierarchy. Represents a contact of the customer account or service account who should be contacted during fulfillment of the line if required. Represents a contact of the customer account or service account who should be contacted for shipping purposes. Alphanumerically references the root order line that corresponds to access at site A of a connection. This value is relevant for network ordering only. Alphanumerically references the root order line that corresponds to access at site B of a connection. This value is relevant for network ordering only. Unique compound product number that represents the virtual network ID. Relevant for network orders. Provided by default from the order number and cascaded to network connection items. Identifies the port number allocated to the access circuit connected to provide (starting) edge router during the fulfillment process. Identifies the port number allocated to the access circuit connected to provide (ending) edge router during the fulfillment process. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA Yes AIA2.0 <Comms>EBO/<Comms>Line/<Com ms>schedule/ownerpartyreference/custo merpartyaccountidentification/businesscompone ntid NA Yes None <Comms>EBO/<Comms>Line/<Com ms>schedule/ownerpartyreference/custo merpartyaccountcontactidentification/businessco mponentid NA Yes None <Comms>EBO/<Comms>Line/<Com ms>schedule/shiptopartyreference/custo merpartyaccountcontactidentification/businessco mponentid NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="node "]/ValueText NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="tono de"]/valuetext NA Yes AIA2.4 Identifies which Access and Nodes belong to the same network. This information may be of value to decomposition. NA Yes AIA2.4 For new services, port number comes back from Network Inventory through provisioning. <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="netw orkid"]/valuetext <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="portn umber"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="topo rtnumber"]/valuetext 71

72 Functional Attribute Name Service Address Prefix To Service Address Prefix Access Circuit To Access Circuit To Service Account ID From Service Address ID To Service Address ID To Service Point ID Service Point Promotion Description Attribute Usage (Semantics) Identifies the area code/npa for the access circuits on starting or two ends of the connection. Identifies the area code/npa for the access circuits on the end of the connection. Provides the Common Language Location Identification (CLLI) for the access circuit on two sides or starting side of the connection. Provides the CLLI for the access circuit on ending side of the connection. Identifies the Service Account ID associated with the end side of a network. Identifies the Service Address ID for the starting point of a network. Identifies the Service Address ID for the ending point of a network. References a dummy asset record that represents the access point to which the starting side of a network service will be connected on the customer s premises. References a dummy asset record that represents the access point to which this service will be connected on the customer s premises. For example, NTE for PSTN, Set top box for Broadband/Cable service. Provides short description that will appear on the invoice. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="servi ceaddressprefix"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="toser viceaddressprefix"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="acces scircuit"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="toac cesscircuit"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="toser viceaccountid"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="from ServiceAddressID"]/ValueText NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="toser viceaddressid"]/valuetext NA Yes AIA2.4 <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="toser vicepointid"]/valuetext NA Yes AIA2.4 Expected to be mastered in network inventory and loaded in Siebel in batch. <Comms>EBO/<Comms>Line/Service PointCode NA Yes AIA2.4 <Comms>EBO/<Comms>Line/ItemRef erence/description This is Promotion Description used for display purposes on customer invoice 72

73 Functional Attribute Name Service ID Attribute Usage (Semantics) Identifies the product/service instance allocated by the fulfillment (network service, physical item, and so on) system during the fulfillment process. Updates Seibel as part of the order updates received from the fulfillment system during the order fulfillment journey. Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning NA Yes AIA2.0 <Comms>EBO/<Comms>Line/<Com ms>schedule/<comms>iteminstance/i dentification/id Balance Bundle Identificatio n Line Description Service Length Service Length Unit of Measure Fulfillment Mode Product Name Supplied later for other order types (action code other than Add) as input to the fulfillment process. Identifies the Balance Bundle to which a service instance belongs. Provides additional description for an order line. For example, to indicate that a charge is being applied for a penalty. Indicates requested service length in Service Length Unit of Measure. Indicates the service length unit of measure. Designates compensation operations for Initiate Billing. May be used in the future to provide explicit revision operations at the line level. NA Not Used by AIA for Communications 2.0 or 2.4. NA No None Not used by AIA for Communications 2.0 or 2.4. <Comms>EBO/<Comms>Line/<Com ms>schedule/balancebundleidentification/b usinesscomponentid <Comms>EBO/<Comms>Line/Descrip tion NA Yes Yes <Comms>EBO/<Comms>Line/<Com ms>schedule/servicetimeperiod/duration NA Yes Yes <Comms>EBO/<Comms>Line/<Com ms>schedule/servicetimeperiod/duration DO, NOOP, REDO, UNDO No None <Comms>EBO/<Comms>Line/Fulfillm entmodecode Provides the name of the product. NA <Comms>EBO/<Comms>Line/ItemRef erence/name 73

74 Functional Attribute Name Compositio n Type Attribute Usage (Semantics) Determines product composition granularity: PartialItem is an order line that constitutes an indivisible element of another order line. This type typically denotes a piece of a product. Seeded Values and Value Type <no value> for NULL, PARTIAL ITEM, WHOLE ITEM Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning No None Consult Oracle on usage. <Comms>EBO/<Comms>Line/ItemRef erence/fulfillmentcompositiontypecode WholeItem is an order line that represents a self-contained subject. A WholeItem may be represented by a single line item or a number of PartialItem order lines. Product Type Billing Type Billing Service Type Service Flag Vendor Vendor Part Number May also assume no value signified by a Null value or absence of value. Classifies products into Products, Discounts, Bundles, Offers, and so on. Classifies products for Billing into Service Bundles, Subscriptions, Items, Discounts, and Special Ratings. Specifies the service type so that when a corresponding product is created in Billing, it is associated to the specified service. Indicates the product of a service or non-service, for example, physical goods. Identifies the vendor supplying the product when the product is supplied by a third party. Identifies the product part number to the vendor. PRODUCT, OFFER, BUNDLE SERVICE BUNDLE, SUBSCRIPTIO N, ITEM, DISCOUNT, SPECIAL RATING No None Used part of fulfillment to determine the order lines Subject Type, which drives the mapping to Product Specifications. No None Used in conjunction with Product Type. <Comms>EBO/<Comms>Line/ItemRef erence/typecode <Comms>EBO/<Comms>Line/ItemRef erence/classificationcode [listid="billingproducttypecode"] NA No None <Comms>EBO/<Comms>Line/ItemRef erence/classificationcode [listid="permittedtypecode"] TRUE, FALSE No None Used in conjunction with Product Type and may be used to parameterize fulfillment flows. <Comms>EBO/<Comms>Line/ItemRef erence/serviceindicator NA Yes AIA2.4 <Comms>EBO/<Comms>Line/ItemRef erence/supplierpartyreference/partyidentification /ID NA Yes AIA2.4 <Comms>EBO/<Comms>Line/ItemRef erence/itemidentification/supplieritemid 74

75 Functional Attribute Name Fulfillment Item Code Item Class Name Success Dependenc y Start Billing on First Usage Smart Part Number Network Product Flag Network Element Type Charge Frequency Code List Price Type Attribute Usage (Semantics) Uniquely identifies the mapping of an Line Subject to a Product Specification. Determines business classification of a product. Declares if all order lines of a bundle or offer must fulfill successfully or else the whole bundle or offer fails (all or none). When set to Yes by CRM or OSM, passes the request along to BRM. In this case, Usage Start Date, Cycle Start Date, and Purchase Date should have no effect. Automatically generated based on a predefined scheme. Mainly, drives dynamic product configuration/pricing rules in CRM. The billing system may use it to dynamically derive a price/discount value. Indicates if this is a network product, which helps determine which user-defined attributes to expect. Indicates if this network product represents a node, a connection, or a network. Indicates charge frequency unit of measure, for example, monthly, quarterly, yearly. Identifies price type. Seeded Values and Value Type 1) Null 2) A unique code that identifies the Product Spec to OM Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning No None <Comms>EBO/<Comms>Line/ItemRef erence/classificationcode [listid = "FulfillmentItemCode"] NA No None <Comms>EBO/<Comms>Line/ItemRef erence/primaryclassificationcode DEFAULT, No None <Comms>EBO/<Comms>Line/ItemRef ALL OR NONE erence/fulfillmentsuccesscode TRUE, FALSE No None Not yet supported by integration. <Comms>EBO/<Comms>Line/StartBill ingonfirstserviceusageindicator We have added BillingStartCode to ItemReference, if this requirement is at the item/itemreference level and not line level then BillingStartCode from ItemReference should be used. NA Yes None <Comms>EBO/<Comms>Line/ItemRef erence/alternateobjectkey [ContextID=SmartPartNumber] TRUE, FALSE No None <Comms>EBO/<Comms>Line/ItemRef erence/networkindicator NA No None <Comms>EBO/<Comms>Line/ItemRef erence/networkitemtypecode NA ONE-TIME, RECURRING, USAGE <Comms>EBO/<Comms>Line/<Com ms>schedule/<comms>schedulecha rge/charge/chargefrequencycode No None <Comms>EBO/<Comms>Line/<Com ms>schedule/<comms>schedulecha rge/charge/typecode List Price Identifies base price of the item. NA Yes None <Comms>EBO/<Comms>Line/<Com ms>schedule/<comms>schedulecha rge/charge/unitlistprice/amount Sale Price Type Identifies price type. ONE-TIME, RECURRING, USAGE No None <Comms>EBO/<Comms>Line/<Com ms>schedule/<comms>schedulecha rge/charge/typecode 75

76 Functional Attribute Name Attribute Usage (Semantics) Seeded Values and Value Type Asset able Prior Value Availa ble Remarks EBO Structure X Path - Depends on Context as Follows: <Comms> Variable for Sales, Fulfillment or Provisioning Sale Price Identifies net price of the item. NA Yes AIA2.0 <Comms>EBO/<Comms>Line/<Com ms>schedule/<comms>schedulecha rge/charge/unitsaleprice/amount Pricing Commit Type Dynamic Discount Method Discount Percent Discount Amount Member [0..N] User Defined Attributes User Defined Attributes User Defined Attributes User Defined Attributes User Defined Attributes Indicates whether the pricing is Committed or Dynamic. Indicates whether the discount is of type amount or percent. Indicates the percent by which the list price is discounted. Indicates the amount by which the list price is discounted Represents a member of a list by their phone number. Indicates attribute is common across all Specification components. Indicates attribute is common across all Specification components. Indicates attribute is common across all Specification components. Indicates attribute is common across all Specification components. Indicates attribute is common across all Specification components. Common/Siebel values are true/dynamic, false/committed. AMOUNT, PERCENT Yes AIA2.4 <Comms>/<Comms>Line/<CommsOr der>schedule/<comms>schedulecharge/c harge/dynamicpricingindicator Yes AIA2.4 <Comms>/<Comms>Line/<CommsOr der>schedule/<comms>schedulecharge/c harge/discountmethodcode NA Yes AIA2.4 <Comms>/<Comms>Line/<CommsOr der>schedule/<comms>schedulecharge/c harge/discountpercent NA Yes AIA2.4 <Comms>/<Comms>Line/<CommsOr der>schedule/<comms>schedulecharge/c harge/discountamount NA No None Used for capturing membership to friends and family plans. <Comms>EBO/<Comms>Line/<CommsOr der>linespecificationgroup/specificationgroup[./nam e="extensibleattributes"]/specification[./name="speci alrating"]/valuetext [0..N] NA Yes None UDA Name <Comms>/<Comms>Line/ItemReferen ce/specificationgroup[name="extensibleattributes "]/Specification/Name ADD, UPDATE, DELETE Yes None UDA Action Code (Expected to change to a Service Action Code element to allow additional value NONE.) NA Yes has Previo us LIC Value STRING, DATE, NUMBER UDA language-independent code Value <Comms>/<Comms>Line/ItemReferen ce/specificationgroup[name="extensibleattributes "]/Specification[name="<Line.XA.Attribute>"] /@actioncode <Comms>/<Comms>Line/ItemReferen ce/specificationgroup[name="extensibleattributes "]/Specification[name="<Line.XA.Attribute>"] /Value Yes None UDA Data Type <Comms>/Prior<Comms>/<CommsOr der>line/itemreference/specificationgroup[name ="ExtensibleAttributes"]/Specification[name="<Ord erline.xa.attribute"]/datatypecode NA Yes None UDA language-independent code Prior Value <Comms>/Prior<Comms>/<CommsOr der>line/itemreference/specificationgroup[name ="ExtensibleAttributes"]/Specification[name="<Ord erline.xa.attribute>"]/value 76