One of the main challenges currently facing the world of enterprise information technology in general and ERP/SCM/CRM systems in particular, is visibility into the business of organizations. While the phenomena of devising supporting tools for process execution frameworks is widespread in academia and practice, there have been few attempts to develop methodologies and software tools that support structured analysis of the business process content layer. The incorporation of content into a business process model produces complexity in the sense that it adds semantics and relationships of actual business data. To confront this complexity, this research suggests a framework and a supporting software tool “ProcessGene Query” for conducting search-queries on business process models.
One of the main challenges currently facing the world of enterprise information
technology, and ERP systems in particular, is visibility into the business of organizations,
[
The current main thrust of business process modeling research has focused on the
study of structural frameworks and execution patterns [
Structural process frameworks define formal architectures and standards for
representing business activities and processes. The spectrum (Fig. 1) ranges from
simple descriptive frameworks such as activity diagrams, suitable mostly for business
users, through more formal frameworks such as OPM [
Decomposition models Flowcharts
IDEF Event Driven
Diagrams
OPM
UML2
Petri-nets
WSFL ebXML Wf-XML
BPEL
The practical deployment of these frameworks, involves an attempt to enumerate
actual business processes carried out within enterprises. Modeling in this context
focuses on the content layer of business process models. We define the content layer
as the itemization of the suite of actual business processes constituting the framework
of business-related activity within a particular industrial sector, or, alternatively,
within a particular enterprise. Only a few scientific publications address the topic of
business process content [
Any self – generated enterprise specific business process descriptions
SAP blueprints
Particular
Integrator/Vendor-based
Public/Consortia
Fig. 2 presents some business process content compendia, divided into three main
types: (a) particular, enterprise specific content; (b) vendor/integrator content such as
the OBM (Oracle Business Models) library [
When this research addresses business process models it refers to “complete” models that also include a content layer, so that the combination of structure and content can display the actual suite of business processes constituting the framework of activity within the enterprise and enable subsequent implementation through IT. For example: a flowchart describing bottleneck leveling in production, or a Petri-net describing the process of managing a service request in CRM. Such business process models are considered complex since they include a large number of interconnected data objects (processes, roles, events, related data, etc.). This complexity increases when the models are to be expressed and actualized by a corresponding IT system (e.g. ERP/SCM/CRM), which requires verification and validation of the business process models from a functional and managerial point of view prior to actual implementation and subsequent execution. To confront this complexity, and in order to enable effective handling of the business process models content, this research suggests a framework and a supporting software tool for conducting search-queries on business process models.
The paper features the following sections: a demonstration of a standardized format for describing the content of a business processes based on current offerings of ERP vendors – (section 2); the “ProcessGene Query” methodology and tool for searching the content of process models (section 3); an example for running content search queries (section 4); conclusions and suggestions for further work (section 5). 2
Due to their dominance in industry, we will focus on content layers from
vendor/integrator commercial business process models. These include, for example,
SAP’s industry and cross-industry Business Solution Maps [
In order to formulate and demonstrate the proposed query framework, we present two data models that organize the business process data and form the foundation for running search-queries on the content layer. Then we elaborate on the query method. 3.1
Process Descriptor Decomposition Model. This model introduces the basic ideas and notations for formally representing business process model content objects by a hierarchal graph of descriptors, as shown in Fig. 4. The process model contains n levels of process hierarchy (L1, L2, … , Ln). At each level, each process is represented by a single process descriptor, and each process descriptor consists of one action, one object that the action acts upon, and possibly one or more action qualifiers, object qualifiers and means.
For example, a process descriptor can be defined as: “Issue confirmed purchase order to local supplier by e-mail”, comprising an object, an action and their qualifiers. Business Action and Object Taxonomy Model. This model organizes a set of process descriptors, attempting to determine the relationships between business actions and objects both longitudinally (hierarchically) and latitudinally (in terms of execution order) as described in Fig 5. In this model an action is related to an object by an operability connector, e.g. the action “receive” is related to the object “invoice”. Longitudinally- the action “issue” is considered a subclass (a more specific form) of “produce”, and the object “purchase order” is a subclass of “purchasing document” (note that the operability connectivity applies also to relations between different hierarchy levels). Latitudinally, each object holds a list of ordered actions applied on that object (e.g. the object “product” is related to the actions “plan” followed by “produce”); (b) a list of ordered objects that express the object lifecycle (e.g. the following lifecycle sequence: “raw material” , (…) , “product” , (…) , “returns” , (…)).
Fig 5: Business action and object taxonomy model
These longitudinal and latitudinal viewpoints contribute another dimension for analyzing and learning the business process model content layer in terms of identifying action and object hierarchies and execution sequences. 3.2
The method aims to provide a simple yet powerful query interface in which users are able to express and perform a large set of queries using intuitive definitions.
The ProcessGene Query mechanism includes four main components. At the frontend: a Scoping-Assistant (SA), for defining the content query range; and a Query Specification Interface (QSI), for expressing the user’s data extraction requirements. At the back-end: a Query Interpreter (QI) for interpreting the user specification into a set of normalized queries; and a Query Results Packager (QRP) for packaging the retrieved results to include only data that is of interest to the user. The SA uses business processes as means for query focusing, since at any hierarchy level, these objects are related with all other data components. After defining the query’s underlying data scope, the QSI enables users to specify data requirements. This module is based on two specification layers, offering at the first layer a simple interface, which enfolds more advanced options for users that wish to drill-down and expand the query capability. The first query specification layer presents all business process model component types as a flat checklist, enabling the user to select query components. Each component can then be expanded, presenting additional data fields and enabling the user to specify different criteria for each field. Conditions are expressed using regular expressions (strings, keywords, wildcards), or by selecting one or more values from a list of values, depending on the data field type. In addition, the QSI also assists in defining the query result structure and content. Instead of generating pre-defined result segment structures, the user can define which data components are to be included in the result set. After the specification phase, the QI analyzes the user request and composes a set of all compatible normalized queries. The QRP then modifies the retrieved results to include only data fields that were required by the user. These manipulated results are eventually presented to the user according to the business process model hierarchy. 4
To illustrate the proposed framework for supporting a search query on business process content we present an example, in which a user is interested to find out “how order-based decisions are handled by sales representatives”. Using the SA, the user selects a level 1 process, “Order to Cash”, based on the information that orders can be handled by sales representatives at pertaining lower-hierarchy business processes (e.g. Order Management, Shipping Management, …) (Fig. 6).
At the next step, the user uses the QSI to select process levels and define content requirements for the relevant process fields (Fig 7).
Fig 7. The query specification interface (QSI)
Following our example, the user will limit the “Name” field to include the string “order”, the “Description” field to include the string “decision”, and the “Owner” field to include the string “sales”. He leaves the “exact phrase” option unchecked in order to retrieve more results. If, in addition, the user is interested only in “new” processes defined in the organization after a new sales strategy was implemented during 2006, he will add to the “Creation date” field the expression: “01-01-2006 - *”. On top of these data fields the user can also check other required data fields. At the next step, the QI interprets QSI definitions into a set of normalized SQL queries, and the QRP joins all resulted data fields into query results ordered by hierarchal location witin the business process model. The example demonstrates how a user without any in-depth understanding of the data structure can extract relevant results for a relatively complex query – all by using the SA and the QSI.
The ProcessGene Query system provides a method for searching business processes, allowing users to phrase queries without extensive knowledge of the underlying database structure. Although the system provides a good starting point for developing the field of business process search queries, many innovations are needed to exploit open issues such as optimization of result sets, adding business logic for determining semantically related answers, query relaxation and the ranking of results. These issues were discussed extensively in the literature, but have not been addressed yet within the context of business process management.
It is hoped that by expanding the search and query capabilities on business processes content, researchers and IT practitioners will be able to generate complete and consistent business process models as part of their services to ERP/CRM/SCM community. 6