#BPM related TLAs comparison

This blogpost is aimed to arrange some acronyms (usually Three Letter Acronym - TLA) in the BPM domain. This blogpost is based on Definition of #BPM and related terms, again and Enterprise as a System Of Processes blogposts.

Just repeat a couple of basics.

Enterprise functioning can be considered to be the enactment of business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise.

Process-based disciplines (TQM/QMS, BPR, TPS, 6Sigma, etc.) exploit the concept of business processes for the better management of the enterprise functioning in support of the enterprise goals.
Note: They are also called process-based management disciplines.

Business process management (BPM) is a process-based discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business processes.

These 6 functions will be used to arrange various TLAs in 2 dimensions: functionality and scope.

Although, the BPM definition mentions "any combination", there are some dependencies between these 6 functions which distribute these functions in time.
  • measurement is before optimisation because you can't improve what you are not measuring;
  • execution is before control and measurement because the focus is on the enterprise functioning;
  • modeling is before automation and execution because any work should be planned first.
These functions can be used in various scopes: a business unit, an enterprise, a supply-chain or an ecosystem.

Processes may be

  • implicit  -it does exist in somebody's head or implemented by an application, e.g. SAP R/3, 
  • explicit - it does exist in a human-readable format, e.g. in Visio,
  • executable - it is does exist in a format which is human-readable and machine-readable, e.g. as BPMN  and may be interpreted by a business process engine application, e.g. Intalio, Bonita, SAP NetWeaver, IBM Webshpere Process Server. 

workflowexecutableexplicit or executableexecutableexplicitimplicitimplicitdepartmental or enterprise
BPAexplicitimplicit or explicitimplicit or explicitN/AN/AN/Adepartmental
BPIimplicit or explicitimplicit or explicitimplicit or explicitimplicitexplicitexplicitdepartmental

N/A means not applicable
executable means machine-assisted execution
BPA means business process automation
BPI means business process improvement

As one can see, BPM (as a discipline) is the most powerful process-based management discipline although not all 6 functions are always used together.



Presenting on a #BPM mini-conference


Alexander Samarin with the topic “How EA, BPM, SOA and ECM work together” and Karl Walter Keirstead  with the topic “Bridging the gap between strategy and operations”

17.00: Lecture from Alexander Samarin: Architecting the synergy between EA, BPM, SOA, ECM and some other information technologies
Enterprise architecture, enriched with business architecture, BPM, SOA, ECM, IT governance and information security, is a powerful set of methodologies and technologies to provide the guidance how to design and implement a complex enterprise environment. Such guidance is based on for example:   
- BPM reference model
- Platform-based architecture

- Enterprise as a system of processes



Enterprise as a System Of Processes

