Some thoughts that have been bubbling for a while, as I dig deeper into the discipline of Business Process Management (BPM) -
Many of the ITIL practice areas (in particular those in Service Delivery) do not appear to be processes in the strict business process management sense. Change, Release, Incident and Problem management all are true business processes: they are repeatable, measurable, start with a defined event, and have a clear value-add end state.
This may be heretical, but I am starting to view Configuration, Availability, Capacity, Financial, and now Operations Management as functions...
They are steady state capabilities with no defined beginning or end, often owned by organizations tending towards silos, which Change, Release, Incident and Problem cross. Their staffing is specialized, as are their tools, which are not generally shared with other areas (unlike Change, Release, Incident, and Problem, whose tools have cross-functional user bases). If this seems radical, ask the question: What is an Incident? Do I know when one is identified, its lifecycle, and when it ends? Are the activities measurable and repeatable? Then it is a true business process. Now ask yourself, What is an Availability? What is a Capacity? And so forth. Configuration Management is a bit of a special case, but I see it still as more function than process; even though it does fundamentally support many areas, that contact generally is realized through one of the true processes, and certainly it requires a deep center of excellence organizational model to do right. Core BPM principles can be found in Geary Rummler and Alan Brache's Improving Performance, perhaps the classic statement of the business process management movement. Other influential BPM authors align with Rummler & Brache on these distinctions, e.g. Paul Harmon (www.bptrends.com), Alec Sharp, and Roger Burlton. We debated process, function, and organization on the Yahoo! dm-discuss list some weeks back (groups.yahoo.com/group/dm-discuss, "function and process" thread, 9/10/2005-9/28/2005) and the final consensus there was also the same. I think one outcome of the whole process management movement, starting with Michael Hammer, is that people are thinking "function bad, process good" and therefore want to call EVERYTHING a process, without being rigorous about what that exactly means. A purely process orientation presents its own set of challenges; reality is a messy matrix. I can't imagine that these questions haven't been debated in the ITIL/ITSM world previously, but I haven't seen any discussions, and I'm concerned that there is a disconnect between ITIL/ITSM and the BPM movement. Thoughts anyone? -Charlie PS. One thing that would help is adopting the principle that (at least in the English language) processes start with active verbs, and functions are passive verb-based nouns: e.g. “Resolve Incidents” or “Execute Changes” versus “Capacity Management” and “Availability Management.” BPM author Alec Sharp frowns on using vague verbs like “manage,” “coordinate,” and “analyze,” favoring concrete verbs such as “resolve,” “execute,” and “complete.” I know when I have “resolved” an incident, but I have no idea when I’m done “managing” something. PPS. An issue the BPM community is still debating is the concept of “process area” which is a grouping of cross-functional processes. The classic example of this is CRM. See again Alex Sharp’s book.
