OSM 7 BestPracticesGuidelines PDF

Order and Service Management 7 Best Practices Guidelines
An Oracle White Paper November 2010
OSM 7 Best Practices Guidelines
Page 2
Table of Contents Introduction ..................................................................................................... 4 Purpose ...................................................................................................... 4 Audience ..................................................................................................... 4 Pre-requisite reading .................................................................................. 5 Intended Use ................................................................................................... 5 Introduction to OSM 7 ..................................................................................... 6 Business Problem Definition ....................................................................... 6 OSM 7 Terminology .................................................................................... 7 OSM 7 Features and Functions .................................................................. 7 Order Fulfillment Process Overview ........................................................... 9 OSM Implementation Framework ................................................................. 11 Planning for an implementation of OSM ................................................... 11 Implementation Framework ...................................................................... 11 Analysis Stage............................................................................................... 15 Introduction ............................................................................................... 15 Purpose .................................................................................................... 15 Methodology ............................................................................................. 15 Key Considerations ................................................................................... 16 Deliverables .............................................................................................. 18 Design Stage ................................................................................................. 20 Introduction ............................................................................................... 20 Purpose .................................................................................................... 20 Methodology ............................................................................................. 20 Design Considerations .............................................................................. 25 Deliverables .............................................................................................. 31 Configuration Stage ...................................................................................... 33 Introduction ............................................................................................... 33 Purpose .................................................................................................... 33 Key Considerations ................................................................................... 33 Deliverables .............................................................................................. 39 Solution Verification ...................................................................................... 41 Introduction ............................................................................................... 41 Purpose .................................................................................................... 41 Key considerations.................................................................................... 41 Deliverables .............................................................................................. 42 Deployment ................................................................................................... 43 Introduction ............................................................................................... 43 Purpose .................................................................................................... 43 Key considerations.................................................................................... 43 Deliverables .............................................................................................. 43 Deliverable Templates .................................................................................. 43
Page 3
Introduction
Purpose
This document provides an overview of the typical activities involved in implementing the Order and Service Management (OSM) product to solve Order Management and Provisioning Management challenges. This document walks you through the various stages of an implementation, and provides pointers and guidelines to assist with the execution of the various tasks involved in completing a successful implementation.
Audience
The primary audience for this document includes members of an implementation planning team. Business Analyst - Responsible for documenting business objectives, processes, and requirements. The business analyst also evaluates functional and process prioritization, and maps the business objectives to OSM business process solutions. Project Manager - Responsible for creating and executing the project plan. The project manager facilitates project communication, monitors project scope, resolves project issues, and makes sure that deadlines are met. IT Lead/Technical Architect - Responsible for analyzing and documenting system integration requirements. The IT lead evaluates integration complexity, the application integration strategy, and the data strategy. This individual develops systems transition strategies, reviews the OSM solutions for impact analysis, and defines the solutions for technical requirements. Application Lead/Application Architect - Responsible for bridging business and technical requirements, and developing a proposed solution for each requirement. The application lead evaluates the gap complexity and development type (such as standard configuration versus custom development) between the business requirements and the OSM functionality. The application lead should have solid knowledge of OSM.
Page 4
Workshop Facilitator - Responsible for conducting business requirements workshops and helping the team prioritize business goals, processes, and requirements. Executive Sponsor - Responsible for executive-level sponsorship, actively participating in the project, and driving commitment to schedules. In conjunction with the project manager, the executive sponsor is responsible for validation and execution of the implementation plan.
Pre-requisite reading
This document does not replace the OSM product documentation. It assumes that you have a basic level of familiarity with the various terms and concepts associated with Order Management and OSM in particular. It is strongly recommended that you familiarize yourself with the contents of the following documents: Oracle Communications Order and Service Management Concepts Oracle Communications Order and Service Management Developer's Guide Oracle Communications Order and Service Management System Administrators Guide Oracle Communications Order and Service Management Application Integration Architecture Order to Activate Cartridge Guide Intended Use This document is intended for use by customers and system integration partners planning for the execution of an OSM Implementation project and is intended as an aid in assisting with the planning and execution of the project. It is intended to supplement the existing processes and tools that may be available to support such an implementation. This guide is best used as a reference and it is expected that you have completed the pre-requisite readings and attended OSM Training. This guide is NOT intended to be a cook book or a mandated way of planning and executing an OSM project. Each implementation project is unique and this document does not attempt to cover all the scenarios that are likely to be encountered during an implementation. It provides suggested ways of executing individual phases of a typical order management implementation. While the contents of this document provide a general framework, each project will adapt the contents to suit specific needs. In addition, a typical implementation of an IT solution also requires the execution of activities such as Project Management, Business Process design, Configuration Management, End-user training, and so on. This document does not cover these activities in detail, except where there is a specific aspect relevant to an OSM implementation.
Page 5
Introduction to OSM 7
Business Problem Definition
The Communications industry has begun the transition in Order Management solutions from custom, middle-ware based point solutions to Commercial-off-theshelf (COTS) Order Management Systems. Communications Service Providers (CSPs) are offering increasingly complex services and are also having to offer a large number of such services to achieve differentiation in the marketplace. This is having a direct impact on the level of sophistication required in their Order Management solutions to ensure customer satisfaction through getting it right the first time. Order and Service Management release 7 is a significant step forward in helping CSPs solve these problems. OSM 7 introduces a number of new out-of-the-box capabilities to help service providers significantly reduce the time taken to design and deliver new service offerings to the market, while keeping a tight control on the operational costs of such an exercise. OSM 7 can be deployed to address two different functional challenges in the order management space: Order Management: This is also called Central Order Management and refers to the series of activities involved in managing an order fulfillment process from the time of sales order submission through to order completion. It involves the identification of the various systems involved in fulfilling this request and co-coordinating the actions across all of them to complete the order. These could include shipping, billing, workforce management and a number of different service fulfillment applications. It also includes managing the fallout and errors which occur during the order fulfillment process. Provisioning Management: This is also called Service Order Management and refers to the process of identifying the network and inventory related activities required to fulfill the customer request. In this process OSM typically interfaces with the inventory and activation applications to fulfill the request. Figure 1 below illustrates the difference between these two functional challenges within the overall order management domain. The order management function typically co-ordinates all the end-to-end processes including the non network facing actions, while the provisioning management function co-ordinates the network facing (inventory and activation) processes.
Page 6
CRM CRM CRM
Billing Billing
WFM
Other
Central Order Management Service Order Management
Inventory
Activation
Other
Figure 1: Order Management and Provisioning Ma nagement functions
Refer to the Oracle Communications Order and Service Management Concepts guide for more information.
OSM 7 Terminology
With release 7, OSM introduces a number of new terms that a user of the application must become familiar with. Refer to the Oracle Communications Order and Service Management Concepts guide for more information.
OSM 7 Features and Functions
Figure 2 below represents a schematic view of various components in release 7 of OSM. The key components are: Task Web Client: Used Creates and updates orders and manages order status. Order Management Web Client: Manages orchestration orders, displays their components and dependencies, and exports orders to Excel spreadsheets. Web Services API: Supports submission of orders from external systems to OSM for processing.
Page 7
Run Time tools

