‘Business Service’ and ‘Technical Service’ are simply label types to be used in the appropriate context. The exact same ‘service’ (i.e. the exact same set of resources and capabilities) can be to one person a Business Service and to another person a Technical Service.
Although in practice you will have some different fields in the Business Service Catalogue compared to fields in the Technical Service Catalogue; in theory the only difference required is the value of one word in the service’s label or type (i.e. ‘Business’ or ‘Technical’). So the exact same service can appear in both the Business Service Catalogue and in the Technical Service Catalogue. Their respective entries may differ in presentation or enrichment suitable for the audiences of the respective catalogues.
If you decide to implement this in a database then you may decide to implement a service as a single record with a couple of check box fields to check ‘Business Service’, ‘Technical Service’ which then makes that service a candidate for the respective catalogue. In this implementation it is not difficult to see that there is one service, that can optionally appear in one or both catalogues. If you choose to implement the Business and Technical Service catalogues as separate tables in the database (or separate databases) then you could end up with 2 records per service and conclude that since these are separate and distinctive records (having different columns per catalogue type) that there must be two separate and distinctive services.
Both of these implementations are valid. Both models are valid i.e. in one Model there is one service that can be both Business and Technical and in the other model Business and Technical are separate service types. At the end of the day it is a choice. Or perhaps I should say ‘at the beginning of the day’ it is a choice, even if you are unaware that you have already made the choice!
(Matrix Reloaded 2003) :
Neo: Are you saying I have to choose whether Trinity lives or dies?
The Oracle: No, you’ve already made the choice. Now you have to understand it.
The question is the same as what is the difference between buying something and paying for something.
One can buy a product. You can not buy a service, but you can pay for it. You enjoy a service while your subscription is in play, but at the end of your contract the service stops and you own nothing as a result. You can buy a car or pay for a taxi ride.
Some times it is a point of view. Sky own a number of TV channels, to them they are products. But when you pay to have access to a channel you are paying for a service. It seems that a thing can be both a product and a service at the same time. This is true. But what it is to you depends on your relationship to the thing. Conceptually if you could buy it and perpetually own it then to you it is a product.
The concept gets a bit more tricky in a case like buy a TV vs. rent a TV. In both cases the TV is a product. But in the first case you buy the TV and in the second case you pay to use the TV. In the second case you are both paying for a service and using a product.
Be interesting to see if Ulster Bank do finally put their issues to bed today. When this all kicked off I was following Robert Peston’s (BBC) blog. Someone posted an article that was quickly taken down. If it were left there it might have caused a run on the banks involved. The gist of it was that the change didn’t ‘fail’ as such, it worked! But it uncovered a previously hidden ’error’ – a massive systemic hole in the finances. At the time I dismissed this as someone making mischief, but as the weeks went by I started wonder if there might actually be a conspiracy. Perhaps the real reason it’s taken so long to recover is that they have had to find ways to re-hide the hole? First pushing it from RBS to Netwest, then on to Ulster Bank. From Ulster Bank there is nowhere left to push it. Sounds like a plot for a novel / film (fiction – I hope!).
Some other articles for reference:
The Telegraph: Bank of England governor says FSA must investigate RBS glitch
The ITSM Review: The RBS Glitch – A Wake Up Call?
Computing.co.uk: EXCLUSIVE: Where NatWest / RBS may have gone wrong – by a former RBS IT manager
Robert Peston BBC: “Is outsourcing the cause of RBS debacle?”
UTV: “Ulster Bank full service resumed”
ITILExpert’s take: If the answer is yes to Robert Peston’s question “Is outsourcing the cause of RBS debacle?“, it would be too easy to conclude that outsourcing is bad. I disagree. Even if the plot were true – if you are in a big hole, the first thing to do is stop digging.
As you adequately put it, the problem is choice. From the Matrix Reloaded – 2003.
The Architect: The first Matrix was quite naturally perfect; it was a work of art, flawless, sublime. A triumph equalled only by its monumental failure… (sound like any ITIL programmes you’ve encountered?)
Neo: … Choice. The problem is choice.
The Architect: … While this answer functioned, it was obviously fundamentally flawed, thus creating the otherwise-contradictory systemic anomaly that if left unchecked might threaten the system itself. Ergo, those that refused the program, while a minority, if unchecked would constitute an escalating probability of disaster.
The Architect: … You are the eventuality of an anomaly, which despite my sincerest efforts I have been unable to eliminate from what is otherwise a harmony of mathematical precision. While it remains a burden assiduously avoided, it is not unexpected, and thus not beyond a measure of control, …
The problem with problem is that it exposes the choices. A failed disk brings the whole system down, who chose not to pay for or take the time to implement mirroring?
Solutions will always involve choices and no matter how good your systems are (ITIL, Six Sigma, CMMI etc.) choices will always lead to undesirable consequences.
The Merovingian: We are forever slaves to it. Our only hope, our only peace is to understand it, to understand the why… (not what the Merovingian meant, but hay-ho I’m writing this!).
ITILExpert’s take: Problem Management is the measure that controls the assiduously avoided, but not unexpected errors, which if left unchecked would constitute an escalating probability of disaster. The process exposes choices. Our challenge is to make it a learning experience rather than a witch-hunt.
Isn’t it the combination of the symptom and the workaround? E.g. you have a blue screen with Error #1234. We know that Error and we have a workaround – e.g. re-boot. Unfortunately we don’t yet know the root cause.
This is why I advocate early raising of the Known Error. The Known Error can be useful before one knows the root cause.
If your ITSM systems separates Problem and Known Error (implements them as separate ticket types), then my advice is to raise both at the same time. Use the Problem ticket to manage the Root Cause Analysis and use the Known Error to manage the work around. This is especially useful if the work around is being worked on by a different group to the one coordinating the RCA.
ITIL Expert’s take: Raise Known Errors early. They can be useful well before the actual root cause is known.
In order to scale, in whatever business, work must be shared. But with infinite possible combinations, where should you draw the demarcations? Luckily ITIL describes the combinations that in general have been shown to work well. Don’t go away thinking that ITIL is the only way, or even the ‘best’ way to arrange affairs in IT. If you run an insular IT shop (increasingly unlikely these days) i.e. high staff retention, low requirement volatility etc. then possibly some non-ITIL combination will work better.
ITILExpert’s take: ITIL is not an invention. ITIL is a description. Rather like discovering a useful complex compound. The chemical formula is not an invention it is a description. Once you have the description you can replicate it – and thus it scales.