OPHI Document title: Authoring guidelines
Version: @@@
Date: 11/5/2003
Status: Draft
Document: openphi.mit.edu/.... for
Please send any comments on the document to gherman@mit.edu
Author of this version: Licensing group
For more information check the Open Process Handbook Initiative at: http://ccs.mit.edu/ophi/

This paper discusses the ways in which process information can be entered into the Process Handbook. It is split into three parts: a brief introduction to the Process Handbook, general approaches to creating entries, and specifics on how to complete a particular entry. A reader with access to the Web based version of the Process Handbook should be able to author an entry after reading this paper.

The Process Handbook is an ongoing project at the MIT Center for Coordination Science (CCS). The overall goals of the project include developing new concepts to understand, analyze, and invent business processes and developing software tools and databases to help improve and manage knowledge about processes. Our approach has been to acquire a growing repository of business process templates, organize this repository in a way that facilitates finding relevant templates, and develop tools and methodologies that help one use this information effectively.

This repository of business processes can include processes proposed by a variety of authors at varying levels of specificity. We use the terms process and activity interchangeably. Some process techniques have a set number of levels of decomposition or have a hierarchy of levels such as process-activity-task. We have no such set limit and some processes may have seven levels (or more) of decomposition.

We also rely heavily on a novel concept that, we believe, provides substantial power in understanding processes:

The Process Handbook uses the common notion of activity decomposition. A process is viewed as being made up of different parts: collections of subactivities that themselves can be decomposed into other subactivities. In addition, the Process Handbook organizes process templates into a functional taxonomy, with abstract processes (generalizations) on one end and more detailed specializations on the other. Sibling processes in the taxonomy can be collected into bundles that compare the relative merits of these alternatives using a tradeoff table. A key advantage of this approach is that it allows people to explicitly represent the similarities (and differences) among related processes and to easily find or generate sensible alternatives for how a given process could be performed.

There are three basic approaches to creating an entry in the Process Handbook. The easiest way overall is to find an already existing process to use as a template, make a copy and change what needs changing. This is described as ‘top down’. A second way is to enter processes as observed with no reference to what already exists in the handbook. This is described as ‘bottom up’. The third is a mix of the two and described as ‘mixed’. The approaches are described assuming no access to the Process Handbook editing software.

In a top down approach, the author should search the handbook to find an existing entry that most closely matches the process to be entered. If the existing entry already has a decomposition, it should be roughly the same as the proposed entry.

The author should then suggest changes to the existing entry. Changes in name and description should follow the instructions in the section describing how to make a specific entry. Changes to decomposition can take the form of additions, deletions or substitutions. The author should identify which existing subactivities should be deleted. Using the Process Handbook’s search function, the author can identify any existing entries to be used as additions. For substitution, the author should look at specializations of subactivities to be used as more specific replacements.

The advantage of this approach is primarily speed. This advantage is especially true when using the editing software. The disadvantage is losing a case specific view of the grouping of subactivities if the existing entry has an already defined decomposition.

In a bottom up approach, the process decomposition is described as observed, regardless of any existing Handbook entries. Each individual activity and subactivity will then be entered by an editor into the Handbook’s specialization hierarchy, suppressing any inheritance. This approach is simplest for the author, in that the least knowledge of the Handbook is required. Another advantage of this approach is that it keeps the case study view. The disadvantage is that the classification work by the editor can be extensive and activities may be very similar to existing entries. The case specific view of the new entry compared to existing entries may make finding specializations more difficult, which decreases the power of the Handbook in finding innovations for the new entry.

A 'mixed' approach mixes the other two entry creation techniques. Generally a high level process is specialized, but significant subactivities will be replaced with entirely different decomposition views than the inherited activities. 'Produce something -Standard Products' was done in this manner.

The advantages of this approach are to keep some level of similarity to the case study, yet be able to leverage activities that have significant decompositions already entered in the handbook or have many specializations and useful trade-off matrices. Keeping a case study unique view may make it more difficult to find other entries.

All activities are types of acting, which are therefore represented by a verb. At a minimum, the name of an activity should contain a verb. The Process Handbook is, at its core, a taxonomy of verbs of increasing specificity. For example, ‘Act’ becomes more specific as ‘Create’ which becomes more specific as ‘Develop’, etc.

