The Process Platform

Bloor sees that there are 16 functional areas required in a Process Platform in order to support the automation of today’s organisational processes. It has to enable organisations to have the capabilities that define, simulate, deploy, execute, and optimise their business processes.

Figure 1: Bloor’s process platform

Model-Driven Development

This provides analysts a modelling environment. The BPMS products on the market all support the use of the standard business process modelling notation (BPMN). Modelling is done using drag-and-drop activities from the menu bar. The environment has the capability to test the process as well as simulate it. There are a few tools on the market that are aimed at true business use, and which use simpler modelling techniques. Examples include IBM’s new BlueWorks Live – this uses a modelling technique similar to the use of the ‘yellow sticky’ much used by consultants in workshops with users. Microsoft Visio is also in common use as simple modelling tool; a number of BPMS vendors have developed an interface to Vision that allow them to move the model into BPMN notation as a first cut process model

Business Rules Management

This allows analysts to adjust the underlying policies, procedures, roles and responsibilities. These rules dictate how processes start, who participates, what each participant must do (and not do), which systems share the work and corresponding exceptions, deadlines, and approvals. At present there is no standard language for writing the rules themselves. Business rules can be expressed in a way similar to conventional programming languages or in languages resembling natural ones. Alternatively, rules can also be expressed in user-friendly rule forms such as decision tables and decision trees. For more details please refer to Business Rules Management, September 2009.

Form and Report Creation

The primary goal of any process-driven exercise is to reduce paper, as this has been seen by business as the way to improve reliability, reduce waste and create visibility. This can be true in many circumstances, as manual driven processes often hide complexities and rely on a particular individual, but it is not always the case. Using a BPMS tool, organisations can design electronic forms to replace the paper and so capture data and documents that users can access and pass around through serial or parallel steps to automate work. In addition new reports can be created from the data integrated through the process

User and Group Collaboration

Process participants need a place to access their tasks. BPM Software provides user interfaces, which, in turn, can be plugged into integrated portal software or made available through standard portal software, particularly Microsoft SharePoint, for anytime access. Through the UI, users can initiate, monitor, and complete work, initiate dynamic tasks, add comments, share work, run reports, and conduct analysis

Process and Rule Discovery

This is recognition that both processes and rules already are defined in existing applications. Therefore to speed automating a process there is a need for software to find how a process is actually worked in a business. With Process Definition, the last 12 months has seen the introduction of Automated Business Process Discovery software from both new arrivals and also from existing BPMS vendors. Currently, from a rules perspective, the provision is to do this from existing definition-style software.

Testing, Simulation and Optimisation

Iterative development involves simulating process definitions for missed requirements or incorrect assertions. The component should enable users to run tests and round trips to predict bottlenecks and missing items before rolling into execution. Rules also need to be tested and simulated in the same way as processes. My colleague David Norfolk has summed this as, “Simple rules tend to increase in complexity with time and often become inter-related in complex ways. Therefore it becomes more difficult to check unless the testing/simulation environment is tip-top.” Other areas that need to be tested are the interfaces to applications and also all calls to Office and Collaborative software.

Process Execution and State Management

Workflows take place between people and applications as well as people to people, applications to applications and now even sensory device to sensory device. The underpinning technology to this is the XML standard and, on top of this, BPEL. So it is also necessary to be able to define roles that people and devices can play and what that means in terms of access to applications and databases.

Meta-data Master Data Management

The defining difference between a simple drawing tool and a process platform tool is that definitions of all objects of interest from attributes to process definitions are stored and managed centrally in a repository that is usually implemented in some database management system. The meta-data in itself has relationships with other meta-data; for instance Input Customer Order Process is associated with another process called Validate Customer Number, as well with the Customer Record, which itself is related the customer database file in SAP. Figure 2 shows a possible meta-model. Besides the model relating all the objects that are collected or designed, there is also a need to support both version and variant management.

Figure 2: A possible master data management meta-model for a BPM tool.

Integration (System Connectivity)

Using web services, adaptors, and other integration techniques, BPMS software is able to auto-populate electronic forms and reports with content of various forms from existing files and databases. Integration also streamlines data validation, data updates and document versioning. BPM software is able to plug into a service bus and other data orchestration and transformation tools.

Knowledge Intensive Processes support (Case Management/Dynamic Tasking)

Not all workflows are set in stone. Knowledge Intensive Processes are critical to the work of many organizations but are often intensely manual, paper-driven and plagued by delay and poor visibility. Primarily this is because Knowledge Intensive Processes require supporting knowledge work, where many of the important steps take place in people’s heads or through collaboration with colleagues, making knowledge intensive processes difficult to analyse and structure. Also, because these types of processes are primarily driven by human participants reacting to changing context, cases do not follow a predetermined path defined in advance – they lack predictability, making them difficult to automate. Knowledge Intensive Processes must support not just serial, but parallel, processing and, as tasks roll out, workflows created can be used as templates to formal process design and execution.

Document Scanning Capability

This component is required to capture the data on documents and translate it into an appropriate input form to use to update a database directly or application screen. Currently this component is to be found in the tools that came from an ECM background but not in other BPMS products.

Run-time Engines

There are usually 2 engines; one for the processes and the other for the rules. The Process Engine is the runtime execution module that executes the actual process flow activities. This engine has to support both system-centric and document-centric processing. The Rules Engine manages the flow of information and activities within a process according to the formulas and rules assigned to it. Physically these run-time engines will tend to be implemented on top of an application server of some sort.

Monitoring (Status Checks, Alerts)

This provides the mechanisms for users to monitor and audit their work. At any given moment participants should be able to know case/task status. Business analysts should be able to measure and analyse time taken, associated costs, and existing/potential bottlenecks. Missed deadlines or event triggers should cause immediate action requests. This knowledge base enables proactive problem solving and workflow automaton.

Activity Monitoring (BAM)

This goes further than simple monitoring and involves the aggregation, analysis, and presentation of real-time information about activities inside organisations and involving customers and partners. One of the most visible features of BAM solutions is the presentation of information on dashboards that contain key performance indicators (KPIs) used to provide assurance and visibility of activity and performance. This information is used by technical and business operations to provide visibility, measurement, and assurance of key business activities. A further development of BAM is Process Intelligence; here BAM capabilities are combined with Business Intelligence data thus providing context to the latter. BAM is now considered a critical component of Operational Intelligence (OI) solutions to deliver visibility into business operations. This is an area that Bloor will be researching during 2012.

System Administration

This covers all the management function for the software and includes handling roles, security and access rights, LDAP integration, permissions, and process execution.