The IT Skeptic - Comments for "ITIL Change Management: where is the line between a change and an admin task?"

Well articulated

Sid — Thu, 03 Feb 2011 02:52:02 +0000

Very well articulated Rob. IMHO change management is one process which if implemented well, can bring down (not eliminate) the number of unplanned incidents. One it is implanted in the techie brains, it at least makes us think twice before clicking that "OK" button. However robust a change management process is, wee admin changes do happen, because it is difficult to implement audit trail for every bit of IT (Core Infrastructure, Applications, End user devices etc.).

I used to work for an organization where it was not allowed (and possible) to connect to $ shares on Windows servers (as one could accidently delete a file on a mapped drive on a server), admins could only connect via PCAnywhere to a Windows NT server because it would record the session of an admin. Security Audit logs were not accessible to Sysadmins and many more. Believe me, unplanned outages due to unintended changes were unheard of. I attribute it to two factors - tight controls and fear factor. ITIL wasn't as widely known then. Every change involved at least two pe

There is a fine line between admin tasks and change, and you have rightly said, that anything that needs a change audit trail is a change.

Standard Change Continuum

CaryKing — Wed, 02 Feb 2011 15:56:39 +0000

It seems to me at this time that the idea of the standard change is somewhat more appealing here.

As you say, work can, and should, be managed with dispatching and routing.

Additionally, work can be organized around standardized around service request and fulfillment offerings with work breakdown structures and bills of materials with the different activities assigned to different individuals and actual time captured.

Work breakdown structures are needed so that responsible individuals for each activity is known and performance monitored.

The constituent bills of materials can be driven from an Infrastructure Management Catalog that is closely associated with Asset Management and is the result of IT Governance activities - particularly Enterprise Architecture Infrastructure.

Service Request and Fulfillment activities can be designed around Lean and DMAIC TQM techniques; can be standardized; and, can be designed to look like external competition. One can do Time-Driven Activity-Based Costing to capture actual times. One can do Activity-Based, or Service-Based Budgeting to develop the services breakdown and prices - and let the rest of the business, our customers, tell us what their demand for these services will be.

It seems to me that changes to these standard activities can, and should, be under Change Management control.

Changes to the infrastructure need to be noted so that both Configuration and Asset Management data is kept current. Closed loop confirmation of changes need to be validated.

Manufacturing and field service organizations have followed these fundamental procedures for decades. ITIL, sort of, refers to them, but has these ideas spread out across the rather disjointed guidance.

Consider that each group with your IT organization can be seen as its own entrepreneurial mini-business unit. Each can, and quite likely should, offer its own products and services to be competitive with services offered by external service providers. The IT "service" then can buy the services of these internal business units, or, if they cannot provide similar services at a price competitive to external service providers then a make / buy decision is coming.

At every step IT must consider developing transparent processes and costs. Each one of these mini-services need to be managed as a business within a business. Because, after all, the rest of the business, our customers, while they need to trust us, also have a right to verify that their money is being wisely spent by IT. Standardization and transparency of costs is the first major step to trust. Espeically since every day the rest of the business, our customers, are being directlymarketed to by any number of outsourcers to take their business from us.

Cary King

Changes vs. work orders

Charles T. Betz — Sat, 29 Jan 2011 03:23:38 +0000

I consider an "admin task" (aka a work order) to be equivalent to a service request. They are distinct from changes as they involve the service catalog and the dispatching, routing, and performance questions that may not be well handled in the Change Management system. Some change management systems have a separate capability for work orders. But in general, risk and approval can be decoupled from execution.

One Change may have zero or more Service Requests. Service Requests that pose certain levels of risk may require a governing Change. Sometimes, volume is the determinant - 1 workstation upgrade is a Service Request, 100 must also have an approved Change.

Basically it's this:

Change >0---0< Service Request (aka work order/admin task)

Charles T. Betz
http://www.erp4it.com