Embed Size (px)
DESCRIPTION
Adopting management processes is usually done under the motive of applying Best Practices. But management frameworks continue to frustrate adopters who are uncertain if the adoption effort is creating an improvement or just a difference. This discussion quickly surveys the path out of that uncertainty.
Citation preview
How Your ITIL Action Affects Your Business Process
An archestra notebook.
© 2013 Malcolm Ryder / archestra
Causality
Nothing is quite as attractive as the idea of Cause-and-Effect. In management arenas, causes are the currency, and effectiveness is the payout.
This is of course why the examination of causes and effects is relentless. Management wants to identify the possibles, the probable, and the actuals, in each case also identifying the desirable, the intended and the controllable.
For example, we can systematically catalog the ways that we refer to effects.
Systematically relating these things operationally is usually what we are thinking about when we think of having “practices”.
© 2013 Malcolm Ryder / archestra
Paving the Road with intentions
The idea of "practices" is naturally based in the context of management.
That is, the "practices" idea has value (distinction and significance) primarily because of the concern with cause-and-effect.
Without that concern, the things that get tied together under the umbrella of "practices" float off in various directions to different conversations such as "resources", "education", or "planning".
Those are interesting conversations, however, because they all address the need for preparation that enables activity to affect conditions in a designated way. They do not cause activity, but they precondition it.
Setups
Likewise, activity itself does not necessarily cause the effects that have been targeted.
We say "not necessarily" because sometimes activity only preconditions the possibility that the targeted effect will occur.
Our comfort with the distinction of "pre-requisites" is legitimate. History has already proved prerequisites to be distinct, in two ways:
• there are effects which did not occur because prerequisites were not addressed,
• and we have successfully provided prerequisites without any further progress occurring towards the goal.
Such proof tells us that identifying an actual cause requires precision. The precision starts with identifying the effect.
Looking for Cause
If we want to say that “water is boiling”, and we want to know the cause, it is necessary to ask why it is boiling.
The correct answers will be factors that are directly circumstantial.
That is, the circumstances of the boiling can be different from one time to another, so the correct answers about why it is boiling are actually explanations of why it is boiling this time.
Many different techniques are used to determine causes of specific effects. The important techniques show how a given circumstance and a given cause coincide with a specific effect.
As it turns out, for a given effect, some things are causes only under certain circumstances.
The distinction of Difference
When we decide that something is a "cause", we are normally also saying that if that thing was not involved the way it was, then the effect would not have occurred the way it did. In comparison, a missing prerequisite means that the effect could not have occurred the way it did. Precision looks into the way things occurred.
The following pattern elaborates on more precise identification as just described. The importance argued here is that a “cause” can be a set of conditions, and an “effect” can be a set of conditions.
PrerequisiteTrigger
ActionConstraint
OutputImpact
An occasion of a desired outcome, seen altogether as an effect
An occasion of a desired event, seen altogether as a cause
© 2013 Malcolm Ryder / archestra
Being Effective
“A business process or business method is a collection of related , structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.” - http://en.wikipedia.org/wiki/Business_process
Given that definition, we could say that the process is the cause and the product is the “business effect”. But if we take the position that “we need a business process”, then the occasion of having one in use is what we are attempting to generate, and our other activities are what should be affecting that occasion. Our affects will mainly create, direct or support the business process.
With those affects, we intend to achieve a number of process characteristics as effects. However, for production of those intended effects, there is an overlay of controls needed. As seen in ITIL, the controls are found in certain management processes. The true status of an effect is usually distinguished in prescriptions,
proposals, reports, etc. But the causes need to be determined as well.
Action Constraint Output Impact
An occasion of a desired outcomeAn occasion of a desired event
CREATE
DIRECT
SUPPORT
Responsiveness
Security
Resilience
Scalability
Functionality
Stability
Durability
Flexibility
Etc.Etc.
Management
One or more processes containing procedures
BUILD
CHANGE
RESOLVE
Etc. Etc.
Prerequisite Trigger
(1) Management processes provide patterns, policies and rules for procedures; and (2) executing the procedures results in events and conditions that “act” on (affect) the business process by (3) giving the business process certain characteristics (effects). A given management process can have multiple affects, and multiple management processes can co-operatively produce a single affect. In short: management processes have an affect that generates effects. Effects have business value.
① ② ③
Creates Directs Supports
Functionality
Responsiveness Task X2, Task Y1
Security Task X3 Task X3, Task Y2, Task Y3
Flexibility Task Y1, Task Y3
Scalability Task X1, Task X2, Task Y1
Durability
Stability Task X1, Task X3
Resilience Task X1, Task Y2 Task Y1
Etc.
Use Cases for Management ProcessesAffect on business process
BUILD
CHANGE
RESOLVE
Contributing management processes spawn tasks
Effects intended as characteristics of the business process
ITIL guidance will naturally be interpreted and applied circumstantially. Why? Most practitioners already acknowledge the indirect relationship between the procedural tasks in a management process and the behavior of a business process. Actual practices, however, frequently introduce complexities that are hard to anticipate and govern, because practices mix task-level activities from multiple processes. Because most resources are consumed and tracked at the task level, the ROI of management processes can be obscured by lack of being traced to business-level effects where value is defined.
Procedure X
Procedure Y
Procedure Z
Task Y1
Task Y2
Task Y3
© 2013 Malcolm Ryder / archestra