Choosing a verb to represent the underlying purpose of the activity may reflect the particular perspective of the author. For example, if the activity to be represented is a window being broken by a baseball, the activity could be looked at as ‘break window’ or ‘create glass shards’ or ‘hit ball through window’. These three phrases all reflect the same activity, but from three different perspectives. The first perspective may be that of the home owner who wanted an unbroken window. The second perspective may be that of someone needing something sharp. The third may be of the child trying to hit a home run.

At increasing levels of specificity, there may be a need to include adverbs in the name of an activity to further define the verb. For example, ‘Sell electronically’ is a more specific form of selling. When looking in the handbook, we sometimes group activities together in ‘bundles’ (see below). A bundle with ‘how?’ in its name usually is describing increasingly specific verbs.

One way of increasing specificity is by specifying the ‘noun’ or ‘object’ operated on by the verb. ‘Create information item’ is more specific than just ‘Create’ and is different than its sibling ‘Create physical item’. Verb-noun is the preferred form of a name.

At increasing levels of specificity, there may be a need to include adjectives to further define the noun. For example, ‘Manage consumer products supply chain’ is more specific than ‘Manage supply chain’. A bundle with ‘what?’ in its name usually is describing increasingly specific nouns.

The name of an activity should represent the activity at the most specific level for which it covers all cases. For example, In the decomposition of ‘Produce as a business’ there is an activity called ‘Sell’. Sell is used as an activity name to cover all cases of exchanging a product or service produced by an organization for money from a buyer. ‘Sell product’, while more specific, may not cover cases of selling information or services, and would be too specific a name for the activity in this context.

Names should be unique. This uniqueness may be achieved by the use of ‘notes’. (In PH_WIN these are entered using the ‘display’ tab.) These notes display concatenated with the rest of the name in {brackets} over the web, and ‘pop up’ when the name is moused over in the editing version of the Process Handbook.

A primary purpose of the description of an activity should be to explain why this activity is interesting. It might be by contrasting it with its siblings to consider alternatives, or may be listing an organization where the activity is used.

Not every activity is interesting in its own right. Some are the connecting entries that link general verbs with a very specific interesting entry. These make up the taxonomy.

Entries need not be lengthy, but give enough detail to be understandable. Due to the web-based nature of the Process Handbook, it is useful to have summary or brief descriptions web linked to more detailed reference material rather than entering it into the Handbook.

Especially in cases where quantitative or comparative statements are made, references should be provided. This is also true when source material is excerpted or quoted.

The contact for an activity should include the author’s name and email address.

Any attribute and value can be entered for a process. Many of these are inherited from the trade off tables in bundles (see bundles below). Other attributes not used for trade offs may be entered at the activity level.

It is often useful to divide the specializations of an activity into different groups. For example, some types of selling have to do with what is being sold (cars, computers, etc.). Other types of selling have to do with how something is being sold (direct mail, retail store, etc.). In the Process Handbook, we use "bundles" to group these. Some bundles contain "tradeoff tables" where each activity is a row, and the columns are different dimensions (such as time and cost) upon which the activities can be compared.

A bundle name should be enclosed in [brackets]. It should follow the same guidelines as for other activities with the following additional consideration of the type of bundle.

How – collects different ways of doing the verb in the generalization

What – collects different nouns that the verbs operate on

When– collects different timing of the process

Where – collects different location of the process

Who – collects different actors of the process

Views – collects different ways of grouping subactivities or level of detail of subactivities.

Examples – collects specific examples, often from case studies. These may be very detailed.

The rows in a trade off table are defined by the specializations of the bundle. The columns are entered by the author.

The attributes to be used for a trade off may vary depending upon how specific the activities under the bundle are. For example, at a general level ‘time’ and ‘cost’ may be appropriate attributes. At a more specific level, a specific cycle time or type of cost may be more appropriate. These attributes are the column headings in the trade off table. These attributes will be inherited any specializations of the bundle.

As with the attributes themselves, the values within the table will get more specific as the processes become more specific. A general comparison may use values like ‘higher’ or ‘lower’ whereas a specific case study may have observed quantitative values.