Business Process Reengineering - Chart Key

From RiskWiki
Jump to: navigation, search

Chart Symbols and Their Meanings


Process Charting Design Rules

Introduction - Key Concept

The full process charting model forms a language for accurately describing processes and other object relationships. The language can be represented either diagrammatically or descriptively (textually). A chart drawn according to the charting method describes a network of unstructured interacting objects (processes, people, etc) and the data output states of this network as it consumes data through its inputs.

The charting method goes beyond a standard process flowchart in that its symbol grammar is sufficiently consistent and structured as to enable the translation of the chart to a text description. The text description takes the form of a program that in turn could be executed directly or translated / re-coded into a standard application programming language as an executable application.

This ability to reliably define a program simply by documenting a real world process according to the design rules below allows an automated modelling testbed to be constructed from the chart, and then stress tested with different data loads, or different error types, or checked for deadlocks, bottle knecks or compared against alternate process designs, etc. Such testing and anlysis can be done either manually or via automation.

There are a number of different symbols and descriptive encoding rules, but in essence many of thesee enhancements are for diagramtic efficiency. The core of the charting system revolves around one meta (undrawn) symbol - data - a few drawn symbols. The full model merely expands on these to provide a richer descriptive set, and more analytic detail with fewer individual diagramatic elements being required to represent the idea than otherwise.

All symbols are one of three classes:

  • Objects - Things that originate, transform, store or consume data
  • Events - Both consumers and orginators of event data. Events may receive and/or generate an excite or inhibit signal.
  • Connectors - Lines joining events and objects through which data flows

The importance of Data

The life blood of the process diagram (or description) is "data". It is data that flows through the connectors to join event or object to event or object. Data is created when an event fires, or a data orgination object manufactures or otherwsie supplies data. Data is stored in data stores and transformed in processes. Data is discarded in data sinks.

Data is inherently transient and never drawn as a symbol, although it is documented. When data is stationary it is held in a data store. A document with writing on it is therefore a data store - not the data itself. Likewise a database record is a data store, not the data itself.

Data is virtual and can take many forms. It may be a piece of information a human would understand or an electronic blib with a voltage value to excite or inhibit the recipient proportionately.

Data is infinitely divisable, imutable and transformable.

Like energy, data can neither be created or destroyed across the entire universe of processes, but within the context of any subset of processes less than the infinite set of all possible processes, data can be orginated and discarded.

When data is held in a data store it transforms the data store in some way. In a paper document datastore, it results in a blank sheet displaying written or image data. In a manufactured item "data store" it results in the transformation of petro chemicals and metals into a consumer item like a lamp shade or a car.

The Class of Objects


All objects are recursive and containers.


All objects or events are connected by lines called connectors.

The key chart comes with a number of design usage rules that are perhaps a little unusual and therefore should be considered carefully:

  • All symbols are either events, objects or connectors ( lines or arrows).
  • All objects are (except events) are recursive - meaning that they can include nested members of the same type as the parent (as well as other types), a constrained subset of the child objects or, in some cases, unrestrained subsets. In computational terms a recursive function is one that invokes itself, while this form of pure recursion of objects is rare in process maps, it is legal within the charting rules.
  • All objects are potentially containers of other objects and, therefore, all objects are notionally sets of one or more objects. (Object encapsulation)
  • Objects contained within a parent inherit the in and out flows (connectors) of the parent - or rather they inherit the right to use the flows. (Object inheritance)
  • All objects and/or events are connected by lines called connectors, or by being recursively embedded in a parent object - which then becomes a container for that object.
  • Data flows through the connecting lines into the objects where it is stored, and/or transformed and/or distributed. Data is ethereal and moves from one place to another transforming and being transformed by the vessels in which it is store. A document, for example, is therefore considered to be a data store - not the data itself. A manufactured item, is also a data store, containing the end result of multiple processes each transforming the storage vessel. This is the key concept that enables this process charting method to transcend both service and manufacturing process modelling domains.
  • The arrows connecting objects are data-flows - referring to the movement of information, not explicitly the media on which the information is stored at the time.
  • Connecting Arrows can take a number of annotations, including:
    • identification of the data stream (or data streams)
    • a filter condition for access
    • selector bars
    • optional (conditional) flags
    • authorisation signature lock
    • global type flags (like E for error flows) and/or
    • weight and fuzzyfiers (mainly used for neural and bayesian process modelling)
  • Objects are scriptable
  • All objects (and ideally, but not mandated - connectors) have unique identifiers.
  • All objects can be contained in multiple container objects simultaneously - but each occurrence of object is globally unique - and therefore has the same definition everywhere where it appears.
  • All objects can be containers and as such may be "drilled through" to their content
  • A process object may be a "map" (tranformational or distributive) or a "controller" (quality governor).
  • A process fires or executes when all required inflows have data present (asynchronous).
  • Events impose a block on some or all functions of the connected object until the event fires.
  • All processes are assumed to operate concurrently when data is present on their incoming connectors, or an event fires, unless also constrained by other events blocking the object's functions. Events may thus operate as a clock, or trigger and as a governor or inhibitor.
  • The data-flow method is capable of modelling both excitatory networks and inhibitory process networks.
  • Everything, that is not a connector or event, is an object of one type or another - including the organisation itself.

Object Hierarchy

There is an implied object as container hierarchy (although not in any way mandatory):

  • Entities can contain processes and all other objects
  • Processes can contain processes and all other objects
  • Data-stores can contain data-store objects

This hierarchy is very much a rough rule of thumb, for there are many cases where a data-store will be modelled with containing processes and data-stores - such as where the data-store is intelligent. Entities like organisations or people are, however better seen as external to the process unless they are containers of the process, as they will always have some processes that are not modelled in any given chart and therefore are potentially unreliable.

Entities and Entity Groups

Notionally, every process, can have a controlling entity (particularly where a person is actually doing the process itself). In the charting method, processes are not "owned" by people (although this is how one tends to conceptualise them), so much as controlled by them. In its pure form the process chart would show "process owners" as controlling entities connecting to their processes and thus, like events, constraining their execution unless present and active. To avoid diagrammatic clutter, where a process is controlled by a single entity (or single entity group), that entity (or entity group) can be identified in the process "owner-controller" property in the process description.

An entity group might be a typing pool, call centre staff pool, a community, etc. Each member of the entity group is inter-changeable for each other member with respect to the process concerned. Individual entities within the entity group may have other filters, conditions and constraints that subsequently exclude them from actually controlling the process. An entity group may be a sub-group of another entity group such as C-level executives in a company entity, or administration staff in a stakeholder community.

With the exception of community entities (which are effectively both an entity and an entity group), all entities and entity groups are presented using the same symbol. This is consistent with the central assumptions about entities with respect to the view of the process flows presented in a chart.