Order Management Web Client Orchestration Mgmt. Web Client
Design Time tools

Admin Tool Design Studio
User Assignment Reporting Clustering
Application Modules
Revision and Cancellation Manager OSM Server and API
View Rules Framework Automation Framework
Orchestration Plan Manager
Oracle Communications Solution Components

Order to Activate PIP Product Launch PIP
Oracle DB 11g Eclipse Ganymede New / Significant change in R7
Oracle Communications Tech. Platform

OS : HP-UX 11, IBM AIX 6.1, Sun Solaris 10, Linux OEL / RHEL Weblogic 10.3 / FMW 11g
User assignment: This module is used to manage the end-users workload, which F are rperforming the various tasks in relation to the order processing lifecycle. igu e 2: OSM 7 Product Components
Reporting: Provides a standardized interface for accessing the OSM database to extract data for reporting purposes. Revision and Cancellation Order Manager: Provides the capability for OSM to understand and manage in-flight order revisions through configuration as opposed to customization. Behaviors Framework: Provides the ability to modify the behavior of the Task Web Client as required by a given project. Automation Framework: Provides the ability to integrate OSM with external applications such as CRM, inventory and activation systems for end-to-end automated order fulfillment. Orchestration Plan Manager: Provides the ability to dynamically generate a unique orchestration plan for each order taking into account an understanding of the order line items, their dependencies and the fulfillment topology for the particular solution. Clustering: supports an active-active WebLogic clustering configuration for enhanced availability and reliability. OSM 7 supports a graphical user interface called Design Studio which you use define process workflows and to create and deploy cartridges to the OSM server. The Administration Tool is used to manage users and workgroups involved in the order fulfillment process.
Page 8
OSM 7 provides support for two AIA Process Integration Packs (PIPs) which provide productized integration with different applications within the Oracle Communications Portfolio to allow for the deployment of an end to end order fulfillment solution.
Order Fulfillment Process Overview
Figure 3 below provides an overview of an end to end order fulfillment process. Typically the order fulfillment process includes the following key functional steps: 1. Order Capture: This refers to the activities involved in capturing the details related to the customers request for services and submitting that information for fulfillment in the form of a Sales Order to the order management application. This function is typically performed within an order capture or CRM application such as Oracle Siebel CRM.
AIA for Comms2.5: Order Fulfillment Functional Flow
CRM
Order Capture
(New, Revision, Follow-on)
Submit Order
Create/Update Trouble Ticket
Update Order & Status
Create/Update Customer Assets
AIA
AIA
AIA
Transform / Enrich Order Decompose & Route Order Components ;
Order Handling
Transform / Enrich Order
Decompose Order Route Order Components , & Listen to Responses and Updates
Manage Fallout
Order Status Management Update Order & Status
Order Management Sync Customer

AIA
Initiate Billing*
AIA
Provision Order
AIA
Update Order
Fulfill Billing
AIA
Billing
Sync Customer
Initiate Billing involves Various APIs * execution of multiple Billing actions
Various APIs
AIA
Provisioning
Provision Order Transform & Enrich Order Decompose Order and Provision Services : ;
Provisioning Management
Transform / Enrich Order
Decompose Order
Design Service
Deliver Service *
Order Status Management
Network Inventory
Legend
AIA Services
AIA Based Integration Points
Internal Functions
Within Product Steps
Application APIs
Point to Point Integrations
Flow Activity
AIA
AIA
Design Service
Activation
Sample/ Optional
Order To Activate Integration Point
Order To Bill Integration Point
Various APIs
* Deliver Service involves execution of a provisioning flow
Figure 3: Order Fulfillment Process Overview
2. Order Management: This refers to the collection of activities involved in validating the order, decomposing the order into its constituent elements, creating an orchestration plan to fulfill the order and managing interactions with the individual applications.
Page 9
3. Provisioning Management: This refers to the collection of activities involved in interacting with the network activation and inventory management related functions required to enable a customer to use the requested service. 4. Status Management: This refers to the function of collating the status of individual order elements and providing the same to the upstream applications for visibility to the customer. 5. Fallout Management: This refers to the ability to deal with errors and exceptions that may occur during order fulfillment and direct these errors to a centralized location for investigation and correction. The order fulfillment process flow described above is a generic representation of the typical fulfillment process. The implementation of such a workflow in a live project must take into account a number of project specific factors including: The types of services and products being fulfilled by the process. The specific requirements of the fulfillment process as dictated by business policies, legal and regulatory requirements, network constraints, edge application constraints and so on. The following sections of this document provide you with guidelines on how to execute the various stages of an order fulfillment implementation.
Page 10
OSM Implementation Framework

Planning for an implementation of OSM
An implementation of OSM must be viewed as a business process implementation exercise aided by technology, as opposed to a purely application deployment exercise. In this context, an OSM implementation typically offers the opportunity to obtain significant benefits by refining and streamlining business processes across the order fulfillment chain. It also offers the opportunity to identify and resolve bottlenecks in the process that are negatively impacting customer satisfaction or operational costs. When planning an OSM implementation, it is important to understand the strategic business problem that is being targeted. Some examples of the strategic business objectives of an OSM implementation can be to: reduce order handling time by 20% from current benchmarks. remove 90% of order fallouts requiring manual intervention and correction. provide customer order status visibility on an hourly basis. centralize Order Management functions on one platform and retire certain systems to save operational costs. In all of the objectives listed above, it is clear that a successful implementation will involve the application of technology (OSM) and likely some measure of change in the business processes or practices to achieve the intended benefits. At each stage of the implementation, decisions must be assessed for their ability to contribute to achieving the defined strategic objective, while balancing the same against the amount of change to existing business processes that the implementation would entail. In most cases, customers are willing to accept significant change to their business processes to achieve strategic objectives. However, the implementation process must ensure that the individual stakeholders buy into the reasons for change and are adequately equipped as a part of the implementation to deal with and execute the new process efficiently through training or other means.
Implementation Framework
The Implementation Framework described below is a generic abstraction of the software development lifecycle processes followed in most IT projects. Every project follows the same lifecycle albeit with varying levels of diligence and completeness due to constraints of skills, time, or other resources. In this section an overview of the various stages are provided. The following sections provide more details about the individual processes. This document does not aim to suggest replacements for any existing implementation frameworks/methodologies that may already exist in a given
Page 11
project environment. It supplements existing processes by providing some samples and checklists to take into consideration during the execution of the project lifecycle. Note that while Figure 4 represents the phases as being sequential in nature, there is a certain level of overlap that is inevitable between the individual phases during real-life execution of the project. Figure 4 provides an overview of the OSM Implementation Framework. The details of the individual phases are described below.
Project Planning and Management
Deploy
Analyze
Verify Configure
Design
Project Planning and Management
Figure 4: OSM Implementation Framework
This set of activities is focused on defining and assembling the project team, establishing the project work breakdown structure and milestones, monitoring ongoing progress, resolving roadblocks, and acting as the final point of decision making with respect to the project. It is also the responsibility of this team to ensure that the strategic imperatives for the project are identified and understood by all and that the ongoing project execution decisions contribute to the achievement of that objective.
Analyze
This set of activities is focused on understanding the current environment from the front office and back office perspectives. It involves understanding the sales catalog, the application infrastructure, the business processes and the network. The deliverables from this set of activities should answer the question What do I want this project to achieve and what are the capabilities/limitations of the underlying infrastructure?. A majority of project failures are the result of ill-defined or illunderstood requirements coming from the analysis stage.
Page 12
Design
This set of activities is focused on converting the requirements into a detailed application configuration design that identifies the various elements of the solution at a technical level and how they will fit together to help achieve the desired solution. The deliverables from these sets of activities help answer the question How do I realize the solution technically?
Configure
This set of activities is focused on configuring the applications, developing any required extensions and integrations, and ensuring that the technical components of the solution work together.
Verify
This set of activities is focused on verifying that the solution meets the defined requirements and is in line with helping the project achieve its strategic objectives. While technical testing of solution components is important, the verification phase must also focus on confirming that the business process can be executed and that the end-users are able to use the solution as outlined.
Deploy
This set of activities is focused deploying the solution to the business environment and assisting the users to learn the execution of their business processes. This ensures that most business scenarios have been encountered and successfully supported by the solution.
Deliverables Overview
A typical OSM implementation could require the creation of a number of different deliverables at different phases of the implementation. While the specific contents and the need for a given deliverable is dependent on the specifics of the given project, the list of deliverables outlined in this document could act as a potential checklist for consideration. Figure 5 provides a list of the deliverables by project phase. The subsequent sections in this document provide further details about each of the deliverables in the context of a project implementation.
Page 13
Phases Analysis Design Configure Verify Deploy

