This article is provided to describe the underlying technology as well as the tools and methodologies your Business Process Methodology Team (BPMT) follows for creating and sustaining integrated, automated, collaborative environment for its customers. To seamlessly implement business solutions, the BPMT has to adapt information technology structures. The foundations of BPM methodology are dependent upon defining and illustrating process data using IT nomenclature and structures.
A process is comprised of sets of related activities. Meaningful data useful in data trending can only be generated by measuring outputs of observable activities. To understand, identify and document process content and the relationships between and among activities, attributes about those activities are identified and associated with each activity. Attributes characterize the "who, what, where, when, why, how, and how much" concerning each activity. These attributes are also known as metadata â data about data.
To optimize collaboration through data sharing and integration, there is an increasing need to transfer business process data to the information technology domain; the body of knowledge about data sharing and integration between business and IT led to the creation of BPM as a distinct methodology. To expedite business information transfer, it is more effective and efficient to create attributes about the business data and relate them to data structures that support a process shared between business and IT domains.
A common contemporary computing practice involves identification and use of data objects. Without delving into the world of object-oriented programming, a very simple definition of a data object is a data reservoir (folder or bin) that includes data that characterize the object and distinguish it from other objects. A group of similar, related activities can exhibit the properties of an object â the object has an identity, a state that describes the data associated with the object, and a definable behavior that enables the object to share information about itself in a computing environment.
In large organizations such as law firms and other businesses that review and approve a lot of documentation, the primary emphasis in the last few years has been on automating libraries of paper-based forms. These forms are designed to collect and convey process information for use in making decisions, granting approvals, and transferring form-based information to those who need it in other processes. Although data gathering using a particular form creates a process lifecycle for that form, it should not be assumed that the form is the only sub-process in the larger process. Also, milestones are associated with each life cycle state; the metadata associated with milestones can be used to monitor and chart trends about the form's life cycle performance. The milestones are illustrated in forms-based sub-processes as workflow diagrams. Figure 1 shows the data object relationships between process data objects, metadata, and workflow data objects.
In Figure 1, the bottom of the figure is a green base that represents the boundary of all that could be known about the process; this base represents the core process activities. The dark green cylinders sitting on the base represent process functions that have been identified. As more process functions are identified, more green cylinders could be added to the drawing.
In terms of data objects, the green base of the process symbolizes the encompassing data object; as a data object by itself, the characteristics of the entire process can be described and labeled as metadata. The middle of the Figure 1 depicts the metadata layer that is created as the characteristics of the process functions are revealed. Each function (F1 to F4) becomes a data object with its own identity, states, and behavior. The light blue balloon A2 above A1 in each function depicts the characteristics of each A1. There are three main strings that include both A1 and A2 balloons in F2. Each F2 string of balloons attaches to a workflow activity (yellow) or state or decision point (1, 2, and "?"). This part of the illustration depicts the relationship between the function and the workflow object in an automated form. The "p" balloons (pink) represent potential sub-processes or functions that have been identified but not detailed.
In Figure 1, metadata (A2) is derived from data source, F2.There are two instances of A2 from data source F2 that are used by two states of the work flow identified as "1" and "2". In this model, A2 metadata is not described so it is not possible to identify if the same data is used in "1" and "2". If it is the same metadata, its use should be identified and restricted for use in only one work flow state. In this case, extensibility of the same metadata to two different work flow states may cause conflicting information that will degrade process performance and tracking. The value and importance of validating the data source as discussed in Section 2.3 is underscored in this example of identifying the extensibility of metadata.
Consider this more concrete example. Metadata about "John" may reside in several tables in a relational database that is updated automatically with data from a single source, such as use of a person description entry form. Metadata associated with "John" might include weight, height, eye color, and hair color that all help to distinguish John from other people. If John has a significant weight loss, identification of John may not be as accurate unless that data is updated. One entry using the person description entry form to correct his weight will change "weight" in all tables. If the same data is entered using different forms, there is a high probability that the data could be entered incorrectly or entered in different formats causing a conflict and creating a data integrity problem.
When deriving metadata about an object, its use in several processes needs to be identified to prevent slightly different, but essentially similar metadata from being collected and entered into multiple data tables using different forms. When verifying the source of data for a specific form, the data needs to be traced to and from any other forms used in any of the sub-processes of the target process.