Business Process Reengineering - Chart Key

From RiskWiki

(Difference between revisions)
Jump to: navigation, search
m
m
Line 47: Line 47:
-
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.
+
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.

Revision as of 16:30, 17 January 2011

Chart Symbols and Their Meanings

IMAGE:BPRChartKeyV4.gif


Discussion

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 recursive - meaning that they can include nested members of the same type as the parent, a constrained subset of the child objects or, in some cases, unrestrained subsets.
  • All symbols are either events, objects or connectors ( lines or arrows).
  • 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 and/or
    • Global Type flags (like E for error flows).
  • 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
  • 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.


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.


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.



BackLinks




CopyRight Bishop Phillips Consulting Pty Ltd 1997-2012 ( Business Process Reengineering - Chart Key )
Personal tools