Thursday, March 31, 2011
Practitioner Radio Episode 7 - The IT Service Catalog
Chris Dancy and I Explore The Concept and Practice of “The Service Catalog”
The Product Is Not The Totality of Your Service
- Jack Probst Visit
- ISO 20000
- Service Catalogue
- Pink11 Blogs around IT Services
- NewScale Software
- Touchpaper (LANDesk)
- Service Catalogue Classes
- How does TROY define a service
- The Service Catalogue is about the EXPERIENCE
- Service Catalogue is the Rosetta Stone between business and the IT
- What was the Rosetta Stone
- What Museum has the Rosetta Stone?
- The product is NOT the totality of the experience
- The service catalogue module
- When I hear you say service, I think of Microsoft “services”
- Where do you start with a Service Catalogue?
- Request Catalogue<> Service Catalogue
- Buy me Now….ACTIONABLE SERVICE CATALOG
- What question has scared Chris about Service Catalogue for YEARS?
- Service Owner
- Business Relationship Management Roll eg. Business Dev
- Demand Management
- Service Level Management Podcast
- The Service Catalogue is your MASTER SERVICE LEVEL AGREEMENT!
- Sears WISH Catalog
- When did RUSH shipping happen?
- Chris’s Birthday
- Troy’s Service Catalog Blogs
Chris’s & Troy’s Thoughts What Are Yours?
Troy’s Thunder Bolt Tip of The Day: “Everyone has a service Catalogue! Its Either a rather large Line Item on your Customers P&L or its some declared value description of the services your provide for the money provided each year. Which kind of catalogue do you have?”
To subscribe to Pink’s Podcasts on iTunes
Friday, March 11, 2011
Sausage and Standards the Practitioner Radio 6 Look at ISO 20000
Practitioner Radio Episode 6 (Special Edition With Jack Probst)
Join Chris, Jack and I as well look at ISO 20000 and the upcoming new release this Spring.
Jack Probst Rocks!
- Jack Probst
- Practitioner Radio Old Episodes
- ISO 20000
- Troy’s Blog
- Is it I-ES-OH or EYE-SO? / ISO/IEC 20000
- Sausage and Standards
- Standards Bodies
- How does someone become part of writing standards?
- Who takes a ISO 20000 class?
- Consulting or Auditing ISO 20000
- ISO Auditing
- Why do organizations want ISO 20000 auditing?
- Does ISO 20000 deliver substance and value?
- Designing Processes Fit for Purpose, start with ISO 20000
- Services, ISO 20000 and the Pink 11 Haze
- ISO 20000-2011 NOW DEFINES a Service!!!!
- Anatomy of a Service (Video Link)
- ISO 20000-2005 vs ISO 20000-2011 class differences
- Time to Make the Donuts
Chris’s, Jack’s & Troy’s Thoughts For The Day what are yours?
A well balanced, inclusive approach, according to certain standards and ideals, is essential for the proper governance of any country.
To subscribe to Pink’s Podasts on iTunes
Tuesday, March 08, 2011
Fit For Purpose ITSM Processes
A key principle of Lean thinking is that Over-engineered solutions are a form of waste (Muda). However, what if those solutions / management practices are so immature, and inconsistent that they place the organization at risk? Or do they? Actually: The Answer is that it depends on context!
The real trick of our trade is to find the Fit for purpose balance between formality and ad-hoc approach for to the ITSM processes required to manage the delivery of Services. The concept for this article has been spawned in part by research I am doing on a new model to address the question of establishing the business case for maturing IT management practices, and also, in part, by a friendly debate the IT Skeptic and I have had for years over the need for a Configuration Management Database (CMDB)
So, to start, let me declare an assumption that the readers of this article may not have considered before.
Assumption - 1: ITIL brings nothing intrinsically new to IT Management that we have not already been doing since the genesis of our industry.
The original OGC mandate for the internal improvement project that birthed ITIL was not about coming up with new things they had never done before, rather to find better ways for doing what they were already doing.
I frequently get asked by Sr. IT Leaders about the business value of adopting and spending money $$ on this ITIL thing; as if it is somehow new, or some foreign idea they are being asked to take on. In these cases I ask them if they already have strategy/portfolio processes, design and build solutions for their customers, have to move those solutions into production, and once there have to support ongoing operations while keeping an eye on improvement opportunities.
Of course, they always answer yes since this is what we have always done. Congratulations I say, your are already doing ITIL, or better yet, are in the business of IT Service Management (ITSM). The only new thing ITIL brings to the table is an external reference model that provides an opportunity to align their current practices, if desired, with an industry accepted definition of what those practices could/should look like and common terms used by other organizations. The reality is that while organizations already do the ITIL processes, the average maturity of those processes is somewhere from ad-hoc to loosely defined.
ITIL does not introduce new practices to the IT industry! It simply provides an evolved set of good practices for what we already do.
Not that there is anything wrong with having a process at an ad-hoc level of maturity. In fact, let me say right now that some processes have a higher degree of value when they are unique each time they are used.
Now to address the question of Configuration Management:
To Rob’s comments on My Article CMDB – Spruce Goose, Death Star Or Answer To World Peace?:
“All the other processes which Troy describes, “identification, control, status accounting, verification and audit”, are either provided by asset management tools, or are not required if we don’t build a CMDB.
When we set up Impact Analysis Reporting process, and test it and rehearse it, we may find levels of unacceptable error, or unacceptable delays in reporting a result. Or we might not. If we do, then once we’ve exhausted the improvements from optimising the procedure and the team of people doing it, then we should look at tools. Simple tools like spreadsheets, analytical reporting tools, data explorers and scrubbers etc… And if THEY don’t work, then maybe we can start building a business case for CMDB based on what we need out of Impact Analysis Reporting and can’t get when we do it with wetware (humans). If you are one of those 3-5% of sites, bummer. Good luck finding the funds….”
First, it has always been the accepted responsibility of IT to manage the IT assets/items under their control. Part of that management accountability is to keep track of where those items are and what they are connected to in relationship to their use and purpose. It just so happens that most organizations do so very poorly with an accuracy level that would make most IT Managers blush and look uncomfortable if you asked some tough questions. Why is that? Simply put it’s a back office type responsibility that is not very sexy, fun, or exciting for most people and the last thing we probably find time for. If this was not the case we would not have had to spend all that time and effort at Y2K to do inventory counts that were accurate for about 3 weeks max.
The reality is that they accuracy of our Inventory/ Asset Databases is more about discipline and culture then it will ever be about automation. Automation and discovery tools can help but there will always be items and attributes we will need to track manually. Just because you purchased the world’s best tracking tools does not mean you will solve your people challenges.
Rob’s article makes reference to an Asset Tool versus a CMDB as if they are two separate things. In my books these are not two separate data repositories but simply a level of data management. In general a goal of data management is that we avoid managing data about the same object (server/application) multiple times if possible. Rather than having one database / spreadsheet for inventory lists, another for financial asset data and yet another called a CMDB for “Impact Analysis Reporting” why not have a common place where we manage data at different levels a detail based on the need? For example desktops are managed as standalone records, other items include financial (asset) attributes and a subset of your items are managed at a relational / dependancy level. A CMDB is not just another tool for managing data poorly for the use of Change Management. It’s a concept of managing accurate relationships and dependencies between objects that are business critical enough to warrant the extra effort of data management.
The real question is to ask, What level of data management in your environment (by domain) is Fit For Purpose? Are you keeping too much information at a high a level of accuracy than is worth the effort? Or are you at the opposite point of the scale with close to nothing in the way of useful management information about your environment?
The fact is that there is no right answer that applies to all organizations! That is why I would like to introduce the following model called “Linking Process Maturity to the Product Lifecycle” based on a Harvard Business Review article by Robert Hayes and Steven Wheelwright.
Linking Process Maturity to the Product Lifecycle
Hayes and Wheelwright originally Intended this model to apply to a business / manufacturing type organization but I have taken the liberty to tune it for information management processes.
The base premise it that everything in life that produces some outcome is the result of a process. Ex: You have raw inventory which gets fed into a sequential or parallel set of steps to get something out you want at the end. This is true if you are building a car, washing dishes, designing an airplane or managing changes and incidents.
The next reality is that we don’t document all processes in a 3 ring binder with slick automation unless there is a darn good reason to do so. In fact, in some cases the processes that produce tailored and unique solutions are better left as flexible and un-regimented since the value of their outcomes is based on the very agile nature of the steps used.
To illustrate this concept I have developed the following visual:
Certain Processes / Outcomes require more of a craft approach while others demand Process formality, a high degree of standardization and minimized variance.
To assist with this concept Hayes and Wheelwright introduce the following Manufacturing Terms:
- Engineer To Order: Each time a customer has a request we apply unique specialist knowledge to develop tailored solutions based on one of a kind requirements. Think about Engineering or Application Development type processes. (perfect for low volume)
- Make To Order: looks at the concept of doing something consistently in a batch format. We will follow a common method for a certain process or IT system during the project lifecycle but the next project may use a totally different approach.
- Assemble To Order: We provide unique offers based on the assembly of pre-defined and approved components. Go to the service catalog and order a standard laptop but add options such as memory, disk drives or approved applications. (Balance between consistency and flexibility)
- Make To Stock: Due to cost, regulatory, risk drivers we have to ensure that every time the widget comes off the assembly line or the release is deployed it happens the same way to minimize variance. (necessary for high volume)
Now consider how you would apply ITSM processes to this model. As I declared earlier all IT shops already manage to deliver services, but the reality from our experience based on hundreds of assessments is that almost all IT Management processes are over on the far right of “Craftmanship”
The important question for Sr. IT Leadership is not about adopting ITIL/ITSM, but rather if it makes business sense for all current IT processes to continue, to stay at a “Craft” level or consistency, repeatability and cost?
The honest answer to that question is not only for IT to decide but ask yourself what your customer, the person /group who funds IT’s Service Model would expect.
In some instances like Strategy Generation, Portfolio, Demand, etc. perhaps all we need in the way of documentation is a fact sheet declaring what the goal of the process is, the key measures, who is involved and how to get access to it. In other areas the risk and cost of leaving Incident, Change, Release and Deployment Management as a Craft across multiple silos and suppliers is too great, and more investment is needed in defining and standardizing your practices.
So getting back to Rob’s question about the need for a CMDB, the answer for each organization is “It Depends” on what is “Fit For Purpose” for you. Do Excel spreadsheets of asset inventories managed to the accuracy needs of individual IT departments work for you? Or, do you need a higher standard of IT data and relationship accuracy to deliver on the service promises to your customer?
Only you can answer that question and it will change from year to year and from technology to service.
Whether you need a 3 ringed binder or a fact sheet, simple or complex tools will depend on your business justification for the investment!
Yes, Rob, we will definitely have to have that beer next year in Vegas at Pink12!
For additional thoughts on this concept check out the following article: Balancing Process Formality With Innovation “You need chaos in your soul to give birth to a dancing star”
Troy’s Thoughts What About Yours?
The great thing about being the only species that makes a distinction between right and wrong is that we can make up the rules for ourselves as we go along.—Douglas Adams and Mark Carwardine, Last Chance to See (1990)