OTRS ITSM Part III(b): Your Shop Is a Business


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.

Configuration Management

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.

Incident Management

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.

Change Management

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 initiated?

  • When will the change be complete?
  • What is the rollback plan in case of issues/failure?

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,



OTRS ITSM Part III(a): You’re a Business


ITSM really doesn’t make sense unless you think of your shop as a business unto itself. This is easy if you’re a consulting or services firm that does contract work. If you’re in the IT department of a company, you might be less inclined to think of your shop as a business or service center, which could mean that you’re in a very reactive shop that seems to shift focus at the whim of whatever VIP last touched base with your boss about what IT should be doing. For all your geeky powers and ability to ruin the entire business with 1 shell script, to a lot of folks outside of IT, you’re just another go-fer. So in the next couple posts I’m going to focus less on your geeky powers and more about having a business-minded approach to yourself and your department.

My Business Cred

I’m not an expert at business, but I’ve had a lot of exposure to running businesses. I’ve been part of a few start-ups; I have several entrepreneurs in my family; and my wife has shared with me pretty much everything she learned while getting her MBA. I’ve also had a lot of success employing the principles I’ll be writing about here, so at the very least I can verify that what I’m telling you has actually worked once.

You’re a Business

This is business 101 for everyone: You, yourself, are a business. Your name is your brand, and your face (or maybe your face tattoo or that weird fedora you always wear) is your logo. Your skill set and the benefits you can provide are definitely drivers of value, but your personality also plays a huge role. Yes, if you’re smart enough, strong enough, fast enough, or unique enough, you can get away with being a huge jerk and still be valuable. Pop culture is full of these figures. Most of the time, though, you can win a job not by being the most qualified candidate but by being the most desirable to work with. A company can teach job skills but generally doesn’t want to work on making you friendly or fun. So you have two major assets as a business: your job-related skills and experience, and your personality.

Managing Your Brand

You need to think about this. What gives your brand value? Are you the printer expert? Are you the ultimate OTRS guru? Are you the jack of all trades who can give the quick answer to any question and knows who to call for more advanced problems? Think about and outline what you offer and how well you’re selling that. If you don’t concentrate on what makes your brand strong, you’ll just be a random IT person. And if you’re a random IT person, you’re a “computer person.” And “computer people” aren’t always highly regarded. The reason is obvious: if you’re the printer expert, but the user’s problem is with their iPhone, to them it doesn’t matter that you can fix printers. You can’t help them with their immediate concern, and so you’re useless. And that’s what they’ll remember–and it will get reinforced every time they have a problem you can’t solve.

This isn’t fair to you, but how are you managing it?

Here are some rules I try to live by:

  • If you have no idea how to fix the problem, be honest.
    • “That’s not my area of expertise, but I’m going to run it by my team and do some research.”
  • Help the user understand the context of their problem and what you can actually do about it. This helps you build expectations correctly.
    • “Well, Sharon, it looks like this isn’t a printer issue. You’re actually not connected to the network at all. I’m going to try a couple basic troubleshooting steps with you, but if they don’t work I’m going to have to call in the big guns. I can help you with all your printer problems, but when it comes to networks, I’m about as much of an expert as Google allows me to be.” (Hey, look at that! Next time Sharon has a network issue, she either knows not to ask you for help, or she knows what level of expertise she’s getting.)
  • Don’t hand off–collaborate.
    • This doesn’t always happen because it can spread resources too thin, but no customer likes to be passed from agent to agent trying to get their problem resolved–explaining the problem over and over again. When possible, stay with the user until either the issue is resolved or your presence is a hindrance. This is a huge value add for your personal brand.


You might be wondering what any of this has to do with ITSM. “Great life advice, Tyler, but I really just need to know how to implement ITSM.” The next post will make clear how this discussion is relevant. Remember that my goal here is not so much to restate the technical details that are already available in the official documentation but to provide context for the implementation and the mentality that will help you design a successful setup.

Love and kisses,


OTRS ITSM Part II: Installation


There are only a couple of paragraphs on OTRS::ITSM installation, but it turns out that there are a couple of gotchas in that small a space. I’ll cover those here.

Scope of Application

  • Amazon EC2
  • RHEL 6.6
  • OTRS 4 (patch level 9)
  • OTRS::ITSM 4 (patch level 9)

Install OTRS

It may not be obvious, especially if you are new to OTRS, but OTRS::ITSM is not a stand-alone piece of software. It is a package (actually a set of packages) that you add to an existing instance of OTRS. So before you can install ITSM, you’ll need to have OTRS up and running. You can find information about how to install OTRS in the official manual. Then you can check out my posts on getting started with OTRS for your initial configuration. If you’ve already done all that, you’re ready to install ITSM.

It’s Not as Easy as It Looks (But It’s Still Easy)

The official documentation offers a couple options for downloading the necessary packages: either enter some specific text into the package manager (Admin->System Administrator->Package Manager), or download the packages manually from the FTP site. I didn’t have anywhere to enter the provided text on the Package Manager page and had to go with the option of downloading from the FTP site. Unfortunately, even though the manual is for ITSM 4, the link provided will take you to the packages for ITSM 3.3. To get the correct packages for ITSM 4, you need to visit ftp://ftp.otrs.org/pub/otrs/itsm/packages4/, which should look something like this:


