User:Sigrinde/sandbox

Barely vs. Easily Repeatable Process
Terminology to support the understanding of different types of work processes or workflows. For process management or IT system solutions there is a need to describe work processes or workflows. One potentially useful parameter for systems analysis could be the process' linearity and predictability. A Barely Repeatable Processes (BRP) can be seen as a complimentary term to the term Easily Repeatable Processes (ERP) although an ERP is a subset of a BRP: if a process framework can handle a BRP it can also handle an ERP, but not necessarily vice versa.

Other terms used for BRPs includes ad-hoc processes, practices or indeed linear and predictable processes (ERPs) including the inevitable exceptions.

Definition
BRPs are the unpredictable processes where the path are dependent on results from earlier activity steps. Path choices, i.e. what next activity step and assignee, can be direct as a result of specific "what next" path choice. Or it can be indirect as a result of choices not directly linked to the path or flow, i.e. when a physician during a diagnosis process enters different symptoms that each will lead to a different next step. BRPs typically describes work processes sometimes termed knowledge work, relation work or practices, typically the core processes of services from consulting to health and government. But it could also include activities in production like R&D, general management, support and issues handling as well as any exception.

History
The term BRP (Barely Repeatable Process) combined with ERP (Easily Repeatable Process) was first coined in a blog post in 2007 suggesting that SAP were missing out on an opportunity by not enabling it's systems to support BRPs.

Characteristics
Given the general nature of human activities in sequences it is not possible to set the precise points where one type becomes the other. But in general: An ERP (Easily Repeatable Process) is characterised by a level of predictability that allows the process to be modelled by ubiquitous IT solutions. The sequence of activities toward the goal would have few but structured divergences from a "normal" path. This typically characterises reality for discrete activities within a larger whole like production, payroll processing, insurance claims or expense reporting. A BRP (Barely Repeatable Process) is characterised by a need for frequent path choices, including forks and loops, depending on results from previous activities which adds up to a high level of complexity if the whole process is seen under one. This typically characterises reality for whole value creation processes like healthcare, government, and any corporation as a whole. Conceptually a BRP (Barely Repeatable Process) can be seen to consist of a cloud of ERP (Easily Repeatable Process) snippets linked together by participant choices or built in rules to act upon results from previous activities in the same flow.

IT support
Currently mainly ERPs (Easily Repeatable Processes) or discrete parts of BRPs (Barely Repeatable Processes) have process based IT support. This leaves most BRP type value creation flows to be handled manually for the most part beyond certain discrete process snippets. The manual methods and practices to handle the flows and ensure the overall value creation includes but is not limited to the organisational hierarchy with it's budgets, rules and reporting. It also includes the direct activities like meetings, ad-hoc communication (email), keeping of lists (todo) and reporting of previous results (Enterprise Resource Planning, Electronic Medical Records).

Practical aspects
BRPs are mostly handled manually using manual frameworks like organisational hierarchies and methods like rules, practices, culture, reporting, meetings and similar aspect which in sum can be termed "management". Thus the cost and resource use by such methods, including in most case all of management, can be seen as flow-work and hence not value-creation for the customer.

In essence freeing the flow-work towards value-creation work would be about "effectiveness", i.e. "what things we do" and less about "efficiency" which is about "how we do things".

Thus the effect of a different, possibly IT based, flow-framework would be substantial. How substantial is hard to quantify but indications are that a knowledge worker spends up to 2/3rd of his/her time on making the flow move forward - i.e. in administration, management and duplicate work.

This would still be far less than a known example of the same effect, when the workflow was given a proper framework and worker's time was freed towards value-creation: In 1913 when Ford implemented their first assembly line "what workers did" changed and waiting for orders and foremen and looking for tools and parts was eliminated and all delivered by the assembly line. At the same time the actual value-creation work - attaching a door or a wheel - remained unchanged as the same tools and movements were used. Still en expected tripling of productivity did not happen, in fact within one year productivity increased 7.8 times.