SUPPLY CHAIN ORCHESTRATION SYSTEM WITH ORCHESTRATION, CHANGE MANAGEMENT AND INTERNAL MATERIAL TRANSFER FLOW
A system is provided that orchestrate a supply chain orchestration process. The system receives a supply request and creates a supply order. The system further selects a supply chain orchestration process for the supply order, where the supply chain orchestration process includes one or more steps. The system further generates an executable supply chain orchestration process. The system further executes the executable supply chain orchestration process to generate one or more supply tasks that are defined by the one or more steps of the supply chain orchestration process. The system further sends the one or more supply tasks to one or more external supply execution systems. The system further receives one or more status values from the one or more external supply execution systems. The system further generates an overall status value for the supply chain orchestration process based on the one or more status values.
Latest Oracle Patents:
- MANAGING DIGITAL MESSAGE TRANSMISSION VIA A PROXY DIGITAL MAILBOX
- END-TO-END NETWORK ENCRYPTION FROM CUSTOMER ON-PREMISE NETWORK TO CUSTOMER VIRTUAL CLOUD NETWORK USING CUSTOMER-MANAGED KEYS
- MODEL MINING AND RECOMMENDATION ENGINE WITH SIMULATION INTERFACES
- AUTHORIZATION FRAMEWORK IN A MULTI-CLOUD INFRASTRUCTURE
- ENTITY FOCUSED NATURAL LANGUAGE GENERATION
This application claims priority of U.S. Provisional Patent Application Ser. No. 61/707,668, filed on Sep. 28, 2012, the subject matter of which is hereby incorporated by reference.
FIELDOne embodiment is directed to a computer system, and more particularly, to a computer system that orchestrates supply chain processes.
BACKGROUNDAs supply chains become global, and manufacturers rely on partners to supplement their capabilities, manufacturers face several limitations of enterprise resource planning software and supply chain software. The limitations include: (1) working only within the “four walls” of a single enterprise; (2) only implementing pre-defined business processes that are difficult to change without extensive coding; and (3) failing to provide integrated visibility across all activities associated with a creation of supply. Further, such enterprise resource planning software and supply chain software often require extensive coding changes to handle demand change and supply side exceptions.
Further, an internal material transfer is a business process used in business organizations to transfer material (e.g., products produced or procured by a business organization) from one division of a business organization to another. An example is an East Coast region of an organization transferring a product to a west coast region of the organization. Another example is a U.S. region of an organization transferring a product to an Asian-Pacific region of the organization. Most existing ERP systems support this business process, using a variety of documentation to process and track the transfer of internal material. Some existing ERP systems use a document called a “Transfer Order” document to process and track internal material transfers. Other existing systems use pairs of documents such as “Internal Requisitions/Internal Sale Orders” or “Purchase Orders/Sales Orders” to process and track internal material transfers. Conditions that dictate the appropriate document or document pair to generate are generally hard-coded into the logic in these systems. Some existing systems have limited configurability to control this logic. Business users typically adapt to this limitation by either customizing or changing their business processes to conform to this limitation.
SUMMARYOne embodiment is a system that orchestrates a supply chain orchestration process. The system receives a supply request and creates a supply order. The system further selects a supply chain orchestration process for the supply order, where the supply chain orchestration process includes one or more steps. The system further generates an executable supply chain orchestration process. The system further executes the executable supply chain orchestration process to generate one or more supply tasks that are defined by the one or more steps of the supply chain orchestration process. The system further sends the one or more supply tasks to one or more external supply execution systems. The system further receives one or more status values from the one or more external supply execution systems. The system further generates an overall status value for the supply chain orchestration process based on the one or more status values.
Further embodiments, details, advantages, and modifications will become apparent from the following detailed description of the preferred embodiments, which is to be taken in conjunction with the accompanying drawings.
According to an embodiment, a supply chain orchestration system is provided that can orchestrate a supply chain orchestration process for a supply request, where the supply chain orchestration process can include multiple supply tasks, and where each supply task can be executed at a separate external supply execution system. The supply chain orchestration system can further modify the orchestration of a supply chain orchestration process in response to a change in the supply request by an external supply request system or a change to the supply chain orchestration process by one or more external supply execution systems. The supply chain orchestration system can further automatically select an execution document from a plurality of execution documents based on execution rules, where the execution document is created as part of the orchestration of the supply chain orchestration process.
A computer-readable medium may be any available medium that can be accessed by processor 22. A computer-readable medium may include both a volatile and nonvolatile medium, a removable and non-removable medium, a communication medium, and a storage medium. A communication medium may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any other form of information delivery medium known in the art. A storage medium may include RAM, flash memory, ROM, erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.
Processor 22 can also be operatively coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”). Display 24 can display information to the user. A keyboard 26 and a cursor control device 28, such as a computer mouse, can also be operatively coupled to bus 12 to enable the user to interface with supply chain orchestration system 10.
According to one embodiment, memory 14 can store software modules that may provide functionality when executed by processor 22. The modules can include an operating system 15, a supply chain orchestration module 16, as well as other functional modules 18. Operating system 15 can provide an operating system functionality for supply chain orchestration system 10. Supply chain orchestration module 16 can provide functionality for orchestrating a supply chain orchestration process, modifying the orchestration of a supply chain orchestration process, or applying one or more execution rules to automatically select one or more execution documents, as is described in more detail below. In certain embodiments, supply chain orchestration module 16 can comprise a plurality of modules that each provide specific individual functionality for orchestrating a supply chain orchestration process, modifying the orchestration of a supply chain orchestration process, or applying one or more execution rules to automatically select one or more execution documents. Supply chain orchestration system 10 can also be part of a larger system. Thus, supply chain orchestration system 10 can include one or more additional functional modules 18 to include the additional functionality. For example, functional modules 18 may include modules that provide additional functionality, such as an “Oracle Fusion Applications” product from Oracle Corporation. In another example, functional modules 18 may include enterprise resource planning (“ERP”) modules of an ERP system, where an ERP system is a computer system that integrates several data sources and processes of an organization into a unified system.
Processor 22 can also be operatively coupled via bus 12 to a database 34. Database 34 can store data in an integrated collection of logically-related records or files. Database 34 can be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigational database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, or any other database known in the art.
Supply Chain OrchestrationAccording to an embodiment, a supply chain orchestration system is provided that enables a user to define and execute complex supply chain orchestration processes that can span over one or more external supply execution systems, such as ERP systems. Examples of supply chain orchestration processes that the supply chain orchestration system can define and execute include single- or multi-party contract manufacturing; order-specific supply creation (commonly referred to as “back-to-back”); complex, multi-stage transfer of material; rule-based or results-based multi-stage manufacturing; or complex purchases. Features of the supply chain orchestration system that can enable these features include: a decomposition layer that can transform and store incoming supply creating requests into a unified structure that facilitates the application of customer-specific orchestration processes; an orchestration layer that can author and maintain a library of orchestration processes, and that can apply one or more of the orchestration processes to a specific supply order, based on one or more rules; a business services layer (also identified as a task services layer) that can communicate with one or more external supply execution systems to create and update execution documents (such as manufacturing work orders, shipping requests, purchase orders, etc.) within each of the external supply execution systems, and can track the life-cycle progress of the supply orders in each of the external supply execution systems; and automated, rule-based handling of any exceptions (such as a supplier changing the quantity or date on a purchase order). By combining these capabilities, the supply chain orchestration system can provide capabilities to have end-to-end visibility into a supply chain orchestration process, sense exceptions that happen during the execution of supply creation, and take corrective actions to ensure the alignment of supply creation with a company's business goals.
As previously described, existing ERP and supply chain systems typically face several limitations including: (1) working only within the “four walls” of a single enterprise; (2) only implementing pre-defined business processes that are difficult to change without extensive coding; and (3) failing to provide integrated visibility across all activities associated with a creation of supply. According to an embodiment, a supply chain orchestration system can overcome these limitations by enabling a user to: (a) define supply chain orchestration processes specific to business practices of a user's company or group; (b) track a life-cycle of each execution document to enable the user to see progress of each supply chain orchestration process involved in supply creating; (c) execute supply creation across multiple heterogeneous external supply execution systems; and (d) have a single, unified workbench to provide a 360-degree view of the supply orders and perform execution management when supply creation activities are at risk of not being completed on time.
In accordance with the embodiment, a supply chain orchestration system can include: (1) a decomposition layer that can convert any type of supply request into a rationalized structure (i.e., supply order structure) that facilitates rule-based orchestration; (2) an orchestration layer that can author external supply execution system-agnostic orchestration processes and apply them to the supply order structure; and (3) a business service layer that can communicate with any external supply execution system to perform tasks created by the orchestration layer, and can collect the progress and perform change management to ensure the success. These layers are further discussed below in greater detail.
As described in this application, a supply request is a request to either make, buy, or transfer a supply (i.e., one or more items or products). A supply request can be sent by an external supply request system. A supply order is an order to make, buy, or transfer the supply. A supply order can be orchestrated by a supply chain orchestration system, where the supply chain orchestration system can identify one or more external supply execution systems that can satisfy or fulfill the request for the supply. An external supply execution system can be a purchasing system that can purchase the supply, a manufacturing system that can make the supply, or a transfer system that can effectuate an internal or external transfer of the supply. The supply chain orchestration can orchestrate and manage the overall supply creation process.
Supply chain orchestration system 200 further includes a decomposition layer 220. Decomposition layer 220 receives the supply requests that are generated by supply requests layer 210 as input, and coverts each supply request into a supply order, where a supply order is a canonical representation of a supply request with a canonical format. Decomposition layer 220 is further described below in greater detail, in conjunction with
Supply chain orchestration system 200 further includes an orchestration layer 230. Orchestration layer 230 provides individual supply chain orchestration processes that manage supply orders. A supply chain orchestration process can provide supply chain process management functionality for implementing one or more steps within a process. A supply chain orchestration process can further provide external task execution functionality to support one or more external tasks, where external tasks can be executed by external supply execution systems. More specifically, business services (or task layer services) can do specific processing and then send data to the external supply execution systems. Thus, orchestration can be a sequence of business layer service invocations.
According to an embodiment, a supply chain orchestration process can be defined by a user of the supply chain orchestration system 200. More specifically, a user can model a supply chain business process, where the supply chain business process can identify one or more business services that define steps to be performed in the supply chain business process. A run-time engine can then use the defined supply chain business process to dynamically invoke the business services based on the definition of the supply chain business process.
Particular embodiments allow an administrative environment outside of a code editor, such as a business process execution language (“BPEL”) editor, for defining processes using associated services. Users can configure processes that can be executed at runtime as executable processes. This alleviates the need for deploying the processes every time a modification of the business process is needed. The user sets up the sequence of services on a data table. The modeled business process is then used to perform an executable process (also identified as an orchestration process), which is assembled and executed at run-time. In one embodiment, “run-time” can be defined as the time when a supply order is received for processing. Metadata is assembled in a data runtime table and used to define the executable process for the business process. The metadata is used to invoke services in the executable process.
In one embodiment, the services invoked are encapsulated and reusable. The metadata is used to determine how and when to invoke services. Also, depending on the metadata, input arguments are generated and sent to the services to invoke the encapsulated service. A common signature is used to send data to invoke the services. Different input arguments can be formulated for different services used in different executable processes. The input arguments are formatted in the same way such that a service can read the different sets of data and invoke the service. Thus, services can be re-used in different business processes without the need to be recoded and redeployed. Deployment of services indicates the process is ready to be released for testing or production.
Orchestration layer 230 may also provide for forward planning and jeopardy management in order to check a promised delivery date of a supply order against current estimated date for completion, map to user-defined thresholds, and handle or escalate conditions. More specifically, when a deviation from a task plan happens (e.g., a task was supposed to have been completed by November 15, but is now late), orchestration layer 230 can assess the deviation's effect on the entire supply chain orchestration process so that supply chain orchestration system 200 can determine how the delivery of the end product will be affected, and manage any fallout.
Orchestration layer 230 may further provide for change management to compensate for a change (such as bring a plan in line with an acceptable business schedule when a task deviates from the plan). In an embodiment change management and split management functionalities can also be associated with a supply chain orchestration process, where change management and split management functionalities can control how supply chain orchestration system 200 addresses changes that originate from a supply side (e.g., a supplier changed the quantity he is willing to ship on a purchase order), or a demand side (e.g., a customer now wants only 50 items, as opposed to an original order quantity of 75). Orchestration layer 230 is further described below in greater detail, in conjunction with
Supply chain orchestration system 200 further includes a business services layer 240. Business services layer 240 prepares execution system-specific messages that include instructions on tasks to be performed, and sends these messages to various external supply execution systems through services provided by the external supply execution systems. Business services layer 240 can provide the functionality through multiple encapsulated services. Business services layer 240 further collects a progress of tasks assigned to the external supply execution systems by listening to events raised by the external supply execution systems and processing them through the logic built into various execution system-specific task layers, such as task layers for purchasing systems, task layers for inventory systems, task layers for manufacturing systems, task layers for logistics systems, task layers for order capture systems, etc. A connection to the external supply execution systems can be brokered by an enterprise integration layer. Business services layer 240 is further described below in greater detail, in conjunction with
Supply chain orchestration system 200 further includes a supply execution systems layer 250. Supply execution systems layer 250 is a layer that is external to the supply chain orchestration system 200, and supply execution systems layer 210 includes one or more external supply execution systems that execute tasks based on messages that include instructions to execute such tasks that are sent by supply chain orchestration system 200 via business services layer 240. Example external supply execution systems include purchasing systems, logistics systems, manufacturing systems, and other third-party systems.
Supply chain orchestration system 200 further includes a workbench 260, where workbench 260 is a user interface for administrators, user, and supervisors to monitor and manage the flow of supply orders through supply chain orchestration system, including the tasks and the relationship among them. Workbench 260 can also identify the tasks that are at risk of getting delayed, and can give a user an ability to take corrective action. Workbench 260 is further described below in greater detail in conjunction with
As is described below in greater detail, supply tracking line 323 can be assigned to orchestration process instance 340, where orchestration process instance 340 is an instance of orchestration process definition 330. As is also described below in greater detail, orchestration process definition 330 is an object that defines an orchestration process, such as a supply chain orchestration process, where an orchestration process is a business process that can be executed at run-time as an executable process, where the business process includes one or more steps that take an order, such as a supply order, through an execution process, such as a supply execution process, and each step can execute a task using a service. Thus, orchestration process definition 330 includes step definition 331, which is an object that defines a step of orchestration process definition 330, task definition 332, which is an object that defines a task associated with the step defined by step definition 331, and service definition 333, which is an object that defines a service used by the task defined by task definition 332. Orchestration process definition 330 can further include a sequence of steps, where each step is defined by a step definition, such as step definition 331. Further, orchestration process instance 340, which is an instance of orchestration process definition 330, includes a step instance 341, which is an instance of a step defined by step definition 331 of orchestration process definition 330, and a task instance 342, which is an instance of a task defined by task definition 332.
Further, according to the embodiment, one or more execution documents, such as transfer order 350, work order 360, and purchase requisition 370, can be created based on supply order 320. Supply exception messages 381 can also be generated, where a supply exception message is a message generated when an orchestration of supply order 320 (via a supply chain orchestration process) raises an exception. Further, evaluate financial transfer rules 382 can be generated, where a transfer rule generates a transfer price for supply order 320. In addition, evaluate execution rules 383 can be generated, where an execution rule selects an execution document that can be generated by supply order 320. Further, change management rules 384 can be generated, where a change management rule adjusts a supply chain orchestration process based on a change that is sent by either an external supply request system or an external supply execution system. Supply order 320 can further provide a relationship between one or more supply chain nodes within a supply network model 390.
The flow begins, and proceeds to 410. At 410, a supply request that is received by a supply chain orchestration system from an external supply request system is validated. According to the embodiment, the supply request can include a payload, where the payload is a data structure that can include one or more attributes, and where each attribute can include a value. The validation can include determining whether one or more attributes that are indicated as mandatory attributes include valid values. Example mandatory attributes can include a supply request source attribute, a supply request record number attribute, a requested supply type attribute, and/or a requested quantity attribute. If one or more of the mandatory attributes do not include valid values, an error message is raised, and the flow ends. Otherwise, the flow then proceeds to 420. Optional validation can further include eliminating supply requests that are sales order reschedule recommendations.
At 420, it is determined whether the supply request is a request to create a supply (i.e., create a supply order) or to modify a supply (i.e., modify a supply order). In certain embodiments, the payload of the supply request can explicitly indicate whether the supply request is a request to create a supply or a request to modify a supply. This indication can be populated within an attribute of the payload, such as within a supply operation attribute. In other alternate embodiments, the payload of the supply request does not explicitly indicate whether the supply request is a request to create a supply or a request to modify a supply. In these embodiments, it can be derived from one or more attributes of the payload of the supply request whether the supply request is a request to create a supply or a request to modify a supply. Further, in these embodiments, after the derivation, an indication whether the supply request is a request to create a supply or a request to modify a supply can be stored within an attribute of the payload, such as within a supply operation attribute. The flow then proceeds to 430.
At 430, one or more attributes of the payload of the supply chain request are validated. More specifically, it is determined whether all attributes necessary for document creation include valid values.
In another example embodiment, the following are the essential attributes that are required to include valid values while receiving a payload for creating a new transfer order:
In another example embodiment, the following are the essential attributes that are required to include valid values while receiving a payload for creating a new transfer order:
In another example embodiment, the following are the essential attributes that are required to include valid values while receiving a payload for creating a new make order:
If one or more of the attributes necessary for document creation do not include valid values, an error message is raised, and the flow ends. Otherwise, the flow then proceeds to 440.
At 440, a requested supply type of the supply request is determined. A supply type of a supply tracking line can be determined based on the requested supply type of the supply request.
In one embodiment, if the requested supply type” is “Transfer,” then execution rules can be invoked to identify whether the supply type of the supply tracking line is a “Buy” or “Transfer”. If the requested supply type is “Transfer”, then a transfer process can be carried out through a transfer order execution document or through a purchase requisition execution document. This can be governed by execution rules. If there is a buy-sell relationship defined between the source and destination organizations or if they are in different legal entities, then the execution document can be a purchase requisition execution document. Otherwise, it can be a transfer order.
The execution rules can determine an execution document type by invoking a service. This service can be called with the inputs from the payload, and can return the execution document type as either a transfer order execution document or purchase requisition execution document, and can also return a supplier identifier and supplier site identifier in case of a purchase requisition execution document. A suggested vendor identifier attribute, a suggested vendor name attribute, and a suggested vendor site identifier can be populated based on the output of the service, and a supply attribute can be populated based on an output document type attribute. For example, if a document type attribute has a value of “XFER-Transfer,” then the supply type attribute can be populated with a value of “Transfer.” As another example, if an document type attribute has a value of “BUYSELL-Purchase Order”, then the supply attribute can be populated with a value of “Buy.” Details of input and output of the service are summarized below.
Get Transfer Document Type Input
The flow then proceeds to 450.
At 450, one or more attributes of the payload of the supply request are enriched. Enrichment provides values to attributes in the payload of the supply request (and thus, in the eventual supply order) that are not available in the payload of the supply request. Enrichment can ensure that any mandatory attributes for document creation that are not populated by the calling application are provided values as required. The flow then proceeds to 460.
At 460, if it is identified at 420 that the request is a request to create a new supply, then a new supply order with a supply order header, one or more supply order lines, and one or more supply tracking lines can be created. On creation of the supply order, the supply chain request is transformed into the supply order. More specifically, one or more attributes of the payload of the supply request are translated into one or more attributes of at least one of the supply order header, the one or more supply order lines, or the one or more supply tracking lines. On creation of the supply order, a status management framework can be called to initialize the status values. The status management framework can initialize the statuses for the supply tracking lines, supply order lines and the supply order header. The flow then proceeds to 470.
At 470, a supply chain orchestration process (or other type of orchestration process) is assigned to one or more of the supply tracking lines of the supply order. An orchestration process is further described below in greater detail in conjunction with
According to an embodiment, business rules can be invoked at the following stages during decomposition: (1) execution rules—to determine a document type in case of a transfer; (2) payload enrichment; (3) assigning an orchestration process to one or more supply track lines. The business rules can utilize one or more attributes of a payload of a supply request as criteria. Thus, the business rules can be applied to the one or more attributes of the payload of the supply request, and can execute functionality based on the values of the one or more attributes. Further, business rules can have a priority, where a higher priority business rule is executed before a lower priority business rule.
An orchestration process instance 520 is assigned to supply tracking line 512, where orchestration process instance 520 is an instance of orchestration process definition 530. Orchestration process definition 530 defines an orchestration process that can be executed at run-time as an executable process, where the orchestration process includes one or more steps that take an order, such as a supply order, through an execution process, such as a supply execution process, and each step can execute a task using a service. In certain embodiments, orchestration process definition 530 can define a supply chain orchestration process, and orchestration process instance 520 can be a supply chain orchestration process instance.
Orchestration process instance 520 includes orchestration process step instance 521, which is an instance of orchestration process step 540, where orchestration process definition 530 includes orchestration process step 540. Orchestration process step 540 is a component of orchestration process definition 530, where orchestration process step 540 is part of sequence of steps defined by orchestration process definition 530. Further, orchestration process step 540 includes orchestration process step dependencies 541, which defines one or more steps that orchestration process step 540 is dependent on. Orchestration process step instance 521 further includes step instance details 522 which includes information necessary to take action defined by orchestration process step 540.
Orchestration process step instance 521 further includes task instance 523, which is an instance of task 550, where orchestration process step 540 includes task 550. Task 550 is an execution task performed by orchestration process step 540, where the execution task is executed at an external supply execution system. Task instance 523 further includes activities 524, where activities 524 represents a plurality of activities performed by task instance 523. Further, task instance 523 includes jeopardy priority 525. Jeopardy priority 525 is further described below in greater detail in conjunction with
Orchestration process step 540 further includes service 560. Service 560 defines a service that communicates with an external supply execution system. Service 560 further includes hold service mappings 561 and hold code definition 562, which can both define a hold service for service 560.
Orchestration process definition 530 further includes jeopardy header 570 and jeopardy threshold 571. Jeopardy header 570 and jeopardy threshold 571 are further described below in greater detail in conjunction with
At 620, a task is defined for each step of the supply chain orchestration process. A task is an execution task that can be initiated by the step of the supply chain orchestration process, where the execution task can be executed at an external supply execution system. In certain embodiments, a service can also be defined for each step of the supply chain orchestration process, where a service communicates with an external supply execution system that can execute the task. The flow then proceeds to 630.
At 630, a sequence of the one or more steps of the supply chain orchestration process is defined. A sequence is an order of the one or more steps of the supply chain orchestration process. Thus, the supply chain orchestration process can perform each step in an order defined by the sequence of the one or more steps. Further, in certain embodiments, one or more dependencies can be defined for the supply chain orchestration process. The flow then proceeds to 640.
At 640, one or more status values are defined for the supply chain orchestration process. Each status value can be assigned to a supply order line of a supply order, or can be assigned to the supply chain orchestration process. The flow then proceeds to 650.
At 650, a cost of change is assigned to each step of the supply chain orchestration process. A cost of change can represent a level of difficulty in changing or modifying each step of the supply chain orchestration process. The flow then proceeds to 660.
At 660, a supply chain orchestration process is deployed. The supply chain orchestration process includes computer program code configured to perform the steps of the supply chain orchestration process. The flow then proceeds to 670.
At 670, a supply chain orchestration process instance is created. The supply chain process instance is an executable version of the supply chain orchestration process, and includes executable computer program code configured to perform the steps of the supply chain orchestration process. The flow then proceeds to 680.
At 680, the supply chain orchestration process instance is executed. The supply chain orchestration process instance executes each step of the supply chain orchestration process, where, in executing each step, the supply chain orchestration process invokes each service associated with each task. The flow then ends.
The forward planning and jeopardy management data model further includes jeopardy threshold header 710, jeopardy thresholds 711, jeopardy priority 712, and jeopardy score history 713. Jeopardy threshold header 710 stores a header entity for jeopardy threshold ranges. Jeopardy thresholds 711 stores jeopardy score ranges for a given threshold. Jeopardy priority 712 stores jeopardy score ranges for a given priority. Jeopardy score history 713 stores a historical progression of jeopardy scores for a given task instance within an orchestration process instance.
According to the embodiment, when a supply request is generated, the flow begins and proceeds to 810. At 810, the supply request is received. The flow then proceeds to 820. At 820, the supply request is enriched and validated. This can involve enriching one or more attributes of a payload of the supply request and validating the one or more attributes of the payload of the supply request. The flow then proceeds to 830. At 830, a supply order is created based on the supply request, and a supply chain orchestration process that is assigned to a supply tracking line of the supply order is executed. The flow then proceeds to 840.
At 840, a forward planning service is executed for the supply order and a jeopardy is determined. Forward planning and determining jeopardy are further described below in greater detail in conjunction with
At 920, for each traversed step of the supply chain orchestration process, a required completion date and required start date are calculated. For a completion step, a required completion date can be a requested delivery date of an associated supply tracking line of a supply order. If more than one supply track line is associated with the supply chain orchestration process, then the latest requested delivery date can be used. Also, for the completion step, a required start date can be: the required completion date of the completion step minus lead-time, where the lead-time can be pre-defined for the completion step of the orchestration process. For a step other than the completion step, a required completion date can be a required start date of the next step of the supply chain orchestration process. Further, for a step other than the completion step, a required start date can be: the required completion date of the step minus lead-time, where lead-time can be pre-defined for the step of the orchestration process. The flow then proceeds to 930.
At 930, the steps of a supply chain orchestration process are traversed, starting with the “first step.” More specifically, a “first step” of a supply chain orchestration process is identified, where the “first step” is the first step of the supply chain orchestration process that has not completed (and thus, is not necessarily the actual first step of the supply chain orchestration process). A step dependency tree of the supply chain orchestration process is then traversed forwards. The flow then proceeds to 940.
At 940, for each traversed step of the supply chain orchestration process, a planned start date and planned completion date are calculated. For a first step that has not completed, a planned start date can be an actual start date for the first step, if there is an actual start date for the first step. If there is not an actual start date for the first step, the planned start date can be a scheduled start date for the first step, if there is a scheduled start date for the first step. If there is not either an actual start date or a scheduled start date for the first step, the planned start date can be a system date. Also, for the first step that has not completed, a planned completion date can be: the planned start date of the first step plus lead-time, where the lead-time can be pre-defined for the first step of the orchestration process that has not been completed. For a step other than the first step, a planned start date can be a required completion date of a prior dependent step of the supply chain orchestration process. Further, for a step other than the first step, a planned completion data can be: the planned start date of the step plus lead-time, where lead-time can be pre-defined for the step of the orchestration process. The flow then proceeds to 950.
At 950, a jeopardy status is assessed for, and assigned to, each step of the supply chain orchestration process. This is further described below in greater detail in conjunction with
The flow begins and proceeds to 1005. At 1005, a first step of a supply chain orchestration process is selected. The flow proceeds to 1010. At 1010, it is determined if a task of the step of the supply chain orchestration process has already completed. If the task has already completed, the flow proceeds to 1060. However, if the task has not already completed, the flow proceeds to 1015. At 1015, it is determined if the step is inactive or cancelled. If the step is either inactive or cancelled, the flow proceeds to 1060. However if the step is not inactive and the step is not cancelled, the flow proceeds to 1020.
At 1020, it is determined whether the task is being visited for the first time. If the task is being visited for the first time, the flow proceeds to 1025. Otherwise, the flow proceeds to 1030. At 1025, a previous jeopardy score for the task is cleared. The flow then proceeds to 1030. At 1030, a jeopardy score is calculated for the step. The calculation of the jeopardy score is described below in greater detail. The flow proceeds to 1035. At 1035, it is determined whether the step jeopardy score is greater than a task jeopardy score. If the step jeopardy score is greater than the task jeopardy score, then the flow proceeds to 1040. Otherwise, the flow proceeds to 1060. At 1040, the task jeopardy score is updated with the step jeopardy score. The flow then proceeds to 1045.
At 1045, it is determined whether the task jeopardy score is greater than a supply chain orchestration process jeopardy score. If the task jeopardy score is greater than the supply chain orchestration process jeopardy score, the flow proceeds to 1050. Otherwise, the flow proceeds to 1060. At 1050, the supply chain orchestration process jeopardy score is updated with the task jeopardy score. The flow then proceeds to 1055. At 1055, the tracking of the jeopardy score for the supply chain orchestration process is updated. The flow then proceeds to 1060. At 1060, the next step of the supply chain orchestration process is selected. The flow then returns to 1010. However, if there are no remaining steps of the supply chain orchestration process, then the flow ends.
A process for calculating a jeopardy score for one or more steps of a supply chain orchestration process is further described below.
1. Calculate Jeopardy Score for Process Steps
-
- To calculate required jeopardy score for process steps, the planning process first calculates the step delay. If the Required Completion Date<Planned Completion Date, there is a delay. When the delay is a partial unit value, it can be rounded up to a whole unit. The delay is compared to jeopardy threshold minimum and maximum values and assigned the score of the threshold into which it falls. The jeopardy threshold assigned is that where the Delay>Range Minimum and <=Range Maximum.
- Jeopardy Threshold may be defined at five levels. The hierarchy between these levels is defined as below:
- 1. Task Type
- 2. Task Name
- 3. Process Name
- 4. Process Version
- 5. Global/Default
- The system can locate the appropriate threshold group in this order:
- 1. For the combination of all four elements
- 2. For the process name, process version, and task name
- 3. For the process name and task name
- 4. For the process name, process version, and task type
- 5. For the process name, task type
- 6. For task name
2. Set task jeopardy score and reason
-
- A task instance is assigned a jeopardy score equal to the highest jeopardy score of all steps which comprise that task.
- A jeopardy reason is assigned, which is a concatenated string containing the required dates, planned date.
- A jeopardy priority will be assigned to the task. The priority is determined by comparing the jeopardy score against the Jeopardy Priority Minimum and Maximum.
3. Create a jeopardy history record
-
- A row will be added in the SCO_JEOPARDY_SCORE_HISTORY table, recording a snapshot of the task status and jeopardy conditions at the time jeopardy was recognized.
4. Set process jeopardy score
-
- The process instance is updated with a jeopardy score
- The process instance is assigned a jeopardy score equal to the highest jeopardy score of all tasks which comprise that process.
5. Set tracking line jeopardy priority
-
- All tracking lines associated to the process instance should have the JEOPARDY_CONDITION set to the JEOPARDY_PRIORITY_CODE of the process instance.
According to the embodiment, when the supply order is received at orchestration layer 1120, the supply order causes a supply task to be invoked. More specifically, a supply task service is invoked. Invoking the supply task involves generating a supply task request, where the supply task request includes data indicating that the supply task has been invoked. Invoking the supply task further involves sending the supply task request to a supply task service of business services layer 1130. Business services layer 1130 is a layer that includes task-specific logic that can be included within a supply task service, so that the logical supply tasks associated with a supply task can be defined. Business service layer 1130 can further receive input that can be used by the supply task service to update an overall status of a supply task.
When the supply task request is received at business services layer 1130, the supply task service of business services layer 1130 creates a payload for the supply task, where the payload includes one or more attributes of the supply task. The supply task service of business services layer 1130 further generates a message that includes the payload of the supply task, and sends the message to external interface layer 1140. External interface layer 1140 is a layer that can map data from an internal format utilized by a supply chain orchestration system to an external format utilized by an external supply execution system.
When the message is received at external interface layer 1140, external interface layer 1140 transforms the payload of supply task into an execution-specific payload. This involves transforming a format of the task payload from an internal format utilized by a supply chain orchestration system to an external format utilized by the external supply execution system that will execute the task. This can allow the external supply execution system to correctly interpret and execute the supply task. External interface layer 1140 further generates a message that includes the execution system-specific payload of the supply task, and sends the message to external supply execution system 1150. External supply execution system 1150 is a supply execution system that is external to the supply chain orchestration system, and that can execute the supply task, such as a purchasing system, a logistics system, a manufacturing system, or another third-party system.
When external supply execution system 1150 receives the message, external supply execution system 1150 executes the supply task and generates one or more status values. External supply execution system 1150 subsequently returns the one or more status values to external interface layer 1140.
When external interface layer 1140 receives the one or more status values, external interface layer 1140 transforms the one or more status values from the execution system-specific format into the internal format that the supply chain orchestration system understands. External interface layer 1140 subsequently sends the one or more translated status values to the supply task service of business services layer 1130.
When business services layer 1130 receives the one or more transformed status values, the supply task service of business services layer 1130 transforms the one or more transformed status values into an overall task status. More specifically, the supply task service of business services layer 1130 analyzes the one or more transformed status values and generates an overall task status based on the one or more transformed status values. The supply task service of business services layer 1130 subsequently sends the overall task status to orchestration layer 1120.
At 1260, one or more status values are received from the external supply execution system. The one or more status values can be received at the external interface layer. The flow then proceeds to 1270. At 1270, the one or more status values are transformed into one or more transformed status values. This can include transforming the one or more status values from an execution system-specific format to an internal format. The flow then proceeds to 1280. At 1280, the one or more transformed status values are sent to a business layer. The one or more transformed status values can be sent to a supply task service of the business layer. The flow then proceeds to 1290. At 1290, the one or more transformed status values are transformed into a task status. The task status can represent an overall status of the supply task. The flow proceeds to 1295. At 1295, the task status is sent to an orchestration layer. The flow then ends.
In certain embodiments, user interface 1300 can display one or more objects that either: (a) have raised an exception; (b) have raised an error; (c) are in jeopardy; or (d) are on track. Depending on one or more settings, user interface 1300 can display objects from one or more of the aforementioned categories. Additionally, in certain embodiments, user interface 1300 can display analytics that provide visualization of the objects stored within the supply chain orchestration system.
Further, in certain embodiments, user interface 1300 can allow a user to take corrective actions in order to mitigate any exceptions of errors on one or more supply tracking lines. Following is a list of actions that the user can perform from user interface 1300: (1) Get Alternate Supply; (2); Notify Requestor (3) Split Supply Line; (4) Simulate Jeopardy Conditions; (5) Edit Supply Line; (6) Cancel Supply Line; (7) Holds; (8) Assign Process to Supply Lines; or (9) Error Recovery. These actions are described below in greater detail.
-
- Get Alternate Supply: This action will allow a user to get an alternate source of supply for an existing or new supply tracking line. A user can invoke this action in the following scenarios.
- No sourcing information available on the supply tracking line.
- Override the existing sourcing information on the supply tracking line to mitigate exception.
- Notify Requestor: This action will allow a user to notify the requestor of the supply that the system will not be able to fulfill their demand. A user can invoke this action to notify the requestor if he/she fails to fetch a suitable supply source to meet the requestor's demand.
- Split Supply Line: This action will allow a user to manually split the supply tracking line. A user can invoke this action in order to mitigate the following types of exception on the supply tracking line.
- Supply tracking line is in high jeopardy and will not be able to meet the need by date for partial quantity.
- Supply tracking line is in high jeopardy and user is aware of another source which can meet this requirement.
- Run Jeopardy Planning: This action will allow a user to manually invoke the jeopardy forward planning engine to simulate the jeopardy conditions. A user can invoke this action to verify the jeopardy conditions after taking the necessary corrective actions to mitigate a supply line exception. This will allow the user to judge if the corrective actions taken would be adequate to mitigate the exception of the supply tracking line.
- Edit Supply Line: This action will allow the user to manually edit a set of supply tracking line attributes and will have the option to update the associated execution document. This action will allow editing the attributes of a Buy, Make, Transfer and ATP supply tracking lines and the corresponding execution documents. The user can invoke this action to mitigate any exception in the supply by changing attributes like need by date, quantity etc.
- Cancel Supply Line: This action will allow the user to manually cancel a supply tracking line and will cancel the associated execution document. The user can invoke this action in cases where the demand got cancelled or there was no alternate supply source found for the supply tracking line that is in exception.
- Holds:
- Apply Hold: This action will allow the user to manually apply a hold on the supply tracking line and the associated execution document. This action will also allow the user to specify a Hold code, add comments and hold all the tasks in progress. The user can invoke this action in the following scenarios:
- The goods received are rejected in inspection due to quality issues.
- Goods cannot be received due to space constraints in the warehouse.
- To handle demand change or cancel request
- Release Hold: This action will allow the user to manually release a hold on the supply tracking line and the associated execution document. This action will also allow the user to specify a Release Reason Code and add any comments. The user can invoke this action once the exceptions are resolved for which the hold was applied.
- View Hold Details: This action will allow the user to view the status of hold and details of the hold like Hold Name, Hold Comments, Hold Date, Release Reason, Release Comments, User name who applied hold etc. The user can view hold details from Manage Supply Line Exceptions page as well as Manage Orchestration Process Exceptions page. The user can invoke this action in order to view the hold details whenever required.
- Note: The Holds functionality in the system can utilize a user interface where users can define Hold Code and Hold Release Codes.
- Apply Hold: This action will allow the user to manually apply a hold on the supply tracking line and the associated execution document. This action will also allow the user to specify a Hold code, add comments and hold all the tasks in progress. The user can invoke this action in the following scenarios:
- Assign Process to Supply Line: This action will allow the user to manually assign orchestration process to the supply tracking lines for which an orchestration process has not been assigned. Also, the user can re-assign a new orchestration process to the supply tracking lines by overriding the existing ones as long as the orchestration process is not started. The user can invoke this action in the following scenarios:
- Supply tracking line was not assigned to an orchestration process as there were no valid orchestration process assignment rules.
- Supply tracking line was assigned to an orchestration process but, the user would like to manually override the existing process with a new orchestration process if the assigned orchestration process has not been started.
- Error Recovery:
- Re-Submit Supply Line Process: This action will allow the user to manually re-submit or re-start the orchestration process of the supply tracking line. The user can invoke this action in the following scenarios;
- Orchestration process was assigned to a supply tracking line but the process was not started.
- Orchestration process or task resulted in an error.
- Remove Exception: This action will allow the user to manually reset the exception on the supply tracking line. The user can invoke this action after taking corrective actions to mitigate the exception on the supply tracking line.
- Re-Submit Supply Line Process: This action will allow the user to manually re-submit or re-start the orchestration process of the supply tracking line. The user can invoke this action in the following scenarios;
- Get Alternate Supply: This action will allow a user to get an alternate source of supply for an existing or new supply tracking line. A user can invoke this action in the following scenarios.
At 1450, one or more tasks that are defined by the one or more steps of the supply chain orchestration process are generated. The flow then proceeds to 1460. At 1460, the one or more tasks are sent to one or more external supply execution systems. The flow then proceeds to 1470. At 1470, one or more status values are received from the one or more external supply execution systems. The flow then proceeds to 1480. At 1480, an overall status value is generated for the supply chain orchestration process based on the one or more status values. The flow then ends.
Supply Chain Orchestration Change ManagementAccording to an embodiment, a supply chain orchestration system is provided that can manage a modification to a supply chain orchestration process, such as a demand side change orchestration process which represents a modification to the supply chain orchestration process by an external supply request system, or a supply side exception orchestration process which represents a modification to the supply chain orchestration process by an external supply execution system. The supply chain orchestration system can provide configurable capabilities on key functionality that can guide the supply chain orchestration system to make decisions during run-time. This further can provide the capabilities to have end-to-end visibility into a supply chain orchestration process, detect exceptions that happen during an execution of the supply chain orchestration process, and take corrective actions to ensure the alignment of the supply chain orchestration process with a company's business goals.
As previously described, existing ERP and supply chain systems typically face several limitations including: (1) working only within the “four walls” of a single enterprise; (2) only implementing pre-defined business processes that are difficult to change without extensive coding; and (3) failing to provide integrated visibility across all activities associated with a creation of supply. According to an embodiment, a supply chain orchestration system can overcome these limitations by enabling a user to: (a) define supply chain orchestration processes specific to the business practices of the user's company or group; (b) track a life-cycle of each execution document to enable a user to see progress of each supply chain orchestration process; and (c) track an exception to a supply chain orchestration process and provide an option to mitigate risk in meeting the demand.
In accordance with the embodiment, a supply chain orchestration system can: (1) provide a configuration capability to define a single orchestration process definition to manage new supply orchestration processes and tasks, demand change orchestration processes and tasks, and supply change orchestration processes and tasks; (2) dynamically split a supply chain orchestration process to track and manage multiple execution documents and tasks; (3) dynamically split a supply line and associated supply chain orchestration process to track and manage supply side changes; and (4) determine and utilize configurable supply availability risk to manage an order-specific change request.
According to an embodiment, an external supply request system of external supply request systems 1510 can request a modification to the supply order (and thus, a modification to the orchestration of the supply order) by sending a demand change 1522 to supply chain orchestration system 1520. For example, a user can utilize an external supply request system to send new supply request 1521 to supply chain orchestration system 1520, where new supply request 1521 represents a request for 100 laptops from a supplier. The supplier confirms that the 100 laptops will be shipped by August 15. After three days, a user can utilize the external supply request system to modify the request from 100 laptops to 60 laptops by sending demand change 1522 to supply chain orchestration system 1520. This is an example of a demand change, where a modification to an original supply chain request is made by an external supply request system. As will be described below in greater detail, supply chain orchestration system 1520 can receive demand change 1522 and dynamically modify an orchestration of the original supply order for 100 laptops, by dynamically modifying the execution of the supply chain orchestration process. This is identified as “change management.”
In another embodiment, an external supply execution system of external supply execution systems 1530 can request a modification to the supply order (and thus, a modification to the orchestration of the supply order) by sending a supply change 1523 to supply chain orchestration system 1520. For example, a user can utilize an external supply request system to send new supply request 1521 to supply chain orchestration system 1520, where new supply request 1521 represents a request for 100 laptops from a supplier. The supplier confirms that the 100 laptops will be shipped by August 15. After four days, the supplier indicates that they can only deliver 50 laptops by sending supply change 1523 to supply chain orchestration system 1520. Supply chain orchestration system 1520 can find an alternate supplier that can provide the alternate supply, so that the original supply chain request of 100 laptops can be fulfilled. This is an example of a supply change, where a modification to an original supply chain request is made by an external supply execution system. As is described below in greater detail, supply chain orchestration system 1520 can receive supply change 1523 and dynamically modify an orchestration of the original supply order for 100 laptops, by dynamically modifying the execution of the supply chain orchestration process. This is also identified as “change management.”
According to the embodiment, as is described below in greater detail, supply chain orchestration system 1520 can send tasks 1524 to external supply execution systems 1530, and can receive task statuses from external supply execution systems 1530. Tasks 1524 can include create tasks, track tasks, change tasks, and cancel tasks.
Example change management scenarios are described below to further highlight various change management concepts and designs.
The following sample scenarios can be used to illustrate various change management concepts and design.
-
- Reschedule Purchase Order request from Planning (Purchase Order (Schedule) ID, ship date, dock date, shipping method)
- Decreased supply (quantity decrease) for a BackToBack order from GOP (DOO Fulfillment Reference ID, Revised(reduced) quantity, etc)
- Increased supply (quantity increase) for a BackToBack order from GOP (DOO Fulfillment Reference ID, additional quantity, etc)
- Cancel Transfer Order request from SSP (Transfer Order Line ID)
Planning Reschedule Purchase Order scenario
A snapshot of the supply and demand lines before, during and after processing the reschedule purchase order is outlined.
Demand and Supply tracking lines snapshot for Planning New Buy Request
Assume where a planning system sends a new buy request, with following values:
-
- Supply Type: Buy
- Need By Date: Aug. 15, 2012
- Shipping Method: 3-day FedEx
The planning system can send the reschedule recommendation with following attribute:
-
- Reschedule of existing Purchase Orders (Purchase Order Schedule ID, ship date, dock date, shipping method)
While processing the above new request, assume that the planning system sends a Reschedule Purchase Order request with following attributes and values:
-
- Purchase Order Schedule ID: POS122
- Need By Date (Ship date): Aug. 20, 2012
- Shipping Method: 2-day shipping method
The following table provides a snapshot of the demand (supply order line) and supply tracking lines (supply tracking line, Document line) for the planning new buy request after new request is successfully processed by the execution system.
Demand and Supply Tracking Lines Snapshot for Planning Reschedule Request for Purchase Order
The following table provides a snapshot of demand and supply lined after procurement successfully processed the change request from the system. For some of the change attributes (Need-by-date), there are two columns to illustrate the values of new request (before processing the change request) and reschedule (after processing the change request).
The following table provides a snapshot of the demand (supply order line) and supply tracking lines (supply tracking line, Document line) after reschedule request is successfully processed by the execution system.
-
- Planning reschedule of existing Purchase Order format (Purchase Order Line (Schedule) ID, ship date, dock date, shipping method) are:
- Supply request system (Planning) sends reschedule request for a specific execution document line (Purchase Order Line (Schedule) ID)
- Supply request system (Planning) sends reschedule request only for a set of pre-defined attributes: ship date (Need By Date, dock date, shipping method)
- Planning reschedule of existing Purchase Order format (Purchase Order Line (Schedule) ID, ship date, dock date, shipping method) are:
A snapshot of the supply and demand lines before and after processing the update (Quantity change) purchase request is outlined.
Demand and Supply Tracking Lines Snapshot for GOP Decreased ScenarioAssume that GOP sends a new buy request, with following values:
-
- DOO Fulfillment Line: FL123
- Item: item1
- Requested Quantity: 100 each (Buy 20 each, Transfer 30 each, On hand 50 each quantity)
While processing the above new request, assume that GOP sends a change request for decreased supply, with following values:
-
- DOO Fulfillment Line: FL123
- Item: item1
- Decreased Quantity: 45 each (Revised quantity is 55)
The following (Step 1) table provides a snapshot of the demand (supply order line) and supply tracking lines (supply tracking line, Document line) for the GOP new buy request.
The following table (Step 2) provides a snapshot of the demand (supply order line) and supply tracking lines (supply tracking line, Document line) after reschedule request is successfully processed by the execution system.
-
- GOP decreased supply (quantity decrease) on of existing BackToBack order (DOO Fulfillment ID, requested quantity, supplier, etc) is:
- Supply request system (GOP) sends supply change request for specific demand line(DOO Fulfillment Line)
- Supply request system (GOP) sends change request only for a set of pre-defined attributes: revised quantity, supplier etc
- GOP decreased supply (quantity decrease) on of existing BackToBack order (DOO Fulfillment ID, requested quantity, supplier, etc) is:
Based on the above Planning Reschedule PO and GOP Decreased Supply scenario, the system can support the following design time requirements:
-
- Ability to configure attributes that manage change for each task type
- Ability to configure task services that must be invoked during update or cancel request
- Ability to configure constraints based on change management attributes
According to an embodiment, configuration steps can be necessary for a change management process. A first configuration can be configuring change management attributes (i.e., “delta attributes”). More specifically, to successfully process the change/cancel request from external supply request systems, a supply chain orchestration system can identify the attributes that manage change. For example, for a planning reschedule recommendation, a supply chain orchestration system can transform a planning reschedule purchase order payload (Purchase Order Line (Schedule) ID, ship date, dock date, shipping method) into supply order line and supply tracking line attributes. To manage a change management process, the first requirement can be to configure a set of attributes that manage change for one or more task types. The following table is an example table that illustrates change attributes of supply tracking lines for a purchasing task type.
A second configuration can be configuring change management constraints. After defining the attributes that manage change, an administrator can configure constraints based on the attributes that manage change. For example, an administrator can define the following set of constraints: (a) reject all quantity change recommendations from a planning system; and (b) reject all shipping method changes for a specific supplier.
A third configuration can be configuring change management task services and business rules. During the processing of a change request or a cancel request, a supply chain orchestration system can provide flexibility for an administrator to define a service to be used by the change request or the cancel request. The following example supply chain orchestration process definition illustrates example default services (that can be pre-defined) for a new request, an update request, and a cancel request for each task.
If the supply request is a new supply request, then the flow proceeds to 1620. At 1620, the new supply request is decomposed, and a supply order is created, where the supply order includes a supply order header, one or more supply order lines, and one or more supply tracking lines. The flow then proceeds to 1621. At 1621, one or more supply chain orchestration processes are assigned to the one or more supply tracking lines of the supply order. The flow then proceeds to 1622. At 1622, execution of at least one of the one or more supply chain orchestration processes is initiated. The flow then proceeds to 1623. At 1623, the at least one supply chain orchestration process creates a requested supply. The flow then proceeds to 1645. At 1645, the supply request is completed, and the flow ends. This is an orchestration flow that has previously been described in greater detail.
If the supply request is either a change supply request or a cancel supply request, then the flow proceeds to 1631. At 1631, the supply request is decomposed. The supply request can be a change supply request or a cancel supply request for a supply order, a specific supply order line of a supply order, a specific supply tracking line of a supply order, or a specific document line of an execution document. The decomposition of the supply change request can generate a change supply order (or a cancel supply order). The decomposition of the supply request is described below in greater detail in conjunction with
At 1632, it is determined whether the supply request is a change supply request or a cancel supply request. If the supply request is a cancel supply request, then the flow proceeds to 1633. If the supply request is a change supply request, then the flow proceeds to 1634. At 1633, a process cancel supply request function is invoked. In certain embodiments, the invocation of the process cancel supply request function can include: (a) selecting one or more supply order lines of the supply order and/or one or more supply tracking lines of the supply order; (b) processing a cancel compensation on an original supply order; and (c) notifying an external supply request system about a status of the cancel supply request. A cancel compensation of an original supply order is further described below in greater detail in conjunction with
At 1635, the one or more supply order lines and/or the one or more supply tracking lines of the supply are filtered. In other words, any supply order lines and/or supply tracking lines that are not eligible for compensation (either cancel or change) are filtered out. In an example embodiment, a supply order can include one or more supply order lines, a supply order line can include one or more supply tracking lines, and a supply tracking line can be associated with one or more document lines of one or more execution documents. In this example embodiment, filtering supply order lines and/or supply tracking lines can be based on: (1) a specific execution document or a specific supply order line; (2) a status of a supply order line and/or supply tracking line; or (3) constraints on a supply order and supply order line delta attributes. As an example, to filter the supply order lines and supply tracking lines for a specific execution document, a filter could be applied in the following order: (1) select all document lines that match specific document line; (2) filter all the supply tracking lines associated with the filtered document lines; (3) filter all the supply order lines associated with the filtered supply tracking lines; and (4) filter all the supply orders associated with the filtered supply order lines. After applying the above filter, or a similar filter, a list of all eligible document lines, supply tracking lines, supply order lines, and supply orders for a specific document line can be generated. The flow then proceeds to 1636.
At 1636, one or more supply order line constraints and/or one or more supply tracking line constraints are validated. More specifically, one or more supply order lines and/or one or more supply tracking lines can be filtered based on: (a) supply order constraints; (b) supply order line constraints; (c) supply tracking line constraints; and/or (d) document line constraints. An example constraint is as follows: if a supply order source is a planning system, reject any supply change request to a requested quantity. After this filter, or a similar filter, a list of all eligible document lines, supply tracking lines, supply order lines, and supply orders that do not violate any constraints can be generated. The flow proceeds to 1637.
At 1637, it is determined whether the supply change request involves a quantity change. If the supply change request involves a quantity change, the flow proceeds to 1638. Otherwise, the flow proceeds to 1639. At 1638, one or more supply lines are prioritized. The prioritization of the one or more supply lines is further described below in greater detail in conjunction with
At 1639, a delta is computed. More specifically, one or more attributes of the eligible supply tracking lines, eligible supply order lines, and/or the change supply order (or cancel supply order) are compared with one or more attributes of the eligible supply tracking lines, eligible supply order lines, and/or the original supply order. Based on this comparison, a delta is computed, where the delta represents a change between the original supply order and the change supply order (or the cancel supply order). In certain embodiments, only attributes identified as delta attributes are compared. The flow then proceeds to 1640. At 1640, the original supply order is compensated based on the computed delta. The compensation of the original supply order is further described below in greater detail in conjunction with
At 1641, one or more tasks of a supply chain orchestration process are filtered. In certain embodiments, the one or more tasks can be filtered based on: (1) task status; (2) an update/cancel compensating service definition in a supply chain orchestration process definition; (3) one or more delta attributes for a specific task type; and/or (4) an external supply execution system response for a compensating service invocation. Thus, a list of eligible tasks that can be compensated by sending an appropriate service request to the appropriate external supply execution system can be generated. The flow then proceeds to 1642. At 1642, an appropriate compensating service is invoked for each eligible task. The flow then proceeds to 1543. At 1643, the appropriate external supply execution system executes a compensation task, and adjusts one or more supply order lines and/or one or more supply tracking lines of the original supply order. The flow then proceeds to 1644. At 1644, it is determined whether the supply change request is a new supply request, a change supply request, or an update supply request. If the supply change request is a new supply request, then the flow returns to 1621. If the supply change request is a change supply request, then the flow returns to 1623. If the supply change request is a cancel supply request, then the flow proceeds to 1645. This is a change management flow.
At 1740, an action attribute of a supply order line of an original supply order is set to “Cancel” to indicate that the supply request is a cancel supply request. The flow then proceeds to 1741. At 1741, a minor action attribute of a supply order line of the original supply order is set to “cancel request” to indicate that the supply request is a cancel supply request. The flow then proceeds to 1742. At 1742, a process cancel supply request function is invoked. In certain embodiments, the invocation of the process cancel supply request function can include: (a) selecting one or more supply order lines of the supply order and/or one or more supply tracking lines of the supply order; (b) processing a cancel compensation on an original supply order; and (c) notifying an external supply request system about a status of the cancel supply request. A cancel compensation of an original supply order is further described below in greater detail in conjunction with
At 1750, an action attribute of a supply order line of an original supply order is set to “Update” to indicate that the supply request is a change supply request. The flow then proceeds to 1741. At 1751, a minor action attribute of a supply order line of the original supply order is set to “change request” to indicate that the supply request is a change supply request. The flow then proceeds to 1752. At 1752, a process change supply request function is invoked. In certain embodiment, the invocation of the process change supply request function can include: a) selecting one or more supply order lines of the supply order and/or one or more supply tracking lines of the supply order; (b) processing an update compensation on an original supply order; and (c) notifying an external supply request system about a status of the change supply request. An update compensation of an original supply order is further described below in greater detail in conjunction with
A compensation pattern comprises one or more services that are invoked in the event of a change request for adjusting the step of the supply chain orchestration process. These services are defined as “compensating services.” A compensating service is defined and associated with a step as part of the process definition of the supply chain orchestration process. Thus, a “compensating pair” is provided in order to encapsulate a compensation pattern. The compensating pair includes the original service capable of performing the step of the supply chain orchestration process and one or more compensating services capable of adjusting the step of the supply chain orchestration process.
According to the embodiment, update compensation pattern 1810 includes an update compensating service that can update a step of a supply chain orchestration process. In accordance with the embodiment, when update compensation pattern 1810 is invoked, the flow begins at 1811, when a change flag for a supply chain orchestration process instance is set to “TRUE.” The flow then proceeds to 1812. At 1812, an update compensating service is invoked to update finished tasks 1816, where finished tasks 1816 are tasks of the supply chain orchestration process instance that have completed, and where a task includes one or more steps of the supply chain orchestration process. The flow then proceeds to 1813. At 1813, the update compensating service is invoked to update active tasks 1817, where active tasks 1817 are tasks of the supply chain orchestration process instance that have been initiated, but have not completed, and where a task includes one or more steps of the supply chain orchestration process. The flow then proceeds to 1814. At 1814, a change flag for a supply chain orchestration process instance is set to “TRUE.” The flow then proceeds to unfinished task 1815, where a service is invoked to execute unfinished tasks 1815, where unfinished tasks 1815 are tasks that have not been initiated, and where a task includes one or more steps of the supply chain orchestration process. The flow then ends.
According to the embodiment, cancel compensation pattern 1820 includes a cancel compensating service that can cancel a step of a supply chain orchestration process. In accordance with the embodiment, when cancel compensation pattern 1820 is invoked, the flow begins at 1821, when a change flag for a supply chain orchestration process instance is set to “TRUE.” The flow then proceeds to 1822. At 1822, a cancel compensating service is invoked to cancel finished tasks 1826, where finished tasks 1826 are tasks of the supply chain orchestration process instance that have completed, and where a task includes one or more steps of the supply chain orchestration process. The flow then proceeds to 1823. At 1823, the cancel compensating service is invoked to cancel active tasks 1827, where active tasks 1827 are tasks of the supply chain orchestration process instance that have been initiated, but have not completed, and where a task includes one or more steps of the supply chain orchestration process. The flow then proceeds to 1824. At 1824, a change flag for a supply chain orchestration process instance is set to “TRUE.” The flow then ends, and no service is invoked upon unfinished tasks 1825, as there is no need to cancel tasks that have not yet been initiated.
According to the embodiment, redo compensation pattern 1830 is a combination of a cancel compensation pattern and a new service pattern. In accordance with the embodiment, when redo compensation pattern 1830 is invoked, the flow begins at 1831, when a change flag for a supply chain orchestration process instance is set to “TRUE.” The flow then proceeds to 1832. At 1832, a cancel compensating service is invoked to cancel finished tasks 1836, where finished tasks 1836 are tasks of the supply chain orchestration process instance that have completed, and where a task includes one or more steps of the supply chain orchestration process. The flow then proceeds to 1833. At 1833, the cancel compensating service is invoked to cancel active tasks 1837, where active tasks 1837 are tasks of the supply chain orchestration process instance that have been initiated, but have not completed, and where a task includes one or more steps of the supply chain orchestration process. The flow then proceeds to 1834. At 1834, a change flag for a supply chain orchestration process instance is set to “TRUE.” The flow then proceeds to all tasks 1838, and no service is invoked upon unfinished tasks 1835, as there is no need to cancel tasks that have not yet been initiated. At all tasks 1838, a service is invoked to execute all tasks 1838. The flow then ends.
According to the embodiment, when new request service pattern is invoked, the flow begins at all tasks 1841, and a service is invoked to execute all tasks 1841. The flow then ends.
According to the embodiment, the flow begins and proceeds to 1910. At 1910, it is determined whether a supply change request involves a quantity change. If the supply change request does not involve a quantity change, the flow ends. If the supply change request does involve a quantity change, the flow proceeds to 1920.
At 1920, it is determined whether the quantity change is a quantity increase or a quantity decrease. If the quantity change is a quantity increase, the flow proceeds to 1930. If the quantity change is a quantity decrease, the flow proceeds to 1940.
At 1930, one or more supply tracking lines that are associated with a minimum supply availability risk are prioritized over remaining supply tracking lines. This means that the one or more prioritized supply tracking lines are selected for the supply chain request, and the supply chain orchestration process adjusts the one or more prioritized supply tracking lines. The flow then ends.
At 1940, one or more supply tracking lines that are associated with a maximum supply availability risk are prioritized over remaining supply tracking lines. This means that the one or more prioritized supply tracking lines are selected for the supply chain request, and the supply chain orchestration process adjusts the one or more prioritized supply tracking lines. The flow then ends.
Further details of a prioritization component of the change management functionality are described below.
Quantity change can be applicable for GOP BackToBack Change request. The following relationship is a valid scenario for BacktoBack request.
-
- Each BacktoBack supply request for a DOO Fulfillment line can be associated only one or more supply order lines
- For example, GOP may send a new request for a DOO Fulfillment line for requested quantity of 100 each of item1 with following supply types:
- Reserve On Hand, 50 each quantity of item1
- Transfer request for 30 each quantity of item1
- Buy request for 20 each quantity of item1
- In this scenario, system will initially create a three supply order lines for a DOO Fulfillment line and create three supply tracking lines to track and manage On Hand, Transfer and Buy supply types.
- For example, GOP may send a new request for a DOO Fulfillment line for requested quantity of 100 each of item1 with following supply types:
- Based on whether split flag enabled/disabled for various tasks and execution system response, system may further split above supply tracking lines into multiple supply tracking lines.
Consider both decreased supply (decrease in quantity) and increased supply (increase in quantity) change request scenarios.
- Each BacktoBack supply request for a DOO Fulfillment line can be associated only one or more supply order lines
Consider the scenario where GOP recommended the following supply recommendation and SCO created three supply tracking lines to track and manage the following recommendations.
-
- Original DOO Fulfillment line schedule: item1, quantity (100 each) Schedule date (August 15, 12), Warehouse (w1) with following supply types:
- Reserve On Hand, 50 each quantity of item1
- Transfer request for 30 each quantity of item1
- Buy request for 20 each quantity of item1
Assume that GOP has sends the change request to reduce the demand quantity (DOO Fulfillment line) from 100 to 70. Note that GOP updates the only the DOO Fulfillment Line quantity and the NOT the supply recommendation quantity
- Revised DOO Fulfillment line schedule: item1, quantity (60 each) Schedule date (August 15, 12), Warehouse (w1) with following supply types:
- Reserve On Hand, 50 each quantity of item1
- Transfer request for 30 each quantity of item1
- Buy request for 20 each quantity of item1
System can have the functional logic to select the best supply tracking line to apply the change request. If reduced quantity is 40 each, system has multiple options:
- Option1:
- Reserve OnHand, 50 each quantity of item1 (Change from 50 to 10)
- Buy request for 20 each quantity of item1 (No change)
- Transfer request for 30 each quantity of item1 (No Change)
- Option 2:
- Reserve On Hand, 50 each quantity of item1 (No change)
- Buy request for 20 each quantity of item1 (Change from 20 to 0)
- Transfer request for 30 each quantity of item1 (Change from 30 to 10)
- Option3:
- Reserve On Hand, 50 each quantity of item1 (Change from 50 to 40)
- Buy request for 20 each quantity of item1 (No change)
- Transfer request for 30 each quantity of item1 (Change from 30 to 0)
- Option 4-n: There are multiple combinations depending upon the current status of the supply creation process
System can have the functional logic to determine the best option to apply the change for BackToBack decreased quantity scenarios. System can choose the option to reduce the quantity for the supply tracking lines that has the higher risk. For example, in the above scenario, system can reduce the risk by of meeting the revised supply request by applying the quantity reduction on the supply tracking line that has schedule exception.
- Original DOO Fulfillment line schedule: item1, quantity (100 each) Schedule date (August 15, 12), Warehouse (w1) with following supply types:
-
- GOP has sends the change request to reduce the demand quantity (DOO Fulfillment line) from 100 to 70. Note that GOP updates the only the DOO Fulfillment Line quantity and the NOT the supply recommendation quantity
- The above change request at the DOO Fulfillment Line allows system to implement functional logic to select the supply that has the maximum risk based on various criteria, such as supply type, cost of change, status, exceptions and jeopardy priority.
Consider the scenario where GOP recommended the following supply recommendation and system created three supply tracking lines to track and manage the following recommendations.
-
- Original DOO Fulfillment line schedule: item1, quantity (100 each) Schedule date (August 15, 12), Warehouse (w1) with following supply types:
- Reserve On Hand, 50 each quantity of item1
- Transfer request for 30 each quantity of item1
- Buy request for 20 each quantity of item1 with supplier1
Assume that GOP have send the change request for incremental supply, 15 each quantity of buy request with same supplier as original request of 20 each quantity. Now the GOP planning repository snapshot can be
- Original DOO Fulfillment line schedule: item1, quantity (115 each) Schedule date (August 15, 12), Warehouse (w1) with following supply types:
- Reserve On Hand, 50 each quantity of item1 (original supply recommendation
- Transfer request for 30 each quantity of item1 (original supply recommendation)
- Buy request for 20 each quantity of item1 with supplier1 (original supply recommendation)
- Buy request for 15 each quantity of item1 with supplier1 (Delta supply recommendation)
Now system has following options to process the Delta supply
- Option1:
- Update existing Buy request for 20 each quantity of item1 (Change from 20 to 30. Send change request to procurement)
- Option2:
- New Buy request for 10 each quantity of item 1 (send a new request to the procurement system)
System can have the functional logic to determine the best option to apply the change. One of proposed design is to that system can choose the option to increase the quantity for the supply tracking lines that has the lower risk. For example, in the above scenario, for the supply tracking that managing the BackToBack buy process has an schedule exception, system can reduce the risk by applying the quantity reduction on the supply tracking line that does not have any exception or jeopardy status is high.
- New Buy request for 10 each quantity of item 1 (send a new request to the procurement system)
- Original DOO Fulfillment line schedule: item1, quantity (100 each) Schedule date (August 15, 12), Warehouse (w1) with following supply types:
The following table provides summary of attribute name, priority score based on attribute vales, and weighted priority score based on attribute values. For every supply tracking line and document line, system should compute the weighted score and prioritize the lines based on weighted score. Based on the following functional logic, the supply line that has minimum weighted score represents the low risk line and supply line that has maximum score is a high risk supply line.
As outlined earlier, for reduced 45 each quantity, system had following options.
-
- Option1:
- Reserve On Hand, 50 each quantity of item1 (Change from 50 to 5)
- Buy request for 20 each quantity of item1 (No change)
- Transfer request for 30 each quantity of item1 (No Change)
- Option 2:
- Reserve On Hand, 50 each quantity of item1 (No change)
- Buy request for 20 each quantity of item1 (Change from 20 to 0)
- Transfer request for 30 each quantity of item1 (Change from 30 to 5)
- Option3:
- Reserve On Hand, 50 each quantity of item1 (Change from 50 to 35)
- Buy request for 20 each quantity of item1 (No change)
- Transfer request for 30 each quantity of item1 (Change from 30 to 0)
- Option 4-n: There are multiple combinations depends upon the current status of the supply creation process
This task has prioritized the options: - Option 2
- Buy request for 20 each quantity of item1 (Change from 20 to 0)
- Transfer request for 30 each quantity of item1 (Change from 30 to 5)
- Reserve On Hand, 50 each quantity of item1 (No change)
- Option1:
In accordance with the embodiment,
According to the embodiment, a supply tracking line split function can be invoked at 2011. The supply tracking line split function can split a supply tracking line into multiple supply tracking lines. The supply tracking line split function can also split an original item quantity for an original supply tracking line into multiple item quantities for the multiple supply tracking lines. Supply tracking line 2031 can subsequently be updated at 2012, where the item quantity attribute of “100” is updated to “50.” Supply tracking line 2032 can subsequently be created at 2013, where supply tracking line 2032 is associated with supply order line 2021, supply tracking line 2032 has an item quantity attribute of “30,” supply tracking line 2032 has a supplier attribute of “supplier1,” and supply tracking line 2032 is associated with purchase order schedule 2042. Further, supply tracking line 2033 can be created at 2014, where supply tracking line 2033 is associated with supply order line 2021, supply tracking line 2033 has an item quantity of “20,” supply tracking line 2033 has a supplier attribute of “supplier1,” and supply tracking line 2033 is associated with purchase order schedule 2043. Thus, the original item quantity of “100” for supply tracking line 2031 is split into an item quantity of “50” for supply tracking line 2031, an item quantity of “30” for supply tracking line 2032, and an item quantity of “20” for supply tracking line 2033.
Also according to the embodiment, a supply chain orchestration process split function can be invoked at 2015. The supply chain orchestration process split function creates parallel orchestration flows for supply tracking lines 2032 and 2033 on a same supply chain orchestration process instance (i.e., supply chain orchestration process instance 2050).
In accordance with the embodiment,
According to the embodiment, a supply tracking line split function can be invoked at 2111. Supply tracking line 2131 can subsequently be updated at 2112, where the item quantity attribute of “100” is updated to “60.” Supply tracking line 2132 can subsequently be created at 2113, where supply tracking line 2132 is associated with supply order line 2121, supply tracking line 2132 has an item quantity attribute of “40,” and supply tracking line 2132 has a supplier attribute of “supplier2,” which represents an alternate external supply execution system. Thus, the original item quantity of “100” for supply tracking line 2131 is split into an item quantity of “60” for supply tracking line 2131, and an item quantity of “40” for supply tracking line 2132. Further supply tracking line 2131 is associated with an original external supply execution system (i.e., “supplier1”), and supply tracking line 2132 is associated with an alternate external supply execution system (i.e., “supplier2”). Also according to the embodiment, an instance of a new supply chain orchestration process (i.e., supply chain orchestration process 2170) can be initiated for supply tracking line 2132.
Supply Chain Orchestration Internal Material Transfer Flow Execution RulesAccording to an embodiment, a supply chain orchestration system is provided that can define declarative execution rules used to define conditions that trigger an appropriate internal material transfer execution document from a choice of available internal material transfer execution documents. The execution rules can be implemented during orchestration of an internal material transfer orchestration process to create the appropriate internal material transfer execution document.
As previously described, an internal material transfer orchestration process is a supply chain orchestration process used in business organizations to transfer material (e.g., products produced/procured by a business organization) from one entity of a business organization to another. Existing ERP systems typically support internal material transfer processes by utilizing hard-coded definitions to create internal material transfer documents, with limited configurability to control the definitions. For example, some existing ERP systems use a document called a “Transfer Order” document to process and track internal material transfers. Other existing systems use pairs of documents such as “Internal Requisitions/Internal Sale Orders” or “Purchase Orders/Sales Orders” to process and track internal material transfers. Business users typically adapt to this limitation by either customizing or changing their business processes to conform to this limitation.
In accordance with the embodiment, a supply chain orchestration system can allow a user to define execution rules that control the selection of an execution document (or multiple execution documents) used to perform the internal material transfer. The user can author the execution rules. The execution rules are interpreted during the internal material transfer orchestration process, and generate the selected execution document(s) used to process the internal material transfer per the definition of the execution rules.
Previous ERP systems did not typically expose control mechanisms for selecting an execution document involved in an internal material transfer orchestration process. As is described below in greater detail, in accordance with an embodiment, a supply chain orchestration system can expose a control mechanism for selecting an execution document in a way that allows business analysts to create execution rules for selecting execution documents, and that further allows the business analysts to modify the execution rules when business conditions change.
Further, create transfer document service 2210 can interpret internal material transfer rules 2220, defined within the supply chain orchestration system, and select one or more execution documents. An example embodiment is illustrated below in the following table. Create transfer document service 2210 may create more than one transfer order for a requisition or a planned transfer request. However, create transfer document service 2210 is not required to combine multiple requisitions or multiple planned transfer requests into a single transfer order.
Single System: The supply chain orchestration system can determine if the external supply request system and the external supply execution system are the same system. A purchase order can be generated if a buy-sell relationship is defined within the supply chain orchestration system between the “transfer from” organization and the “transfer to” organization. A transfer order can be generated if a transfer is within an organization (i.e., a “transfer from” and “transfer to” organization is the same, but the sub-inventory is different). This can also be identified as an intra-organization transfer. Further, a transfer order can also be generated if a transfer is an inter-organizational transfer.
Cross-System: The supply chain orchestration system can further determine if the external supply request system and the external supply execution system are separate systems. Create transfer document service 2210 can always create a purchase order for internal material transfers involving cross-systems.
According to the embodiment, create transfer document service 2210 can determine an appropriate external supply execution system that can fulfill the internal material transfer. Create transfer document service 2210 can further initiate a generation of the appropriate execution documents, such as a purchase order and/or a transfer order. Create transfer document service 2210 can further invoke a supply task service to send a message to the external supply execution system to execute the appropriate supply task and to generate the appropriate execution documents.
As previously described, internal material transfer execution rules 2220 can define one or more operation policies that govern the execution transactions that can be created to execute an internal material transfer request. In one embodiment, execution rules can allow a user to define the following:
-
- Buy Sell Relationship: Internal material transfer (“IMT”) that are based on buy sell relationship. In this case, IMTs can involve creating a PO on the requesting organization. The PO is assumed to be electronically transmitted to the fulfilling organization, which will, it is assumed, create a sales order. It is also assumed that there will be references on the sales order to indicate the appropriate PO/PO Line Number/PO Distribution Number that the sales order/sales order line is fulfilling. Execution rules, for buy sell relationships, can be defined, for all IMTs across two organizations, Item categories or specific items.
- If a Buy Sell relationship is not defined, then:
- IMT can be executed using Transfer Orders, if the transfer is between organizations, within an instance
- IMT can be executed by creating a purchase order, if the transfer is between organizations, spanning multiple instances. The PO is assumed to be electronically transmitted to the fulfilling organization, which will, it is assumed, create a sales order. It is also assumed that there will be references on the sales order to indicate the appropriate PO/PO Line Number/PO Distribution Number that the sales order/sales order line is fulfilling.
- Route Internal material transfers through distributed order orchestration (“DOO”) or not: Customers will be able to define rules and conditions that determine whether internal material transfers are routed through DOO or not. Internal material transfers can be configured to be routed through DOO or bypass DOO. Transfer orders will route internal material requests through DOO, based on this rule.
- Grouping Rules to determine creation of transfer order: Customers will be able to define grouping rules to control the grouping of transfer orders that get created, for requisitions and/or planned requests. The document creation service will create transfer orders adhering to these grouping rules.
At 2420, one or more execution rules are invoked. An execution rule is a rule that includes one or more conditions and one or more actions. The one or more conditions can include conditions based on one or more attributes of the internal material transfer request. The actions can include one or more selection actions that select one or more execution documents from a plurality of execution documents. The flow then proceeds to 2430.
At 2430, one or more execution documents are selected based on the one or more invoked execution rules. Examples of execution documents include a transfer order and a purchase order. The flow then proceeds to 2440.
At 2440, a supply chain orchestration process is selected based on the one of more selected execution documents. A supply chain orchestration process that can initiate a generation of the one or more selected execution documents can be selected. An instance of the selected supply chain orchestration process can be generated and executed. The flow then proceeds to 2450.
At 2450, a business service is created. The business service can create the one or more selected execution documents. The business service can be created by the supply chain orchestration process instance. The flow then proceeds to 2460.
At 2460, the business service is invoked, and a supply task is created, where the supply task includes a payload, the payload includes one or more attributes, and the payload creates the one or more selected execution documents. The flow then proceeds to 2470.
At 2470, a message is sent to an external supply execution system, where the message includes the payload. The external supply execution system can then create the one or more selected execution documents. The flow then ends.
Thus, in one embodiment, a supply chain orchestration system can orchestrate and manage complex orchestration processes that transcend a plurality of external supply execution systems, which can provide users significant business benefits. More specifically, this can allow users to more easily utilize multiple specialized factories to produce goods or utilize partners to supplemental their capabilities. Examples of these complex orchestration processes can include single- or multiple-party contract manufacturing, complex outside processing of manufacturing operations, multi-plant manufacturing (also referred to as distributed manufacturing, rule-based execution of internal material transfers (transactions where two entities of the same company exchange materials). Further, when complex manufacturing activities occur across multiple plants or business partners, companies often create multiple execution documents, such as manufacturing work orders, purchase orders, transfer requests, etc., to facilitate various types of transactions, which are related without any obvious link. Understanding the progress of supply creation activities requires the users to understand the link amongst these execution documents and to under how a progress of an execution document affects the progress of the final outcome of the orchestration process. The supply chain orchestration system can provide the ability to manage these interlinked processes. Thus, with the aid of the supply chain orchestration system, companies can: (1) supplement their capabilities with those of the partners, thus increasing their business profiles; (2) expand their product offerings; (3) reduce order fulfillment time; and (4) improve their return on assets. Further, the supply chain orchestration system can allow business analysts to author execution rules to determine a choice of execution documents during the process of internal material transfers. Execution rules can range from broad rules, affecting a wide variety of internal material transfers, to granular rules that only affect specific internal material transfers. Thus, a business organization can become flexible enough to easily and quickly adapt to modifications in their internal material transfer supply chain orchestration processes by modifying the execution rules that control the generation of execution documents.
The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of “one embodiment,” “some embodiments,” “certain embodiment,” “certain embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases “one embodiment,” “some embodiments,” “a certain embodiment,” “certain embodiments,” or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.
Claims
1. A computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to orchestrate a supply chain orchestration process, the orchestrating comprising:
- receiving a supply request;
- creating a supply order;
- selecting a supply chain orchestration process for the supply order, wherein the supply chain orchestration process comprises one or more steps;
- generating an executable supply chain orchestration process;
- executing the executable supply chain orchestration process to generate one or more supply tasks that are defined by the one or more steps of the supply chain orchestration process;
- sending the one or more supply tasks to one or more external supply execution systems;
- receiving one or more status values from the one or more external supply execution systems; and
- generating an overall status value for the supply chain orchestration process based on the one or more status values.
2. The computer-readable medium of claim 1, the orchestrating further comprising:
- validating the supply request, wherein the supply request comprises a payload, and wherein the payload comprises one or more attributes;
- determining whether the supply request is a request to create a supply or a request to modify a supply;
- validating at least one attribute of the one or more attributes of the payload of the supply request;
- determining a supply type of the supply request; and
- enriching at least one attribute of the one or more attributes of the payload of the supply request.
3. The computer-readable medium of claim 2,
- wherein the supply order comprises supply order header, one or more supply order lines, and one or more supply tracking lines;
- wherein creating the supply order further comprises translating the one or more attributes of the payload of the supply request into one or more attributes of at least one of the supply order header, the one or more supply order lines, or the one or more supply tracking lines of the supply order.
4. The computer-readable medium of claim 1, the orchestrating further comprising:
- defining the one or more steps for the supply chain orchestration process;
- defining a task for each step of the supply chain orchestration process;
- defining a sequence of the one or more steps of the supply chain orchestration process;
- defining one or more status values for the supply chain orchestration process; and
- assigning a cost of change to each step of the supply chain orchestration process.
5. The computer-readable medium of claim 4, the orchestrating further comprising:
- deploying the supply chain orchestration process;
- creating a supply chain orchestration process instance, wherein the supply chain orchestration process instance comprises the executable supply chain orchestration process; and
- executing the supply chain orchestration process instance.
6. The computer-readable medium of claim 1, the orchestrating further comprising:
- receiving a supply task request;
- creating a supply task comprising a payload;
- sending a message comprising the payload of the supply task to an external interface layer;
- transforming the payload of the supply task into an execution system-specific payload of the supply task; and
- sending a message comprising the execution system-specific payload of the supply task to an external supply execution system.
7. The computer-readable medium of claim 6, the orchestrating further comprising:
- receiving one or more status values from the external supply execution system;
- transforming the one or more status values into one or more transformed status values;
- sending the one or more transformed status values to a business layer service;
- transforming the one or more transformed status values into a task status; and
- sending the task status to an orchestration layer.
8. The computer-readable medium of claim 1, the orchestrating further comprising:
- receiving a change supply request;
- creating a change supply order;
- computing a delta between the change supply order and the supply order;
- executing the executable supply chain orchestration process in a change mode to compensate at least one supply task that is defined by at least one step of the supply chain orchestration process using a compensation pattern; and
- compensating the at least one supply task using at least one external supply execution system.
9. The computer-readable medium of claim 1, the orchestrating further comprising:
- analyzing a supply request and determining whether the supply request is an internal material transfer request;
- invoking one or more execution rules when the supply request is an internal material transfer request;
- selecting one or more execution documents based on the one or more invoked execution rules when the supply request is an internal material transfer request;
- creating a supply task comprising a payload when the supply request is an internal material transfer request, wherein the payload creates the one or more selected execution documents; and
- sending a message comprising the payload of the supply task to an external supply execution system when the supply request is an internal material transfer request.
10. The computer-readable medium of claim 1,
- wherein the supply request comprises one of: a request to create a supply; a request to make a supply; or a request to transfer a supply;
- wherein the supply order comprises one of: an order to create a supply; a request to make a supply; or a request to transfer a supply;
- wherein the supply chain orchestration process orchestrates a supply creation process; and
- wherein the one or more external supply execution systems comprises at least one of: an external purchasing system; an external manufacturing system; or an external transfer system.
11. A computer-implemented method for orchestrating a supply chain orchestration process, the computer-implemented method comprising:
- receiving a supply request;
- creating a supply order;
- selecting a supply chain orchestration process for the supply order, wherein the supply chain orchestration process comprises one or more steps;
- generating an executable supply chain orchestration process;
- executing the executable supply chain orchestration process to generate one or more supply tasks that are defined by the one or more steps of the supply chain orchestration process;
- sending the one or more supply tasks to one or more external supply execution systems;
- receiving one or more status values from the one or more external supply execution systems; and
- generating an overall status value for the supply chain orchestration process based on the one or more status values.
12. The computer-implemented method of claim 11, further comprising:
- validating the supply request, wherein the supply request comprises a payload, and wherein the payload comprises one or more attributes;
- determining whether the supply request is a request to create a supply or a request to modify a supply;
- validating at least one attribute of the one or more attributes of the payload of the supply request;
- determining a supply type of the supply request; and
- enriching at least one attribute of the one or more attributes of the payload of the supply request.
13. The computer-implemented method of claim 11, further comprising:
- defining the one or more steps for the supply chain orchestration process;
- defining a task for each step of the supply chain orchestration process;
- defining a sequence of the one or more steps of the supply chain orchestration process;
- defining one or more status values for the supply chain orchestration process; and
- assigning a cost of change to each step of the supply chain orchestration process.
14. The computer-implemented method of claim 11, further comprising:
- receiving a change supply request;
- creating a change supply order;
- computing a delta between the change supply order and the supply order;
- executing the executable supply chain orchestration process in a change mode to compensate at least one supply task that is defined by at least one step of the supply chain orchestration process using a compensation pattern; and
- compensating the at least one supply task using at least one external supply execution system.
15. The computer-implemented method of claim 11, further comprising:
- analyzing a supply request and determining whether the supply request is an internal material transfer request;
- invoking one or more execution rules when the supply request is an internal material transfer request;
- selecting one or more execution documents based on the one or more invoked execution rules when the supply request is an internal material transfer request;
- creating a supply task comprising a payload when the supply request is an internal material transfer request, wherein the payload creates the one or more selected execution documents; and
- sending a message comprising the payload of the supply task to an external supply execution system when the supply request is an internal material transfer request.
16. A system, comprising:
- a request reception module configured to receive a supply request;
- an order creation module configured to create a supply order;
- an orchestration process selection module configured to select a supply chain orchestration process for the supply order, wherein the supply chain orchestration process comprises one or more steps;
- an executable orchestration process generating module configured to generate an executable supply chain orchestration process;
- an execution module configured to execute the executable supply chain orchestration process to generate one or more supply tasks that are defined by the one or more steps of the supply chain orchestration process;
- a task transmission module configured to send the one or more supply tasks to one or more external supply execution systems;
- a status value reception module configured to receive one or more status values from the one or more external supply execution systems; and
- a status value generating module configured to generate an overall status value for the supply chain orchestration process based on the one or more status values.
17. The system of claim 16, further comprising:
- a supply request validation module configured to validate the supply request, wherein the supply request comprises a payload, and wherein the payload comprises one or more attributes;
- a supply request determination module configured to determine whether the supply request is a request to create a supply or a request to modify a supply;
- an attribute validation module configured to validate at least one attribute of the one or more attributes of the payload of the supply request;
- a supply type determination module configured to determine a supply type of the supply request; and
- an attribute enrichment module configured to enrich at least one attribute of the one or more attributes of the payload of the supply request.
18. The system of claim 16, further comprising:
- an orchestration process definition module configured to define the one or more steps for the supply chain orchestration process;
- wherein the orchestration process definition module is further configured to define a task for each step of the supply chain orchestration process;
- wherein the orchestration process definition module is further configured to define a sequence of the one or more steps of the supply chain orchestration process;
- wherein the orchestration process definition module is further configured to define one or more status values for the supply chain orchestration process; and
- wherein the orchestration process definition module is further configured to assign a cost of change to each step of the supply chain orchestration process.
19. The system of claim 16, further comprising:
- a change supply request reception module configured to receive a change supply request;
- a change supply order creation module configured to create a change supply order;
- a delta computation module configured to compute a delta between the change supply order and the supply order;
- a change mode execution module configured to execute the executable supply chain orchestration process in a change mode to compensate at least one supply task that is defined by at least one step of the supply chain orchestration process using a compensation pattern; and
- a compensation module configured to compensate the at least one supply task using at least one external supply execution system.
20. The system of claim 16, further comprising:
- an analysis module configured to analyze a supply request and determining whether the supply request is an internal material transfer request;
- an execution rule invocation module configured to invoke one or more execution rules when the supply request is an internal material transfer request;
- an execution document selection module configured to select one or more execution documents based on the one or more invoked execution rules when the supply request is an internal material transfer request;
- a supply task creation module configured to create a supply task comprising a payload when the supply request is an internal material transfer request, wherein the payload creates the one or more selected execution documents; and
- a message transmission module configured to send a message comprising the payload of the supply task to an external supply execution system when the supply request is an internal material transfer request.
Type: Application
Filed: Sep 30, 2013
Publication Date: Apr 3, 2014
Applicant: Oracle International Corporation (Redwood Shores, CA)
Inventors: Kannan TARAKAD (Belmont, CA), Ashok VERMA (Pleasanton, CA), Thomas DANIEL (Austin, TX), Srikanth KARIMISETTY (Austin, TX), Gnani PALANIKUMAR (San Jose, CA), Taruna GAUTAM (Dublin, CA), Imran Ali JEDDY (Hyderabad), Srinivas KALLAKURI (Hyderabad), Chandrashekar Reddy TIRUVIDULA (Austin, TX), Bankush GULATI (San Ramon, CA), Stephanie MERENDA (San Jose, CA), Jaewook KIM (Foster City, CA), Maria MATHENY (San Ramon, CA)
Application Number: 14/040,911
International Classification: G06Q 10/06 (20060101);