OSM Configuration (cartridges) Sales Catalog Analysis
Deliverables
Requirements and Process Analysis IT Application Analysis Network Services Analysis
OSM Configuration Design
Integration Design
Deployment Design
Integration Package
Verification Strategy and scripts
Deployment package
Functional & Process Verification Report
Deployment Readiness Report
User and Operations Guide
Production Deployment Status Report
Figure 5: OSM Implementation Deliverables
Page 14
Analysis Stage
Introduction
This section reviews the various activities to be performed during the analysis stage and identifies the deliverables that need to be produced to help with the subsequent stages of project implementation.
Purpose
The purpose of the Analysis stage is to ensure that questions pertaining to the What of the project can answered at the end of the stage. Some of the sample questions to be asked are: What is the strategic imperative for this project? What are the measurable metrics that will define success for this project? What are the business processes that will be impacted by this project? What are various activities involved in performing this business process? What business rules govern the activities related to this business process? What groups do the people performing these processes belong to? What are the various scenarios related to the execution of the process the success path scenarios and the kinds of exceptions encountered? What kinds of remedial actions are expected to be initiated to recover from errors? What is the sales catalog that this order management solution will support? What are the services that the network supports? What are the requirements, capabilities, and limitations of the other applications that form a part of the solution?
Methodology
While each project environment is unique, and the analysis techniques and methodologies need to be adapted to the specifics of the project, it is important to ensure that the chosen technique ensures completeness of information gathering to support the analysis. In that context, two commonly encountered techniques are outlined below.
Interview method
In this method, the analysis is conducted as a series of one-on-one interviews with key users, managers, and other stakeholders across the various business groups involved in the execution of the business process. An advantage of this method is that it may be easier to get honest perspectives on the problem at hand from those who are not comfortable speaking in a more public forum. It is also an opportunity to make sure every person is heard and their views considered. It may
Page 15
be easier for individuals to make time for a one on one discussion as opposed to spending days in a workshop. You must ensure that the set of interviewees covers the full scope of business operations and organizational hierarchy and is not limited only to the managers.
Workshop method
In this method, the analysis is conducted as a series of group workshops where the attendees include key users, managers, and other stakeholders across the various business groups involved in the execution of the business process. An advantage of this method is that it may be easier for participants to provide real time feedback and understand each others points of view/problems, and thus help arrive at a consensus quicker. It may also be an easier format to understand the exception processing cases and the challenges they cause at a broader organizational level. However, you should ensure that attendance at these workshops is adequate and representatives are present from the full scope of business operations and the organizational hierarchy. It is also important to ensure that individual opinions are not drowned out by more vocal participants.
Key Considerations
Every exercise in analysis is a balancing act between ensuring completeness of coverage and understanding versus getting stuck in analyzing too deeply so that decisions cant be made (figuratively known as analysis paralysis). While the exercise must ensure that sufficient level of detail around the requirements are captured, the project must establish an environment that recognizes that it may not be possible to identify every requirement or understand the implication of every requirement until further down the project lifecycle. To handle this requires a willingness on the part of both the customer and the implementation team to make required adjustments to scope, timelines, resources and/or cost as the project lifecycle evolves. It is our expectation that through the repeated use of a consistent set of implementation artifacts, the implementation teams can develop better estimates for time and cost, thus reducing the likelihood of unexpected outcomes for all involved. Note that the Analysis phase is more than just a Requirements phase. In some cases it may even be considered as a follow-up to a short Requirements phase. While understanding and documenting the expectations of the business or IT users of the application in the form of a requirements document is an important element of this stage, the analysis stage must also go beyond this to gain an understanding of the capabilities and constraints of the underlying network and IT infrastructure that will support the deployment of this solution. It is sometimes inevitable that a certain measure of answering the How questions, is introduced into the process of gaining such an understanding and the use of proof-ofconcepts or other such tools must be explored to gain that understanding. Figure 6 provides an overview of the Analysis phase activities.
Page 16
Activities
Conduct Business Process workshops / Interviews Analyze Sales Catalog Analyze Network Services Review individual system functionality
Document Business Processes and Requirements
Identify the non-functional requirements
Identify Catalog groupings
Identify Services and Mappings
Review API capability
Review system data structures
Deliverables
Requirements and Process Analysis Sales Catalog Analysis Network Services Analysis IT Application Analysis
F i g u r e 6 : O S M A n a l ys i s S t a g e O v e r v i e w
To ensure completeness of the analysis exercise, some of the key types of requirements that must be covered during this phase are highlighted in the subsections below.
Functional Analysis
Functional analysis is typically focused on the requirements of the day-to-day users of the application. Some of the considerations are: What is the sales catalog that this order management solution intends to support? What are the steps that are involved in the execution of the process? What are the user interface requirements related to the individual user groups of the applications? What behaviors are they expecting? What are the security requirements around users access to information or the performance of tasks? What are the typical assumptions that are made in the day-to-day execution of the process? Do these need to be validated by the system? What are the processing errors that occur? Is the resolution process automated or manual? What are the day-to-day reporting requirements?
Non-Functional and Operational Analysis
Non-functional and operational analysis is focused on the requirements of supporting the performance, availability, and maintenance of the business process. Some of the considerations are: What are the application performance requirements?
Page 17
What are the reliability or uptime requirements? Can the business survive for 1 hour , 1 day, or 1 week if the application is down? What are the business continuity requirements? Is there a need for a high availability or disaster recovery setup? What are the management reporting requirements?
Integration Analysis
Integration analysis is focused on understanding the capabilities and limitations of the individual applications that support the execution of the business process and how they need to be integrated into the end to end solution. Some of the considerations are: What is the level of sophistication of the individual applications APIs? Do they exist? What level of understanding and documentation is available with regards to these individual applications APIs and data models? What are some of the dos and donts with respect to integration with this application? Can a technical owner for each of these applications be identified for more indepth discussions during the design phase? What are the limitations and requirements related to data transformation and mapping between different applications?
Deliverables
The understanding gained during the Analysis exercise must be documented and signoff obtained from the appropriate stakeholders to ensure that their expectations have been well understood and any early tradeoffs on scope, timelines, and cost have been accepted. A top-down approach to the solution combines the sales catalog with the requirements and process analysis. The IT application and network services analysis drives a bottom-up approach. As an output of the analysis exercise, the key deliverables described in the following sub-sections could be produced.
Sales Catalog Analysis
The objective of the sales catalog analysis is to confirm the scope of products that will be supported by this implementation, and to understand the various types of products that exist in the catalog such as (service related products, billing only products, installation products and physical goods products). Further, you need to understand if these products can be grouped together based on similar characteristics into product classes, and what set of activities and actions are required to fulfill items in a given product class.
Page 18
The Sales Catalog Analysis SpreadsheetTemplate provides a sample spreadsheet template to capture the output of the sales catalog analysis exercise.
Requirements and Process Analysis
This deliverable documents the business processes as described by the users during the workshops or interviews along with any desired changes to the process. Interactions with individual applications involved in the process should also be represented in a diagram for greater clarity on the human-to-system interactions. If required and applicable, it may be easier to document both an as-is and to-be process diagram to provide greater clarity on how the process will change postimplementation. In this deliverable, the details of the analysis should be documented along with a numbered set of requirements. It is important that the requirements are written in a manner that supports the development of test cases that can verify if the requirement has been adequately addressed. A numbering scheme helps ensure coverage of the requirements during the testing phase through traceability reports. Each requirement must also have the name of an owner assigned to it to allow for ease of further clarification or prioritization at a later stage. Note: Consider the use of Design Studios process charting capabilities to document the flows to reduce downstream implementation effort and provide users with a visualization of the end-solution. The Requirements and Process Analysis Document Template provides a sample table of contents for such a deliverable.
IT Application Analysis
The objective of the IT Application analysis is to understand the capabilities and constraints of the individual applications that will form a part of the solution with a view to being able to abstract the fulfillment functions they can support and what the implementation of that function would be. It is also important to understand how any errors in the interactions with these applications can be handled so that they form a part of the implementation of the fulfillment function. The IT Application Analysis Spreadsheet Template provides a sample spreadsheet template to capture the output of the IT applications analysis exercise.
Network Services Analysis
The objective of the Network Services analysis is to collate a list of all the services supported by the underlying network and then to map this to the sales catalog products to ensure the integrity of the link from the front office sales catalog through to the back end network. (The Network Services analysis does not attempt to understand the capabilities and constraints of individual network elements and how to interact with them)
Page 19
Typical interactions with an inventory and activation system are at the services level of granularity. This analysis helps in developing a solution for translating commercial products into services that are typically implemented to support the provisioning function. The Network Service Analysis Spreadsheet Template provides a sample spreadsheet template to capture the output of the network services analysis exercise. Design Stage
Introduction
This section explains the activities to be performed during the design stage and identifies the deliverables that need to be produced to help with the subsequent stages of project implementation.
Purpose
The purpose of the Design Stage is to ensure that questions pertaining to the How of the project can be answered. Some of the sample questions to be asked are: How will OSM be configured? How will integration with external applications be implemented to achieve the desired functionality? How will error handling be managed? How many custom extensions are required? Are they well understood? How will the operational requirements be accommodated in the solution?
Methodology
While each project environment is unique and the design techniques and methodologies need to be adapted to the specifics of the project, it is important to ensure that the chosen technique ensures completeness of the design process to a level of detail that enables the construction phase. In that context, a few key considerations with respect to the design of an OSM 7 solution are highlighted below. Note: This document only focuses on aspects related to the functional design of the OSM solution component. Additional design elements related to operational or infrastructure must also be factored in to the deployment design.
Configuration design
The design of an OSM 7 configuration involves the use of Design Studio to configure the metadata and any required extensions or automation plug-ins. The
Page 20
table below presents the many questions that must be answered during the design stage and how they map to the various configurable metadata elements in OSM 7.
Question Metadata Element
What are the various data elements related to the incoming order? What additional data is generated by the individual applications that are a part of the fulfillment process needed for further processing? What are the data elements needed by individual tasks? How is the order data organized? How will the incoming order format be recognized? How can we validate specific content on the incoming order data? (if required) How can we enrich the content on the incoming order data? (if required) How will OSM identify and understand the structure of the individual line items on the order? How will OSM determine the fulfillment actions that need to be performed for line items on the order? How will OSM recognize which set of fulfillment actions are to be performed for an order? What are the fulfillment actions involved in the processing? Which systems are involved in the fulfillment lifecycle? What is the processing granularity for each target fulfillment system? (e.g. is it one line item per request/bundle of line items per request/) How will the order fulfillment actions
Data Dictionary
Order Template Order Recognition Rules Order Recognition Rule -> Validation X-Query Order Recognition Rule -> Order Transformation X-Query Order Item Specifications
Product Specifications
Fulfillment Modes
Order Component Specifications Fulfillment actions Order Component Specifications Fulfillment Target Systems Order Component Specifications Processing Granularity
Sub-processes and tasks
Page 21
Question
Metadata Element
be realized? Manual and automated. What are the steps in decomposing the sales order into a set of fulfillment requests to be executed by the different fulfillment systems? What is the sequence in which the decomposition should happen? What are the various teams and groups of people involved in executing the fulfillment actions? What are the various policies that control the execution of the order around who and when items can be modified, revised, etc? Is there a specific order in which the fulfillment actions must be performed? Is there a certain stage of processing beyond which no revision to an inflight order can no longer be accepted or allowed for business reasons? What actions need to be performed on a given task in cases when an in-flight order is revised? How will external systems be notified of status changes or order data changes in OSM? What are the key data elements of the order that need to be tracked changes to which external applications may need to be notified? If applicable, what specific rules apply to how the OSM Web client works? How will OSM integrate with external applications to exchange data and invoke actions to execute the fulfillment actions? Orchestration Stages
Orchestration Sequences Workgroups & Roles
Order Lifecycle policies
Dependencies
Point of No Return
Compensation Configuration
Notifications
Line Item data fields returned from fulfillment, status and milestones on the order data Behaviors (View Rules) Automation plug-ins
Page 22
Integration design
Every order management configuration involves integration between multiple systems (and usually the execution of manual actions) as a part of the end to end fulfillment lifecycle. It is expected that the Detailed Analysis stage has provided sufficient information to identify, for each process: List of systems involved in the process and technologies they support for integration. List of manual actions required in the process. The Integration design exercise aims to clearly identify the following aspects: List of integration points. For each integration point: OSMs partner system (and its specific module if applicable). The exact details of the data being passed from one application to another. The specific function calls/APIs being invoked each way for interapplication communication. The error handling mechanism. Any special performance or failover requirements, for example, number of retries.
Cartridge packaging design
OSM configuration and extensions are deployed onto the run-time server in the form of cartridges. These cartridges contain all the required metadata configurations, extensions, and other code developed to facilitate the order management automation. Design Studio supports the ability to define discrete cartridges with model entities that can be combined into a single solution. This allows a modeler to build up a library of foundation cartridges which can then be shared across multiple solutions. In turn, supporting a design principle called separation of concerns, an individual cartridge can be focused on a specific objective and not be overloaded with model entities that are not pertinent to that objective. While OSM cartridges can range in complexity, one of the key design decisions that must be made is the number of cartridges that need to be created to address the full scope of requirements. Some of the considerations in making this decision include: Functional differences central order management vs. service order management. Re-use.
Page 23
Ease of maintenance and frequency of change for given configuration elements. Performance. Cartridge compartmentalization is also very useful for supporting multi-person development work since design and implementation can be focused on a problem subset. While each deployment would have its own specific considerations, as a general rule Oracle recommends the following guidelines: Build separate cartridges for each functional sub-process. For example, build separate cartridges for central order management and service order management. Put configuration elements that are more commonly changed into a separate cartridge for ease of maintenance. If a given component of the overall end-to-end process has distinct notification and status management requirements, use a separate cartridge f and treat its input as a sub-order from the main order. For example, if the process of shipping a piece of equipments involves interactions with three to four systems and multiple notifications to other systems, consider creating a Shipping order management cartridge to handle this requirement. For a given cartridge, limit the total number of sub-processes to less than 10 and the number of tasks to less than 10 per sub-process, for ease of maintenance. Consider defining a cartridge which contains only a data dictionary with data nodes and structures that are specific to a technology or service or space. Model a cartridge which only contains product class definitions since they are modified with high frequency. These considerations should be taken into account when designing a solution so that the right granularity of cartridge design can be used to enforce good design and coding practices and reusability.
Deployment design
An order management solution typically involves more than one application.From a deployment perspective, this adds a measure of operational complexity that must be considered during the design stage. The key deployment configuration questions that must be answered during the design exercise are: How will the central and service order management functions be mapped to the physical architecture? Will there be one vs. two instances? How will system data be backed up and restored, if required? How will application performance monitoring and operational maintenance activities (such as log file clearing) be handled?
Page 24
How will business continuity be maintained in the event of an application failure? What is the expected level availability for the solution? Is there a need to implement clustering or other high availability solutions? How often will data be purged from the database? How will it be done? How will errors and failures in other interfacing applications be handled? How will the application configuration and code be deployed into the production environment from the test environment? Is there a requirement for automated deployment? Questions such as the above must be considered and answered during the design phase as they may have a specific impact on the detailed design of the configuration and integration aspects of the solution.
Design Considerations
Integration Considerations Managing status updates
Status values for an order item and for the whole order often need to be reflected back in the upstream system that submitted the original request. There are a number of ways to achieve this. Use an order data change notification to configure a plug-in that is triggered when data changes in the order template. Design the notification plug-in to generate a status response back upstream. Be aware that there can be race conditions if multiple status updates are executed in parallel. The plug-in needs to have visibility to all status updates in order to calculate an aggregated status value. Configure an automation plug-in to be triggered for an order milestone. The plug-in could be triggered for a state change (such as order created, order completed, order failed) and would be designed to generate a status update back upstream. Configure a message-driven bean (MDB) to generate a status message whenever the order changes state. This is less desirable then the option above since it does not provide an automation context and would be designed, built, and packaged separately from a cartridge. Configure an automation task as part of a system interaction process to handle status updates back upstream. Configure a status update function as an order component and make it a firstclass member of the orchestration plan. This option can only be used if status updates are only sent at a specific point in the orchestration plan, for example as the last function after provisioning and billing. The options above can be evaluated based on the complexity of the status update requirements for the solution. Complexity can range from simple status updates
Page 25
based on order complete or order failed, to the need for numerous interim status updates per order item throughout the orchestration process.
Completing an automation task handling concurrent status updates
There are situations that arise when an automation task is processing multiple responses. Consider, for example, an interaction with an activation system which sends back updates for each service on the activation request, or a provisioning system which returns an update for each line item on the provisioning request. The automation task should complete when all updates have been received. If the update response itself contains some data that indicates it is the last response, the automation task can easily check for this condition and complete itself. In other cases the only way to detect when the last response is received is to check that a status response has been received for each action request sent out on the original outbound message. If multiple responses are processed concurrently, the automation receiver instances executing concurrently do not have visibility to status updates from the other receivers. The receiver may never execute with a view that contains all status updates and so never realizes when to complete the task. This situation can be handled by configuring a data change notification plug-in that monitors the status field(s). The data change notification plug-in would be triggered every time the status field is updated by the automation receiver. The notification plug-in executes in a separate transaction after the receiver updates, and can check the status responses to determine if all responses have been received for each action request. When all responses are received, have the notification plug-in generate a message to trigger an automation receiver which correlates on an ID set by the sender specifically for tracking the status updates. The receiver then executes with a view that contains all of the status responses and can complete the task.
Figure 7: Automation task messaging
Page 26
Intercommunication between orders in the same domain
There is a special consideration when dealing with intercommunication between orders, and by extension cartridges that are deployed in the same domain. The automation sender in the child cartridge needs to use the correlation ID specified by the parent orders task. However, if both parent and child task senders use the JMSCorrelationID header there is a potential situation where duplicate entries will exist in the one OSM database with the same correlation ID, resulting in an error when the parent receiver tries to lookup an automation context. The design guideline to handle this is as follows: On the parent automation sender, set the JMSCorrelationID header either programmatically, or allow the system to auto-generate this value. On the child automation sender, set the JMSCorrelationID header to a different correlation ID than what the parent task sent. Set a different JMS header field (custom defined) to the correlation ID expected by the parent task. On the parent automation receiver, use the message property correlation configuration to retrieve the correlation ID from the custom defined JMS header field. This will prevent multiple entries with the same correlation ID in the database and will allow the parent task to correlate the automation context properly.
Data design
The following sections provide some guidelines on the different data modeling aspects involved in configuring a solution with OSM. There are many considerations to keep in mind when designing the data model a solution. For example, what data types are needed on an order, and what will the structure of the data be? What cardinality and validation rules apply, and what data needs to be made available to each task, rule, or condition?
Order Template
OSM supports a feature called order template contribution. It is a design practice that encourages localized definitions of order template data structures on the entity which best defines its structure. Design Studio generates the order level order template by aggregating all the localized order template definitions with any definitions defined at the order level. Localized order templates can be defined on an: order item specification Define ControlData/OrderItem and all of the order item properties.
Page 27
order component Define ControlData/Functions/<FunctionName> and any other data needed by the tasks in the process that execute this component. Use localized order templates to support: encapsulation re-factoring modify order template data at the entity level to which it is associated because localized order templates highlight the connection between an entity and its order template data. maintenance modifications to localized order templates help the designer understand the impact of changes such as possible breaks in compatibility. traceability localized order templates provide direct traceability from order template data to the modeling entity to which it is attached.
Task View
When designing task views, include only the data into the view that is necessary for the task. Performance is impacted by the amount of data the system needs to load into a task context. Size considerations also apply to the volume of data managed inside of an XML data type. Consider defining smaller XML data type nodes for storing sections of a sales order rather than including a single XML data type that contains the entire sales order.
Order Item Specification Properties
Order item specification properties are used to support orchestration, orchestration rules, decomposition rules, and dependency conditions. Modelers should keep this consideration in mind when modeling properties so that they are not reproducing the entire incoming line item with properties. Performance is impacted by the number and size of order item properties that are defined.
Considerations when designing related orders
There are some considerations to keep in mind when designing a solution with related orders.
Querying and Flexible Headers
There will often be one or more fields that contain common data across related orders, information such as a reference number or telephone number. Flexible headers can be used to query these data fields across orders in different cartridges as long as they are positioned in their order templates against the same mnemonic path. The Task Web Client query screen allows you to input search criteria once it then returns all orders that match the flexible header search values.
Page 28
Orchestration Design Recognition Rules
Always consider modeling a catch-all recognition rule which is prioritized at the lowest level (0) and accepts any incoming order (fn:true()). This will ensure that every incoming message is captured in OSM. All valid recognition rules should be prioritized higher and will catch valid inbound messages.
Debugging Consideration
Recognition rules are global metadata entities. A single recognition rule can cause problems when submitting an order for unrelated cartridges if the rules on the bad recognition rule throw exceptions when trying to process an inbound message.
Considerations with Order Change Management
It is important to consider compensation aspects when designing tasks. OSM takes into consideration data visibility on a task view when deciding whether a task needs to be compensated or not. If the data in the task view has changed values since the last time the task was executed, it will be amended. Use the significance node attribute to optimize the data delta calculation. If a node is configured as not significant, it is not included in the delta calculation analysis. A task is amended only if the delta analysis results in at least one data node with a changed value. Process design is also important to consider with order change management. Use sub-processes to control the scope of compensation. The example below illustrates this.
Page 29
Figure 8: Example without sub-processes
In this figure there is a choice between two possible flows: one through Task1_1 and the other through Task1_2. Both join at SandboxTask1. Assume that this flow executes through Task1_2 and is sitting in TaskFinal. A revision is received that changes the execution flow through Task1_1. In this scenario, the compensation plan will undo SandboxTask2, followed by SandboxTask1 and then Task1_2. Now consider a modification to this configuration where SandboxTask0, Task1_2, Task1_1, and SandboxTask1 are defined in a sub-process with the same flow.
Figure 9: Using sub-processes
Page 30
With this configuration, the revision would not necessarily trigger an undo in SandboxTask2. The compensation plan will compensate the sub-process first, which would undo SandboxTask1 and Task1_2. Task1_1 and SandboxTask1 would be executed in amend_do mode and the sub-process would be compensated. Compensation continues with SandboxTask2. This simple example displays the powerful and flexible use of sub-processes when designing a solution to support order change management.
Deliverables
The understanding gained during the Design exercise must be documented and signoff obtained from the appropriate stakeholders to ensure that the intended design meets their expectations. A traceability matrix must be created to ensure completeness of the design exercise. As an output of the Design exercise, three key deliverables must be produced, as described below:
Configuration Design Document
In this deliverable, the intended configuration of all the different elements of OSM must be documented. The design document must also provide a recap of any trade-offs made. Where multiple options were considered and one chosen, outline the other options and the reasons for rejection. This deliverable should also provide details of the cartridges to be created and deployed for the solution. For each cartridge, the document must outline the configuration elements that will be included and the integration points supported. It must also include a diagram to assist with understanding of dependencies between the cartridges for use by the application support teams in maintaining the application. The Configuration Design Document Template provides a sample table of contents for this deliverable.
Integration Design Document
In this deliverable, the details of all the integration points must be documented. The design document must also provide an outline of the intended operational requirements to manage the interface. For example, you would need to consider whether or not you need to monitor specific log files, and whether a batch job is required for the execution of the interface. The document must also explain clearly how data is mapped between OSM orders and the interfacing application. The Integration Design Spreadsheet Template provides a sample table of contents for this deliverable.
Page 31
Deployment Design Document
This deliverable should provide details of the how the operational considerations will be addressed and any specific technical artifacts that must be created to support the ongoing solution operations.
Page 32
Configuration Stage
Introduction
This section highlights the various activities to be performed during the configuration stage and identifies the deliverables that need to be produced to help with the project implementation. The procedure for creating cartridges is also outlined. Use the training material for details on how to configure specific elements.
Purpose
The purpose of the Configuration Stage is to ensure that all the technical artifacts required to support the implementation have been built and details of the solution verification exercise to be carried out have been outlined.
Key Considerations
Design Studio is the primary design tool to configure OSM 7. A number of training modules are available to help with using Design Studio for OSM 7. In particular, it is recommended that you access the following for additional details:
Topic Training Material
How to use Design Studio
Self paced training titled Design Studio for OSM Self paced training titled Configuring Studio for OSM 7 development Self paced training titled OSM Provisioning Plug-in for Studio Self paced training titled Modeling Customer Order Orchestration cartridges Self paced training titled Modeling Service Order Management cartridges
Configuration Management in Studio
Self paced training titled Version Management in Studio
Oracle University also offers a number of Live Virtual Classes (LVCs) to help train developers on OSM. It is strongly recommended that anybody involved in OSM development take these courses to understand how to configure OSM.
Configuration Guidelines: Steps to create a customer order management (orchestration) cartridge
The following is an outline of the series of steps needed to be completed to create an customer order management, or orchestration, cartridge using Design Studio.
Page 33
The detailed instructions for executing the same are not provided here as it is expected that the implementation team has undertaken sufficient product training (via above self-paced courses or LVC) to implement OSM. This list below is provided to act a check list. Create a new OSM 7 project in Design Studio. Create a new role or roles that will have ownership of executing the various activities. Associate the role to manual tasks and automated tasks as well.. Define a query task for this role., which will be used later for defining permissions on order items and so on. Create a new Control Dictionary and populate it. Set Cardinality it should be able to accept multiple order items. The componentKey is 100 chars long. Others do not have an explicit length. Display names should be the same as real names. Populate the main dictionary. This will hold all the individual data elements and data structures that contain the order data. Configure recognition rules. Set name space upon creation. Fill in recognition and transformation tabs. Define order item specs. Define data instance to support product spec mapping (this includes an XML file form mappings). Define manual tasks and sub-processes that will be mapped in order component specs. Define order component specs. Follow folder naming conventions by creating three sub-folders titled FUNCTIONS, GRANULARITY, and SYSTEMS to hold details of the decomposition functions, processing granularity and system definitions respectively. Use generic names such as BillingFunction, ShippingFunction, BillingSystem, ShippingSystem because they are just shells. The specific system is defined later, in the decomposition rules. Use executable flags only touched for granularity. Define Fulfillment Modes (which must be unique in the workspace).
Page 34
Create orchestration stages. Create an orchestration sequence. Use a three stage sequence Function, followed by system, followed by granularity. Create an orchestration process. Create product specifications. Create product classes. Define decomposition rules. Use two types of decomposition rules: System decomposition rules to map the functions to a system, and Granularity decomposition rules to map a function-system combination to the level of execution or order vs. item level. Even in cases where there is only system of a given fulfillment type, the topology uses decomposition rules that are dummy (a 1:1 mapping). Create creation task. Add the needed data Create order lifecycle policy. Complete the order.
Configuration Guidelines Organizing Design Studio and naming conventions
The following is a suggested set of naming conventions for selected configuration elements within Design Studio. However, each project is free to use whatever conventions are suitable.
Metadata Element Naming Convention Sample SalesOrderFulfillmentOR R SalesOrderFulfillmentIte mSpec
Order Recognition Rules Order Item Specifications Product Specifications
Use the convention of <CartridgeName>ORR Use the convention of <CartridgeName>ItemS pec Use names that clearly identify the productclass that this spec would map to. Consider using PS_<ProductClassName >_<SpecName>
PS_HighSpeedClass_Bro adbandSpec
Page 35
Metadata Element
Naming Convention
Sample
Fulfillment Modes
Use names that clearly identify the type of action to be taken Use names that are easily recognizable from a functional perspective e.g. Billing, Shipping, etc. Use names that represent groupings of systems from a functional perspective e.g. Billing, Shipping, etc. Use names that are easily recognizable from an order structure format in the front-end system e.g Item, Bundle, Order, etc. Use the names DetermineFulfillm entFunctionStage DetermineFulfillm entSystemStage DetermineProcessi ngGranularityStage As the names of the three stages
DELIVER QUALIFY QUOTE BillingFunction ShippingFunction ProvisioningFunction BillingSystem CRMSystem ServiceManagementSyste m ItemGranularity BundleGranularity OrderGranularity - N/A -
Order Component Specifications Fulfillment actions Order Component Specifications Fulfillment Target Systems Order Component Specifications Processing Granularity
Orchestration Stages
Orchestration Sequences
Use the convention of <CartridgeName>Seque nce Create two subfolders titled SYSTEM DECOMPOSITION and PROCESSING GRANULARITY under Decomposition rules to hold the two
SalesOrderFulfillmentSe quence DR_BillingFunction_To _ResBRM DR_DetermineGranulari ty_For_BillingFunction
Decomposition Rules
Page 36
Metadata Element
Naming Convention
Sample
types of decomposition rules Consider using the naming convention DR_<FunctionName >_To_<SystemName > for system decomposition rules Consider using the naming convention DR_DetermineGranu larity_For_<Function Name> for granularity decomposition rules
XML Catalog
XML Catalog is a facility in OSM that allows resources (XQuery files, XSLT files, custom jar files and so on) to be referenced through URI locators. The resources are deployed as part of the cartridges and then accessed as needed at runtime. For resources that are only accessed by a single cartridge, Oracle recommends that the resources be packaged in the cartridge itself and configured as Bundle In. Resources that are used by multiple cartridges should be packaged into a shared resources cartridge and configured to be accessed via URI. XML Catalog should be used to support development cycles and extensibility. Development cycles can involve numerous coding, building, deployment, and test cycles. XML Catalog can help reduce this cycle time by instructing the system to locate resources on the file system instead of from within the cartridge par file. In this configuration, any configuration changes made to a resource can be picked up by the runtime without having to build and redeploy the solution. Once testing is complete, the URI can be redirected to load resources from the cartridge par file. This is accomplished as follows: 1. In the package explorer view in Design Studio, navigate to the <cartridgeProject>/xmlCatalogs/core/ directory. 2. Create or edit the catalog.xml file. You can create the file by renaming a copy of xmlCatalogCoreTemplate.xml. 3. Create an entry like the following:
Page 37
This tells OSM to load all resources that start with http://example.org/somewhere from the filesystem located on localhost at /dev/env1/mycartridge/resources. Once testing is complete this configuration can be changed to load from the cartridge par file:
XMLCatalog can be used to support resource extensibility in a solution. The description above shows how URIs can be easily rewritten to change where resources are loaded from. This same mechanism allows an integrator/customer to redirect the solution to use customized resources different from the ones that were originally provided by the solution.
Use of model variables for versioning support
XML Catalog is a global metadata entity. This means that resources located through a URI locator will load the resources based on the rewriteURI configuration picked up from XML Catalog regardless of where the resources are located. Some recommendations are provided here to help support cartridge/solution versioning so that resources can be scoped to a controlled set. Define a model variable in Design Studio from the Cartridge -> Model Variables tab. For example, CARTRIDGE_VERSION with some version value such as 2.5 Use the model variable in the URI locator. For example,
http://oracle.communications.ordermanagement.unsupported.centralom/%{CART RIDGE_VERSION}/xquery/my.xqy
Define the following in the core.xml file <rewriteURI uriStartString=

