US20140095249A1

US20140095249A1 - Supply chain orchestration system with orchestration, change management and internal material transfer flow

Info

Publication number: US20140095249A1
Application number: US14/040,911
Authority: US
Inventors: Kannan TARAKAD; Ashok Verma; Thomas Daniel; Srikanth Karimisetty; Gnani PALANIKUMAR; Taruna GAUTAM; Imran Ali JEDDY; Srinivas KALLAKURI; Chandrashekar Reddy TIRUVIDULA; Bankush GULATI; Stephanie MERENDA; Jaewook KIM; Maria MATHENY
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2012-09-28
Filing date: 2013-09-30
Publication date: 2014-04-03
Also published as: US20140095343A1; US9767499B2

Abstract

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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.

FIELD

One embodiment is directed to a computer system, and more particularly, to a computer system that orchestrates supply chain processes.

BACKGROUND

As 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.

SUMMARY

One 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.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

FIG. 1 illustrates a block diagram of a system that can implement an embodiment of the invention.

FIG. 2 illustrates a block diagram of an example architecture of a supply chain orchestration system, according to an embodiment of the invention.

FIG. 3 illustrates a block diagram of a decomposition data model for a decomposition layer, according to an embodiment of the invention.

FIG. 4 illustrates a flow diagram of the decomposition functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 5 illustrates a block diagram of an orchestration data model for an orchestration layer, according to an embodiment of the invention.

FIG. 6 illustrates a flow diagram of the orchestration functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 7 illustrates a block diagram of a forward planning and jeopardy management data model of an orchestration layer, according to an embodiment of the invention.

FIG. 8 illustrates a flow diagram of the forward planning and jeopardy management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 9 illustrates another flow diagram of the forward planning and jeopardy management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 10 illustrates another flow diagram of the forward planning and jeopardy management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 11 illustrates a sequence diagram of a business services layer, according to an embodiment of the invention.

FIG. 12 illustrates a flow diagram of the business services functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 13 illustrates an example user interface of a workbench for a supply chain orchestration system, according to an embodiment of the invention.

FIG. 14 illustrates a flow diagram of the overall orchestration functionality of a supply chain orchestration module, according an embodiment of the invention.

FIG. 15 illustrates a block diagram of an example architecture of a supply chain orchestration system that implements change management, according to an embodiment of the invention.

FIG. 16 illustrates a flow diagram of the change management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 17 illustrates a flow diagram of a decomposition component of the change management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 18 illustrates a flow diagram of an orchestration component of the change management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 19 illustrates a flow diagram of a prioritization component of the change management functionality of a supply chain orchestration module, according to an embodiment of the invention.

FIG. 20 illustrates dynamic splitting of a supply tracking line and a supply chain orchestration process to manage multiple execution documents, according to an embodiment of the invention.

FIG. 21 illustrates dynamic splitting of a supply tracking line and a supply chain orchestration process to manage a supply side exception, according to an embodiment of the invention.

FIG. 22 illustrates a block diagram of an internal material transfer business process, according to an embodiment of the invention.

FIG. 23 illustrates an example user interface that defines execution rules for an internal material transfer business process, according to an embodiment of the invention.

FIG. 24 illustrates a flow diagram of the internal material transfer execution rule functionality of a supply chain orchestration module, according to an embodiment of the invention.

DETAILED DESCRIPTION

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.
FIG. 1 illustrates a block diagram of a supply chain orchestration system 10 that may implement one embodiment of the invention. Supply chain orchestration system 10 includes a bus 12 or other communications mechanism for communicating information between components of supply chain orchestration system 10. Supply chain orchestration system 10 also includes a processor 22, operatively coupled to bus 12, for processing information and executing instructions or operations. Processor 22 may be any type of general or specific purpose processor. Supply chain orchestration system 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of machine or computer-readable medium. Supply chain orchestration system 10 further includes a communication device 20, such as a network interface card or other communications interface, to provide access to a network. As a result, a user may interface with supply chain orchestration system 10 directly, or remotely through a network or any other method.
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 Orchestration