From here, right-click the package you want (I just grabbed the latest version of each package), select “Save Link As…” (they’re XML files), and save it to somewhere you know you can find it in a minute. As the manual says, you need to install GeneralCatalog and ITSMCore first.

Note: When selecting packages, make sure you get the same version number for each package. In other words, if you get GeneralCatalog-4.0.9.opm, make sure you also get ITSMCore-4.0.9.opm.

Once you have the packages you need, just select them with the Browse button under “Actions” on the Package Manager page (top left), click the Install Package button, and follow any prompts or instructions. These prompts will usually let you know if there are prerequisites or if you’re trying to install an incompatible version.


Repeat these steps for the remaining packages on the FTP page. See? Easy.

Love and kisses,


OTRS ITSM Part I: What is ITSM?

[A couple of boring paragraphs about why I’m writing these posts. Skip to next set of brackets to ignore. :]

What seems like a long time ago now, I wrote a few posts on how to configure the online ticketing system OTRS. While it’s a great system with thorough documentation on how to install the system and configure it, I felt that there were some gaps in the official documentation. So I made some up and wrote a brief manual on the basics of getting started with OTRS, split up over three posts. To my surprise, those posts have brought a consistent stream of traffic to this blog ever since. I’ve received quite a few kind and encouraging comments, which I really appreciate.

In addition to those comments, I get questions. The question I get most consistently is this: Will you do a similar series on ITSM? I promised I would, but in the meantime I had changed jobs and was no longer working with OTRS on a daily basis. On top of that, I started going to school part time. So while I’ve had it on my to-do list to write these posts for well over a year, it took until now for me to work in the time to write them. But it’s finally happening. For those who have been waiting for these posts, thanks for coming back. Sorry for making you wait so long…

[Okay, on to the meat of the subject.]


This post will cover the basics of what ITSM is and why you would want to use it. It’s not meant to be a replacement for the official ITSM manual (which is really well done, btw), but since you were nice enough to stop by and see me here, I’m going to give you my take.

Scope of Application

I won’t be going into a lot of technical detail here, but just so you know where the starting point will be on the technical side, I’m now running OTRS 4, patch level 9 on an Amazon EC2 instance. The OS is RHEL 6.6, which means all the following should apply to CentOS, as well. I’ll be working with OTRS::ITSM 4, patch level 9.

IT Service Management

That should clear up what ITSM stands for. (If you don’t know what IT stands for, you’ve come to the wrong blog–the wrog, maybe.) But what is it?

The official documentation gives a brief reminder of ITIL and the standards that exist for IT best practices. If you’re in a shop that is or wants to be ITIL certified, you’ll be well versed in this. If you’re not part of one of those shops, you still probably want to employ industry best practices whenever possible. A big part of the appeal of OTRS is that it is (or at least claims to be) fully ITIL compliant–meaning it will help you enforce best practices. Being open-source and fully customizable means that you’re not bound by those practices and can implement your own strategies, but you’ll start with an ITIL compliant foundation.

“But Tyler,” you say, “I don’t know what ITIL is, and I’m pretty sure I don’t care. I just want to know that IT Service Management is.” Okay. Fine. From here on, I’m going to assume that if you’re looking into OTRS::ITSM, you’re already familiar with the OTRS ticketing system. If not, check out my series on that.

Incident Management

If you work in IT, there aren’t a lot of standard days at the office. That’s what attracts a lot of people to the work–the only constant is problem-solving. There’s always a problem. In the last few weeks, you’ve probably had to reinstall someone’s printer driver, reset a password or two, flushed some caches, imaged a couple machines, etc., etc.

If somebody asked you to write a job description for your position, it would either be incredibly long, or it would just say this:

  • Ideal candidate will know everything about computers and all peripheral technologies and be ready to fix every possible problem at a moment’s notice, likely under duress.

This is why you have a ticketing system like OTRS. Requests are constantly streaming in, and you need some way to organize and prioritize them. This is incident management, and it’s one part of ITSM. But wait… there’s more!

Asset Management

You may have a storage room somewhere that looks like this:

If you were lucky enough to be in that shop before anybody started thinking about asset management, you may have even been lucky enough tog et to catalog everything that was in that storage room as you asked yourself, “Why in the world are we hanging onto this?” Well, part of ITSM is establishing (and hopefully following) the policies and practices for things like tracking equipment, deciding when and how to buy new equipment and who’s responsible for approving it, etc. It’s not usually fun to walk into someone’s office to help them with their printer problem and find out that they bought their own printer and want you to make it functional on the office network.

Change Management

This is a big one, and it’s too often neglected. When you are making changes in production, no matter how sure you are that everything will be fine, there’s a good chance that some edge case you weren’t ready for will interfere with your plan. Change management is planning what the change will be, when the change will happen, who is responsible for the change, and, probably most important, the roll-back strategy in the event that the change fails or breaks something. OTRS::ITSM provides tools for handling this whole process.


I’ve covered some of the high-level categories for IT Service Management as an overview of what OTRS::ITSM aims to help with. But to get even more general, ITSM covers any of the policies and practices that help IT deliver the services needed to help the business reach its goals. That’s a pretty broad task, which means that OTRS::ITSM has a lot of features. My goal isn’t to cover them all. I’m going to do with these posts what I did with the original OTRS series and make recommendations for the initial setup while also trying to elaborate on any “gotchas” in the system. Hopefully it will be useful to those who find the official documentation overwhelming.
Love and kisses,Tyler