Business Process Management (BPM) is a term that picks up process discovery, mapping, modeling and, in the case of complex processes, rollout of improved mapped processes to a run-time environment that supports BAM (Business Activity Monitoring).
If your organization has complex processes and your BPM/BAM journey ends with “communication” of mapped paper processes, your organization is not “managing” its processes.
Consider two travelers starting on a trip by automobile, one using a paper roadmap for navigation, the other a GPS. The traveler with the GPS is using a roadmap that has been “rolled out” to a runtime environment. The GPS provides orchestration. Orchestration greatly increases sustainability of your processes – without orchestration, staff receives training on processes, then slowly reverts to old ways. There is no sustainability.
Some BPMs (Business Process Management systems) accommodate rollout without the need for customization.
You map your processes in a graphic environment using drag-and-drop (steps, connecting arcs, loopbacks), with attributes that include step names, data collection forms needed at steps, skill designations for step performance. No need for difficult-to-learn “languages”, no need to write computer code.
One click compiles your map and deploys or rolls it out (i.e. the software carves up your process into discrete steps and posts these according to the logic of your flowgraph to the InTrays of the right users).
You are now in a run-time “Case” environment that provides automatic resource allocation with your BPM providing background orchestration.
Users see tasks post at their InTrays, they micro-schedule tasks, perform tasks and commit these as they complete tasks. Supervisors level and balance workload across users.
Only when you reach this level of process maturity are you “managing” your processes.
What does “perform” a task mean?
It means . . . .
- Taking action at a task (i.e. in a manufacturing setting a task might post as “assemble parts 120A and 120B”),
- Recording data on one or more data collection forms at the task (ranging from a simple “done” check-mark to recording various measurements/observations), then,
- Declaring the task to be complete (so that the BPMs can post the next-in-line step(s) to the appropriate users).
The software automatically builds a History (date, time, process, instance, step, user, data), and automatically posts the next-in-line task to the appropriate user(s).
The contribution of BPM is to provide background orchestration so that the right things get done the right way, using the right resources, at the right places and the right times.
Important considerations for managing processes are:
- Users need to consult the History prior to taking action at tasks (the history allows users to see which tasks along a workflow have been completed and which tasks are ‘current’ along a workflow).
- Users will typically be working on multiple instances of a process (i.e. there may be several active customer orders where there is a need to “assemble parts 120A and 120B”). Users may also be performing work on several processes at the same time, each with more than one instance. One worker may be performing all tasks along a workflow or different tasks may need to be performed by different workers with different skill capabilities. In some settings there may be a need to “hand off” in-progress tasks to other workers (e.g. at change of shift).
- However much time is spent mapping and improving processes, circumstances arise where it becomes necessary to deviate from “best practice” protocols (i.e. processes). A user may need to re-visit an already committed process step, record data at a not-yet-current step, skip a step, or insert a step that was not part of the process.
Clearly, we develop processes with the expectation that users will make consistent use of these, but with the understanding that deviations away from “best practices” may be required under specific situations and contexts. We need some control over deviations (i.e. global rule sets within the run-time environment as opposed to rule sets that are local to a particular process or process fragment).
Your BPMs ends up providing orchestration (i.e. guidelines provided by BPM process templates) and governance (i.e. guardrails provided by the run time environment).
With reference to our “highway map/GPS” analogy, we could say center lines on a highway provide orchestration whereas the guardrails on both sides of the highway provide governance.
The big question becomes, what type of run-time environment is needed to accommodate structured BPM activity and unstructured “ad hoc” interventions?
- You need a User Interface that allows users to see pending tasks and allows users to micro-schedule these and commit tasks. Supervisors need to be able to level and balance workload across users.It turns out the UI can consist of a single split screen, ½ consisting of anInTray, the other ½ consisting of a traditional calendar.
If you think about it that is all any of us needs to perform work. We come into the office each day and take note of our fixed time appointments (calendar) and we then schedule ToDo items (InTray) for performance before or after our fixed time appointments. We all do this, all day long, every day.
- You need a way to set a focus on a particular customer (i.e. establish a cursor position in a relational database management system).
- You need a means of auto-recording of “user sessions” in a History (i.e. date, time, user, process, instance, step, form data) with a re-call capability that allows anyone at the customer record, to view data as it was, at the time it was collected, on the form versions that were in service at the time.
- Your run-time environment needs to be able to accept data streams from outside of the environment and deliver data to local and remote 3rd party systems and applications.
What is “wraparound”, how do achieve it?
Wraparound (i.e. process discovery, mapping, modeling, rollout, monitoring, discovery), for example, a customer in business, a patient in healthcare, a case under investigation in law enforcement, an insurance claim, is achieved by consulting the History before engaging processing at process steps.
At a higher level (i.e. across customers, patients, . . .) wraparound is achieved by data mining with the objective of discovering ways and means of improving “best practices”.
If you are looking for wraparound BPM, consider CiverOrders (a drag-and-drop graphic process mapping environment plus compiler) and CiverSupplier (a Case based run-time environment that accommodates any mix of structured versus unstructured work, featuring RALB, CRM, ECM).
Call 1+ 800 529 5355 for more info or e-mail us at email@example.com
A 5-simultaneous-user run-time system costs as little as $1,500 per year for annual service and maintenance, inclusive of free software updates.
RALB: Resource allocation, leveling and balancing
CRM: Customer Relations Management
ECM: Enterprise Content Management
Run-Time Environment: A user/supervisor workspace where all process step posting and data collection takes place.
Drag-and-drop Graphic Processing Mapping environment: a no-coding process map builder* and compiler.
Customization versus Configuration: Customization involves writing computer code that is translated into computer programs and building/maintaining database tables and fields, configuration involves selecting options that an application system uses to address the specific needs of a customer. The differences are twofold. Customization takes longer and requires technical staff, i.e. computer programmers), configuration, in the main, can be done by functional unit staff.
*some process steps require “rule sets” consisting of an organized set of “if-then” statements (e.g. “if a >1 then b=TRUE”). Some vendors call this coding, others say it is not coding. Civerex does not consider rule sets to be “coding” but not all functional unit members are able to build and maintain rule sets without some assistance from, say IT department or business analyst staff assistance). Users of CiverOrders/CiverSupplier are otherwise able to map out processes and design custom data collection forms without coding or the need to build database tables/fields.