According 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.
FIG. 2 illustrates a block diagram of an example architecture of a supply chain orchestration system 200, according to an embodiment of the invention. According to the embodiment, supply chain orchestration system 200 includes a supply requests layer 210. Supply requests layer 210 is a layer that is external to the supply chain orchestration system 200, and supply requests layer 210 includes one or more sources of supply requests, where a supply request is a request to one or more suppliers to create goods and/or services. Sources of supply requests can be external supply request systems, such as supply chain planning systems or order promising systems. However, supply chain orchestration system 200 can connect to any type of external supply request system. Further, example supply requests can include order requests or internal material transfer requests.
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 FIGS. 3 and 4.
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 FIGS. 5, 6, 7, 8, 9, and 10.
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 FIGS. 11 and 12.
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 FIG. 13.
FIG. 3 illustrates a block diagram of a decomposition data model 300 for a decomposition layer, according to an embodiment of the invention. As previously described, supply requests (such as supply requests 311, 312, 313, and 314) that are generated by external supply request systems are received as input, and each supply request is converted into a supply order 320, where a supply order is a canonical representation of a supply request with a canonical format. In certain embodiments, supply order 320 includes a supply request system attribute, one or more source document attributes, and a status attribute. More specifically, supply order 320 includes a supply order header 321, where supply order header 321 is an object that contains a hierarchy of supply order 320. A hierarchy includes one or more supply order lines, one or more supply tracking lines, one or more supply tracking line documents, and one or more supplemental information components. Supply order line 322 is an object that contains the information of the corresponding supply order line of supply order 320, where a supply order line represents an individual supply request that is part of the overall supply request. In certain embodiments, supply order line 322 includes a supply source system attribute, a supply request type attribute, one or more supply item detail attributes, one or more supply quantity detail attributes, one or more document key attributes, and a status attribute. Supply tracking line 323 is an object that contains the information of the corresponding supply tracking line of supply order 320, where a supply tracking line represents an external supply execution system that corresponds to the individual supply request. In certain embodiment, supply tracking line 323 includes a supply source system attribute, a supply request type attribute, one or more supply item detail attributes, one or more supply quantity detail attributes, one or more supply source detail attributes, one or more requesting source detail attributes, one or more supply date attributes, and a status attribute. Supply tracking line document 324 is an object that contains the information of the document that corresponds to supply tracking line 323. Supply line supplemental information 325 is an object that contains all supplemental information for supply tracking line 324.
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.
FIG. 4 illustrates a flow diagram of the decomposition functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. In one embodiment, the functionality of the flow diagram of FIG. 4, as well as the functionality of FIGS. 6, 8, 9, 10, 12, 14, 16, 17, 18, 19, and 24, are each implemented by software stored in memory or other computer-readable or tangible medium, and executed by a processor. In other embodiments, each functionality may be performed by hardware (e.g., through the use of an application specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field programmable gate array (“FPGA”), etc.), or any combination of hardware and software. In certain embodiments, some or all of each functionality may be omitted.
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:


Name	Description	Comment

Supply Request	System that has requested for the supply.
Source	PLN—Planning, DOO—Distributed Order
	Orchestration through GOP Pegging Tree
	for Back to Back Orders, SSP—Self
	Service Procurement,
	INV—Inventory, SCO—in case of
	Alternate supply
Record Number	Record Number
Requested Supply	Supply Type recommended by the calling	For Buy
Type	application - Make, Buy, Transfer or ATP	orders,
		this will
		be BUY
Item ID	Item ID in Fusion
UOM Code	Unit of Measure code in Fusion
Quantity	Requested Quantity
Requested	Need by date
Delivery Date
Destination	Destination organization ID in Fusion
organization ID
Destination Type	Destination type - Inventory or Expense	In case
Code	or Dropship	of GOP -
		default
		this as
		Inventory

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:


Name	Description	Comment

Supply Request	System that has requested for the supply.
Source	PLN—Planning, DOO—Distributed Order
	Orchestration through GOP Pegging Tree for
	Back to Back Orders, SSP—Self Service
	Procurement,
	INV—Inventory
Record Number	Record Number or Requisition Line Id for	In case of GOP -
	SSP	this will be the
		DOO Fulfillment
		line ID - against
		which
		recommendation
		received
Requested Supply	Supply Type recommended by the calling	For Transfer
Type	application - Make, Buy, Transfer or ATP	orders, this will
		be Transfer
Item ID	Item Id in Fusion
Source	Ship from organization ID or Code in Fusion.
Organization ID	Either source organization ID or Code is
	mandatory.
Destination	Destination organization ID or Code in
Organization ID	Fusion. Either destination organization ID or
	Code is mandatory.
Quantity	Requested Quantity
Requested Delivery	Need by date on the internal requisition
Date Or Ship Date	(arrival date). Ship Date on the internal sales
	order or transfer.
UOM Code	Unit of Measure Code in Fusion

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:


Name	Description	Comment

Supply	System that has requested for the supply.	SCO will not receive
Request	PLN—Planning, DOO—Distributed Order	make recommendations
Source	Orchestration through GOP Pegging Tree for	from INV or SSP.
	Back to Back Orders, SSP—Self Service
	Procurement,
	INV—Inventory
Record	Record Number from the source
Number
Requested	Must be Make
Supply Type
Organization	Organization ID in Fusion	This is the organization
ID		where the job will be created.
Item ID	Item ID in Fusion
Start	Job start quantity.	This could be the same
quantity		as Requested Quantity.
		For GOP - this would
		be the tracking line qty

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


