Having problems with message search?
Charles,
I like the model you have created. I cannot tell you how
pleased I am to see this topic. I gave a presentation a few weeks ago on a
very similar topic at a local user group meeting. It is something I
have been working on for a number of years now. I have always felt that a
Process/Workflow model wasn¡Çt enough to define requirements as it defines the ¡Èverbs¡É
(activities) and not the ¡Ènouns¡É (classes, states, if you will).
I took the liberty to overlay some of my thoughts on your model;
·
Your diagram highlights one of the things in ITIL that has
bugged me(or in ones interpretation of ITIL) – that being Change Management
involvement in the service lifecycle prior to production. I think this is
where ITILv3 improved a bit over v2 ~ by breaking up Release Management into
two (technically four) process areas;
o Release
and Deployment (covered in v2 Release)
o Service
Validation & Testing (covered in v2 Release)
o Transition
Planning
o Evaluation
·
One way (not mentioned in ITIL) around this is different CAB
types (usually have different names);
o Planning
CAB – PCAB
o Technical
CAB – TCAB
o Deployment
CAB – DCAB
I have a presentation that I need to make some enhancements to, and
I am working on a whitepaper on how to go from strategy to execution, in an IT
Service Management context. All done using modeling and BPM tools that I
am familiar with. Using models you refer to in your book.
Many of these are part of the solution my company offers.
I want to avoid the shameless plug here but using BPM technology soup to nuts for
IT Service Management supports the ideas you have put forth for all of the ITIL
v3 processes (even including CSI).
JOHN M. CLARK
President | Managing Director
ICCM US, LLC
Main: +1 (800) 651-7408
Mobile: +1 (513) 673-2012
Fax: +1 (513) 453-4006
|
7577
Central Parke Blvd ¡ü
Suite 131 ¡ü Mason, Ohio 45040 |
NOTE: This internet e-mail is intended solely for the person
whom it is addressed. It may contain confidential
or privileged information. If you have received it in error
please notify us immediately by telephone and destroy the transmission.
PPlease consider the environment before printing this e-mail.
From:
erp4it@yahoogroups.com [mailto:erp4it@yahoogroups.com] On Behalf Of Charles
Betz
Sent: Saturday, November 22, 2008 1:58 PM
To: erp4it@yahoogroups.com
Subject: [erp4it] Entity lifecycles & ITSM process architecture
Entity
lifecycles & ITSM process architecture
Been working with my three-lifecycle model for a while now
(also here) and it is holding up in the lab so far.
(I have an ITSM laboratory called my day job, as an enterprise ITSM architect
for a large US bank.) Can't talk too much about that side of things but the
reader can assume I'm not going to keep blogging about dead ends.
The chevrons show the true processes. What do they have in
common? They all are conceptual entities as well, candidates for entity
lifecycle analysis. Furthermore it is interesting to consider the average
duration of their lifecycles:
Service: Years
Technology Product: Years
Asset: Years
Project (strict SDLC): Months
Release: Weeks
Change: Weeks
Service Request: Days
Incident: Hours
Problem: Days/Weeks (& more, but then it gateways back to
Project or even one of the big 3)
My belief is that a comprehensive process architecture - in the
rigorous sense, not the confused ITIL sense - could be derived by looking at
the state transitions of these entities as events and documenting the synch
points and dependencies.
What does this mean in terms of MRP? Dependencies seem like
another way of saying "buffer needed." Interesting...
An interesting question for another time: what is the
relationship between Program and Service? My understanding in the military
sense is that a Program might deliver Services. It's a highly mature concept
for domains where the assumption is everything, no matter how big, is
transitory - only the overall mission is permanent.
-ctb
Offline 
Send Email