Analysis of Planning of Business

Planning is a vital part of any large endeavor. Many managers spend most of their time developing and tracking plans. This section provides some basic patterns for planning. The patterns describe individual plans as well as protocols - standard procedures that can be used repeatedly.

Any action carried out within a domain can be recorded. The Proposed and Implemented Action (Section 1) pattern divides the possible states of an action into two key sub-types, which represent the intention and what actually happens. The end of an action is similarly divided into Completed and Abandoned Actions (Section 2). An abandoned action represents a final cancellation of the action, and temporary holds on an action are represented by Suspension (Section 3).

A Plan (Section 4) is used to hold a group of proposed actions. We discuss structures of plans that record the dependency and sequencing of a group of actions while allowing a single action to appear in several plans. The latter property is essential to choreographing multiple plans, which are one-off arrangements. A Protocol (Section 5) is used for standard plans that are repeated many times.

Carrying out an action requires resources. The Resource Allocation (Section 6) pattern describes protocols for proposed and implemented actions. We consider two different kinds of resources: consumables, which are used by actions, and assets, which are used over time.

So far our discussion of plans has focused on planning and monitoring actions and has ignored the effects of the actions. The final pattern we discuss handles Outcome and Start Functions (Section 7), which tie the patterns in this section with the observation and measurement patterns developed in Analysis of Clinical Observations..
These functions allow us to say what we think an action has achieved (outcome), what a protocol should achieve (outcome function), and what conditions make us want to begin a protocol (start function).

Planning is a complex area, and the patterns in this section, even more than other sections, are not intended to be complete. The patterns came out of the Clinical Process Model, and its constructions are thus decidedly bent in directions that support health care planning. The resource side comes from unpublished discussions with the developers and users, and the influence of the Common Basic Specification.

Key Concepts: Proposed Action, Implemented Action, Plan, Suspension, Resource Allocation, Asset, Consumable, Temporal Resource,
Start Function, Outcome Function

1. Proposed and Implemented Action

The basis of any plan consists of the fundamental actions that people take. It is difficult to give any more than an outline description of what makes up an action. A plan can be coarse, consisting of large actions, or it can be fine grained, consisting of small actions. Actions can have a range of properties, based on who, when, and where. With such coarse-grained properties it is difficult to provide more than the most generic terms of party, time reference, and location, as shown in Figure 1.


Figure 1. Properties of actions.

When making and monitoring plans, we must consider the many states that an action can go through. It can be scheduled, resourced, peopled, started, and completed. A state-transition diagram can record these states and how the transitions can occur. It is difficult to make any rules about these transitions. Scheduling an action and resourcing it can clearly happen in any order. A surface analysis may conclude that an action cannot be started before resourcing and scheduling. How do we deal with actions that are started before any formal decision is made to state a time for them? We could argue that such actions are scheduled a moment before they are started, but this sounds more like a management theory rationalization than a reflection of the real business process. Another problem arises with partial resourcing.
Any project manager will tell you that in the real world, tasks are often begun before all the required resources are allocated. How can we reflect this situation in descriptions of action states?

The two important states of action are proposed and implemented actions, as shown in Figure 2. A proposed action is purely a proposal that exists in some plan. As such it can be scheduled by adding a time reference, resourced by adding parties, and located with the appropriate location. These changes can be made at any time, in any order. Once an action is begun, it is implemented. Not only is this a change in state, but also a separate implemented action object is created. This allows us to record differences between plan and implementation. By retaining the original proposed action, we can see the differences between the plan and reality. A common difference, for example, is the time reference; however, any attribute can change as planning documents finally turn into actions.


Figure 2. Basic structure of plans and actions.

Separate objects record the proposal and the implementation so that differences can be tracked.

Example: we decide to prepare a presentation for OOPSLA on July 1, 1997, but we don't get around to doing it until the 3rd. These actions can be represented as a proposed action with a date of July 1 and an implemented action with a date of July 3. All other attributes of the proposal are the same.