Attribute	Valid Values

Supply Request	System that has requested for the supply.
Source	PLN—Planning, DOO—Distributed Order
	Orchestration through
	GOP Pegging Tree for Back to Back Orders,
	SSP—Self Service Procurement,
	INV—Inventory
Supply Request	Supply Request Type
Type	XFER—Transfer
Supply Request	Document Reference number from the supply
Reference Number	system.
	Ex: Requisition number in case of SSP requests.
	Batch number for planning
Supply Request	Document Reference id from the requesting system.
Reference Id	Ex: Req Header Id for SSP requests
	Batch number for planning

GetTransferDocumentTypeLines


Attribute	Valid Values

Line Number	Reference line number from the requesting source.
	Will be defaulted if not passed.
	Example: Record number for planning
Supply Type	Requested supply type for the line. Defaulted with
	the supply request type if not passed in.
	XFER—Transfer
Supply Source	Source system in which the supply must be created.
System	Passed by planning.
Inventory Item Id	Item for which the supply is being requested.
Supply Order	Document Line Reference id from the requesting
Reference Line Id	system.
	Requisition Line Id in case of SSP.
	Record Number for planning
Source BU Id	Source business unit
Source	Inventory organization from where the supply is
Organization Id	being fulfilled.
Destination BU Id	Destination business unit
Destination	Destination inventory org.
Organization Id
Quantity	Transfer Quantity
UOM Code	Transfer UOM
Need By Date	Supply need by date
Ship Date	Transfer ship date
Destination	Destination subinventory
Subinventory
Deliver to Location	Deliver to location
Id
Deliver to	Deliver to requestor
Requestor Id
Preparer Id	Preparer
Shipping Method	Ship method
Firm Demand Flag	Passed by planning for Internal Req in EBS

Output of the Service is


Attribute	Valid Values

Request Source	Document Reference id from the requesting system.
Reference Id	Ex: Req Header Id for SSP requests
	Batch number for planning
Request Source	Document Line Reference id from the requesting
Reference Line Id	system.
	Requisition Line Id in case of SSP.
	Record number for planning
Return Status	S—Success
	E—Error
Error Message	Error message code passed if there is an error.
Code
Error Message Text	Error message text passed in case of error.
Document Type	Type of document
	XFER—Transfer
	BUYSELL - Purchase Order
