Database Reference
In-Depth Information
Figure 7: XML document based on the integrated process model in Figure 6(b)
automatic generation of external and integrated process models. Thus, the second and third
steps also provide base algorithms to solve the agility problem.
Fourth Step: Construction of a Customized Process Model
The fi nal step of the federated process framework is to construct a partial process
model from an integrated process model. The integrated process model can be quite large
and complex, and thus it may need to be reduced into a partial process model to support
access control for user-level securities or to provide a smaller process model appropriate
to a specifi c task of a user or user group. Such a partial process model constructed from an
integrated process model is called a
customized process model
. When a customized process
model is constructed, users' needs for customization are fi rst identifi ed, and activities that are
unnecessary for the needs are removed. To remove the unnecessary activities, the nine rules
presented in the second step are iteratively applied to the integrated process model. Figure 8
exemplifi es a customized process model for the online store's customer support staff, which
is constructed by removing messaging activities, A
2,1
and A
2,7
, from the integrated process
model in Figure 6(b). This customized process model helps the customer support staff to
focus only on the process information necessary for customer services.
The existing object data example can be easily extended in order to manage the cus-
tomized process model by adding new
WorkTransition
objects for the customized process
model and assigning “CUSTOMIZED” to its
PMType
attributes. On the other hand, in the
same way as in the second step, an XML document based on the integrated process model
can be transformed into one based on the customized process model by eliminating the
Activity
elements corresponding to the removed activities.
This section presents the federated process framework to facilitate process informa-
tion sharing among collaborating but autonomous organizations. Specifi cally, the four steps
of the framework facilitate seamless integration of multiple collaborating process models
while accommodating fl exible activity-level sharing policies. To support these features of