We can provide a derived action state property to make it easier to tell what state an action is in without navigating the various structures that record its state. This is not really necessary at this stage but becomes valuable as we consider additional structures later.

To retain the best degree of flexibility in recording daily actions, the links between proposed action and implemented action, as shown in Figure 2, are optional. Often the best laid plans gather dust without implementation, and many actions occur without any prior planning. We should resist the temptation to rationalize last-minute plans.

Example: Doctor Jones orders a full blood count for John Smith, but the patient does not turn up for the test. This represents a proposed action without an implemented action. If the patient is rebooked for a later date, this constitutes a new proposed action.

Example: Doctor Cairns is called to attend a woman who is taken suddenly ill on a train. Here there is an implemented action but no proposed action.

2. Completed and Abandoned Actions

So far we have considered how actions are proposed and begin but not how they might end. Clearly actions either succeed or fail. The problem is that often we cannot determine success or failure with any certainty, especially in health care. Thus in this section we consider only two ending actions: completion and abandonment. Completion occurs when the action is carried out according to plan. Any consideration of the success or failure is left to further analysis (see Section 7). This definition can be too strict for domains other than health care, where success is more easily judged. The distinction between carrying out an action as expected and the action achieving its goal is still valuable.


Figure 3. Completed and abandoned actions.

Abandonment is a complete and final cessation of the action. It can occur either before or after beginning to implement the action. Abandoning a proposed action is deciding not to begin it at all.

Example: A renal transplant provides renal function by replacing a damaged kidney with a donated working kidney. The renal transplant action is judged a success if the kidney is safely transplanted into the recipient. If the kidney is rejected later, this does not invalidate the success of the transplant procedure. The transplant procedure is still completed; it would be abandoned only if a problem occurs during the operation.

Example: we chose to fly from London to Boston, expecting to arrive in Boston at 2:00 p.m. The flight is delayed, so we did not arrive until 7:00 p.m. This action was still completed, because we arrived in Boston that day. The delay we suffered meant that it was not a success. The proposed action to go to dinner that evening, however, was abandoned.

Example: Our car would not start, and we determined the problem was a faulty starter motor. we thus proposed and began to replace the starter motor. Just after beginning we found that the fault was actually a bad connection, and the starter motor was fine. we thus abandoned the action of replacing the starter motor, although we was not unhappy with the result!

3. Suspension

We can also put off actions, with the intention of continuing them later. When this occurs a suspension is linked to the action, as shown in Figure 4.
The suspension is valid within its time period (which might be open ended). If an action continues after the end point of the suspension, the suspension still exists but is no longer suspending, and the action continues.


Figure 4. Suspension of actions.
A suspension is a temporary hold on an action.

Thus an action is suspended if it has currently open suspension. Both proposed and implemented actions can be suspended; suspending a proposed action is equivalent to postponing the start of an action.

Example: A patient is on the waiting list for a renal transplant. This is represented by a proposed action of renal transplant. The patient has to wait for a kidney to become available. If the patient develops a cold while on the waiting list, the doctor must place a suspension on the patient. The transplant is not abandoned because the patient goes back on the waiting list when the cold abates. The record of the suspension is essential to explain why the doctor did not give a suitable kidney to the patient during that time.

Example: we have a proposed action to wash the dishes. It is frequently suspended for long periods, but we never quite abandon it!

4. Plan

In its simplest sense a plan is a collection of proposed actions linked in some sequence. A sequence can be expressed in a number of ways, but most commonly it is expressed as a dependency—an indication that one action cannot begin until another completes. Plans are often described by using a dependency diagram, as in critical path analysis.

