In Part III(a), I mentioned that ITSM (the concept itself, not the OTRS module) really doesn’t make sense unless you think of your shop as a business unto itself. (I said that exactly, in fact. Now I’m just copying and pasting to fill space.) In that post, I focused on thinking of yourself as a business and managing your brand. In this post, I’ll talk about managing your shop’s brand and how ITSM helps you do that.
I’m going to continue with the assumption that you’re in the IT Department of a company, not running your own IT consulting firm. If you’re doing that, you probably know all this already.
A Generic Sketch of A Business
The idea of a business is pretty simple: in exchange for money, a business provides you with goods or services. But there’s a lot that’s implicit there. For example, if you give me a hamburger today, when do you want to be paid?
Probably before you give me the hamburger, right? And did I agree that the hamburger is acceptable if it is medium well and has pickles on it? Or for me to be willing to pay for it, does it need to be medium and have tomatoes and pickles? So let’s refine our definition of a business: In exchange for an agreed upon amount of money, a business provides goods or services that meet an agreed upon standard within an agreed upon amount of time.
In other words, every interaction with a business is a temporary partnership. In the case of buying a hamburger, it’s a pretty short partnership. In the case of purchasing a software license, it can be a long or even indefinite partnership.
IT As Partner
Your IT department provides valuable service to the business it is a part of as long as the work you do aligns with larger business goals. However, in most businesses I’ve been a part of, there’s no direct exchange of money for each service. I hear that large IT departments in big corporations do bill time back to the departments that utilize their services. If that’s not the case for your shop, though, your role as partner might be implicit–or it might be ignored. In fact, you might feel a lot like you’re just a team of go-fers. The business recognizes that it needs IT, but it really just needs a team to do its bidding. It is not offering IT a place at the table so much as keeping them around to pick up the table if it falls over. If you’ve ever been in a meeting where the first time you’ve heard about a new document management system is during the week that you’re being asked to help deploy it (and you didn’t just start working there that week), you’re probably in a shop where the CEO tells IT what he wants without asking IT what’s possible and reasonable.
If that’s all your business wants, ITSM probably can’t help much. It’s unlikely that your “partners” will have respect for the constraints that ITSM will put on your team and your customers. For ITSM to work, other departments must recognize that your expertise can help them be more successful. Password resets and installing new printers is one thing. Deploying new hardware company-wide or integrating new accounting software in the environment are jobs that need teams of experts with proper resources in order to succeed. If you are a partner, the VP of Finance will call you in to review processes and consult on what you can do to alleviate the problem before they tell you what to do. Note that they still get to tell you what to do, and it still might not be what you suggested, but they take your input as part of the decision-making process. In this case, though, you’ve been invited to hold a stake in the project and let your partner know what they can expect you to deliver.
How Does ITSM Help You Be a Better Business Partner?
Back in my first post on ITSM, I gave a brief introduction to some of the categories of IT Service Management. I’m now going to elaborate on how things like Change Management make you a better business partner.
You’ve probably heard the term “Asset Management.” I used it in Part I of this series. Some will argue that there’s a difference between “Configuration Management” and “Asset Management.” I agree with that, but to avoid a semantic argument, let’s say that Configuration Management includes Asset Management.
Assets are pretty important for a business. If I’m going to sell hamburgers, I’d better have some ground beef. If I’m going to provide electrical services, I’d better have the tools I need that are in working condition. You can see why this would be important for an IT shop. When a new employee starts, you’ll need to know if you have a laptop for them, that it has the latest image installed, that they have an AD username and password, etc.
If someone from HR calls you up and says, “I have a new employee starting on Monday, and I need a laptop for them,” and you say, “Gee… Uh… Okay… Um… I ‘ll have to check and see if we have any laptops…” You’ll have to check and see? That’s not going to be great for your brand. You’ll lose the trust of your partners–and eventually, if none of your partners trust you, they’ll look for ways to go around you. This can only make your life harder.
In addition to keeping track of all the pieces, you also want to keep track of dependencies. It’s not enough to have a motherboard if you don’t have a case to put it in or RAM to accompany it. It’s no use having a server if you don’t have Cat 5 cable on hand. And then there’s the stream of software dependencies when you’re installing something new…
Now imagine that you know exactly how many printers you have, but you don’t know where they are in the building, whether they’re all operating properly, or what their makes and models are. Eventually this will come back to bite your business in the rear. Ideally, you’ll have a database somewhere that contains all of this information. If you can pull up information on what equipment you have and key information about it at any time, that’s going to be great for your brand. Your partners will know that you’re on top of your game and will gain respect for your authority in your domain.
OTRS::ITSM provides a Configuration Management Database.
What do your partners do when they have a problem with your product? How will you record interactions? How will you resolve them and make the resolution repeatable if the event comes up again?
You need some policies and processes in place for dealing with service and purchase requests, complaints, and system alerts. If you don’t have them, you’ll become a firefighter. Every time a customer calls in or raises a red flag, you’ll either have to respond immediately or ignore it, letting it get lost in the shuffle (or maybe exploding not too far down the line). If you want your brand to have the highest possible value, you’ll establish clear policies on how you expect your partners to alert you to their needs and how you expect your team to respond to those alerts.
Of course, if you’re looking into OTRS::ITSM, you know that OTRS already includes pretty much everything you need for incident management in its ticketing system. It’s not the only possible use for the ticketing system, but it’s probably what you’re using it for.
We’ve all had one of those “Oh, crud!” moments when we realize we just executed that SQL query on a production server. “Did I make a backup before I did that? Do I know how to restore the backup?” And while it’s bad enough that you’ve made the mistake, you might also be bringing heat down on your boss and any other number of people who interact with that system. This can impact your relationship with your partners as well as your personal brand and team morale.
There are basic things you should be tracking whenever you implement changes in your business, regardless of the scale. The larger the scale of the change, the more important it is to track these things, but it’s always appropriate to track them:
- What is changing?
- Why is it changing?
- Who requested the change?
- Who is responsible for the change?
- What will the change impact/what’s the overall scope?
- When will the change be complete?
- What is the rollback plan in case of issues/failure?
When will the change be initiated?
If you don’t answer all of these questions well before implementing a change, you may be reaching for your disaster recovery kit sooner rather than later. If there’s no agreement about who is responsible for a change, it might never happen. It definitely won’t happen on schedule. If there’s no schedule for initiation, it might end up interfering with other processes when someone just decides to roll it out. And if there’s no rollback plan, there’s no way to mitigate a worst-case scenario.In some cases, a few of those questions will be difficult to answer. “What will the change impact?” for example. Answering this question accurately requires having a detailed understanding of all the dependencies in your business. Your partners may resist waiting on answers to questions like “What’s the overall scope?” They may want to implement the new hiring system by the end of the month without much regard for the consequences. But as you provide transparency into your process and manage lots of successful implementations for your partners, they’ll trust you when you say that something is important and that following your established policies is what allows you to help them reach their goals.OTRS::ITSM to the rescue once again. All this data can be entered into the system and built into a workflow.
IT Service Management is involved. It requires a lot of documentation. It requires imposing constraints on how you do things. If you’re not required to implement it (and even if you are), there will be times when you’ll need a reminder of what is motivating the use of such an elaborate and sometimes cumbersome process. I’ve tried to show how ITSM, and OTRS::ITSM in particular, strengthen your ability to be a reliable, respected, and successful business partner. My motivation here has been the same as for OTRS: if you know how the system is intended to be used, figuring out how to use it is a lot simpler.
I’m not entirely sure where I’ll go next in exploring OTRS::ITSM. If the concepts I’ve explained make sense to you, then the official documentation is really your next step. Let me know if you have specific questions about implementing OTRS::ITSM. Otherwise, I’ll continue to look for gaps in the documentation that need fleshing out.
Love and kisses,