Catalogue yourselves as an Information Service Provider

User vs. IT Staff Making Service Requests

Hi Rob,

Addressing your statement "To be clear I'm talking about internal service providers, i.e. IT departments. Hence the concern of being outsourced."

My opinion in this area is that is inappropriate to attempt and create job security for yourself in any way other than to provide the best services at the lowest cost, even if you're an internal Service Provider. If an organization is good at what it does and is cost effective, then that organization will have its best chances of not being outsourced.

Executives look at Organizations and Services as being components of a portfolio they have to manage. There is only so much money to go around and fund everything an enterprise wants to achieve. When it comes down to it, outsourcing is a decision made because an organization is perceived to not provide the same "value" (a combination of deliverables, costs, quality, timeliness, etc.) as some external Service Provider that performs the same Services. Unless I'm misreading it, your original post appears to recommend not using a name that brings attention to your group so that you won't be outsourced. I know this is a tough thing for many professionals to hear but an enterprise has to run itself like a business and, in doing so, such an enterprise has to make judgement calls about what is or isn't valuable. Therefore, my position is that if a group doesn't provide quality services, in a timely manner, for justifiable costs, then maybe it should be outsourced in favor of another group that does, so that funds can be freed to achieve other things in other areas of the enterprise. If an organization is changing its name to not draw attention in an attempt to avoid being considered for outsourcing, I think that organization is inappropriately trying to create job security for itself, at the expense of the enterprise. This doesn't seem appropriate to me. I think the most effective way to avoid being outsourced is to simply be very good at what you do, at competitive prices.

Addressing your statement "I think a service catalogue should contain no more than "a few dozen" first-level services, else it becomes inaccessible to humans."

I want to agree with your statement and I agree that "simplicity" and "intuitiveness" make a Service Catalog usable and effective. However, the best and most effectively used Service Catalogs that I've seen and participated in have had many hundreds of standardized Service Categories and many thousands of standardized Service Requests. The way I've seen implementers handle your reference to "a few dozen first level services" was to create "contexts" or "groups" of Services. Depending on your role or the work you were performing, you would use the contexts associated with those roles or that work that would quickly lead you to the available Service Requests that could be invoked for those areas. However, there are many times that you need to go out of your role based context and do something else. In this case, you need to find a way to get to other Services offered throughout the enterprise, especially if you need a Business Service as opposed to an IT Service. In these cases, you need to be able to find a way to get that work done or who performs that type of work. Done correctly, I've seen the Service Catalog become the knowledge platform for how a business operates. You go to the Service Catalog, look things up by keyword and it points you to your options, throughout the enterprise. If you take all of the Services throughout an enterprise and put them into the Enterprise Service Catalog, it's never small. It's only when you create an intentional hierarchical set of categorizations (i.e. Service Taxonomy) that you start to get a smaller list to work with, at the highest levels of the Taxonomy. I've found that in some cases Service Taxonomies work and in others they don't. I think this has to do with the experience level and skills of those creating them as well as those of the people implementing the Service Catalog, itself. BTW, the best Service Catalogs I've ever seen have always been home-grown. Two of the best, believe it or not, were spreadsheet driven. In one case the spreadsheet was translated to a two-dimensional HTML table as a script and simply published to the enterprise Intranet with embedded links to all Organizations, Services, Service Request Templates, etc. In another, the spreadsheet was published as a hyper-link enabled two-dimensional table in a Microsoft Sharepoint List Structure. In both cases, people used the "Find" feature in their browser to highlight the key areas of interest in the table and, step through the highlighted keywords until they found the desired service, and simply click the links that led them to where they need to go (Request Forms for that Service, the Service Organizations' home pages, Service Contacts, SLAs, reference material, etc.).

Apologies if this sounds like marketing but the IF4IT is actually working on an open Service Management & Catalog Framework (the name of it is still TBD) that takes the above concepts and puts them into practice via a repeatable pattern that standardizes enterprise Service names and their representations, with the intent to decouple the Service names from the enterprise's organizational names (which can be custom to the enterprise). It's intended to be published in the next few months. Given that your blog's community have experience in these areas, maybe, with your help, we can find people to help review it and provide feedback, when it's ready. We all realize that no solution is perfect. However, through productive collaboration, there is always a way to help solutions evolve in a positive direction.

Always a pleasure.

My Best,

Frank
The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices