Untitled Document
According to a recent Forrester Research market update, Business Service Management
(BSM) initiatives are up by over one-third year-on-year, as more companies develop
strategic BSM deployment plans. This upswing in adoption may be attributable
to the fact that BSM provides benefits for both business users and IT teams.
But what are the critical success (and failure) factors when it comes to BSM
-- and how can we leverage these lessons learnt to ensure future success?
A successful BSM blueprint starts by defining the purpose behind the initiative
and establishing how to measure success against that objective. Typically, adopters
of BSM want to ensure quality of service (driven by IT) and the quality of end-user
experience (driven from the business side). Yet the largest hurdle to getting
started is not that organizations confuse quality of service and the end-user
experience; it's that organizations often focus on the end result rather than
the journey to success itself.
While it's important to understand the desired outcome, companies need to start
with something achievable. As with most corporate-wide initiatives, it is the
success achieved during the BSM journey which dictates the success and acceptance
of the end results. That journey need not be a long or complex one, and making
BSM a success needn't be confined to a purely BSM-focused IT initiative. While
the most successful BSM projects leverage existing people, process, and technology
and seek to change the mindset of IT throughout the organization, they do so
in a way that is driven by support and sponsorship from the lines of business.
As a first step, it's important for companies to realize that quality of service
(QoS) and end-user experience are not one and the same. Quality of service is
focused on availability, while end-user experience centers on whether the available
service is useable in the context of how the business actually operates. Getting
these definitions wrong can lead to the wrong kind of monitoring -- and the
wrong kind of monitoring sets up any BSM initiative to fail from the outset.
Monitoring everything is costly, time consuming and doesn't necessarily provide
the right information to the business or IT. For example, recognizing that a
hard-drive has failed in a disk-subsystem is good to know. But knowing that
the disk-drive is part of the subsystem and your data is safe because it is
part of a cluster is better; you can then prioritize the repair accordingly
and congratulate yourself on knowing those systems are still available. Better
still, knowing that the users' website transaction experience has slowed dramatically
because the back-end credit card payment service underpinned by the problem
hard-drive failed over to a server node with an incorrect software configuration,
is really what allows IT to be responsive.
-1-