Figure 5 is a diagram of a dependency relationship between proposed actions. This structure is useful when the actions are always proposed as part of a single plan. In many situations, however, plans interact. When a doctor sets up a treatment plan for a patient, actions within that treatment plan are used by the nurses in setting up their nursing plans. It is not unusual for many caregivers to have plans for a patient, and it is important that these plans be properly choreographed. The structure shown in Figure 6 supports interaction by allowing an action to be referenced within multiple plans and for the dependencies to be drawn up between the references rather than between the actions.


Figure 5. Dependencies between proposed actions.
This will only allow actions to be proposed within one plan, making it difficult to coordinate plans.

Example: A doctor needs a full blood count for a patient. She checks the list of proposed actions and finds that another doctor has already proposed a full blood count as part of his plan. This is represented as the other doctor's plan having an action reference to the full blood count proposed action. A new plan can be created with a new action reference to the same proposed action.


Figure 6. A plan consisting of references to proposed actions. This structure allows actions to be referenced by several plans.

Example: we need to visit the liquor store to get some St. Emillion for a dinner on Saturday and Old Peculiar for a party on Sunday. The action of visiting the liquor store is referenced in both the plan for preparing for the dinner and the plan for the party. The dinner preparation's reference has a dependency where attending the dinner is the consequent and visiting the liquor store is the dependent. The party plan's reference has a dependency where beginning the party is the consequent and the visit to the liquor store is the dependent.

This notion of an action and a reference to an action within behavioral description is a common pattern in behavioral modeling. It is analogous to the definition of a subroutine and its call within another subroutine. The definition of the subroutine contains no information on how it is used within a calling program. The calling program has no knowledge of the contents of the subroutine.

The model in Figure 6 is a simple behavioral meta-model. A plan is a description of intended behavior, thus a behavioral modeling technique is
appropriate. We can use any behavioral modeling technique. First we represent the technique by its meta-model. Then we tie the actions of the meta-model to the plan object and to the proposed actions. We should choose a behavioral model that is sophisticated without being overly complex.

Plans are always subject to change and can be replaced by other plans, as shown in Figure 7. The association is multivalued in both directions - as plans change, a single plan can be split up and replaced by separate plans, or several plans can be consolidated into one.


Figure 7. Replacement plans.

Example: we have a plan to buy bread at the Garden of Eden and cheese at Bread and Circus. We replace this by a plan to get a take-away from Jae's instead.

We can consider a plan to be a sub-type of an action, as shown in Figure 8. Thus we can propose a plan (that is, we can plan for a plan) and monitor a plan to see if it is finished. Since planning is often quite complex, it is valuable to be able to schedule and track a plan's progress.


Figure 8. Plans as actions and compound actions.
We can plan to plan, and we can have complex actions without an explicit plan.

We can think of a plan as a way of aggregating actions. For example, a full blood count can be represented as a plan, with each component measurement as a proposed action within it. This is a very heavy-handed representation, however. The structure shown in Figure 8 also allows an action to be decomposed into component actions, but it allows two ways to represent actions being part of a larger action: Using the parent-component association works well for simple cases, and using a plan works well for more complex cases. We can restrict the parent-component association to a hierarchy so only the parent-component association is used for simple cases.


5. Protocol

An organization's standard operating procedures are common actions carried out many times in much the same way each time. We can describe these common actions, referred to here as protocols, using constructs similar to those we used for plans, as shown in Figure 9. Planning patterns, like other patterns in this book, can be divided into knowledge and operational levels. The operational levels describe the day-to-day plans and actions. At the knowledge level are protocols, which describe the standard procedures that guide the operational level.


Figure 9. Structure for protocols.
It is a similar structure as the one for plans - a simple behavioral meta-model.


There are some interesting differences between the knowledge and operational levels in the structure. Using a hierarchic structure is much less useful at the knowledge level. Protocol can be referenced by many other protocols; it is hard to think of a case where restricting it would be useful. We can often effectively represent an action as part of another action in cases where we want to aggregate actions in a regular manner, such as the measurement as part of a full blood count.