Supplier Id	Supplier for creating the purchasing document
Supplier Site Id	Supplier site for creating the purchasing document

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 FIG. 5. The flow then ends.
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.
FIG. 5 illustrates a block diagram of an orchestration data model for an orchestration layer, according to an embodiment of the invention. According to the embodiment, supply order 510 is a canonical representation of a supply request with a canonical format, where supply order 510 includes at least one supply order line 511, and each supply order line 511 includes at least one supply tracking line 512.
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 FIG. 7. Additionally, task 550 is associated with task type 551, where task type 551 represents a task type, and where a task type is a collection of logically-related tasks.
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 FIG. 7. Orchestration process definition 530 also includes change order attributes 580 which define one or more attributes of supply order 510 that, when modified, indicate a modification to supply order 510. Orchestration process definition 530 additionally includes status values (identified in FIG. 3 as “status codes”) 590. Examples of status codes 590 include supply line status rule sets 591, supply line status conditions 592, supply tracking line status codes 593, process class status codes 594, task type status codes 595, task layer status mapping 596, supply status rule set assignments 597, and process status conditions 598. Orchestration process definition 530 inherits from process class 599, where process class 599 is a mechanism for grouping orchestration processes for inheritance of status information.
FIG. 6 illustrates a flow diagram of the orchestration functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. The flow begins, and proceeds to 610. At 610, one or more steps of a supply chain orchestration process are defined. A step is a component of a supply chain orchestration process, where a step can be associated with a task and a service, and where the supply chain orchestration process can include a sequence of steps. In certain embodiments, a step type is assigned to each step. Further, in certain embodiments, each step is assigned to a parent step, where the step is not executed until the parent step has completed execution. Additionally, in certain embodiments, a split attribute can be defined for a step, where the split attribute indicates whether the step can be split. The flow then proceeds to 620.
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.
FIG. 7 illustrates a block diagram of a forward planning and jeopardy management data model of an orchestration layer, according to an embodiment of the invention. As previously described, a supply chain orchestration system can provide for 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. According to the embodiment, the forward planning and jeopardy management data model illustrated in FIG. 7 includes elements of the orchestration data model illustrated in FIG. 5. More specifically, the forward planning and jeopardy management data model includes supply order header 510, supply order line 511, supply order tracking line 512, orchestration process definition 520, orchestration process step definition 521, orchestration task definition 522, orchestration process instance (illustrated in FIG. 7 as “orchestration process runtime”) 525, orchestration process step instance 526, and orchestration process task instance 527. These entities are described in conjunction with FIG. 5, and are not described again here.
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.
FIG. 8 illustrates a flow diagram of the forward planning and jeopardy management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. According to the embodiment, FIG. 8 illustrates example external supply request systems 800 (illustrated in FIG. 8 as “demand systems”). Each external supply request system of external supply request systems 800 can generate and send a supply request.
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 FIGS. 9 and 10. If the supply order generates a document request, then the flow proceeds to 850. Otherwise the flow proceeds to 880. At 850, the document request is processed. This can involve sending the document request to an external supply execution system of external supply execution systems 890 (identified in FIG. 8 as “execution systems”), and having the external supply execution system collect progress data. The flow then proceeds to 860. At 860, the progress data is received from the external supply execution system. In certain embodiments, the flow returns to 840. In other embodiments, the flow proceeds to 870. At 870, a status of the supply order is tracked and monitored. The flow then proceeds to 880. At 880, an action is taken based on progress data. Examples of actions can include modifying the supply chain orchestration process. The flow then ends.
FIG. 9 illustrates another flow diagram of the forward planning and jeopardy management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. The flow begins and proceeds to 910. At 910, the steps of a supply chain orchestration process are traversed, starting with the “last step.” More specifically, a “last step” of a supply chain orchestration process is identified, where the “last step” is a step identified as the completion step for the process (and thus, is not necessarily the actual last step of the supply chain orchestration process). A step dependency tree of the supply chain orchestration process is then traversed backwards. The flow then proceeds to 920.
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 FIG. 10. The flow then ends.
FIG. 10 illustrates another flow diagram of the forward planning and jeopardy management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. According to the embodiment, once planned and required dates are established for steps of a supply chain orchestration process, in-process supply orders can be evaluated to determine where planned completion dates for steps of the supply chain orchestration process are later than the required completion dates. For any step of the supply chain orchestration process that is late, a score can be assessed based on user-defined thresholds. A jeopardy score can be maintained at a task level. When a task has multiple steps leading to a jeopardy score, the highest score among all the step scores can be the score assigned to the task. Further, a jeopardy priority can be determined using the jeopardy score. A jeopardy score can also be maintained at a supply chain orchestration process instance level. The jeopardy score for a supply chain orchestration process instance can be the highest jeopardy score for the task in the supply chain orchestration process instance.
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.

FIG. 11 illustrates a sequence diagram of a business services layer, according to an embodiment of the invention. According to the embodiment, FIG. 11 includes decomposition layer 1110, orchestration layer 1120, business services layer (identified in FIG. 11 as “task services layer”) 1130, external interface layer 1140, and external execution supply system 1150. A supply order can be created within decomposition layer 1110, where a supply order represents a supply request. Decomposition layer 1110 then sends the supply order to orchestration layer 1120.
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.
FIG. 12 illustrates a flow diagram of the business services functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. The flow begins and proceeds to 1210. At 1210, a supply task request is received. The supply task request can be sent from an orchestration layer. The flow proceeds to 1220. At 1220, a supply task is created, where the supply task includes a payload, and where the payload includes one or more attributes. The flow then proceeds to 1230. At 1230, a message is sent to an external interface layer, where the message includes the payload of the supply task. The flow then proceeds to 1240. At 1240, the payload of the supply task is transformed into an execution system-specific payload. This can include transforming the payload of the supply task from an internal format to an execution system-specific format. The flow then proceeds to 1250. At 1250, a message is sent to an external supply execution system, where the message includes the execution system-specific payload. The flow then proceeds to 1260.
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.
FIG. 13 illustrates an example user interface 1300 of a workbench for a supply chain orchestration system, according to an embodiment of the invention. User interface 1300 provides a comprehensive view of a supply chain orchestration system. For example, user interface 1300 allows a user to search the supply orders that have been created within the supply chain orchestration system. User interface 1300 can utilize an “object switcher” that allows the user to switch between objects to search on, such as supply orders, supply order lines, supply tracking lines, orchestration processes, and messages. User interface 1300 then can display the one or more objects, such as supply orders, supply order lines, supply tracking lines, orchestration processes, and messages. User interface 1300 further allows a user to manage one or more objects, such as supply orders, supply order lines, supply tracking lines, orchestration processes, and messages. More specifically, a user can attach files to objects, add notes to objects, or perform contextual actions on objects, such as supply orders, supply order lines, supply tracking lines, orchestration processes, and messages. User interface 1300 also allows the user to edit details of one or more objects, such as supply orders, supply order lines, supply tracking lines, orchestration processes, and messages.
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.
- 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.

