|Oracle® Communications Order and Service Management Concepts
Part Number E35415-02
|PDF · Mobi · ePub|
An OSM application used to manage user workgroups, calendars and schedules, email notifications, and system events.
A generic term that refers to making changes to in-flight orders. Amendments are typically made when processing a revision order, or managing an order cancellation or order failure. The amendment usually performs compensation; such as redoing or undoing tasks.
The Oracle Application Integration Architecture. A set of Oracle products that enable you to set up and orchestrate cross-application business processes so that multiple applications can work together. OSM integrates with Oracle AIA for Communications. Oracle AIA runs on top of Oracle Fusion Middleware.
A set of OSM cartridges that integrate with the Oracle Communications Order to Cash Integration Pack for Oracle Communications Order and Service Management (Order to Cash Integration Pack for OSM). The Order-to-Activate cartridges and the integration pack enable OSM to be part of an order fulfillment solution that cover the entire order-to-activate process from order creation to service activation.
Automated Service Activation Program. An Oracle product used by communication service providers to activate operational support systems equipment across multiple technology domains. ASAP supports many hardware vendor's network systems, and is integrated with OSM using activation tasks.
A task that does not require manual activity. Automated tasks handle interactions with external systems such as billing systems, shipping systems, and activation systems. They can also perform custom calculations and other tasks. Automated tasks are implemented using automation plug-ins. See manual task.
An interface that enables the integration of OSM with external applications. It is used to automate tasks and notifications to other systems. It can also be used to perform business logic (such as performing complex calculations) without interacting with an external system. The automation framework is an OSM server component that performs the work required by automation plug-ins.
An OSM component that performs the operation specified by an automated task. For example, you can create automation plug-ins to update order data, complete order tasks with appropriate statuses, set process exceptions, react to system notifications and events, send requests to external systems, and process responses from external systems. These operations can involve communication with external systems. OSM provides several predefined plug-ins. You can also develop your own plug-ins using a custom template.
OSM behaviors allow you to control the validation and presentation of data elements in the OSM Web clients and data providers. For example, you can use the Calculate behavior to derive the value of the data in a field by adding the values in two other fields. You could use the Information behavior to present a tool tip for a field in the Task Web client.
A software package created in Design Studio to deploy functionality to an OSM run-time system. Cartridges contain order metadata such as recognition rules, processes, order states, behaviors, specification, and other entities used for order processing.
Cartridges are created with Design Studio, but Oracle also offers customized cartridges that support integration with other common applications (for example, the Oracle Communications Order to Cash Integration Pack for Oracle Communications Order and Service Management). Oracle also offers pre-configured cartridges that demonstrate the capabilities of OSM.
The OSM system role that receives customer orders from one or more order-source systems such as Siebel CRM, creates an OSM order, and manages the fulfillment of the order across other enterprise systems including billing, shipping, and service fulfillment systems. OSM operating in the central order management role also receives status information from these systems and provides visibility of an order's status back to the order-source system. The central order management role is sometimes called central fulfillment.
An OSM instance can operate in a central order management role or in a service order management role.
The fulfillment state list that is defined on the States tab of the fulfillment state map entity. The common fulfillment state list provides the values that can be used for both mapped fulfillment states and composite fulfillment states.
Changes that are made to accommodate revisions to in-flight orders (orders still being processed). For example, if a customer initially orders Bronze-level DSL service but upgrades to Gold-level service while the original order is in place, tasks may need to be done, redone, or undone. OSM automatically calculates the compensation required to accommodate the changes to orders.
OSM uses these types of compensation: Do, which is a change that needs to be made in addition to the original tasks. Redo, which is a change that needs to be made to redo work that was already performed by the order. Undo, which is a change that needs to be made to undo work that has already been done by the order. Amend Do, which is the same as Do, but performed during amendment processing.
Metadata in an orchestration order that is used to manage the execution of the orchestration plan. OSM extracts control data from an order. Control data provides information about order items, order components and dependencies required to create the orchestration plan. This includes status and timestamps for its order items and components. During the execution of an orchestration plan, the order data, including control data, can be updated as transactions are completed.
Design Studio automatically generates control data for order components. You manually model control data for order items.
The task that contains data required for the order. The creation task specifies what information must be provided to the order before it can start processing. This applies equally to manual order entry through the Task Web client as well as through OSM WS or XML APIs. A creation task is defined in the order specification.
In OSM Web clients, the creation task represents the step that creates and submits an order instance that starts the order workflow.
Customer relationship management. A system for managing a company's interactions with customers, clients and sales prospects; for example, Oracle's Siebel CRM. When used in OSM documentation, CRM refers to sales and order capture activities.
An order request received by OSM to obtain a product or products, typically generated by the CRM or some other order-source system. OSM converts the customer order to OSM format after which it is referred to as an order. Sometimes called an in-bound order.
The logical repository of data elements used in Design Studio. The Data Dictionary defines data types and structures that can be used within OSM orders. For example, you can define a simple type that represents an IP address or a phone number, or more complex types representing addresses, product attributes and so on. Data elements in a Data Dictionary are used as building blocks of an OSM order.The data elements within a Data Dictionary project can be referenced by other projects in a work space. Multiple data dictionaries can be used to contribute data structures to a single order definition. A single Data Dictionary can also contribute to multiple order definitions.
An entity viewable in Design Studio. When you model simple and structured data elements in the Data Dictionary, you can create new data elements that inherit their attributes from other existing data elements.The new data element can extend the information configured in the parent data element (also referred to as the base data element). For example, if you have a structured data element called person with first name, last name, and social security number child elements. You can extend the person structured data element by using it as a base for a new structured data element called employee, to which you add the employee number, hire date, and department child elements.
Simple data elements are reusable data types that contain no child dependencies. A simple data element has no structure, and is associated—directly or indirectly—to a primitive type (int, boolean, char, and so forth). Structured data elements are reusable data types and are containers of simple data elements and other structured data elements.
An adapter that can retrieve order data from external systems in an XML format. Design Studio provides several built-in data providers to retrieve external XML instances from specific sources such as a JDBC database or a SOAP Web service. Additionally, you can create your own custom data provider. Data providers are used when defining Data Instance behaviors.
The process by which a customer order is broken into constituent order items, which are then organized into order components. For example, OSM can use the following algorithm to achieve decomposition:
Map order items to functions (fulfillment function order components)
Map function order items to fulfillment systems (fulfillment system order components)
Map fulfillment system order items to processing granularity (granular order components)
The example above is representative of what OSM is normally configured to do for decomposition, but OSM is not restricted to these three stages. Decomposition is specified through configuration and can have any number of stages through which the order is decomposed.
Rules that determine the order items in each order component. Decomposition rules specify the conditions in which OSM decomposes one or more order components into another order component. OSM evaluates every order item in the source order component against the conditions that you define for the decomposition rule. If an order item passes all specified conditions, OSM includes the order item in the target order component.
Unlike many other OSM modeling entities, decomposition rules are not directly referenced by other parts of the model. OSM selects decomposition rules by matching the source and target order components of the decomposition rule to the order components in the orchestration stages in the orchestration sequence.
See also executable order component.
The first process that runs after an order is created. A default process can either be an orchestration process (which will be backed by a dynamically generated orchestration plan) or a workflow or workstream process.
A process activity that specifies that a process stops until a condition evaluates as true. In OSM there are two types of delays, timer delays and event delays. A timer delay retries the evaluation of the rule at a fixed time interval. An event delay retries the evaluation of the rule only when order data changes.
A relationship in which a condition related to one order component or order item must be satisfied before another order item can be processed. For example, it may be necessary to perform provisioning before billing can occur for the same order item. Dependencies can have the following relationships:
Between different order components for the same order item.
Between different order components for different order items.
Between order items across orders.
The software application used to design, configure, and deploy OSM Order Management cartridges into OSM environments. Design Studio is based on the Eclipse Integrated Design Environment (IDE). OSM plug-ins provide the specific screens (editors), validation logic, and cartridge-build functionality that allow users to create and configure OSM cartridges.
A functional unit created and edited in Design Studio; for example, tasks, processes, behaviors, projects, and notifications. Entities are collected in a cartridge to deploy in a run-time environment to support your business processes (for example, you deploy cartridges to OSM run-time environments.
Entity names must be unique by entity type. For example, you cannot name two task entities with the same name. However, you can create identical names for different entity types. For example, you can model a task entity and a process entity with the name
Entity names are sometimes defined just by a simple name (the filename of the entity), and sometimes by a simple name and a namespace URI. In the case where a namespace URI is provided, it is the combination of the URI plus the simple name that gives the entity its unique name.
See also data element.
An order component with an associated process. Typically this is a component decomposed to its final level of granularity. Executable order components are generated during the last orchestration stage in an order.
The amount of time an order, or some part of the order (order component, product specification or task), is expected to take to complete processing.
The date on which an order is expected to start being processed. Expected start date is determined for orchestration orders by calculating the expected order duration and factoring this in with the requested delivery date for order items on the order.
The status returned from a fulfillment system to an order component. This may be the exact status returned by the system, or automation may be used to translate the status before it is put on the order. It is a key input into a fulfillment state mapping.See also fulfillment state.
The failure of an order during processing. Fallout occurs whenever an order encounters a situation that prevents it from being processed. Causes for fallout include missing data or the inability to access a fulfillment system. Fallout management includes detecting, investigating, and resolving failed orders.
A mechanism initiated from the OSM Task Client to interrupt or stop an order, or to redirect it to any task in the same process or any other process. A fallout exception halts an order at a particular task in order to correct an error caused by a previous task.
A process that includes detecting, investigating, and resolving failed orders. Administrators perform fallout management with the OSM Web clients. The clients allow them to search for failed orders, identify the reason for the failure by viewing order details, and resolve dependencies to allow order processing to proceed. In cases where the dependency cannot be resolved, you can cancel or terminate the order.
An order that is submitted to modify a completed order. Follow-on orders are not processed until their order-item dependencies on the in-flight orders allow them to proceed.
Operations that fulfill a customer's order. This may be providing, modifying, resuming or canceling a customer's requested products and services.
Fulfillment functions are operations that must be performed to process an order item; for example, initiating billing, shipping, or performing installation. Fulfillment functions are defined in order component specifications created in Design Studio.
An entity that represents the intent of an order. For example, the fulfillment mode could indicate whether the order is intended for qualification, delivery to fulfillment systems, testing and so on. Every customer order can specify a fulfillment mode.
Different fulfillment modes will have different orchestration sequences. If OSM receives two identical incoming customer orders with different fulfillment modes, it generates a different orchestration plan for each order. The two plans include different executable order components with different dependencies among order items.
The state of an order or order item aggregated and translated from status values returned by external systems. This state can be used to provide status visibility to upstream systems and to users by using the Order Management Web client.See also common fulfillment state, composite fulfillment state, external fulfillment state, and mapped fulfillment state.
The Design Studio entity that contains both the definition of common fulfillment states and fulfillment state mappings. A common fulfillment state defined on one fulfillment state map is available to all fulfillment state mappings in the workspace.
A participating system in an order management solution. Fulfillment systems can include billing, provisioning, activation, shipping and workforce management systems, among others. OSM interacts with fulfillment systems when processing orders.
The arrangement of network elements, processes, systems, and software used to fulfill a customer order. The fulfillment topology represents the types and instances of fulfillment systems involved in fulfilling an order. For example, all of the Business Support Systems (BSS) and Operational Support Systems (OSS) that participate in order capture and order fulfillment represent the fulfillment topology.
An order that has a requested delivery date that is later than the current date and time. For example, a customer order to have a new VoIP service added at the beginning of the next month is a future-dated order. OSM uses the order orchestration plan to calculate the order start date of future-dated orders so the order can be completed by the time the customer wants it.
See customer order.
Any order that is not in a closed state (Closed or Aborted). An in-flight order still has the potential for further work to be performed on it.
A dependency between order items in different orders.
A dependency between order items in the same order. An intra-order dependency can refer to external information, but not to data in other orders.
Internet Provider Service Activator. An Oracle product used by communication service providers to define and fully automate the activation of services on large-scale multi-vendor IP networks. IP Service Activator delivers end-to-end network control and enables real time reaction to new service and customer demands.
See order line item.
Data definitions for entities such as processes, states, and rules modeled in Design Studio. OSM uses metadata to determine how to process order data. For example, OSM uses metadata from the product specification to determine how order items are to be grouped into order components in an orchestration plan.
A synonym for an entity name. Mnemonic is a legacy term for OSM. The proper name is entity name.
A data element that is permitted to have more than one instance. For example, you configure the ControlData/OrderItem structure as a multi-instance data element so that OSM can create an instance of the structure for every order line item extracted off the in-bound customer order.
1. An XML namespace is a method for uniquely naming elements and attributes in an XML document. Attributes and elements are identified by a fully qualified name that consists of a namespace name paired with the local attribute or element name.
2. An OSM entity namespace is a method for uniquely naming OSM entities across projects. Fully qualified OSM entity names consists of a namespace name paired with the local entity name. OSM entity namespaces allow different work groups of Design Studio users to create different entities without concern for name contention. Services can be implemented independently by a different teams, then deployed into a single OSM run-time environment.
Not every OSM entity has a separate namespace (example: tasks and processes). For these types of entities, a unique name is created by attaching the cartridge name and version number to the entity name.
3. An OSM cartridge namespace is a method for uniquely naming OSM cartridges. This allows you to identify what cartridge is deployed in an environment. For example, if you are diagnosing an order failure, it's useful to know the logic and configuration of the cartridge that processed that order. Fully qualified cartridge names consist of a namespace name paired with the cartridge name.
You can view namespaces and other details about an entity or cartridge through Design Studio.
Messages sent by OSM to alert users of order problems (jeopardy notifications) or changes to an order's state, status or data (event notifications). By default, OSM sends most types of notifications to the Task Web client Notifications page. You can also specify that notifications be sent by e-mail.
Oracle's application server for building and deploying enterprise Java EE applications. The Oracle WebLogic Server hosts the OSM server, OSM integration, and related interfaces.
The process OSM uses to manage the fulfillment of a complex order. Order fulfillment often requires interaction with many fulfillment systems. Various dependencies may require that these interactions be run in a specific order to ensure that order items are sent to the proper systems, and that the required steps, in the proper sequence are run.
An order that requires an orchestration plan for fulfillment. Orchestration orders contain control data for an orchestration plan. The default process for an orchestration order is an orchestration process. See process-based order.
A dynamically generated plan that is used to manage the fulfillment of an order. Order fulfillment often requires interaction with many fulfillment systems, and various dependencies may require that these interactions be run in a specific order. The orchestration plan includes the order, order component, and the type and the sequence of order component execution. An orchestration plan is generated for each order based on the metadata defined for the type of order being processed.
For example, an order is captured by Siebel CRM and is sent to OSM for processing. Using the recognition rules and other entities provided by the OSM cartridges in the Order to Cash Integration Pack for OSM, OSM decomposes the order and dynamically generates an orchestration plan that is used to manage the fulfillment of the customer's order across other enterprise systems.
A set of orchestration stages for an order. Orchestration sequences specify the set of orchestration stages for an order. Orchestration stages and sequences together define how an order is decomposed.
A step in an orchestration sequence used to decompose an order and create an orchestration plan.
An order in the OSM format. You model orders by creating order specifications in Design Studio.
There are many order variants including:
A collection of order items that can be processed together because they meet some common criteria as determined by an orchestration stage. Order components are modeled in Design Studio, based on factors such as a function that needs to be performed, the systems that need to perform that function, and what other items can be processed in the same group.
An ID associated with an order component that can be used in decomposition. When implementing fulfillment systems; for example, you can configure OSM to achieve decomposition by using decomposition rules or by using the component IDs of the order items. For example, a decomposition rule can select order items from fulfillment system order components and group them into an order component to create a single bundle. OSM can then use an order component ID calculation to generate distinct bundle instances.
Uniquely identifies a data element or structure in an order by differentiating the data element or structure based on a data element value. Order data keys are important when identifying order data changes during compensation and for multi-instance data elements.
See order specification.
See expected duration.
See order specification.
Orders typically consist of two parts: an order headers containing information that is applicable to the entire order such as the customer name and address, and order line items such as the products, services, and offers requested by the customer and the action to be performed on them (Add, Suspend, Delete, Move, and so on).
An order line item transformed so that it can be processed in OSM. Each order item includes the action required to implement it, such as Add, Suspend, and Delete. Order items are decomposed into order components based on shared characteristics defined in a product specification.
See also order component.
The Design Studio entity used to aggregate and evaluate the fulfillment states of order component order items and child order items and compose them into a single composite fulfillment state for the entire order item.
Unique value that enables the system to match incoming revision orders to the corresponding OSM order. If the order key matches an order that is currently in progress, the order is considered to be a revision that amends a base order. For example, you can specify to use the customer reference ID as the order key. In that case, when OSM processes an order, it looks for previous orders that have the same customer reference ID, and amends it.
The order key can be any data or combination of data associated with the order. It is configured in Design Studio as an XPath expression to a data element that will uniquely match an amended order to its corresponding OSM order. For example, you might specify a customer reference ID as the following Xpath expression:
The sequential states through which an order passes and the transactions it undergoes from the time it is received in OSM until the time it is resolved. States include Not Started, In-progress, Suspended, and Completed. Each order state is associated with a set of transactions that can be performed while the order is in that particular state. Transactions include Update Order, Cancel Order, Complete Task, and Raise Exception. The life cycle of an OSM order is governed by the order state model and order life cycle.
A set of policies that controls the states in which an order can be, and the transactions allowed in those states. The order life-cycle policy also determines which roles can perform which transactions. For example, while an order is in the In Progress state, you might want your Customer Service role to be able to perform the Update Order, Cancel Order, and Suspend Order transactions, while your Fallout role is able to perform the Raise Exceptions transaction. Every order type you create must be associated with an order life-cycle policy.
An OSM web application that displays an order's orchestration plan, including dependency, orchestration stages, order components, order items, and processes. The Order Management Web client is used by fallout administrators responsible for locating orders with errors, determining the causes of failures, and taking the necessary corrective actions; operations and management personnel who monitor the progress of orders; and orchestration plan designers who can use this application to test and validate orchestration-based orders during the modeling and implementation of OSM solutions.
A value that OSM uses to determine which orders should be given more processing resources. OSM uses order priority to determine the next thing to be done. Orders with higher priority will be processed before orders with lower priority. In situations where resources are constrained (for example, the system is using all available CPU, memory, or other resources to process orders), orders with higher priority will process faster than orders with lower priority.
The process of determining the type of an incoming customer order so it can be mapped to an order specification in OSM. During order recognition, OSM steps through an ordered list of recognition rules to determine which rule applies to the customer order. Each rule is associated with an order specification.
A value associated with an order specified in one of the OSM Web clients or OSM APIs. OSM uses an order reference number as an identifier to external systems. Reference numbers can be used as keys to correlate orders between systems.
An order entity defined in Design Studio. The order specification is the central entity in OSM. It defines the basic information OSM requires for it to be able to process orders. It specifies such things as what data is allowed in an order (order template), what are the range of order priorities, whether amendments are allowed and how they are processed, how to handle jeopardy, fallout, permissions and so on.
Other entities such as tasks, processes, and notifications require that you specify an order specification to which it relates. Order specifications can inherit from other order specifications, and multiple order specifications can be modeled and can exist simultaneously. Also known as an order definition and order entity.
OSM processes each order within a set of order states. A state is the condition of the order. For example:
An order is created in the Not Started state.
When processing begins on the order, the state changes to the In Progress state.
When the order is complete, it transitions to the Completed state.
See order life cycle.
Changes from one order state to another order state as a result of a transaction. Each order state has a set of allowable transitions. For example, when an order is completed, it transitions from the In Progress state to the Completed state.
A part of an order specification that defines what order data OSM will use to process and fulfill the order. For example, the order template defines the data required for order items as well as the data required in an order header. Create or modify order templates by adding data elements from one or more data dictionaries.
The manipulation and enrichment of the structure and contents of a customer order through a set of rules. Transformation rules are defined as part of recognition rules, and are based on applying a series of XQueries to the in-bound order.
Three types of transformation rules are available: order priority rules, which define the priority of the order in relation to others; order reference rules, which define the order reference number; and order data rules, which add to or modify incoming customer order data.
A process that occurs during order recognition that validates that an order is syntactically correct. When an inbound order is recognized, OSM validates it based on validation rules defined in the order recognition rule.
For example, a validation rule can determine that all mandatory fields are populated, that valid characters (numeric or alphanumeric) are used for fields, and that the order has a valid status code such as Open. Validation rules are implemented as XQuery expressions. Each node in the expression must evaluate to true for validation to pass.
The primary interface for external systems to OSM. The OSM order management Web services provide for in-bound order operations such as creating, managing, retrieving, updating, or canceling an order. Web services are Web APIs that support interoperable machine-to-machine interaction over a network such as the Internet. Web services run on a remote system hosting the requested services such as OSM. Web service interfaces are described by the Web service definition language (WSDL).
A callback interface that allows you to generate an audit trail log of users before they gain access to order data that is considered sensitive. The security callback interface is designed to intercept order access from defined functions such as GetOrder, XML API WorkList.Request, and Task Web client Order Data History page.
The two OSM GUI applications called the Order Management Web client and the Task Web client. The Order Management Web client displays an order's orchestration plan, including dependency, orchestration stages, order components, order items, and processes. The Task Web client is used for monitoring and managing the tasks in an order.
The point in the orchestration of an order item after which revisions can no longer be accepted.
A sequence of tasks and subprocesses that need to be carried out to fulfill all or part of an order. For example, an ADSL fulfillment process could include the following tasks that can take place over a number of days: assign a port, ship modem to customer, activate DSLAM, send customer survey, and verify order. The process includes definitions of the relationships between tasks and the sequence in which they are run.
An order that does not include an orchestration plan. A process-based order typically handles a provisioning process. See orchestration order.
Decomposition groups order items into optimally executable order components. For example, if monthly fees, VoIP adapter, and VoIP phone are all billed by the same billing system, they can be grouped into a single executable order component. This is called processing granularity. See decomposition.
A data repository that stores and retrieves information about your products including price lists, discount lists, and unit groups. The product catalog is used to create customer orders. Sometimes called the master product catalog. The product catalog exists on the CRM or other order-source system. An example of a product catalog is the Siebel Sales Catalog or Oracle Product Information Management Data Hub for Telco.
Groups of related products that share common attributes. For example, suppose you sell products for three levels of DSL service. Though there are different values to differentiate the service levels, the products are structurally identical and provisioned by the same system; they are variations of the basic DSL service. As a result, a single product-class to product-specification mapping can be used for all of them.
Product classes are defined in a product catalog such as the Siebel Sales Catalog or Oracle Product Information Management Data Hub for Telco.
An entity that includes the fulfillment function order components and dependencies required to fulfill a product order. Each order item in an order is mapped to a product specification. OSM uses the product specification to determine the necessary fulfillment functions, order components, the dependencies that exist between them, and dependencies on other product specifications to generate an orchestration plan.
Providing the data necessary for enabling a service, with the actual enabling done by activation.
Rules that enable OSM to validate a customer order and transform it into an OSM order format.
An order that contains order items that depend on another order.
A tool for generating reports about OSM orders, tasks, and notifications. The Reporting Interface augments the reports that are available through the OSM Web clients. See OSM Reporting Interface Guide for more information.
An order that modifies a previously submitted order that is still being processed. For example, a customer may want to switch to a higher level of service before an order is completed. Revision orders may require compensation. The system can process revision orders until the original order reaches its point of no return. A revision order is sometimes called a supplemental order.
See also follow-on order.
A set of permissions to access to functions in the Task Web client and Order Management Web client that can be assigned to users. Functions include viewing reports, assigning tasks, and querying orders. In addition to granting OSM Web client permissions, you can also grant permissions at the order and task levels. Roles are created with the OSM Administrator application or Design Studio. The Administrator application refers to roles as workgroups, although they are both the same thing.
Rules are defined as part of an order specification to work on data in the order. Rules are used in many OSM activities to evaluate conditions and determine next process steps. For example, you can specify to delay the next task in a process until a specified data element includes a certain value.
A processing component of OSM that evaluates rule and timer delays for transition to the next task. The engine is implemented as one or more Oracle database jobs. The rule engine is configured as one or multiple jobs to improve performance.
An order received by an OSM instance acting in the service order management role.
The OSM system role that serves as part of a service fulfillment stack, working with inventory and activation systems to fulfill services in one or more network domains. An OSM instance can operate in a service order management role or in a central order management role. Sometimes called local fulfillment.
See order specification.
An individual step that is required for the processing of an order. Tasks are defined by the order specification in Design Studio, and can be either a manual task (performed by human action) or automated task (performed by an automation plug-in).
Tasks are run as part of any process-based order. For example, a completely process-based order consists of a series of steps which are defined by tasks. By contrast, an orchestration order starts out as orchestration plan. Each order component within the orchestration plan is implemented by a subprocess which in turn contains tasks and other subprocesses.
A state describing the milestones of a task in a process. The task state also determines how it can be worked on. OSM provides the following task states: Received, Assigned, and Accepted. You can, however, create your own task states. For example, you can define a Suspended task state to indicate the progress of automated tasks, or you can define a Completed task to indicate that user is finished with the task and the order is ready to move to the next task in the process.
A representation of how a task can transition to the next step in a process. The task status shows how the task transitions in a process; for example, if the task transitioned the process to the next task, or if it caused the process to fail. Changing the status of the task determines the next step in the order process. The statuses that you define appear as task transition options in the OSM Web clients.
For example, if you have a task called Assign Port, and the two statuses are Port Available and Port Unavailable, the status determines whether the process can proceed to the next task. Task status also controls notifications, so when the status is Port Available, OSM can send a message saying Successful.
An OSM GUI application used for monitoring and managing the tasks in an order. This application is typically used by order processing personnel to ensure that all the tasks are completed. It is also used by order fallout managers. You can also suspend and resume orders, cancel orders, and create orders manually.
An action taken by the OSM system on an order. For example, the Suspend Order transaction stops all processing on the order and transitions the order to the Suspended state. Also called an order state transaction
Some other transactions are Abort Order, Complete Task, Process Amendment and Raise Exception. Most transactions perform transitions that change the state of the order to a different state. However, some transactions do not perform a transition to another state. For example, the Update Order transaction can make changes to an order without changing the order's state.
A request to the trouble ticketing system indicating that an error occurred during the processing of an order. Different from a fallout task in that trouble tickets come from front-end systems such as Siebel CRM.
A dependency with at least one unmet condition.
A group of users with assigned permissions to access to functions in the Task Web client and Order Management Web client. Functions include viewing reports, assigning tasks, and querying orders. In addition to granting OSM Web client permissions, you can also grant permissions at the order and task levels. Workgroups are created with the OSM Administrator application or Design Studio. Design Studio refers to workgroups as roles, although they are the same thing.
A list of manual tasks assigned to OSM operations personnel who use the Task Web client to manage orders. When an order arrives at a task, it is added to the worklist of all the members of all the workgroups assigned to work on that task. Users can select a task from their worklist to view the assigned task in the order process. Worklist also refers to the main page in the Task Web client used for managing orders.