There is no difference at the knowledge level between proposed and implemented actions, nor is there a valuable distinction between a plan and another group of actions. The components of a protocol are always a bag (since a protocol can be performed more than once within another), but the proposed actions of a plan always form a set (since you cannot do the same action twice, but you can have two actions with the same protocol).

A protocol need not be detailed with components. A protocol can be merely a name. It can be descriptions, textbook pages, Web pages, even a video of someone performing a particularly tricky surgical procedure. Protocol references can just describe components without any dependencies. Some protocols can be entirely coded into a computer, in which case they become a piece of software. (A software protocol is a protocol that is coded in software, not a protocol in the sense of a communications protocol.)

We can form actions from a complex protocol in two ways. The simplest way is to use the parent-component association. This technique works well when the component actions all take place in a well-bounded time period, and no one wants to share the component actions. We first create a proposed action for the whole protocol and only indicate the component actions if we have to specify particular properties, such as timing or resources. (If there are a lot of these particular properties, then we should use a plan.) If all actions are done by the same party at about the same time, the parent action is enough. A component action is created for each component protocol's reference; that is, a protocol carried out three times within a parent protocol would yield three component actions; any dependencies would exist exactly as in the protocol.

A plan offers greater flexibility and precision of tracking and thus is preferred when we want to monitor when and how individual protocol steps are carried out. These relationships are shown in Figure 10. In addition, a plan allows the component proposed actions to be picked up and shared with other plans. An important feature of plans is that, while they can copy the dependencies of the protocol, plans can also define new dependencies that might ignore that of the protocol. This ability is important in skilled professions such as health care, where we often have to override protocols to take into account the needs of individual patients. Frequently we need one-off plans, which are based on protocols but are not faithful copies.

Forming actions from a protocol will typically use plans at higher levels of the protocol, and use the parent-component association at lower levels.

5.1 Plans and Protocols as Graphs
We can also represent a plan as a directed acyclic graph (DAG) of proposed actions. The arcs on the graph correspond to the dependency relationships on the action references. Each plan has its own separate graph structure. We can represent this compactly as shown in Figure 11. This is, in essence, another association pattern.

To apply this notion to a protocol, however, we do not form a DAG of the subsidiary protocols. Instead we form a DAG of the protocol references, as shown in Figure 12, because one protocol can appear as more than one step in another parent protocol. This is specifically not the case for a plan due to the uniqueness constraint shown in Figure 6.


Figure 10. Relationships among action, plan, and protocol.


Figure 11. Plan as a directed acyclic graph of proposed actions.

The base form for a DAG association pattern thus includes the dependency types (with the constraint) together with the fact that the element in the DAG can only appear as one node in a DAG.


Figure 12. Protocol using a DAG.

If we use a graph for the plan structure we lose the ability to build the association between the plan reference and the protocol reference that is shown in Figure 10. Naturally we could still have the DAG version as a derived mapping; the derivation would include how to derive the graph's arcs.


6. Resource Allocation

The second major part of planning is allocating resources. A primary difference between proposed and implemented actions lies in how they use resources. An implemented action will actually use resources allocated to it. A proposed action will book some resources. Figure 13 shows resource allocation as a quantity of some resource type. Resources can only be booked by one action and used by one action.


Figure 13. Action's use of resources.
Proposed actions book resources, and implemented actions use resources.

There are various kinds of resources. The first and most obvious is a consumable. Consumables are such things as drugs, needles, and raw materials. Consumables can be used only once and are used up by the action that uses them. Typically consumables are asked for by quantity.

Example: A resource allocation of 10 gallons of orange juice has a quantity of 10 gallons and resource type of orange juice.

Example: For a particular hip replacement operation, four units of packed red cells (blood) are booked, but only two are used. This can be represented by two resource allocations of the resource type packed red cells. One is linked to the proposed hip replacement with
quantity four units; the other is linked to the implemented hip replacement with quantity two units.