FIG. 14 illustrates a flow diagram of the overall orchestration functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according an embodiment of the invention. The flow begins, and proceeds to 1410. At 1410, a supply request is received. The flow then proceeds to 1420. At 1420, a supply order is created. The flow then proceeds to 1430. At 1430, a supply chain orchestration process is selected for the supply order, where the supply chain orchestration process includes one or more steps. The flow then proceeds to 1440. At 1440, an executable supply chain orchestration process is generated based on the selected supply chain orchestration process. The flow then proceeds to 1450.
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 Management

According 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.
FIG. 15 illustrates a block diagram of an example architecture of a supply chain orchestration system that implements change management, according to an embodiment of the invention. According to the embodiment, the architecture includes external supply request systems 1510, supply chain orchestration system 1520, and external supply execution systems 1530, where external supply execution systems 1530 can generate execution documents 1540. As previously described, an external supply request system can send a new supply request 1521 to supply chain orchestration system 1520. Supply chain orchestration system 1520 can create a supply order that represents new supply request 1521 and can assign one or more supply chain orchestration process to the supply order. Supply chain orchestration system 1520 can further execute the one or more supply chain orchestration processes to fulfill the supply order and cause external supply execution systems 1530 to generate execution documents 1540.
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.


	Supply Order Line	Supply Tracking Line	Document Line

		Rqstd				Schd	Orig Ship	Need-By-	Shipping		Trkd
		Qty	Need_by_Date	Need_by_Date		Date	Mthd	Date	Method		Qty
		(New	New	(After		New	New	(After	(After		New
Step #	Line #	Rqst)	Request)	Reschd)	Line #	Rqust)	Rqst)	Reschd)	Reschd)	Line #	Rqust)

Planning-	The current snapshot of both demand and supply tracking lines for a new Planning buy request.
Step1	Based on Planning recommendation, system created one supply order line (SO1) of 100 each quantity and, Need By
	date of Aug. 15, 2012
	System also created a supply tracking line of Buy (TL56) of 100 each quantity and need-by-date of Aug. 15, 2012.
	After sending purchase request to the procurement systems, let us assume that procurement system returned a
	Purchase Requisition (PR122) and PO Schedule (POS122) of 100 each quantity for Scheduled date of Aug. 15, 2012.
	System will update the document lines with Requisition (PR122) and PO Schedule (POS122) of 100 each quantity
	At this stage, both purchase requisition and purchase order tasks are complete
	New request supply process instance is waiting for receipt of the PO Schedule and it is the only active task

SO1

100	Aug. 15,		TL56	Aug. 15,	3-day		PR122		100
		2012			2012	FedEx		POS122

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.


	Supply Tracking Line

		Orig
	Schd	Ship	Schd	Ship	Document
Supply Order Line	Date	Mthd	Date	Method	Line

		Rqstd	Need_by_Date	Need_by_Date		New	New	(After	(After		Original
Step #	Line #	Qty	(New Rqst)	(Reschd)	Line #	Rqst)	Rqst)	Reschd)	Reschd)	Line #	Qty

Planning-	This will be the snapshot after procurement system processed the change request of PO Schedule and returned the
Step1	updated PO Schedule with revised Schedule date (Aug. 20, 2012) and Shipping Method (2-day FedEx)
	At this stage, both demand line and supply tracking lines will readjusted with the revised Need_by_Date, Scheduled
	Date and Shipping Method
	Note that there are no changes to requested quantity

SO1

100	Aug. 15,	Aug. 20,	TL56	Aug. 15,	3-day	Aug. 20, 2012	2-day	PR-122	100
		2012	2012		2012	FedEx		FedEx

Key Takeaway

- 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)

GOP BacktoBack Decreased Supply Scenario

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 Scenario

Assume 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.


	Supply Tracking Line

Supply Order Line

Tracked

Requested

Qty

Document Line

		Requested	Qty (After		Tracked	(After		Original	Tracked Qty
		Qty	applying		Qty	applying		Qty	(After applying
		(New	update		New	update		New	update
Step #	Line #	Request)	request)	Line #	Request)	request)	Line #	Request)	request)

GOP-	The current snapshot of both demand and supply tracking lines for a new BacktoBack order.
Step1	Based on GOP recommendation, SCO created a supply order line (SO1) of 100 each quantity, three
	supply tracking lines of Buy, Transfer, OnHand (TL56, TL34, TL12) supply types of 20 each, 30 each,
	50 each quantity respectively.
	After sending create request to the execution systems, execution systems returned three document lines
	(PO Schedule (POS122), TO Line (TO344), Reservation (RE566) of 20 each, 30 each, 50 each quantity
	respectively
	Let us assume that system created the supply tracking lines in the following order

SO1*	100	TL12	50	RE566	50
		TL34	30	TO344	30
		TL56	20	POS122	20

Step 2	Now SCO has following two options to process the decrease quantity change request based on the current
	status of the supply creation process.
	Let us assume that SCO has prioritized both the supply tracking and document lines based on ascending
	order of original quantity: TL 56 (20 each), TL 34 (30 each), TL 12 (50 each)
	In the first option, procurement system processes the change request to reduce the quantity from
	20 each to 0 each.
	In the second option, procurement system rejected the change request to reduce the quantity from
	20 each to 0 each
Step	In this, procurement system processes the change request to reduce the quantity from 20 each
2a	to 0 each.
	Note that Tracked quantity is zero for POS 122 after procurement system processed the update
	request

SO1*	100	80	TL56	20	0	POS122	20	0
		55	TL34	30	5	TO344	30	5
			TL12	50	50	RE566	50	50

Step	In the second option, procurement system rejected the change request to reduce the quantity from
2b	20 each to 0 each
	Note that Tracked quantity does not change (20 each) for POS 122 after procurement system rejected
	the update request

SO1*	100	100	TL56	20	20	POS122	20	20
		75	TL34	30	5	TO344	30	5
		55	TL12	50	30	RE566	50	30

Key Takeaway

- 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

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.


			Reschedule
	Logical	Attributes	Purchase	Change
Task	Business	that manage	Order	Request
Type	Entities	change	(Planning)	(GOP)

Purchase	Supply	Tracked	No	Yes
Order	Tracking	Quantity
	Line	Need-By-	Yes	Yes
		Date
		Ship Date	Yes	Yes
		Shipping	Yes	Yes
		Method

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.


SCO Process Definition	New	Update*	Cancel*	OBR

Step #	Steps	Task	Task Type	Service	Service	Service	Rules

1	Initiate Purchase	Purchase	Purchase	Create	Update	Create
	Request	Request	Requisition
2	Wait for purchase	Purchase	Purchase	Wait	Wait	Wait
	requisition	Request	Requisition
3	Create	Reserve	Reservation	Create	Update	Cancel
	Reservation	Requisition				Create
	against Purchase
	Requisition

4	Track PO	PO	Purchase	Track	Track	Cancel
	Schedule	Schedule	Order
5	Wait for PO	PO	Purchase	Wait	Wait	Wait
	Schedule	Schedule	Order
6	Create Receipt	Receipt	Receipt	Create	Update	Cancel
	Advice	Advice	Advice
7	Wait for Receipt	Receipt	Receipt	Wait	Wait	Wait
	Advice	Advice	Advice
8	Track Receipt	Receipt	Receipt	Track	Track	N/A
9	Wait for Receipt	Receipt	Receipt	Wait	Wait	N/A
10	Track PO closed	Check PO	Purchase	Track	Track	N/A
	for receiving	Closure	Order
11	Wait for PO	Check PO	Purchase	Wait	Wait	N/A
	closed for	Closure	Order
	receiving
12	Track DOO	Check	DOO	Track	Track	N/A
	Fulfillment Line	Fulfillment	Update
	Items Shipped	Line
		Shipped
13	Wait for DOO	Check	DOO	Wait	Wait	N/A
	Fulfillment Line	Fulfillment	Update
	Items Shipped	Line
		Shipped

FIG. 16 illustrates a flow diagram of the change management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. The flow begins at 1611, where a supply request is received from an external supply request system 1610. In certain embodiments, the supply request references an original supply order. In other embodiments, the supply request references a supply order line, or a supply tracking line, or an original supply order. The flow then proceeds to 1612. At 1612, it is determined whether the supply request is a new supply request, a change supply request, or a cancel supply request. A new supply request is a request to execute a new supply chain orchestration process to orchestrate a supply order. A change supply request is a request to modify an already-executing supply chain orchestration process that is orchestrating a supply order. A cancel supply request is a request to cancel an already-executing supply chain orchestration process that is orchestrating a supply order.
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 FIG. 17. The flow then proceeds to 1632.
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 FIG. 18. The flow then proceeds to 1635. At 1634, 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. A change (or “update”) compensation of an original supply order is further described below in greater detail in conjunction with FIG. 18. The flow then proceeds to 1635.
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 FIG. 19. The flow then proceeds to 1639.
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 FIG. 18. The flow then proceeds to 1641.
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.
FIG. 17 illustrates a flow diagram of a decomposition component of the change management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. The flow begins and proceeds to 1710, where a supply request is received from an external supply request system. In certain embodiments, the supply request references an original supply order. In other embodiments, the supply request references a supply order line, or a supply tracking line, or an original supply order. The flow then proceeds to 1720. At 1720, it is determined whether the supply request is a new supply request, a change supply request, or a cancel supply request. If the supply request is a new supply request, then the flow proceeds to 1730. If the supply request is a cancel supply request, then the flow proceeds to 1740. If the supply request is a change supply request, then the flow proceeds to 1750. At 1730, a supply order is created, a supply chain orchestration process is selected for the supply order, and the supply chain orchestration process is executed, as previously described. The flow then ends.
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 FIG. 18. The invocation of the process cancel supply request function creates a cancel payload for a cancel supply task. The flow then proceeds to 1743. At 1743, a cancel supply task service is invoked, where a message including the cancel payload is sent to an external supply execution system. The flow then proceeds to 1744. At 1744, it is determined whether the cancel supply request requires the creation of a new supply. If the cancel supply request requires the creation of a new supply, the flow proceeds to 1730. Otherwise, the flow proceeds to 1760, where the flow ends.
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 FIG. 18. The invocation of the process change supply request function creates a change payload for a change supply task. The flow then proceeds to 1753. At 1753, a change supply task service is invoked, where a message including the change payload is sent to an external supply execution system. The flow then proceeds to 1754. At 1754, it is determined whether the change supply request requires the creation of a new supply. If the change supply request requires the creation of a new supply, the flow proceeds to 1730. Otherwise, the flow proceeds to 1760, where the flow ends.
FIG. 18 illustrates a flow diagram of an orchestration component of the change management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. In the context of change management, compensation is defined as the act of adjusting steps in a supply chain orchestration process in order to accommodate change requests. Therefore, in order for a supply chain orchestration system to process change requests, various service patterns are needed to perform the adjustment of the supply chain orchestration process steps. A service pattern is a template for providing a service that can be used in many different situations, where a finished service that is capable of being executed can be created based on the template. The service patterns capable of adjusting the steps of a supply chain orchestration process are defined as “compensation patterns.”
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.
FIG. 18 illustrates three example compensation patterns: an update compensation pattern 1810, a cancel compensation pattern 1820, and a redo compensation pattern 1830. One of ordinary skill in the art would readily appreciate that these are example compensation patterns according to an example embodiment, and that, in other alternate embodiments, there can be other types of compensation patterns. Further, FIG. 18 also illustrates a new request service pattern 1840, for comparison purposes.
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.
FIG. 19 illustrates a flow diagram of a prioritization component of the change management functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. According to the embodiment, for a supply order-specific change request, a supply chain orchestration system can prioritize one or more supply tracking lines based on supply availability risk, where the one or more prioritized supply tracking lines can be used to initiate the change request to one or more external supply execution systems. For example, for a change request with a reduced quantity, the supply chain orchestration system can select the supply tracking lines with a higher supply availability risk to meet the original demand. As another example, for a change request with an increased quantity, the supply chain orchestration system can select the supply tracking lines with a lower supply availability risk. Depending on business needs, a user of the supply chain orchestration system can customize the supply availability risk based on various risk criteria, such as a supply type, a status, an execution, a cost of change, or a jeopardy priority. Thus, the prioritization component of the change management functionality can minimize a risk in meeting a revised supply quantity.
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.
- 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.

Decreased Supply

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.

Key Takeaway

- 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.

Increased Supply

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.

Prioritizing Supply Tracking Lines Based on Various Criteria

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.


		Non-Delta
		Attribute (How
	Delta	to represent it
Logical	Attribute	in the UI)	Low- to High	Weighted
Entities	Name	Name	Priority Score	Score	Description

Supply		Supply Type	OnHand - 1	10 power 5
Tracking			Transfer - 2
Line			Buy - 3
			Make - 4
		Status		10 power 4	Supply Status
		Exception Type	No exception- 1	10 power 3
			Jeopardy
			exceptions - 2
			Schedule
			Exceptions - 3
			Quantity
			Exceptions-4
		Jeopardy	Low - 1	10 power 2
		Priority	Medium-2
			High-3
		Cost of Change	Low-1	10 power 1
			Medium-2
			High-3
	Tracked		Highest 1	10 power 0
	Quantity		Lowest - <n>
Document	Tracked			10 power 0
Line	Quantity

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)

FIG. 20 illustrates dynamic splitting of a supply tracking line and a supply chain orchestration process to manage multiple execution documents, according to an embodiment of the invention. According to the embodiment, a supply chain orchestration process can have a capability of dynamically splitting to track and manage multiple execution documents and tasks. This can happen when orchestrating a supply order involves generating multiple execution documents at multiple external supply execution systems. Example scenarios include multiple purchase order schedules, or multiple receipts in a purchase order schedule. According to the embodiment, if a supply chain orchestration process is split, the supply chain orchestration system can track and manage each sub-process individually. This can involve splitting a supply tracking line associated with a supply chain orchestration process.
In accordance with the embodiment, FIG. 20 illustrates a supply order 2010. Supply order 2010 includes supply order lines 2020, 2021, 2022, and 2023. Further, supply order line 2021 originally includes supply tracking line 2031. Supply tracking line 2031 has an item quantity attribute of “100” representing 100 items, and a supplier attribute of “supplier1,” represents an external supply execution system. Further, supply tracking line 2031 is associated with purchase order schedule 2041. Supply tracking line 2031 is also associated with a supply chain orchestration process, supply chain orchestration process 2050. An instance of supply chain orchestration process 2050 can be initiated to orchestrate supply tracking line 2031 (and ultimately supply order 2010). Supply chain orchestration process 2050 can further communicate with purchase order task layer service 2060, where purchase order task layer service 2060 is a task layer service that communicates with an external purchasing system.
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).
FIG. 21 illustrates dynamic splitting of a supply tracking line and a supply chain orchestration process to manage a supply side exception, according to an embodiment of the invention. According to the embodiment, a supply chain orchestration system can have a capability of dynamically splitting a supply tracking line and an associated supply chain orchestration process to manage a supply side change (such as a reduction in quantity that a supplier can provide, or a pushing out of a delivery date). The splitting of the supply tracking line will allow the supply chain orchestration system to track the partial supply that meets an original demand, and the partial supply that has an exception. The supply chain orchestration system, or a user, can mitigate a shortage in supply by selecting an alternate source of supply or notifying the external supply request system.
In accordance with the embodiment, FIG. 21 illustrates a supply order 2110. Supply order 2110 includes supply order lines 2120, 2121, 2122, and 2123. Further, supply order line 2121 originally includes supply tracking line 2131. Supply tracking line 2131 has an item quantity attribute of “100” representing 100 items, and a supplier attribute of “supplier1” representing an external supply execution system. Further, supply tracking line 2131 is associated with purchase order schedule 2141. Supply tracking line 2031 is also associated with a supply chain orchestration process, supply chain orchestration process 2150. An instance of supply chain orchestration process 2150 can be initiated to orchestrate supply tracking line 2131 (and ultimately supply order 2110). Supply chain orchestration process 2150 can further communicate with purchase order task layer service 2160, where purchase order task layer service 2160 is a task layer service that communicates with an external purchasing system.
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 Rules

According 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.
FIG. 22 illustrates a block diagram of an internal material transfer business process 2200, according to an embodiment of the invention. As previously described, internal material transfer business process 2200 transfers material (e.g., products produced or procured by a business organization) from one division of a business organization to another. According to the embodiment, internal material transfer business process 2200 invokes a create transfer document service 2210. Create transfer document service 2210 is a service that can perform the following functions. Create transfer document service 2210 can receive a supply request and determine whether the supply request is an internal material transfer request. Create transfer document service 2210 can also validate the supply request for syntactic accuracy (e.g., valid item, valid unit of measure, valid quantity, etc.). Create transfer document service 2210 can further calculate a transfer price for an internal material transfer request. Create transfer document service 2210 can also create a supply order within a supply chain orchestration system.
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.


	Intra-	Inter-
	Organizational	Organization	Buy-Sell
System	Transfer	Transfer	Relationship

Single System	Transfer Order	Transfer Order	Purchase Order -
			Sales Order
Cross-System	Purchase Order -	Purchase Order -	N/A
	Sales Order	Sales 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.

FIG. 23 illustrates an example user interface 2300 that defines execution rules for an internal material business process, according to an embodiment of the invention. According to the embodiment, a user of a supply chain orchestration system can utilize user interface 2300 to define one or more execution rules for an internal material business process. An execution rule can include one or more conditions, and one or more actions. A condition can be a condition involving one or more attributes of an internal material transfer request. An action can be a selection action, where one or more execution documents are selected based on the one or more conditions. Execution rules can range from broad execution rules affecting a wide variety of internal material transfers (e.g., execution rules for transferring material for all items of a first organization to a second organization) to granular execution rules (e.g., execution rules for transferring a single item from a first organization to a second organization).
FIG. 24 illustrates a flow diagram of the internal material transfer execution rule functionality of a supply chain orchestration module (such as supply chain orchestration module 16 of FIG. 1), according to an embodiment of the invention. The flow begins and proceeds to 2410. At 2410, a supply request is analyzed and it is determined whether the supply request is an internal material transfer request. An internal material transfer request is a supply request to create a supply for a transaction between a first entity and a second entity, where the first entity and the second entity are part of an overall enterprise. If the supply request is not an internal material transfer request, the flow ends. Otherwise, the flow proceeds to 2420.
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

We claim:

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;

generating an executable supply chain orchestration process;

12. The computer-implemented method of claim 11, further comprising:

determining a supply type of the supply request; and

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;

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;

15. The computer-implemented method of claim 11, further comprising:

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.