A friend of mine just pointed me at this Wikipedia definition of BSM. Whilst I like some of the entry, I must admit that I'm not keen on the first couple of paragraphs, which seems to imply that BSM is a bunch of management tools you buy from one or more vendors.
As one of the people, who can actually claim to have been involved in the very early formulation of BSM (at BMC), can I please explain what we were trying to achieve and what I think BSM really is? It has grown and developed since then, but I think a few key points are getting lost in the plethora of tools.
- BSM is not a bunch of tools. You cannot buy it.
BSM is actually a mindset. Everything you do has to be from a business point of view. This is absolutely key. Once you get this, everything else flows on from here. Tools are pointless if you don't have the mindset and processes to exploit them.For instance if I walk into a motor manufacturer IT department and ask an employee what he/she does, the correct answer is I sell cars - not I monitor Oracle.Once you have this, then you look at things like ITIL and CoBIT to help you achieve your goals.
- You don't need all of ITIL - choose the bits you need
My big hang-up with ITIL is that it demands you learn its grammar and syntax and vocabulary. Sorry, I know why I need a CAB, but I couldn't care less what the initials actually stand for. Use ITIL as a means to achieve the first bullet, not as a gospel that has to be followed blindly.
- BSM is two-way
Everyone loves to talk about the business impact of a failed router or whatever, but that is only a small part of the story and an example of IT impact on the business.
What most people forget or ignore is the other way - the impact of business on IT. One of the definitions cited in the Wikipedia entry says that BSM is a
"strategy and an approach for linking key IT components to the goals of the business. It enables you to understand and predict how technology impacts the business and how business impacts the IT infrastructure."
I would actually say services rather than components, but I see too many people getting bogged down in the first half and forgetting the second. Actually you have to get the second half right before you can do the first. There is no way you can design an IT infrastructure if the business hasn't told you what their goals / budgets etc. are. I can design you a sub-second 24x7 system, but do you need it and can you afford it? It may be right for some business services , but not all etc.
- IT and business need to be co-joined.
If IT does not have a place on the board with equal or greater importance than other departments like manufacturing, sales etc. then get another job. BSM has no chance in a place like this, as IT will always play second fiddle.
However, this also means that IT people have to learn to not talk IT when they meet anyone from outside their department, and that business people have to say what they need rather than what they want.
- Don't run stuff in-house that should be outsourced
BSM is not about protecting IT - it's about running IT in the most efficient and effective manner possible for the business. For example, if you know nothing about networks, get someone else to run them for you.
- Make your contracts business based, not component
Any contracts you have with service providers, or you have with someone outside your organisation should be based on the delivery of that service, not on the availability of server no. 843, which is meaningless.
This raises some very interesting questions on who measure the service and reports on it and with what regularity? Are they measuring it from your point of view or theirs? I don't care if the service provider uses carrier pigeons if the service meets my requirements. I have no interest in how they do it, I just need to know that it will work and how they will respond when it breaks?
- Don't run something just because someone else does or you read it somewhere
Every business is different. Your company goals are different. Your strategy is different. (If not, then merge and save some money). Ergo, your IT will be different.
There are many more examples I could quote, but I hope you agree that everything flows from the first bullet. If not, or you think I'm totally wrong, please let me know.