Each day is a game of fire-fighting in your world as a systems analyst or manager in your organisation's IT department. Whether it’s faulty hardware or monitoring that’s been shut off and failed to signal critical alerts, you spend day in, day out wondering if your organisation’s ad-hoc approach will ever improve. You know the potential that a well-managed IT environment can provide to your company, but for you the idea of a proactively managed system –where all the little fires are kept from happening in the first place, and you can spend your time instead envisioning and creating the future-seems like a pipedream.
We Need to Stop Fire-fighting:
What we need to do is to start thinking about our IT systems as a collection of services provided to the company, rather than discrete components of technology. What does this mean? A good example would be looking at the service of Messaging that we provide to colleagues at our companies, rather than focusing narrowly on individual components like health of your Exchange server or security patching which support the Messaging service. These things are obviously important, but they are meaningless if they don’t support a specific service of value to the company. People don’t care that our Exchange server is down or doesn’t have the latest security patching. They care that they can’t send off that time-sensitive email to a customer company exec who’s about to sign a killer sales deal.
Why it Matters:
When we start to think of what we do in the IT department as supporting a variety of business services, then we can start to a) be more efficient in how we manage and troubleshoot problems and b) start to make more sense to the non-technical leaders in our company, by using our services offered as a means to have conversations which shape the strategy and direction of the company overall.
A good first step is to listen to the wisdom of ITIL and start spending some time to create a Service Catalogue and a Service Map. By listing the services your IT department provides to the company, and then outlining all of the technological dependencies that make each service possible in the first place, you’ll immediately have greater visibility of what it is that you manage. Here’s an idea of what a Service Map might look like:
This, however, is a complex example of Messaging as a service. It might be easier to start by looking at it like this:
With the above example, we can see all of the puzzle pieces that come together and must function properly in order for your Messaging service to go uninterrupted. Using this example, you could start grouping help desk calls recieved based on Messaging (as a service) being affected and not just the particular technology/area with the error. We can start having conversations about where we are efficient with Messaging and where we could stand to improve and where we might need more help. By being able to gather data in a Services dashboard each week/month/quarter, we can start to have better conversations about what is working for the company, and what is not.
Think of all of the services your IT department provides to the company at large….Isn’t it time they start getting the visibility and proactive management they deserve? Isn't it time you stopped being a fire-fighter? Contact us to learn more about how Microsoft Premier Support can help you build the Service Catalogue and Service Mapping you need.
The links for Service Catalogue and Service Mapping are broken.
Hey there--thanks for letting me know. I've removed the links for now. If you'd like to see the data sheets associated with Service Catalogue and/or Service Design, send me an email to firstname.lastname@example.org and I'll forward them on. Cheers :)