Selection of Business Partners in Process ChoreographiesThe modelling of organizational aspects in business process management
can be extended to business partners, which is important in the context of
business-to-business processes.
Consider a business process choreography with multiple business partners,
each of which plays a specific role in the choreography. If there is a role Shipper
specified according to the requirements for shipping goods, it can be bound to
specific enterprises that can perform the work. Additional flexibility is gained
because the organizations participating in a choreography are not hardwired,
but represented at the model level.
There are different options for selecting a particular shipper. The selection
can be done before a particular process instance starts. This alternative is
useful if sufficient information on the goods to be shipped is available before
the process starts.
In scenarios where only during run time of the process instance are the
goods and the sender and receiver determined, the dynamic selection of a
shipper is useful. Based on the information on the shipment and on its additional
properties—such as dangerous goods—an appropriate shipper can be
selected at run time.
Before the process choreography can be realized, the broker requires information
on the suppliers available. This information is gathered by the broker in a
separate process choreography, whose message flow is not shown in the figure.
The process choreography starts with the creating of an order by the customer.
Then, the customer sends a Request Supplier Info message to the broker.
The broker receives this message and uses local information to find the
supplier most suitable for fulfilling the order. In the Send Supplier Info message,
the broker informs the customer about this supplier.
The customer receives this message and uses the information received to
send an order to the selected supplier, Supplier-A in this case. When the
supplier has processed the order, the supplier sends the goods to the customer,
and the process completes.
In the example shown, the selection is performed using a third party, the
broker. While this is a valid option in scenarios where a broker has rich information
on a set of business partners, the selection can also be done locally,
i.e., without the involvement of a third party.
In this case, the actual selection can be performed as a manual activity,
using information on suppliers available and capable of fulfilling the order.
Role resolution in this case is not performed by the business process management
system, but by a knowledge worker. This task also matches the
service-oriented approach, where a service requestor (the knowledge worker)
uses the broker to select from among a set of services (supplier services) the
one that is suited best for the task at hand.
Standardized Software Interfaces
Standardized interfaces to existing software systems are another means of
flexibility in business process management. A variety of techniques to specify
software interfaces are known from software engineering and software architectures.
It is a key concept to decouple the use of a software component from its
implementation, i.e., to hide implementation details from usage information,
following the information hiding principle.
In the context of business process management, standardized software interfaces
are of crucial importance in system workflows, and also in human
interaction workflows, since the overall process structure can be decoupled
from the implementation of particular activities realized by software components.
A flexible association of process activities with software systems allows us
to change the implementation of specific process activities without changing
the overall business process. There are two variations: the software system
realizing a particular activity can be defined at design time of the process or at
run time of the process instances.
We assume that an ERP system is deployed to provide the functionality
of the order management system and of the inventory management system in
an integrated, robust, and scalable manner.
By standardized software interfaces, the business process activities can use
the functionality of the new system without changing the business process.
This enhances the flexibility of the business process implementation, because
the realization of particular process activities can be changed without modifying
the business process.
This discussion describes an ideal setting, in which activity realizations
can easily be exchanged. However, specific properties of legacy systems make
the definition of clean, standardized interfaces cumbersome, because legacy
systems offer their functionality typically by proprietary and often not well
documented interfaces.
In addition, the granularity with which legacy systems provide functionality
often does not match the granularity required by the business process. In
particular, legacy systems often realize complex subprocesses rather than individual
activities in a business process. Sometimes, the processes realized by
legacy systems and the modelled business processes are not immediately comparable.
These issues have to be taken into account when software interfaces
to existing information systems are developed.
One option to solving this problem is developing software interfaces that
make available the functionality provided by legacy systems with a granularity
that allows reuse of functionality at a finer level of granularity. The granularity
should match the granularity required at the business process level.
Depending on the legacy system, its complexity, software architecture,
and documentation, as well as the availability of knowledgeable personnel,
the required effort can be very high. If the need for finer-grained granularity
and efficient reuse of functionality is sufficiently high, then partial or complete
reimplementation can be an option.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment