Monitoring and Control
Functions for the administration and management of the real-time flow of work are part of most BPM Systems. Administration tools include facilities for changing the flow of processes based on measures of performance, workload balancing requirements and changing worker roles. BPM Systems provide a view of data on the current status of work in a process and detect conditions such as unacceptable delays at a particular step in the process. Such delays may be due to a particularly difficult event to handle on the part of a worker, too many jobs being routed to a particular step, unanticipated exceptions to the tasks to be performed or exceptions to the rules to be followed. In such cases, an administrator will be alerted and may change the flow of work by sending some of the workload to another worker or to a manager for consideration of how to handle an unanticipated event. In many cases the sophistication of the BPMS and rules engines implemented for the process will determine whether some type of automatic intervention will be available or a human supervisor will be required to take action.
Decision Support/ Performance Management
When measurements of process performance have been defined and implemented, the capability to track and report on these critical metrics is available. Management reports may be generated that indicate efficiency data such as the average time to complete a process step, delay times between steps, resource use and costs associated with processes. In addition, process tracking data may tell us what information was accessed to complete a task, who approved actions during a process, when an action was completed and other information that will be useful in auditing how processes and controls were accomplished for compliance monitoring. Reports will be useful for management to continuously look for areas of improvement and to reduce the costs of compliance monitoring. Other reports may be useful to IT managers for managing networks, servers and other systems components.
Performance measurement and management applications have been developed to assist management decision making. Some BPM Systems have integrated these applications into their suite of capabilities. In large enterprises, the data and other information required to make decisions on business performance may be disbursed over a number of different systems and databases. Enterprise Application Integration (EAI) systems have been developed to facilitate accessing and reporting on information from a variety of sources. These systems use a group of application interfaces to pull information and then present summarized information in the form of management reports. Extensions of EAI and Data Warehousing systems called Business Intelligence (BI) systems have sophisticated data mining and management dashboards for presenting process performance data to managers to support decision making.
BI systems are dependent on the creation of metrics for various business performance indicators. The term Business Performance Management has come in use in recent years to refer to efforts to provide management processes taking advantage of sophisticated methods for determining the performance of various aspects of an organization. BPM systems that measure the performance of various aspects of business processes are a part of an overall performance measurement program.
Business Rules Management System (rules engine)
A category of software applications that are related to the monitoring and control of processes are rules engines. In general, a rules engine provides the capability to develop statements that monitor process events and then take specific actions based on an event occurrence. The most common use of rules involve conditional routing where a transition between process activities is based on detecting a particular condition and routing the process to the appropriate employees or to another process action.
Rules are also important to detect business process conditions and identify conditions to determine when further decisions are required. Given the dynamics of business processes it is not always possible to predetermine conditions, and rules engines that allow for exception handling and decision processes are necessary.
Other rules based on data analytics may be used to measure business process performance. We may wish to establish rules that look for events having to do with financial performance, conditions of regulatory compliance or production controls. For example, management may want to be alerted when projected sales of a certain product fall below a certain point so that sales efforts may be adjusted before poor sales performance is a fact. In manufacturing, a rule may be established such that when the inventory of certain parts is below a specified level, then purchase orders are automatically generated by a system.
Basically, most rules engines provide a language for creating rules statements. The most common form of a rule is the “If …Then….” type of statement. Actions supported by the rules engine may include alerts sent to specific individuals to make a decision or take an action or the action may be to execute a set of codes in a software application that would perform a function. Rules engines may be part of a BPM application or may be independent programs that interact with other applications to perform a task.
An emerging class of software is Business Rules Management Systems (BRMS). As management and process designers determine the rules that are applicable to a given process, a somewhat daunting task is to translate the conceptual rules into executable code.
Business Rules Management Systems allow designers to create rules in natural language statements (the If-Then statements). The system then generates the required code for execution. BRMS generally include methods to maintain the repositories of rules, test rules and make changes based on design changes. Therefore, rules management is in the hands of designers without reliance on technical coders. BRMS’s are particularly useful for large organizations with complex rules requirements to manage.
Process Repository Management
Process Repository Administration is a critical component of managing business processes that should be taken as seriously as the administration of any other company asset. The Process Repository is the blueprint for process management within the organization, not only as a common frame of reference and method of consistent communication, but it is also the system of record for information on process ownership, technological enablers, business rules and controls, both financial and operational. Effective and consistent administration of this valuable asset is critical to developing and maintaining the holistic nature of the enterprise’s processes through promotion and acceptance of their cross-functional nature.
A Process Repository is a central location for storing information about how an enterprise operates. This information may be contained in various media including paper, film or electronic form with a storage mechanism appropriate to the medium. Electronic repositories range from passive containers which store process artifacts (also referred to as process objects) to sophisticated tools that serve as active participants in executing and managing business processes. They come in the form of Document Management Systems, Process Modeling Tools and Business Process Management Systems.
Process Repository administration activities includes storing, managing and changing process knowledge (objects, relationships, enablers, attributes, business rules, performance measures and models) for an enterprise. It includes creating the repository structure; defining and maintaining procedures to ensure changes are controlled, validated and approved; mapping processes to applications and data, and providing the required infrastructure to enable effective and consistent use of the models in the repository.
Process Repository Content
The type of information about a process that should be maintained in a process repository includes:
Who owns the process What the process does
What technology enablers and controls are used What triggers or events initiate the process What are the expected results
When is the process initiated
Where does the process take place
How the process interacts or links to other processes
How the process interacts with those of other business units or external enterprises
How the results are delivered
Why it’s needed, how the process aligns to strategic goals
Process metrics such as time to perform, number of resources required, minimum and maximum concurrent executions, direct and indirect cost, etc. Business Rules
Regulatory requirements
Type and source of data related to the process
Object-based repositories also store information about the individual objects used by the Business. These objects are reused throughout the model providing consistency and simplifying maintenance. Consistent use of common objects avoids redundancy and contradictory information about a business artifact as the object only exists once in the repository but can be visually represented in multiple places. This allows a change to an object to be immediately visible wherever that object has been used.
Examples of these objects are customers, applications, organizations, roles, events, and results. The information kept for each will vary by type but includes such attributes as:
Name Description Owner
Associations to other objects or processes Value (measurement varies by type of object) Importance to the Business
Technical specifications
Managing and integrating models
Managing models within the enterprise should start with identifying the levels of models that the enterprise will maintain. These range from an enterprise-wide model to temporary working models. While the figure below only shows one level of business unit or project sub-model, there could be additional levels depending on the size and structure of the organization or project. In addition, the granularity of the information contained at each level may vary. For example, the enterprise-level model may contain a few key attributes for each item while a business unit model would contain a more detailed set. However, if the enterprise-level model is a true ‘master’ then each sub- model will contain a subset of this model and the granularity of information for each item will be the same. Figure 10.2 below shows an example of the relationship between these levels.
This example starts with the enterprise level model which contains all the processes and related objects for the entire business. Each business unit would own and maintain a business unit master model and the active project models. Note that projects that span business units will also have a project model which may contain components from various business unit master models. The central repository administrator works with the business unit model administrator to identify all the business processes required for the end-to-end execution of the business unit’s processes. These should be assigned to a category or subject area. Many of the modeling tools provide this functionality. A modeling tool, should at the minimum, have the ability to maintain an inventory of these groups and the components included.
The business unit master model is a sub-model of the enterprise master model. Formal scheduled synchronizations are performed to maintain the integrity of the information in both models. The next level of model is the project model. For each project, a project sub model is created containing the business processes required for the project. The business processes are checked out of the business unit master and when the updates have been completed and approved, checked back in. A formal change control procedure needs to be in place and adhered to. This procedure must include how to request check-out/check-in, check-in/check-out criteria, approvals required, timelines, and conflict resolution. When any component is checked out, a change freeze must be implemented.
Managing a model should be treated in the same manner as managing databases and source code. There must be regularly scheduled back-ups and full disaster recovery procedures in place.