This blogpost is an attempt (inspired by www.bpm.com forums and http://thebusinessarchitect.accelare.com/2014/03/10/a-systems-view-of-business-architecture/ ) to understand how separate processes work together as one functional whole (i.e. a System Of Processes -- SOP) at the scale of an enterprise. Use of processes (and related to them constructions) will reduce the undesired complexity of an enterprise, improve understanding of its structure and behaviour, thus facilitates the management and evolution of the enterprise.

Basics of the management by processes

Enterprise functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise. (Business activity is a unit of work). Those flows and individual business activities within them are interrelated. Flow emphasises that business activates are interrelated in time as well. So, the relationships between business activities are static (expressed as structure) and dynamic (expressed as behaviour).

Although any enterprise has its naturally complexity, the lack of explicit and codified knowledge about all relationships (static and dynamic) adds a lot of undesired complexity. The latter is the root cause why it is difficult to manage and improve enterprises. Often, even small changes provoke big disasters.

Historically, business process is the basic business concept to bring some order into the structure and the behaviour of interrelated business activities. A business process is explicitly-defined coordination for guiding the purposeful enactment of business activities.

In its simplest form, the explicitly-defined coordination is an initially agreed plan to follow a defined sequence of activities; the plan may include some variants and the plan allows some changes during its execution. A detailed, formalised and unchangeable plan (e.g. in a form of process template expressed in BPMN) is one of the several coordination techniques (see http://improving-bpm-systems.blogspot.fr/2014/03/coordination-techniques-in-bpm.html ). The explicitly-defined coordination reveals the structure and the behavior and thus reduces the undesired complexity.

Because the coordination can be strong (e.g. as in the army) or weak (e.g. as in an amateurs football team), it is possible to discover various constructs (in addition to business processes) within the whole structure and behaviour of business activities within an enterprise. Usually, the coordination between business activities which belong to a particular construct is stronger that the coordination between similar constructs. The number of relationships between business activities which belong to a particular construct is higher than the number of relationships between business activities which belong to different (but similar) constructs.

Thus, the knowledge about constructs reduces the number of potential relationships between business activities and allows concentrating on constructs themselves and relationships between constructs. Note that relationships between constructs can be implemented by different coordination techniques (see http://improving-bpm-systems.blogspot.fr/2014/03/coordination-techniques-in-bpm.html ).

Coordination within processes

It was observed that although all business processes are unique, they are actually composed from similar process fragments or process patterns. For example, let us consider a typical “repair” process in housing management which comprises claim making, evaluation, selection of a service provider, repair, control, invoicing and insurance to pay the activities. This process several is actually composed from a few process patterns as shown in illustration below (an original process model is covered by patterns).

Patterns used in this illustration are:
Although any pattern is a highly-cohesive construct, patterns can be adapted to particular needs. For example, the Delegation of Authority Matrix (DAM) pattern is implemented differently in the procurement and in the project management.

Some process patterns are available at http://improving-bpm-systems.blogspot.fr/search/label/practical%20process%20patterns

In general, process templates must not be considered as something “fixed forever” – see http://improving-bpm-systems.blogspot.fr/2010/12/illustrations-for-bpm-acm-case.html

Coordination between processes

The coordination between processes is usually event-based (see the illustration below). In the simplest variant, the finish of a process is the start of another process. Note that it looks like the state-based coordination between processes.
In the reality, there are more complex interactions between processes (see the illustration below)

  • the finish of one process is the start of another process – marked with circled “1”;
  • starting another process and just waiting for its finish (aka synchronous invocation) – marked with circled “2”;
  • starting another process and waiting for its finish sometimes later (aka asynchronous invocation) – marked with circled “3”;
  • starting another process and not waiting for its finish at all (aka “fire and forget”) – marked with circled “4”;
  • staring another process from one process and waiting for its finish in third process – marked with circled “5”, and
  • co-processes (e.g. a pair of rock climbers tied together by a rope agree to climb one after the other, and not simultaneously -- see http://www.slideshare.net/samarin/process-practical-patterns-si).
Additional coordination techniques are also necessary because


Cluster of processes

Processes ,which are strongly related to each other, form Cluster Of Processes (CLOP). They are usually functional processes which are implemented a particular business function, e.g. Field Services.

Halo of processes (HLOP) is a set of processes which helps to execute a particular CLOP; the former are monitoring, operating and governance processes for the latter. The processes from HLOP are also called leading processes.
  • Monitoring processes are responsible for analysing the running functional processes – some sort of operational intelligence. 
  • Operating processes are used for implementing operational (via available parameters or controls) changes. 
  • Governance processes are used for detecting, designing and implementation of structural changes, e.g. “customer satisfaction and loyalty development”, “quality”, “strategy and planning” etc.
All together, they constitute two control loops – operational and strategic. Sometimes, extra health-check-points may be introduced for better monitoring of complex clusters.

At the operational loop, the following coordination techniques can be used:
  • intelligence-based – using the data about the execution of processes, it is possible to predict the future behaviour of processes and to take proactively some mitigation measures to avoid troubles. For example, an insurance claim (functional) process has an SLA related to the maximum execution time and some threshold to automatically accept small-value claims; otherwise a claim should be checked by an operator. If the monitoring process has detected that there is a “wave” of claims and there is a risk that the SLA can’t be kept because of the staff limitation then the operating process can temporary increase the threshold to absorb the “wave”. 
  • goal-based – as a typical business goal can be very hierarchy-structured (imagine a complex “fish-bone” diagram) and different sub-goals are supported by different processes, then some analysis of the actual situation related to achieving of goals may lead to adjusting some parameters in related processes or, even, starting of some processes. For example, if the HR cannot fill some positions then a process for reviewing the job descriptions for those positions can be initiated. 
Each CLOP may relate to the enabling group of clusters (EGOC), the supporting group of clusters (SGOC) and the customer group of clusters (CGOC). EGOC are typically specific for this CLOP while SGOC are common for several CLOPs.

Because of the natural recursion, a CLOP can be SGOC for some CLOPs. For example, a particular enterprise value system is a CLOP with SGOC of finance CLOP, IT CLOP, HR CLOP and procurement CLOP. Note that an enterprise may have several value systems.

Using the popular terms “core processes” and “supporting processes”, it is possible to say that “core IT processes” are “supporting processes” for “core business processes”.

Value streams and end-to-end enterprise processes are usually formed from a few CLOPs. In some sense, the whole enterprise is a “printed circuit board” in which CLOPs are connected “microchips”.

Coordination between CLOPs

Let us look at situations when some activities from a CLOP initiate (maybe even indirectly) activities in other CLOPs. The explicit coordination via event-based techniques is used in the form of “fire and forget”. For example, a service technician found that a particular piece of equipment must be replaced and he/she has to initiate an order to carry out this replacement.

The implicit coordination between CLOPs may happened as well. There are many situations in which one process is changing a business object and some non-trivial actions may be taken because of those changes. Also, a chain of changes may happen: a trivial change in a business object necessitates a change in another business object which necessitates a non-trivial action. And the business objects maybe of different types.

For example, a field service technician updated (in an activity in the process “close services”) his/her work order (business object 1) with a report which contains some lessons learnt. Those lessons learnt, after some validation, may be incorporated into the product maintenance guide (business object 2) or to the customer’s profile (business object 3). An analysis of customer’s profiles may reveal a need for some preventive maintenance (business object 4) or an opportunity for a custom project (business object 5).

Illustration below shows the separation between the update logic (change the state as the result of an external stimulus) and life-cycle logic (performing some activities that are related to a particular state).

More examples are below.

Coordination cases for business objects like products:
  • product’s life-cycle which requires some works in future (e.g. a technical service of the car after each 20 000 km) – aka scheduling.
  • eco-system influence, e.g. end of support/production for some components of a particular product.
  • technology progress, e.g. the availability of a cheaper material/component of a particular product.
Coordination cases for business objects like resources:
  • if a resource is not available then processes are queuing for it.
  • resource requires replenishment if its capacity is below a threshold.
Coordination cases for business objects like customers:
  • offering new services and products as the result of the field servicing.
  • changing of legal conditions (to renegotiate a maintenance contract).
  • market campaigns.
Typically, business object life-cycles are supported by custom applications and COTS (e.g. ERP, ECM). This makes difficult adding the coordination to existing life-cycles logic. A possible solution is to consider life-cycle as a process - http://improving-bpm-systems.blogspot.fr/2013/11/practical-process-patterns-lifecycle-as.html .

There are a couple of related techniques fro implementing the implicit coordination between CLOPs. A data integration process may be used for propagating data among several business objects (actually data repositories) as shown in illustration below.

Another technique is the “big data” or “business intelligence” approach when the data from various business objects is collected in one data warehouse and analysed by

Which technique is the best – all depends on a particular situation.

Functional view of system of processes

There is a definition of cross-functional (or end-to-end) process -- process which is understood differently by all participating organisational functions. This root cause of this effect is that separate organisational functions see the system of process from their functional silos. For example, department ZZ understands their process as show below.

Actually, their process is as show below.
And activities A and B are from processes of other departments as show below.
Again, implementation of functional processes separately will create a lot of undesired complexity.

Error-recovery relationships between processes

Another type of relationships which are very explicit. How CLOPs are linked for the error-recovery. For example, a client ordered a payment in an e-banking system (front-office). The e-banking system passes the payment to the bank's STP system (back-office) The latter tried to execute the payment and it was rejected by the recipient's bank. The back-office starts its recovery-error process which must start front-office recovery process BEFORE the client gets complains from the recipient.   Sounds simple, but it does not work in, even, in my world-wide bank.

Other factors to consider

Note, so far, both implicit and explicit forms of processes were treated equally. Typically, implicit processes are implemented within custom-built applications and ERP systems. Extracting important events from existing applications/ERPs is mandatory to exploit the power of processes.

In the worst case scenario, some processes are defined only on paper by the business and ignored by the IT.

Ideally, the target is explicit and executable business processes.


Enterprise patterns: AGA

Enterprise pattern – Architecture Governance Anchor (AGA)

This pattern addresses a typical problem – where to start Enterprise Architecture (EA) governance in a practical way without “boiling the ocean”.

Illustration below is used as an anchor. It considers that a typical EA function has to have an EA tool which is populated with various EA artefacts to provide the EA knowledge repository to its “users”. It is supposed that the EA knowledge repository will improve the decision-making related to all modifications within an enterprise. For example:

  • Formal project management process.
  • Informal project delivery practices.
  • Corporate-wide strategic programmes, business strategy and its execution.
  • Continual process improvements.

Governance challenges

The typical architecture governance challenges are at the interfaces as shown in illustration below.

1 The EA function may be involved in some “very important” projects but the EA engagement into all IT-related projects is not systematic neither systemic. As the result, some IT solutions and tools are unknown to the EA function or the EA function is dealing with them in the post-factum manner not up-front.

2 Although the EA is a unique corporate function which, potentially, must holistically covers the breath (all business units) and the depth (strategy to execution from the business to IT) of the enterprise, the potentials of the EA may be not unleashed yet. Usual practices in the IT-related decision-making do not take into account the EA function, especially in “shadow IT” and some IT tool-centric groups.

3 Being a guardian for the coherent transformation of the enterprise, the EA function should be an entry point for any IT-related changes now and an entry point for all business and IT changes soon. All changes, ranging from strategy to BAU projects should involve the EA function to guarantee the feasibility of changes and their optimal execution.

4 Is the EA function equipped with tools that are adequate to its current challenges (primarily the undesired complexity of the IT landscape)? Can an EA tool handle the following:

  • complete nomenclatures of the EA artefacts (solutions, processes, business functions, applications, services, roles, rules, data, capabilities, etc.);
  • validated dependencies between the EA artefacts (e.g. which business functions used in a particular business process);
  • established procedures to maintain the EA repository (e.g. it is updated at the end of a project) and
  • descriptions for proven and ready-to-use solutions.

Without this information, it is impossible to estimate the impact of changes. Also reference architecture and available solutions are not known to project teams.

5 The efficient delivery of the EA function is about making the EA knowledge:

  • available (complete, up-to-date, and logically organised),
  • understandable (detailed instructions and expert support on demand),
  • actionable (linked to change processes to be used by the business and the IT department without systematic involvement of the EA staff members).

Thus, the EA function will be perceived as a facilitator of changes.

6 Gartner recommends that the EA team should be about 1-2% of whole IT staff (for IT organisation of 1 000 – 5 000 people). Estimate if the EA team is adequately staffed.

7 The set of available competencies in the EA function may be at its initial level. In particular, typical missing competences are: business architecture, process architecture, cross-domain architecture and SOA (see as well http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-ear.html ).

8 If the users are not happy with the typical IT deliverables (develop something unformed and impose it to everyone) then maybe EA can offer something more adaptable to various needs of different users to make the diversity efficient.

Example of work items to improve the governance

The mentioned above governance challenges have to be analysed and prioritized. Potential work items to address some governance challenges are shown on illustration below (those work items are labelled stars).

The work item A is about obtaining the better input from projects. This allows avoiding duplications in the development (potential technique - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html ).

The work item B starts to handle various EA artefacts (primarily processes, business functions, applications and capabilities) and relationships between them.

The work item C is adding some missing expertise into the current EA team.

The work item D is the selection of an EA tool which can handle all EA artefacts and produce various views (e.g. project, business unit, application portfolio, etc.)

The work item E is about improving the interface between the EA function and the project management processes. EA provides some tools and techniques to simplify project execution, for example:

  • evaluation check-lists,
  • templates for mandatory documentation (business case, architectural dossier, etc.),
  • “as-is” EA artefacts and relationships between them,
  • macro-planning,
  • clear rules for approval gates.
The work item F may combine diversity and uniformity (potential technique -http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html ).

Evolution of the EA function

Logically, the EA function has to “expand” its influence step-by-step.
  1. Staring from the IT domain and making it in order (EA is under the CIO)
  2. Moving up-stream and helping to address operational issues (EA is under the COO)
  3. Ideally, reaching the strategy level, EA function is enabling the execution of the corporate strategy (EA is under the CEO).




Enterprise patterns: EAR

Enterprise pattern -- Enterprise Architectural Roles (EAR)

This is an explanation of relationships between some roles in the enterprise architecture (inspired by  http://grahamberrisford.com/00/Architect%20roles%20-%20by%20level%20and%20domain.htm ). A background description about Enterprise Architecture (EA) can be found in http://improving-bpm-systems.blogspot.ch/2013/06/entarch-basics-in-for-dummies-style.html

I think there are three dimensions (each of them has different type of partition) which are necessary for separation of enterprise architectural roles:

1) “Business domain span” – nested partition into the whole enterprise, business domain, business unit, etc.

2) “Architecture span”– mutually exclusive partition into business architecture, process architecture, information architecture, application architecture, data architecture, technology architecture, security architecture, etc.
Note:  EA is responsible for the synergy between all other architectures.

3) “Time span” – partially overlapping partition into enterprise life-span, solution life-span, technology life-span (e.g. client-server, SOA), tool life-span, platform life-span, etc.

Usually, a solution (a unit of deployment) may have several versions and each version is implemented as a project (see illustration below).
Usually, there is an architect in "project 1", but very rarely he/she is actually the "solution architect" because "project 1" is just the tip of the iceberg in the whole solution life-span. Sure, some projects are just BAU for small modifications.

A few consecutive solutions may form (rather implicitly) a capability (see illustration below).

A platform usually has a few primary tools (with their own life-spans) and several overlapping in time solutions (see illustration below). See about platforms - http://improving-bpm-systems.blogspot.ch/search/label/PEAS

Enterprise architect:
  • Business domain span = the whole enterprise
  • Architecture span = all architectures TOGETHER
  • Time span = enterprise life-span
Note: In some sense, enterprise architect is “enterprise as a system” solution architect.

Enterprise application architect:
  • Business domain span = the whole enterprise
  • Architecture span = application architectural domain
  • Time span = enterprise life-span
Solution architect:
  • Business domain span = usually a particular business domain or unit
  • Architecture span = a few architectures (which are critically related to the solution) TOGETHER
  • Time span = solution life-span (usually a big project to deliver the first version and, optionally, several smaller evolution projects)
Platform architect:
  • Business domain span = may be the whole enterprise or a particular business domain or a few domains
  • Architecture span = a few architectures (which are critically related to the platform) TOGETHER
  • Time span = platform life-span
Relationships between these roles in 3rd (time) dimension are shown in illustration below.

 SOA architect:
  • Business domain span = the whole enterprise
  • Architecture span = partially on technology and application architectures
  • Time span = SOA as a particular architectural style usage in a particular enterprise
BPM architect:
  • Business domain span = the whole enterprise
  • Architecture span = partially on technology, data, application and business architectures
  • Time span = BPM as a particular methodology and application architecture usage in a particular enterprise
Capability or tool or platform or solution may use several architectures in different extend as shown in illustration below. (+++ means "intensive use").

Supply-chain architect:
  • Business domain span = supply-chain as the business domain
  • Architecture span = all related architectural domains TOGETHER
  • Time span = business domain life-span
Cross-domain architect:
  • Business span = integration between several business domains
  • Architecture span = all related architectural domains TOGETHER
  • Time span = enterprise (or its particular business model) life-span
Various business domains may use several architectures in different extend as shown in illustration below. (+++ means "intensive use").

Solutions, platforms and capabilities may span several business domains as shown in illustration below. Sometimes, the architect for "Solution 1" is called "enterprise solution architect".

In general, a solution architect must follow all rules, standards, norms from all other architectures (relevant to a particular solution implemented in a particular project) unless explicitly specified and agreed up-front. Often a project architect is too limited by a project manager to address the real complexity of a solution. Application, domain and enterprise architects must help such a project and the PMO (see  http://improving-bpm-systems.blogspot.ch/2011/01/relationships-between-ea-and-pmo.html ).



Practical Process Patterns: RAAP

This practical processes pattern RACI As A Process (RAAP) shows the use of the well-known technique RACI (Responsible – Accountable – Consulted – Informed) http://en.wikipedia.org/wiki/Responsibility_assignment_matrix in processes.
  • Responsible - to do the work
  • Accountable - to control and approve
  • Consulted - to be solicited to provide some input (two-way communication)
  • Informed - to be kept up-to-date (one-way communication)
Let us consider that any business activity can be decomposed into four logical steps (similar to the PDCA cycle http://en.wikipedia.org/wiki/PDCA ) connected in a simple process:

1. PLAN: preparation for the work to be done;
2. DO: execution of an indivisible unit of work;
3. VALIDATE: checking the correctness and quality of the work carried out;
4. REFLECT (or “re-factor”): analysis of the work experience and results to see whether it is useful to propose/implement any improvements for future similar work.

The illustration below shows that different roles are involved in different extend in different steps:
  • actually perform (depicted by double lines)
  • involved as a core team member (depicted by solid lines)
  • involved as an observer (depicted by dashed lines)

In addition, some exceptions (e.g. an escalation because of the too long execution time) should be addressed to Accountable.


Coordination techniques in #BPM

In the context of BPM (see http://improving-bpm-systems.blogspot.fr/2014/01/definition-of-bpm-and-related-terms.html) I use the following definition of business processes. A business process is an explicitly-defined coordination for guiding the enactment of business activity flows.

Considering that there are different techniques to coordinate the work to be done (e.g. the discipline in the army and an agreement on positions in a football team of amateurs), this blogpost lists the several coordination techniques which are applicable in business processes.

This blogpost is the continuation of http://improving-bpm-systems.blogspot.fr/2012/07/coordination-techniques-in-bpm-social.html

flow-chat-based – a typical workflow which is the formal token logic (multiple tokens are possible) which controls the order of activities to be executed. Note: flow of control vs flow of data.

state-based – a typical state-machine which is the simplified formal token logic (only one token is possible which is located at a particular state); for example, a life-cycle diagram for an object type because each object instance can be only in one state.

event-based – as a simplified EPN (Event Processing Network) – see http://improving-bpm-systems.blogspot.fr/2011/01/explicit-event-processing-agents-in.htmll

role-based – use of a role-dependent function the further routing of tokens; e.g. distribution of load.

rule-based or decision-based or intelligence-based – use of a calculation-intensive function to guide the execution.

data-based – use of predominantly data in rule-based or decision-based techniques.

information-based – use of predominantly information in the intelligence-based technique.

knowledge-based – use of predominantly knowledge in the intelligence-based technique.

community-based or social intelligence or social knowledge – asking a community for an advice to guide the execution.

goal-based – a variant of the intelligence-based with the use of goal-dependent function to guide the execution, e.g. stop the process if its goal is reached (consider a shopping list or a check list). Milestone is a kind of goal.

instance-based – exchange of events between process instances, e.g. co-processes

inter-process – a simple variant of instance-based when the end of one process instance is the start of another process instance.

managerial – a variant of the knowledge-based with the use predominantly of tacit knowledge.

instinct-based – a variant of "very" tacit knowledge, e.g. flock of birds shows complex behaviour because all birds have the same "internal" program which interprets some signal between them.

inter-organisation – a variant of the inter-process when processes are in different organisations.

resource-based – the execution depends on the availability of a resources, e.g. a system of mass-servicing like a hair-dress shop. (also known as demand-supply balance)

decomposition cascade – a variant of goal-based in which something complex should be disassembled into smaller components in several steps (of a component is also complex that it should be decomposed as well), e.g. architecture of an IT system, cascade of secondary particles, lightening.

assembling cascade – as the opposite to the decomposition cascade, assembling something complex from smaller parts; e.g. building construction, implementation of an IT system/application. Typically, a Gantt diagram is used to manage the complexity of assembling cascade.

combined cascade – doing decomposition and assembling together as in agile development, by architecting some components and then implementing them as mini-cascades (in waterfall development, the decomposition cascade and assembling cascade for the whole system are clearly separated in time).

life-cycle-based - necessary to add as a "high-level" coordination - http://improving-bpm-systems.blogspot.com/2013/11/practical-process-patterns-lifecycle-as.html 

Scheduling 3-tier from karl walter keirstead - see https://kwkeirstead.wordpress.com/2014/11/16/three-tier-scheduling-and-why-you-need-it-for-acmbpm/