Some resources are not consumed, such as equipment, rooms, and people. In no sense is a person consumed by an action (although after writing this book I wonder). However, we can say that a person's time is used up. In this case the resource type is the person, and the quantity is time. Thus our spending five hours on an action is a resource allocation of five hours of us.

This is somewhat too individual a view of resource types. Resource types, which lie at the knowledge level, more typically indicate a kind of thing rather than the thing itself. Projects that we work on demand five hours of an experienced OO modeler rather than us in particular. Although some people are sufficiently singular to be resource types in their own right, most of us mortals are merely one of many.

In planning, therefore, the requirement is stated as "We need five hours of an OO modeler." At some stage in the planning process, this is resolved by booking five hours of us, a specific instance of the resource type. This implies two levels of resource allocation: a general one where only the type is specified and a specific allocation where the individual is specified.

In Figure 14 the individual is referred to as an asset. Assets are classified by asset type, which is just a kind of resource type.


Figure 14 Resource allocations for assets.
Specific allocations name the individual asset used or booked. General allocations only specify the type of asset.

The difference between a specific resource type and a general resource type is that the former links to the asset and the latter to a resource type, which for an asset would be an asset type. A temporal resource is a specific resource allocation of an asset. It can have not just an amount of time but also a specific time period. This period can be derived from the action that books or uses the temporal resource, or it can be separate.

Example: A modeling meeting is scheduled to be held in a small conference room for a couple of hours. Initially this is represented as a proposed action that books a general resource allocation. The resource type of the general resource allocation is the asset type small conference room. The quantity of the general resource allocation is two hours. At some later point the actual conference room is booked as Q9. This reclassifies (or replaces) the general resource allocation to a temporal resource of two hours of the asset Q9. If the proposed action of the meeting is booked between 2:00 and 5:00 p.m. on Tuesday, then that time period is the derived time period of the allocation of Q9. If the last hour of the meeting is to be held in the pub, then a time period of 2:00 to 4:00 p.m. on Tuesday is linked to the temporal resource.

The asset is allowed to have several asset types. This multiple classification of assets is important to represent those assets that can do several things, although not necessarily at once.

Example: If the conference room Q9 has projection facilities, it can be classified as both a small conference room and a presentation room.
It cannot be booked as both at the same time by separate actions.

Specific resource allocation is less important for consumables. For example, it is usually enough to say that 10 gallons of orange juice were booked and used by an action without being more specific about which 10 gallons. With assets we usually need to be specific because there is a greater likelihood for contention between parties about use of assets.