http://oracle.communications.ordermanagement.unsupported.cetralom/2.5"
rewritePrefix="osmmodel:///MyCartridge Resources/2.5/resources"/ When you start to work on the next version of the cartridge, change the model variable version value and the rewriteURI configuration in core.xml. This ensures that the cartridge versions maintain their own distinct repository of resources. Introduce more model variables as needed to manage more complex packaging and deployment configurations.
Design document updates
It is not uncommon for most implementation projects to modify the design and discover that assumptions made during design are invalid during the development phase.
Page 38
The development team must make the necessary modifications to the design document along the way (or as a one-time exercise at the end of development) to ensure that the post-production support teams are capable of operating and maintaining the solution.
Developer Integration Testing
Each developer (or sub-team for development) is responsible for ensuring that their individual component is functioning as designed. Developers must conduct adequate level of testing to ensure that: The specific module or code element (script) is working as designed. In cases where more than one system is involved, that the communication between the systems is functioning (with error handling for exceptions) and well documented. The developer must keep a record of all the tests executed along with test data used for the tests for subsequent verification and use.
Deliverables
The output of the Development effort is a combination of code based and non code based artifacts. It is recommended that the Design Stage traceability matrix be re-visited and updated to map the requirements to the design elements to the code based artifacts that have been created to ensure completeness of the development exercise. As an output of the configuration exercise, the following key deliverables must be produced:
OSM Configuration
This deliverable consists primarily of the following: The OSM Cartridge with metadata configured. The automation plug-ins embedded within the OSM Cartridge. Any shell scripts or java code created to support the solution requirements such as batch scheduler jobs
Integration Package
This deliverable consists primarily of the following: The code, scripts and extentions created to interface with the partner applications. Any shell scripts or java code created to support the operation of these interfaces such as batch scheduler jobs
Page 39
Deployment Package
This deliverable consists primarily of the following: The code, scripts and created to support the operational and deployment requirements such as shell scripts, java code, and batch scheduler jobs
Verification Strategy and Scripts
This document must capture the details of how the various types of testing will be executed and the test cases, test data, and step-by-step procedures to execute the verifcation activities. Specifically it must address the following types of verification activities: Technical Verification. Business Process Verification. Non-functional (Performance, backup, etc.) and Operational Verification. Regression Verification.
Page 40
Solution Verification
Introduction
This section highlights the various activities to be performed during the Solution Verification stage and identifies the deliverables that need to be produced to help with the project implementation.
Purpose
The purpose of the Solution Verification stage of activities is to ensure that the solution meets the in-scope requirements and functions in a manner that meets the business requirements. It is not focused on technical verification of individual code modules, for example, but more on the endto-end solution and its usability by the stakeholders.
Key considerations
Technical Verification
The Technical Verification exercise is also sometimes referred to as system testing or end-to-end testing. It is focused on ensuring that the solution as configured works from end-to-end. The Technical Verification exercise draws its scope of work from the list of use cases documented in the Process Flow Diagram and Use Cases Document during the Analysis stage. It takes more of a black box approach to the verification exercise and is focused on ensuring that a given set of inputs produce the expected set of outputs, both positive and negative.
Business Process Validation
This is sometimes also referred to as User Acceptance Testing (UAT). However, the focus is not on the users verifying the individual screens and configurations, but on being able to execute their business process in a manner that was outlined during the analysis stage. While it is common for certain changes to have taken place since the analysis phase, these changes must now be documented and approvals obtained. It may also be required during this phase to document some workarounds and job aids to help the users execute their business processes using the new solution. The goal of this exercise is to provide users with the confidence that they can execute their day to day activities in the new solution.
Non functional and Operational Validation
This is an often neglected or overlooked component of the verification exercise. The solution cannot be used if it cannot be maintained or does not perform to expectations in terms of speed, availability, reliability, and so on. This component of the verification exercise must focus on ensuring that the expectations outlined in the detailed analysis document and the contents of the users and operational guide are accurate and usable.
Page 41
Deliverables
The output of the Solution Verification effort is essentially an approval to deploy to production. The results of the verification exercise are designed to capture any outstanding issues that may not be gating from a deployment perspective but need to be addressed soon after.
Functional and Process verification report
This document captures the results on the solution verification from a functional perspective and also from an end-to-end business process perspective. This report will help build confidence with the senior management that the business users are comfortable in executing the new business processes and all the adequate application/non-application artifacts (such as guides, and cheat sheets) have been put in place to support the business.
Deployment Readiness Status report
This document captures the results of the solution verification exercise and the list of outstanding issues. Specifically it must capture: Completeness of the verification exercise, and any exceptions. Confirmation of the deployment and rollback procedures. List of user issues and comments encountered during the process. Classification of the outstanding issues into 30 day, 90 day and Phase 2 buckets. Approval to deploy to production.
User and Operations Guide
This document contains information on the tasks required to be performed from an operations and maintenance perspective. It serves as a How To guide or a FAQ for the business, end users, and operations personnel who will be responsible for the system post deployment. While this document does not need to replicate the training material that will be produced to train the end-users, it must capture: Step by step instructions for common business end user tasks. Detailed operational procedures for activities like user creation/password resets, backup, restore, log file purging and so on Troubleshooting tips for integration points. Troubleshooting tips for performance issues. Considerations and checklists for making configuration changes post go-live.
Page 42
Deployment
Introduction
This section highlights the various activities to be performed during the deployment stage and identifies the deliverables that need to be produced to close out the project implementation.
Purpose
The purpose of the Deployment stage of activities is to ensure that the approved solution is configured into the designated production environment and the users can start using it.
Key considerations
It is not uncommon for the non-functional verification exercise (performance and operational testing) to be performed on the designated production environment when budget constraints disallow an equivalently sized test environment. In such cases, special precautions must be taken to ensure that the data created for the verification exercise be purged from the system prior to go-live. In cases where the production environment consists of existing applications, then appropriate maintenance windows must be scheduled, with notification to the users, prior to the deployment to production. In such cases, the documentation of a backout procedure takes on special significance as there will be a need to return the production environment to its original configuration in case of any issues with the deployment procedures. A pre-determined set of production deployment verification exercises must be prepared to confirm successful deployment. These could include a sample test order being passed through the application.
Deliverables
Production Deployment Status report
This document captures the results of the production verification exercise and acts as the gating checkpoint to confirm completion of solution implementation. The production operations and maintenance teams along with the business users take ownership of the solution henceforth. Deliverable Templates A number of template files are available which supplement this white paper. They provide templates for artifacts to be used in your solution and include: Sales Catalog Analysis Spreadsheet Template Requirements and Process Analysis Document Template
Page 43
IT Application Analysis Spreadsheet Template Network Service Analysis Spreadsheet Template Configuration Design Document Template Integration Design Spreadsheet Template
Page 44
Order and Service Management 7 Best Practices Guidelines October 2010 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright 2010, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. 0408

