Order Management System Decoupling Fulfillment Flow from Topology

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing computer systems used in telecommunications and other industries face challenges in managing dynamic orders due to frequent changes in product offerings and increased complexity, making static executable processes inefficient and costly to modify.

Innovation Solution

A computer-readable medium with instructions that decouple the fulfillment flow from the fulfillment topology, allowing for the partitioning of orders into components using decomposition sequences and routing rules, and generating an orchestration plan that includes fulfillment topology information to dynamically manage order fulfillment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a single static executable process is used to fulfill orders, then the system is simple to implement and maintain, but it cannot handle dynamic orders and frequent product changes effectively

Engineering Contradiction:

Improveability to handle dynamic orders and frequent product changesVSAvoidsystem architecture complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the order fulfillment system into multiple independent executable processes, each responsible for specific product lines or order types. This allows the system to handle diverse and dynamic orders through specialized processes rather than a single monolithic process, improving adaptability while maintaining manageable complexity through modular design.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent introduces dynamic process selection and routing mechanisms that allow the system to adapt to changing order requirements in real-time. Executable processes can be dynamically selected, activated, or deactivated based on current product offerings and order characteristics, enabling the system to respond to frequent product changes without requiring complete system reconfiguration.

Inventive Principle:

Principle #15Dynamics

2Adaptability or versatility

If source code modifications are made frequently to handle new product offers, then the system can adapt to changing product offerings, but the modification time and costs increase significantly

Engineering Contradiction:

Improveability to accommodate new product offersVSAvoidsource code modification time

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements preliminary configuration and template-based process definitions that allow new product offers to be accommodated through pre-prepared process templates and configuration files. When new products are introduced, the system can instantiate new executable processes from existing templates rather than requiring de novo source code development, significantly reducing modification time.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent utilizes parameter-driven process configuration where executable processes accept dynamic parameters and configurations rather than hard-coded logic. This allows the system to adapt to new product offers by changing process parameters and configuration data rather than modifying source code, enabling rapid adaptation without programming efforts.

Inventive Principle:

Principle #35Parameter changes

3Adaptability or versatility

If a static executable process is used, then development and maintenance costs are low, but the system cannot handle bundled products requiring different fulfillment sequences

Engineering Contradiction:

Improveability to handle bundled products with different fulfillment sequencesVSAvoidorder fulfillment efficiency

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent implements local quality by creating specialized executable processes tailored to specific product bundles and fulfillment requirements. Each process is optimized for its specific function and product type, allowing different fulfillment sequences to be handled by appropriately specialized processes rather than forcing all orders through a single generic process sequence.

Inventive Principle:

Principle #3Local quality

Solution Approach 2:

The patent introduces an intermediary process selection and routing layer that determines which executable process should handle each order based on product bundle characteristics and fulfillment requirements. This intermediary mechanism efficiently directs orders to the most appropriate specialized process, maintaining high productivity while handling diverse fulfillment sequences.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS10373217B2Order management system with decoupling of fulfillment flow from fulfillment topology

Publication Date: 2019.08.06 ORACLE INT CORP

AI summary

An order management system is provided. The order management system creates the fulfillment flow, where the fulfillment flow does not include any fulfillment topology information. The order management system partitions an order into one or more order components using a decomposition sequence, where the decomposition sequence include one or more routing rules, where each routing rule includes fulfillment topology information, and wherein each routing rule determines a target fulfillment provider. The order management system generates an orchestration plan for the order by applying one or more dependencies of the fulfillment flow and the one or more routing rules to the one or more order components, wherein the orchestration plan includes the fulfillment topology information.