Doug McClure has an insightful post where he describes the landscape most of us face when trying to implement a BSM solution.
"Let’s face it, here in North America most IT organizations are structured around functional silos of expertise. It’s not uncommon to see the Network Group, Windows Server Group, Unix Server Group, Mainframe Group, Application Group, Operations Group (NOC/OCC/ECC, etc), Tech Support/Help Desk, etc. "
I think it's widely accepted that the biggest obstacle in implementation of a BSM solution has not been the technology for quite some time. Yes the tools are not perfect and have a lot of problems, and need to be better, but the organizational issues are by far harder to overcome. The fundamental underlying problem has not changed, it is the specialized silos as described in Doug's post. In any project, the more parties involved harder it gets for the project to succeed. This faith is not unique to BSM. Other projects that require participation of multiple groups (silos) such as ITSM/ITIL projects also suffer in a similar way. Matrix organizations to facilitate collaboration help but have limited success.
So what to do? It will be interesting to see how people respond to Doug's post. (Ironically it seems like IT folks are less into the blog world than say dog owners but that's a subject for another post). In my experience, success of BSM (like other cross departmental projects) require strong support from the business. In my opinion business is the ultimate owner of the service and whoever will own the service (service manageer, etc.) needs to be part of the business, and act with full support of the business. One approach that works in some cases is to implement BSM for a couple of services instead of cross the board for all services. This is against some of the "principles" of BSM, and certainly introduces inefficiencies, yet it often is the less risky way to proceed.
Pick a service (or two) that has high visibility and critical to the business and implement BSM around the service. Typically highly visible/critical services have strong support from the business which comes with organizational support, budget, attention of management etc., all ingredients for the success of the cross departmental projects like BSM. This approach is in line with the evolution instead of revolution meme. It's hard (if possible) to get organizations to change, larger the change harder it gets. Involvement of the management and support from the business is essential for the success of the projects and it's much easier to get this support for a service that has high visibility in an organization. Couple of success stories go a long way to win over the cynics and lay the ground work for bigger changes later on.
I find introducing a new way of working is easier without labeling it with new terms. In the post-Dilbert world, new job titles, etc. only fuel the skepticism. It is safer to change things in a such a way that it is not even registered as a "change" by the people involved. Yet accomplishing this is easier to be said than done.
Looking forward to hear what people think. I hope that people will step up and comment on Doug's post. After all we're all living with this, and love to hear some good (and bad) news :)
