U.S. patent application number 14/040911 was filed with the patent office on 2014-04-03 for supply chain orchestration system with orchestration, change management and internal material transfer flow.
This patent application is currently assigned to Oracle International Corporation. The applicant listed for this patent is Oracle International Corporation. Invention is credited to Thomas DANIEL, Taruna GAUTAM, Bankush GULATI, Imran Ali JEDDY, Srinivas KALLAKURI, Srikanth KARIMISETTY, Jaewook KIM, Maria MATHENY, Stephanie MERENDA, Gnani PALANIKUMAR, Kannan TARAKAD, Chandrashekar Reddy TIRUVIDULA, Ashok VERMA.
Application Number | 20140095249 14/040911 |
Document ID | / |
Family ID | 50386070 |
Filed Date | 2014-04-03 |
United States Patent
Application |
20140095249 |
Kind Code |
A1 |
TARAKAD; Kannan ; et
al. |
April 3, 2014 |
SUPPLY CHAIN ORCHESTRATION SYSTEM WITH ORCHESTRATION, CHANGE
MANAGEMENT AND INTERNAL MATERIAL TRANSFER FLOW
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.
Inventors: |
TARAKAD; Kannan; (Belmont,
CA) ; VERMA; Ashok; (Pleasanton, CA) ; DANIEL;
Thomas; (Austin, TX) ; KARIMISETTY; Srikanth;
(Austin, TX) ; PALANIKUMAR; Gnani; (San Jose,
CA) ; GAUTAM; Taruna; (Dublin, CA) ; JEDDY;
Imran Ali; (Hyderabad, IN) ; KALLAKURI; Srinivas;
(Hyderabad, IN) ; TIRUVIDULA; Chandrashekar Reddy;
(Austin, TX) ; GULATI; Bankush; (San Ramon,
CA) ; MERENDA; Stephanie; (San Jose, CA) ;
KIM; Jaewook; (Foster City, CA) ; MATHENY; Maria;
(San Ramon, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Oracle International Corporation |
Redwood Shores |
CA |
US |
|
|
Assignee: |
Oracle International
Corporation
Redwood Shores
CA
|
Family ID: |
50386070 |
Appl. No.: |
14/040911 |
Filed: |
September 30, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61707668 |
Sep 28, 2012 |
|
|
|
Current U.S.
Class: |
705/7.25 |
Current CPC
Class: |
G06F 7/02 20130101; G06Q
30/0633 20130101; G06F 16/00 20190101; G06Q 30/0603 20130101; G06Q
30/0621 20130101; G06Q 30/0635 20130101; G06Q 10/06315
20130101 |
Class at
Publication: |
705/7.25 |
International
Class: |
G06Q 10/06 20060101
G06Q010/06 |
Claims
1. A computer-readable medium having instructions stored thereon
that, when executed by a processor, cause the processor to
orchestrate a supply chain orchestration process, the orchestrating
comprising: receiving a supply request; creating a supply order;
selecting a supply chain orchestration process for the supply
order, wherein the supply chain orchestration process comprises one
or more steps; generating an executable supply chain orchestration
process; executing the executable supply chain orchestration
process to generate one or more supply tasks that are defined by
the one or more steps of the supply chain orchestration process;
sending the one or more supply tasks to one or more external supply
execution systems; receiving one or more status values from the one
or more external supply execution systems; and generating an
overall status value for the supply chain orchestration process
based on the one or more status values.
2. The computer-readable medium of claim 1, the orchestrating
further comprising: validating the supply request, wherein the
supply request comprises a payload, and wherein the payload
comprises one or more attributes; determining whether the supply
request is a request to create a supply or a request to modify a
supply; validating at least one attribute of the one or more
attributes of the payload of the supply request; determining a
supply type of the supply request; and enriching at least one
attribute of the one or more attributes of the payload of the
supply request.
3. The computer-readable medium of claim 2, wherein the supply
order comprises supply order header, one or more supply order
lines, and one or more supply tracking lines; wherein creating the
supply order further comprises translating the one or more
attributes of the payload of the supply request into one or more
attributes of at least one of the supply order header, the one or
more supply order lines, or the one or more supply tracking lines
of the supply order.
4. The computer-readable medium of claim 1, the orchestrating
further comprising: defining the one or more steps for the supply
chain orchestration process; defining a task for each step of the
supply chain orchestration process; defining a sequence of the one
or more steps of the supply chain orchestration process; defining
one or more status values for the supply chain orchestration
process; and assigning a cost of change to each step of the supply
chain orchestration process.
5. The computer-readable medium of claim 4, the orchestrating
further comprising: deploying the supply chain orchestration
process; creating a supply chain orchestration process instance,
wherein the supply chain orchestration process instance comprises
the executable supply chain orchestration process; and executing
the supply chain orchestration process instance.
6. The computer-readable medium of claim 1, the orchestrating
further comprising: receiving a supply task request; creating a
supply task comprising a payload; sending a message comprising the
payload of the supply task to an external interface layer;
transforming the payload of the supply task into an execution
system-specific payload of the supply task; and sending a message
comprising the execution system-specific payload of the supply task
to an external supply execution system.
7. The computer-readable medium of claim 6, the orchestrating
further comprising: receiving one or more status values from the
external supply execution system; transforming the one or more
status values into one or more transformed status values; sending
the one or more transformed status values to a business layer
service; transforming the one or more transformed status values
into a task status; and sending the task status to an orchestration
layer.
8. The computer-readable medium of claim 1, the orchestrating
further comprising: receiving a change supply request; creating a
change supply order; computing a delta between the change supply
order and the supply order; executing the executable supply chain
orchestration process in a change mode to compensate at least one
supply task that is defined by at least one step of the supply
chain orchestration process using a compensation pattern; and
compensating the at least one supply task using at least one
external supply execution system.
9. The computer-readable medium of claim 1, the orchestrating
further comprising: analyzing a supply request and determining
whether the supply request is an internal material transfer
request; invoking one or more execution rules when the supply
request is an internal material transfer request; selecting one or
more execution documents based on the one or more invoked execution
rules when the supply request is an internal material transfer
request; creating a supply task comprising a payload when the
supply request is an internal material transfer request, wherein
the payload creates the one or more selected execution documents;
and sending a message comprising the payload of the supply task to
an external supply execution system when the supply request is an
internal material transfer request.
10. The computer-readable medium of claim 1, wherein the supply
request comprises one of: a request to create a supply; a request
to make a supply; or a request to transfer a supply; wherein the
supply order comprises one of: an order to create a supply; a
request to make a supply; or a request to transfer a supply;
wherein the supply chain orchestration process orchestrates a
supply creation process; and wherein the one or more external
supply execution systems comprises at least one of: an external
purchasing system; an external manufacturing system; or an external
transfer system.
11. A computer-implemented method for orchestrating a supply chain
orchestration process, the computer-implemented method comprising:
receiving a supply request; creating a supply order; selecting a
supply chain orchestration process for the supply order, wherein
the supply chain orchestration process comprises one or more steps;
generating an executable supply chain orchestration process;
executing the executable supply chain orchestration process to
generate one or more supply tasks that are defined by the one or
more steps of the supply chain orchestration process; sending the
one or more supply tasks to one or more external supply execution
systems; receiving one or more status values from the one or more
external supply execution systems; and generating an overall status
value for the supply chain orchestration process based on the one
or more status values.
12. The computer-implemented method of claim 11, further
comprising: validating the supply request, wherein the supply
request comprises a payload, and wherein the payload comprises one
or more attributes; determining whether the supply request is a
request to create a supply or a request to modify a supply;
validating at least one attribute of the one or more attributes of
the payload of the supply request; determining a supply type of the
supply request; and enriching at least one attribute of the one or
more attributes of the payload of the supply request.
13. The computer-implemented method of claim 11, further
comprising: defining the one or more steps for the supply chain
orchestration process; defining a task for each step of the supply
chain orchestration process; defining a sequence of the one or more
steps of the supply chain orchestration process; defining one or
more status values for the supply chain orchestration process; and
assigning a cost of change to each step of the supply chain
orchestration process.
14. The computer-implemented method of claim 11, further
comprising: receiving a change supply request; creating a change
supply order; computing a delta between the change supply order and
the supply order; executing the executable supply chain
orchestration process in a change mode to compensate at least one
supply task that is defined by at least one step of the supply
chain orchestration process using a compensation pattern; and
compensating the at least one supply task using at least one
external supply execution system.
15. The computer-implemented method of claim 11, further
comprising: analyzing a supply request and determining whether the
supply request is an internal material transfer request; invoking
one or more execution rules when the supply request is an internal
material transfer request; selecting one or more execution
documents based on the one or more invoked execution rules when the
supply request is an internal material transfer request; creating a
supply task comprising a payload when the supply request is an
internal material transfer request, wherein the payload creates the
one or more selected execution documents; and sending a message
comprising the payload of the supply task to an external supply
execution system when the supply request is an internal material
transfer request.
16. A system, comprising: a request reception module configured to
receive a supply request; an order creation module configured to
create a supply order; an orchestration process selection module
configured to select a supply chain orchestration process for the
supply order, wherein the supply chain orchestration process
comprises one or more steps; an executable orchestration process
generating module configured to generate an executable supply chain
orchestration process; an execution module configured to execute
the executable supply chain orchestration process to generate one
or more supply tasks that are defined by the one or more steps of
the supply chain orchestration process; a task transmission module
configured to send the one or more supply tasks to one or more
external supply execution systems; a status value reception module
configured to receive one or more status values from the one or
more external supply execution systems; and a status value
generating module configured to generate an overall status value
for the supply chain orchestration process based on the one or more
status values.
17. The system of claim 16, further comprising: a supply request
validation module configured to validate the supply request,
wherein the supply request comprises a payload, and wherein the
payload comprises one or more attributes; a supply request
determination module configured to determine whether the supply
request is a request to create a supply or a request to modify a
supply; an attribute validation module configured to validate at
least one attribute of the one or more attributes of the payload of
the supply request; a supply type determination module configured
to determine a supply type of the supply request; and an attribute
enrichment module configured to enrich at least one attribute of
the one or more attributes of the payload of the supply
request.
18. The system of claim 16, further comprising: an orchestration
process definition module configured to define the one or more
steps for the supply chain orchestration process; wherein the
orchestration process definition module is further configured to
define a task for each step of the supply chain orchestration
process; wherein the orchestration process definition module is
further configured to define a sequence of the one or more steps of
the supply chain orchestration process; wherein the orchestration
process definition module is further configured to define one or
more status values for the supply chain orchestration process; and
wherein the orchestration process definition module is further
configured to assign a cost of change to each step of the supply
chain orchestration process.
19. The system of claim 16, further comprising: a change supply
request reception module configured to receive a change supply
request; a change supply order creation module configured to create
a change supply order; a delta computation module configured to
compute a delta between the change supply order and the supply
order; a change mode execution module configured to execute the
executable supply chain orchestration process in a change mode to
compensate at least one supply task that is defined by at least one
step of the supply chain orchestration process using a compensation
pattern; and a compensation module configured to compensate the at
least one supply task using at least one external supply execution
system.
20. The system of claim 16, further comprising: an analysis module
configured to analyze a supply request and determining whether the
supply request is an internal material transfer request; an
execution rule invocation module configured to invoke one or more
execution rules when the supply request is an internal material
transfer request; an execution document selection module configured
to select one or more execution documents based on the one or more
invoked execution rules when the supply request is an internal
material transfer request; a supply task creation module configured
to create a supply task comprising a payload when the supply
request is an internal material transfer request, wherein the
payload creates the one or more selected execution documents; and a
message transmission module configured to send a message comprising
the payload of the supply task to an external supply execution
system when the supply request is an internal material transfer
request.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] One embodiment is directed to a computer system, and more
particularly, to a computer system that orchestrates supply chain
processes.
BACKGROUND
[0003] 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.
[0004] 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
[0005] 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
[0006] 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.
[0007] FIG. 1 illustrates a block diagram of a system that can
implement an embodiment of the invention.
[0008] FIG. 2 illustrates a block diagram of an example
architecture of a supply chain orchestration system, according to
an embodiment of the invention.
[0009] FIG. 3 illustrates a block diagram of a decomposition data
model for a decomposition layer, according to an embodiment of the
invention.
[0010] FIG. 4 illustrates a flow diagram of the decomposition
functionality of a supply chain orchestration module, according to
an embodiment of the invention.
[0011] FIG. 5 illustrates a block diagram of an orchestration data
model for an orchestration layer, according to an embodiment of the
invention.
[0012] FIG. 6 illustrates a flow diagram of the orchestration
functionality of a supply chain orchestration module, according to
an embodiment of the invention.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] FIG. 11 illustrates a sequence diagram of a business
services layer, according to an embodiment of the invention.
[0018] FIG. 12 illustrates a flow diagram of the business services
functionality of a supply chain orchestration module, according to
an embodiment of the invention.
[0019] FIG. 13 illustrates an example user interface of a workbench
for a supply chain orchestration system, according to an embodiment
of the invention.
[0020] FIG. 14 illustrates a flow diagram of the overall
orchestration functionality of a supply chain orchestration module,
according an embodiment of the invention.
[0021] 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.
[0022] FIG. 16 illustrates a flow diagram of the change management
functionality of a supply chain orchestration module, according to
an embodiment of the invention.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] FIG. 22 illustrates a block diagram of an internal material
transfer business process, according to an embodiment of the
invention.
[0029] 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.
[0030] 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
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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:
TABLE-US-00001 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
[0060] 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:
TABLE-US-00002 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
[0061] 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:
TABLE-US-00003 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
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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
TABLE-US-00004 [0066] 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
TABLE-US-00005 [0067] 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
TABLE-US-00006 [0068] 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
[0069] The flow then proceeds to 450.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] A process for calculating a jeopardy score for one or more
steps of a supply chain orchestration process is further described
below.
[0103] 1. Calculate Jeopardy Score for Process Steps [0104] 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. [0105] Jeopardy Threshold may be
defined at five levels. The hierarchy between these levels is
defined as below: [0106] 1. Task Type [0107] 2. Task Name [0108] 3.
Process Name [0109] 4. Process Version [0110] 5. Global/Default
[0111] The system can locate the appropriate threshold group in
this order: [0112] 1. For the combination of all four elements
[0113] 2. For the process name, process version, and task name
[0114] 3. For the process name and task name [0115] 4. For the
process name, process version, and task type [0116] 5. For the
process name, task type [0117] 6. For task name
[0118] 2. Set task jeopardy score and reason [0119] A task instance
is assigned a jeopardy score equal to the highest jeopardy score of
all steps which comprise that task. [0120] A jeopardy reason is
assigned, which is a concatenated string containing the required
dates, planned date. [0121] 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.
[0122] 3. Create a jeopardy history record [0123] 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.
[0124] 4. Set process jeopardy score [0125] The process instance is
updated with a jeopardy score [0126] The process instance is
assigned a jeopardy score equal to the highest jeopardy score of
all tasks which comprise that process.
[0127] 5. Set tracking line jeopardy priority [0128] All tracking
lines associated to the process instance should have the
JEOPARDY_CONDITION set to the JEOPARDY_PRIORITY_CODE of the process
instance.
[0129] 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.
[0130] 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.
[0131] 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.
[0132] 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.
[0133] 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.
[0134] 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.
[0135] 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.
[0136] 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.
[0137] 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.
[0138] 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.
[0139] 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.
[0140] 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. [0141] 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. [0142] No sourcing information
available on the supply tracking line. [0143] Override the existing
sourcing information on the supply tracking line to mitigate
exception. [0144] 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. [0145] 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. [0146]
Supply tracking line is in high jeopardy and will not be able to
meet the need by date for partial quantity. [0147] Supply tracking
line is in high jeopardy and user is aware of another source which
can meet this requirement. [0148] 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. [0149] 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. [0150] 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. [0151] Holds: [0152] 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: [0153] The goods received are rejected in inspection due
to quality issues. [0154] Goods cannot be received due to space
constraints in the warehouse. [0155] To handle demand change or
cancel request [0156] 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. [0157] 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. [0158]
Note: The Holds functionality in the system can utilize a user
interface where users can define Hold Code and Hold Release Codes.
[0159] 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: [0160] Supply
tracking line was not assigned to an orchestration process as there
were no valid orchestration process assignment rules. [0161] 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. [0162] Error Recovery: [0163] 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; [0164]
Orchestration process was assigned to a supply tracking line but
the process was not started. [0165] Orchestration process or task
resulted in an error. [0166] 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.
[0167] 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.
[0168] 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
[0169] 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.
[0170] 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.
[0171] 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.
[0172] 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.
[0173] 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."
[0174] 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."
[0175] 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.
[0176] 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. [0177] Reschedule Purchase
Order request from Planning (Purchase Order (Schedule) ID, ship
date, dock date, shipping method) [0178] Decreased supply (quantity
decrease) for a BackToBack order from GOP (DOO Fulfillment
Reference ID, Revised(reduced) quantity, etc) [0179] Increased
supply (quantity increase) for a BackToBack order from GOP (DOO
Fulfillment Reference ID, additional quantity, etc) [0180] Cancel
Transfer Order request from SSP (Transfer Order Line ID) Planning
Reschedule Purchase Order scenario
[0181] 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
[0182] Assume where a planning system sends a new buy request, with
following values: [0183] Supply Type: Buy [0184] Need By Date: Aug.
15, 2012 [0185] Shipping Method: 3-day FedEx
[0186] The planning system can send the reschedule recommendation
with following attribute: [0187] Reschedule of existing Purchase
Orders (Purchase Order Schedule ID, ship date, dock date, shipping
method)
[0188] While processing the above new request, assume that the
planning system sends a Reschedule Purchase Order request with
following attributes and values: [0189] Purchase Order Schedule ID:
POS122 [0190] Need By Date (Ship date): Aug. 20, 2012 [0191]
Shipping Method: 2-day shipping method
[0192] 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.
TABLE-US-00007 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
[0193] Demand and Supply Tracking Lines Snapshot for Planning
Reschedule Request for Purchase Order
[0194] 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).
[0195] 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.
TABLE-US-00008 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
[0196] Planning reschedule of existing Purchase Order format
(Purchase Order Line (Schedule) ID, ship date, dock date, shipping
method) are: [0197] Supply request system (Planning) sends
reschedule request for a specific execution document line (Purchase
Order Line (Schedule) ID) [0198] 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
[0199] 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
[0200] Assume that GOP sends a new buy request, with following
values: [0201] DOO Fulfillment Line: FL123 [0202] Item: item1
[0203] Requested Quantity: 100 each (Buy 20 each, Transfer 30 each,
On hand 50 each quantity)
[0204] While processing the above new request, assume that GOP
sends a change request for decreased supply, with following values:
[0205] DOO Fulfillment Line: FL123 [0206] Item: item1 [0207]
Decreased Quantity: 45 each (Revised quantity is 55)
[0208] 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.
[0209] 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.
TABLE-US-00009 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
[0210] GOP decreased supply (quantity decrease) on of existing
BackToBack order (DOO Fulfillment ID, requested quantity, supplier,
etc) is: [0211] Supply request system (GOP) sends supply change
request for specific demand line(DOO Fulfillment Line) [0212]
Supply request system (GOP) sends change request only for a set of
pre-defined attributes: revised quantity, supplier etc
[0213] Based on the above Planning Reschedule PO and GOP Decreased
Supply scenario, the system can support the following design time
requirements: [0214] Ability to configure attributes that manage
change for each task type [0215] Ability to configure task services
that must be invoked during update or cancel request [0216] Ability
to configure constraints based on change management attributes
[0217] 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.
TABLE-US-00010 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
[0218] 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.
[0219] 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.
TABLE-US-00011 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
[0220] 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.
[0221] 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.
[0222] 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.
[0223] 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.
[0224] 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.
[0225] 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.
[0226] 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.
[0227] 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.
[0228] 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.
[0229] 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.
[0230] 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.
[0231] 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.
[0232] 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."
[0233] 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.
[0234] 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.
[0235] 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.
[0236] 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.
[0237] 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.
[0238] 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.
[0239] 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.
[0240] 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.
[0241] 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.
[0242] 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.
[0243] 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.
[0244] 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. [0245] Each BacktoBack supply request for a DOO
Fulfillment line can be associated only one or more supply order
lines [0246] 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: [0247] Reserve On Hand, 50 each quantity of
item1 [0248] Transfer request for 30 each quantity of item1 [0249]
Buy request for 20 each quantity of item1 [0250] 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. [0251] 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
[0252] Consider the scenario where GOP recommended the following
supply recommendation and SCO created three supply tracking lines
to track and manage the following recommendations. [0253] Original
DOO Fulfillment line schedule: item1, quantity (100 each) Schedule
date (August 15, 12), Warehouse (w1) with following supply types:
[0254] Reserve On Hand, 50 each quantity of item1 [0255] Transfer
request for 30 each quantity of item1 [0256] 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 [0257]
Revised DOO Fulfillment line schedule: item1, quantity (60 each)
Schedule date (August 15, 12), Warehouse (w1) with following supply
types: [0258] Reserve On Hand, 50 each quantity of item1 [0259]
Transfer request for 30 each quantity of item1 [0260] 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: [0261] Option1: [0262] Reserve OnHand, 50 each quantity of
item1 (Change from 50 to 10) [0263] Buy request for 20 each
quantity of item1 (No change) [0264] Transfer request for 30 each
quantity of item1 (No Change) [0265] Option 2: [0266] Reserve On
Hand, 50 each quantity of item1 (No change) [0267] Buy request for
20 each quantity of item1 (Change from 20 to 0) [0268] Transfer
request for 30 each quantity of item1 (Change from 30 to 10) [0269]
Option3: [0270] Reserve On Hand, 50 each quantity of item1 (Change
from 50 to 40) [0271] Buy request for 20 each quantity of item1 (No
change) [0272] Transfer request for 30 each quantity of item1
(Change from 30 to 0) [0273] 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
[0273] [0274] 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 [0275] 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
[0276] Consider the scenario where GOP recommended the following
supply recommendation and system created three supply tracking
lines to track and manage the following recommendations. [0277]
Original DOO Fulfillment line schedule: item1, quantity (100 each)
Schedule date (August 15, 12), Warehouse (w1) with following supply
types: [0278] Reserve On Hand, 50 each quantity of item1 [0279]
Transfer request for 30 each quantity of item1 [0280] 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 [0281]
Original DOO Fulfillment line schedule: item1, quantity (115 each)
Schedule date (August 15, 12), Warehouse (w1) with following supply
types: [0282] Reserve On Hand, 50 each quantity of item1 (original
supply recommendation [0283] Transfer request for 30 each quantity
of item1 (original supply recommendation) [0284] Buy request for 20
each quantity of item1 with supplier1 (original supply
recommendation) [0285] Buy request for 15 each quantity of item1
with supplier1 (Delta supply recommendation) Now system has
following options to process the Delta supply [0286] Option1:
[0287] Update existing Buy request for 20 each quantity of item1
(Change from 20 to 30. Send change request to procurement) [0288]
Option2: [0289] 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
[0290] 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.
TABLE-US-00012 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. [0291] Option1: [0292] Reserve On Hand, 50 each
quantity of item1 (Change from 50 to 5) [0293] Buy request for 20
each quantity of item1 (No change) [0294] Transfer request for 30
each quantity of item1 (No Change) [0295] Option 2: [0296] Reserve
On Hand, 50 each quantity of item1 (No change) [0297] Buy request
for 20 each quantity of item1 (Change from 20 to 0) [0298] Transfer
request for 30 each quantity of item1 (Change from 30 to 5) [0299]
Option3: [0300] Reserve On Hand, 50 each quantity of item1 (Change
from 50 to 35) [0301] Buy request for 20 each quantity of item1 (No
change) [0302] Transfer request for 30 each quantity of item1
(Change from 30 to 0) [0303] Option 4-n: There are multiple
combinations depends upon the current status of the supply creation
process This task has prioritized the options: [0304] Option 2
[0305] Buy request for 20 each quantity of item1 (Change from 20 to
0) [0306] Transfer request for 30 each quantity of item1 (Change
from 30 to 5) [0307] Reserve On Hand, 50 each quantity of item1 (No
change)
[0308] 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.
[0309] 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.
[0310] 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.
[0311] 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).
[0312] 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.
[0313] 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.
[0314] 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
[0315] 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.
[0316] 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.
[0317] 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.
[0318] 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.
[0319] 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.
[0320] 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.
TABLE-US-00013 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
[0321] 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.
[0322] 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.
[0323] 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.
[0324] 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: [0325] 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. [0326] If a Buy
Sell relationship is not defined, then: [0327] IMT can be executed
using Transfer Orders, if the transfer is between organizations,
within an instance [0328] 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. [0329] 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. [0330] 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.
[0331] 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).
[0332] 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.
[0333] 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.
[0334] 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.
[0335] 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.
[0336] 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.
[0337] 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.
[0338] 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.
[0339] 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.
[0340] 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.
[0341] 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.
* * * * *