At this point it is worth considering whether the relationships from sub-types of the action shown in Figure 13 should be specialized. For example, it may be reasonable to say that implemented actions can only use specific resource allocations of assets. Assuming that this is something that is required (and I'm not sure that it is in general), there are several ways of doing it. This brings up a good example of how a business rule can be modeled in different ways.

The first, and most obvious, way is to introduce a structural constraint. In this case we can use a rule such as "Implemented actions cannot use general resource allocations whose resource type is an asset type." This eager checking is an aggressive way to enforce the business rule. It says that you are not allowed to record a situation that violates the policy.

This can be too strong a way to do things, however. Sometimes it makes sense to allow a situation that violates the policy to be recorded, and to have a separate checking phase later. This lazy checking can be done by having some operation on implemented action (such as isConsistentQ) and having that operation return true if the business rule is followed. This provides greater flexibility in handling situations where a full constraint might not be available from the beginning. The incomplete information is recorded, and a means for checking it is provided.

The great advantage of lazy checking is that it separates the resolution of the problem from the recording of the information. People recording the information can make their best attempt at the time, and then either they or a more qualified person can clear things up later. If matters can be resolved easily at the point of information capture, then eager checking is better.

Whether to allow general resource allocation of assets to implemented actions depends on the specific problem. If the needs of the domain are satisfied by knowing that it took two hours of an OO modeler without knowing which one, then general allocation of asset types should be allowed. This question may be dependent on the asset type. For example, hospital policy may dictate that all implemented allocations of consultants must be specific, although orderlies may be allocated generally.

We can use specific resource allocation with consumables if we are concerned with removing the consumable from some finite store that we have to track. In such cases we want to say that the consumable is taken from a particular holding of that consumable, as shown in Figure 15.


Figure 15 Allowing specific allocations of consumables.

Holdings can be organized in various ways, depending on the resource tracking process, which we are not considering here. However, it is worth saying that a holding can be seen as an account and a resource allocation as an entry, following the approach described in Analysis of Accounting>, Section 14.

Resource allocations can also be used by protocols to describe the resources needed for a protocol to be carried out. In this case we use general resource allocations.

Example: To make chapati (Indian bread) you need V4 cup of flour, V8 cup of water, V4 tablespoon of oil, and a pinch of salt. This can be represented as four general resource allocations.

7. Outcome and Start Functions
In this section we use concepts developed in section 3 to consider reasons why we form a plan and how we can gauge its success.

Plans are initiated by observations, which, of course, can be hypotheses or projections. Similarly their outcomes are observations linked to the actions within the plan, as shown in Figure 16. Like many aspects of observation, the outcome link is dependent on the eyes of the performer. Thus some parties may not see an observation as the outcome of an action while others would. We would record this situation by having more than one observation by different performers.


Figure 16. Links between observation, plan, and action.

Example: John Smith came to his doctor with the classic symptoms of diabetes: weight loss, thirst, and polyuria. The doctor creates a plan triggered by these observations. The plan includes a proposed action to carry out a blood glucose measurement.

Example: After experiencing poor sales, a company decides to improve the sales force's commission and to cut prices. Some analysts might say that the improved sales were the outcome of the increase in commission, others might say the improvement was the outcome of the cut in prices. Separate observations would be made by each group, with links to different actions.

Note that observations are a sub-type of actions. They can be scheduled, timed, have performers, and be parts of plans. Their additional behavior is that they identify an observation concept or measure a phenomenon type.

A similar set of linkages appears at the knowledge level using start functions and outcome functions, as shown in Figure 17. A start function contains information on conditions that are likely to trigger the use of a protocol. Following the example of associative functions, the model records the observation concepts and protocols used as arguments to the start function but does not specify how they are combined. The intention is for different kinds of start functions to have different methods for combining them.


Figure 17. The use of start and outcome functions at the knowledge level.

Start functions indicate the conditions for beginning an action, and outcome functions indicate the targets and side effects.

Example: The protocol add oil is indicated by a start function with an argument of low oil level.

Example: Beta-blockers are a treatment for hypertension and angina but should not be used if the patient has asthma. This leads to three start functions, all of which indicate beta-blocker treatment. (Beta-blocker treatment is a protocol with a resource allocation of the resource type beta-blocker.) Two start functions, one with the argument hypertension and one with the argument angina, have a simple body with no processing, which is a straightforward indication. The third has the argument asthma and is a body of logical negation. (We could have a centra-indication sub-type of start function, but it all really depends on the way the arguments are processed.)

Outcome functions operate similarly. Again the input is a combination of protocols and observation concepts. The result is two sets of observation concepts. Some observation concepts represent the target use of the protocol, that is, the effects that represent the purpose of the protocol.
The other observation concepts are the side effects. A protocol can have many results. This may reflect other protocols or observation concepts that the patient might have at that time. These are introduced as arguments inherited from the knowledge function.

Example: Decreasing prices have an outcome function with a target of increased market share and a side effect of reduced revenue per unit sold.

Example: The protocol liver transplant has an outcome function with a target of good liver function and side effects of organ rejection and
biliary stricture (narrowing of the bowel duct). The start function can also include information on the likelihoods of these conditions arising.
Separate outcome functions might exist with the same target and side effects but with arguments representing diseases that affect the procedure. These separate outcome functions indicate different likelihoods for the target and side effects due to presence of the disease arguments.