OSM 7 BestPracticesGuidelines PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

OSM 7 BestPracticesGuidelines PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Order and Service Management 7 Best Practices Guidelines

An Oracle White Paper November 2010

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

CRM CRM CRM

Central Order Management Service Order Management

Figure 1: Order Management and Provisioning Ma nagement functions

OSM 7 Features and Functions

OSM 7 Best Practices Guidelines

Run Time tools

Design Time tools

User Assignment Reporting Clustering

View Rules Framework Automation Framework

Orchestration Plan Manager

Oracle Communications Solution Components

Oracle Communications Tech. Platform

OSM 7 Best Practices Guidelines

(New, Revision, Follow-on)

Create/Update Trouble Ticket

Update Order & Status

Create/Update Customer Assets

Transform / Enrich Order Decompose & Route Order Components ;

Transform / Enrich Order

Order Status Management Update Order & Status

Order Management Sync Customer

Initiate Billing involves Various APIs * execution of multiple Billing actions

Transform / Enrich Order

Order Status Management

Order To Activate Integration Point

Order To Bill Integration Point

* Deliver Service involves execution of a provisioning flow

Figure 3: Order Fulfillment Process Overview

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM Implementation Framework

OSM 7 Best Practices Guidelines

Project Planning and Management

Project Planning and Management

Figure 4: OSM Implementation Framework

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

Phases Analysis Design Configure Verify Deploy

OSM Configuration Design

Verification Strategy and scripts

Functional & Process Verification Report

Deployment Readiness Report

User and Operations Guide

Production Deployment Status Report

Figure 5: OSM Implementation Deliverables

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

OSM 7 Best Practices Guidelines

Document Business Processes and Requirements

Identify the non-functional requirements

Identify Catalog groupings

Identify Services and Mappings

Review API capability

Review system data structures