Seven Empirical ITSM Truths


Published on

Sometimes, to prescribe something that works -- let's say, ITSM -- you include certain things to put in mainly because you've already seen what happens if you leave them out. This notebook is a list of several of those things. Think of it as risk management.

Published in: Business
1 Like
  • Hi Mark.
    Well, DevOps is about new stuff being produced. DevOps is a methodology that changes the way releases are done, in order to minimize the risks in refreshing the resource supply to align to business requirements.

    New stuff is vetted and intoduced at high frequency. It is made safe to do it through collaborative management...

    The business manager must prioritize demand; the IT Service Manager must prioritize provisioning options, and the infrastructure manager must prioritize operational support (not business support).

    A release coordinator aligns the priorities, as part of the methodology that is governed by the practice.

    The way that affects Dev's relationship to Ops is, in my view, very simple. Ops is Dev's client. Meanwhile, Business is Ops's client, This subverts the popularr proposition that Business is Dev's client -- but that's a good subversion in my view because Dev is not responsible for provision; Dev is responsible for supply. The supply responsibility is met in the requirements management process (which extends straight through QA), but the accountability for provision of the new resource belongs to the release coordinator. The release coordinator confirms availability of the new resource to the IT service manager. Meanwhile, Ops knows from QA that Ops can confirm the new stuff to the infrastructure manager.
    Are you sure you want to  Yes  No
    Your message goes here
  • Lots of insights here; Each one could be elaborated upon. I'm thinking specifically about the concept of 'Practices'; the relationship between operations and demand; the relatiionship between business manager and it service manager; and the relationship between ITSM and IT infrastructure management.

    I'd be interested in your thoughts on how all this affects the relationship between operations and development (DevOps), given the current interest in that relationship in the industry.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Seven Empirical ITSM Truths

  1. 1. Seven ITSM Truths Made Obvious over 10 Years by 4 ITSM Vendors and 25 Enterprises ©2013 Malcolm Ryder / archestra
  2. 2. Keywords 1. Compliance 2. Practice 3. Management 4. Customers 5. Infrastructure 6. Strategy 7. Change
  3. 3. There IS such a thing as ITIL compliance, but here is what that actually means. • Methods are a combination of ideas that drive decisions, and ideas about how to act on decisions. The sets of ideas can be prescribed as a package. The study of methods is “methodology”. • Methodologies are commonly stored as documents in a library. • An IT infrastructure library would be full of documentation of methodologies regarding IT infrastructure. • By consensus, multiple providers of methodologies can come to a consensus about what methods to recommend. • Recommendations that repeatedly find actual success in use become preferred and are accepted as good practical advice. • “Practices” apply sustained explicit attention to collections of actions compared against collections of recommendations. The comparisons provide awareness of the extent, duration and type of alignment that actions have to prescriptions believed to drive success. That is, the actuals-vs-recommendeds can be audited. • For the above to be meaningful, management actually has to establish a Practice-level of attention.
  4. 4. Many organizations try ITSM without a Practice to govern it. Oh well… • A Practice is a function of a management organization; it must be designed, learned and formalized. • The discipline of a Practice does not form intuitively or organically. Management actually has to establish a Practice-level of attention, and it will not exist unless it is literally incorporated in an organizational structure. • A Practice is an executive-level creation.
  5. 5. The point of Service Management is not Service, but Management. • Service management is not about what services to use. It is about how to manage services. • A service is a model of a relationship between an operation and a demand. The relationship between an operation and a demand exists whether or not it is managed; but the concept of a service is a model that is used to make the relationship manageable. • Whenever automation increases the ease of exposing operations to demand, unmanaged relationships are more likely to increase than to decrease. For that reason, part of managing automation is to proactively manage that relationship. • Good service management can improve services, but to improve service management, you have to improve management.
  6. 6. IT Service Management is not customer-centric; business management is customer-centric. • IT Service Management is service-centric. (!!) • IT Service managers are responsible for making services both the perspective and the point-of-view on the lifecycle of the relationship between operations and demand. • Business managers are responsible for making operations and demand conform as resources for meeting business requirements. Because of the impact of customers, business managers add, change and remove operations; business managers also add, change and remove demand. This affects operations and demand regardless of whether they are respectively good or bad, and whether they are service-managed or not.
  7. 7. IT Infrastructure management is bigger than IT service management. • Doing ITSM without doing IT architecture makes no sense, sooner or later, probably sooner. • Doing ITSM without doing IT investing makes no sense, sooner or later, probably sooner. • IT Strategy makes ITSM less likely to fail. • ITSM makes IT strategy more likely to succeed.
  8. 8. For most organizations, IT Service Management is not strategy, but it is strategic. • From an enterprise perspective, IT Service Management is fundamentally administrative, while IT management is back office. • The exception, of course, is for the business called “IT Service Provider”... where “service” management is the same as “product” management. • In general, without good administration, business can be quickly crippled by complexity. Therefore, while administration is not the same as strategy, administration is strategic. • An ITSM Practice is created and instituted accordingly.
  9. 9. For most organizations, change control is the decisive problem of ITSM • Change control is decisive to whether the organization pursues ITSM from an urgency (continuity) perspective or instead from an importance (agility) perspective. • The “urgency” approach relies on automating support processes asap, allowing a release of resources to the change control effort. ROI is easier, but smaller, and is based on cost recovery. • The “importance” approach is to start with change control to minimize the risks of taking on new demand. This relies on governing provision processes to prevent rogue activity. ROI is harder, but bigger, and is based on opportunity cost.