=Paper=
{{Paper
|id=None
|storemode=property
|title=PNav: Process Navigator for the Design of New Business Process Models
|pdfUrl=https://ceur-ws.org/Vol-615/paper7.pdf
|volume=Vol-615
|dblpUrl=https://dblp.org/rec/conf/bpm/LincolnG10
}}
==PNav: Process Navigator for the Design of New Business Process Models==
https://ceur-ws.org/Vol-615/paper7.pdf
PN av : Process Navigator for the Design of New
Business Process Models
Maya Lincoln and Avigdor Gal
Technion - Israel Institute of Technology
mayal@technion.ac.il, avigal@ie.technion.ac.il
Abstract. In this demonstration we introduce a prototype of PN av , a
process navigator that assists designers in designing new process models.
To do that, PN av generates activity suggestions for the newly gener-
ated process models. The business logic for such suggestions is extracted
from process repositories through the analysis of existing business pro-
cess model activities.
1 Introduction
Enterprise process repositories contain hundreds of business processes, developed
over the years to support enterprise activities. Such repositories contain a large
number of activities that can be re-used when redesigning existing processes
or whenever the need for new processes arises. Process modeling is considered
a manual, labor intensive task, whose outcome depends on personal domain
expertise with errors or inconsistencies that may lead to bad process performance
and high process costs [3]. Hence, reuse of activities can save design time and
support non-expert designers in creating new business process models.
In this demonstration we introduce a prototype of PN av , a process naviga-
tor that assists designers in designing new process models. To do that, PN av
generates activity suggestions for the newly generated process models. The busi-
ness logic for such suggestions is extracted from process repositories through the
analysis of existing business process model activities. Each activity is encoded
automatically as a descriptor, using the PDC notation [2,1]. The collection of
all descriptors formulates a descriptor space, and distances between every two
space coordinates are calculated in terms of business process conduct proximity.
In the Process Descriptor Catalog model (PDC) [2,1] each activity is com-
posed of one action, one object that the action acts upon, and possibly one or
more action quali ers and object quali ers. For example, the activity nameManually
complete a supplier maintenance form is decomposed into (action='complete' ,
object='form' , action quali er='manually' , object quali er='supplier mainte-
nance').
The model has two basic elements, namely objects and actions, and we delin-
eate four taxonomies from them: an action hierarchy model, an object hierarchy
model, an action sequence model and an object lifecycle model. The business ac-
tion and object taxonomy models organize a set of activity descriptors according
to relationships among business actions and objects both hierarchically and in
terms of execution order.
An example from the Oracle Business Model (OBM)
1 is given in Fig. 1 and
Fig. 2, showing a section of the business action and object taxonomy models as a
set of activity descriptors according to the relationships among business actions
and objects both longitudinally (hierarchically) and latitudinally (in terms of
execution order), as detailed next.
Do Object
Complete Check Evaluate Send Information payment
Manually Re- Send by Send by Informati Information Nonstan
complete Check e-mail fax on on on purchase dard
suppliers items payment
Fig. 1. Segments of the action hierarchy model and the object hierarchy model ex-
tracted from the OBM for procurement processes.
Non-approved supplier
Candidate Examined supplier
supplier Approved supplier New supplier
Requests for Evaluated Approved request for NSPT
nonstandard payment request for NSPT
terms (“NSPT”) Rejected request for NSPT
Supplier: Search Examine Approve Insert
Request for NSPT: Receive Evaluate Approve Document
Fig. 2. Segments of the action sequence model and the object lifecycle model extracted
from the OBM for procurement processes.
The longitudinal dimension of actions and objects is determined by their
quali ers. To illustrate the longitudinal dimension of the OBM work ows, a seg-
ment of the action hierarchy model and a segment of the object hierarchy model,
both related to procurement processes, are presented in Fig. 1. To illustrate the
latitudinal dimension of the OBM process repository, a segment of the action
sequence model and a segment of the object lifecycle model are presented in Fig.
2.
1
http://www.oracle.com/applications/tutor/index.html.
Based on the activity decomposition model, it is possible to visualize the
operational range of a business process model as a descriptor space comprised
of objects and actions, related to each other and among each other in dierent
relationship types. A navigation within this space can be a powerful tool for
analyzing and utilizing the underlying business process knowledge encapsulated
within a business process repository. More details of the descriptor space and
how to navigate it can be found in [1].
The demo is intended for both academics, interested in new techniques for
designing business process models and practitioners, interested in state-of-the-
art technology for design support tools. The tool can help automate the reuse
of constructs gathered from prede ned process models. Such a tool saves design
time and supports non-expert designers in creating new business process models.
The proposed software tool, can be used in real-life scenarios, yet several research
and development are required in order to enable a more commercialized version
of the tool.
2 Maturity
PN av implements a client-server architecture, in which the client is responsible
for presenting and collecting data from the user and the server is responsible
for processing the user's input data and suggesting directions for advancing the
design process. Server side logic is implemented in PHP using a MySql database.
The client runs within an Internet browser and is implemented in HTML and
JavaScript, with AJAX calls to the server.
Process Model Step
NL Parser
ProcessGene Converter Navigator
Process Steps
BPM Suite
Process Generator
Process Model Suggestion
Repository
Connector Ranker
Database
Fig. 3. PN av high-level architecture.
The server side high-level architecture includes ve main components (see
Fig. 3): (a) the navigator, responsible for managing and orchestrating the pro-
cess design mechanism; (b) the process repository database that contains the
existing business process repository, in terms of activity descriptors and object
and action taxonomies; (c) the process model connector, which provides an in-
terface for communicating with the process repository database; (d) the process
model converter, responsible for converting inputted business process reposito-
ries into a normalized data structure as saved in the process repository database.
Currently, our system supports the conversion of repositories expressed in BPEL
or BPMN; (e) the Natural Language (NL) parser, an existing web service for de-
composing sentences into linguistic components. The parser we use is called the
2
Stanford Parser . This web service decomposes activity names into descriptor
components.
The navigator is further decomposed into four main components: (a) the
process steps generator, responsible for producing suggested activities for each
design phase. It communicates with all other components and presents the user
at each stage with options for advancing the design process; (b) the step naviga-
tor, which is responsible for navigating in the process model database, and for
retrieving a list of relevant activity options; (c) the suggestion ranker, responsible
for ranking the suggested activity options at each stage.
The navigator is designed to connect to the ProcessGene BPM suite and to
assist designers in designing new process models. Each time a user opens a new
3
process model in ProcessGene , and de nes the new process model name, PN av
is activated and suggests the user to use its services. Once the user decides to
use PN av , she is guided in a step-by-step procedure that advises and supports
the creation of the new process model.
We have conducted experiment sets with PN av using two case studies[1].
The rst experiment set was based on an aviation process repository that covers
airport activities starting from the passenger's entry to an airport, through doc-
ument handling and security checks and terminating as the passenger boards the
4
airplane . The second experiment set was based on the Oracle Business Model,
which serves for our demonstration script and will be discussed in details next.
PN av is currently installed and works well on a workstation running Win-
dows XP, IIS6, PHP 4.8 and MySQL 5.0. This workstation serves as the server.
A client, running Internet Explorer as the application container and presentation
layer, will be available at the Demo site.
3 Script
We demonstrate the applicability of our ideas using 14 processes from the Oracle
Business Model. Nine business processes are taken from the Procurement cat-
egory, containing altogether 96 activities and ve business processes are taken
from the Inventory category, containing altogether 31 activities. The Procure-
ment data set contains related, sequential activities and therefore encapsulates
a focused operational area. The Inventory data set encapsulating a loosely
coupled business logic regarding an extended business area.
Using the selected 14 processes we created a process repository database.
The demo user shall provide a starting activity and then interact with PN av
to receive a ranked list of suggested activities, re ne the suggestions and move
2
http://nlp.stanford.edu:8080/parser/index.jsp
3
http://www.processgene.com
4
Many thanks to Samia Mazhar and the BPM Group at QUT for providing access
to the aviation process data.
on to the next activity. It should be noted that the tool oers only activities
designer needs to add junctions.
3.1 Example for using PN av for Designing a New Process Model
To illustrate the proposed software tool we present a short example from the
eld of procurement. The newly designed process, Verify supplier details, is
related to the procurement eld, but is not covered by the OBM. Its goal is to
verify whether the supplier details, as declared in the new supplier form, are
correct.
Verify Document
Verify Search for Call
company collected
address recommenders recommenders
code data
Fig. 4. The new designed process diagram for Verify supplier details.
The example supports the design of a new business process for: Verify sup-
plier details. The generated output (new process model) of this example is
illustrated in Fig. 4 as a YAWL diagram. The design process starts when the
(human) process designer inserts into PN av the name of the new process (Verify
supplier details) which is then translated automatically into the following pro-
cess descriptor: (action=verify, action quali er=null, object=details, object
quali er=supplier) (see Fig. 5a) and determines that the rst activity is: Ver-
ify address. Respectively, the process delineator searches the descriptor space,
looking for next activity possibilities. The result set includes the following ac-
tivities: [1] Check supplier, [2] Verify supplier and [3] Verify address (see
Fig. 5b). The designer selects the option Verify address and decides that this
activity is suitable.
The design process continues with four more design phases. The second phase
required a re nement for the option Search for additional data - which was
suggested as the next activity after Verify company code. The re ned option
list includes the option: [1] Search for recommenders, and this option was
selected by the designer. Note that this activity was not represented as is in
the business process repository.
The designer now wishes to design the new business process: Review invoices
to prevent fraud. An interesting observation in this design process is that the
designer selects more often next step activities that share the same action applied
on sibling objects. For example, the activity Check signature was followed
by Check date and Check payment terms. The business logic behind this
phenomenon is that this process expresses a more independent business conduct
in which there is only one party (the reviewer) which operates on one item (the
invoice).
(a) The designer's request for designing the new (b) The third phase in designing the new process:
process: “Verify supplier details” “Verify supplier details”
Fig. 5. The designer's request for designing the new process: Verify supplier details.
References
1. M. Lincoln, M. Golani, and A. Gal. Machine-assisted design of business process mod-
els using descriptor space analysis. In Proceedings of the eigth International Con-
ference on Buisness Process Modeling (BPM'2010), Hoboken, NJ, USA, September
2010.
2. M. Lincoln, R. Karni, and A. Wasser. A Framework for Ontological Standardization
of Business Process Content. International Conference on Enterprise Information
Systems, pages 257263, 2007.
3. D. Muller, M. Reichert, and J. Herbst. Data-driven modeling and coordination of
large process structures. Lecture Notes in Computer Science, 4803:131, 2007.