Building an IT Operations Manual - Dealing with Hardware

Richard Tubb

Hardware in IT operations manual. My recent blog post entitled, “How to Create an IT Operations Manual for your Business” generated a lot of feedback from IT Companies eager to learn more.

It seems systemizing your IT business and creating processes that create efficient processes is high on the list of many IT businesses priorities.

In our last article we looked at how to document clients IT infrastructures.

In this article we’ll look at how you as an IT Company deal with your clients Hardware.

Despite the emergence of “The Cloud”, local Hardware will always be required. Even the most basic small business client has a Router, a Network Switch, a PC and one or more Printers. Other clients may have Firewalls, Servers, Plotters, Multi-Function Units and any array of other hardware – most of it IP-enabled.

Multiply that by multiple clients, and you’ve got an awful lot of hardware that becomes really easy to waste a lot of time and effort trying to manage – if you’re not organized.

From Chaos to Order

The first step in bringing order to the chaos is to buy a Label Printer. My personal favorite is the P-Touch Handheld range from Brother. Anything that you can easily carry with you, plug into the mains (battery operated is fine – but batteries run out, and you then start to forget to label things) and print labels will do the job. If you have more than one engineer, buy them all label printers and get them to label them with their own names – they’ll be more inclined to look after them.

Next, organize a time for an engineer to visit client sites with his labeler at the ready – grabbing and labeling anything and everything with a power plug on the end and making a written note of each to take back to the office.

(Talking of power plugs, get your engineers into the habit of labeling these too, especially servers. Clearly knowing which plug belongs to a PC and which to a monitor is a real benefit when you’re crawling under a dark desk on a dirty floor trying to work out what to unplug and what not to.

Whether Labels?

But why bother labeling things?

Firstly, you’re acknowledging the existence of a device. If it’s labeled, you know about it and can document it for future reference.

Secondly, when new hardware “mysteriously” appears at a client site and a client calls you for support on it (probably outside your support contract) you can save yourself a heap of time trying to work out why Windows 7 Home Edition is installed on it rather than a Business O/S.

Thirdly, labeling hardware speeds up the support process. If a user telephones the Helpdesk to say they can’t print to “That printer in the corner of the office”, then you can ask them to read the label and quickly identify which printer it is that they’re trying to print to.

What the label says depends on the hardware, but the label should help you easily identify the hardware in question. Some examples:-

  • PCs – Workstation name, Fixed IP address (if applicable)
  • Servers – Server name, Fixed IP address, Domain name
  • Routers/Firewalls – External IP address, Internal IP address
  • Network Switches – Internal IP address, Management IP address
  • Local Printers – Locally attached Workstation name
  • Network Printers – Fixed IP address, Queue Name (//Server/Queue)

We’re not going to worry about Workstation and Server naming schemes, IP address ranges or any other standards just yet. Right now we’re focusing on documenting what's already out there.

Tangled cables. In some cases the engineer won’t be able to identify network equipment. Rather than ignore the hardware, they should label it as “unidentified” and raise a support ticket or make a written note to investigate how to identify it later.

This takes some time, especially if you have a lot of clients – but it’s time well spent. You should make this type of 'discovery work' a part of the on-boarding process of every new client, as the time spent discovering hardware now will pay dividends when you’re supporting that same hardware later – perhaps in a time-sensitive situation.

Going forwards, make it a policy that from now on, every piece of hardware you deploy to a client site should have a label on it.

Document your findings. If you have an RMM tool such as GFI Max, then you’ll already be able to scan networks for devices. Supplement this automated information with your own findings.

Pretty soon you’ll have a good overview of the hardware at all your client sites. It’ll make supporting the client, both remotely and on-site, a *lot* easier.

The use of the labeler as a force of good doesn’t stop there.

Hardware in the Workshop

Whenever an engineer brings a piece of hardware back to the Workshop for troubleshooting, it needs to be labeled. You might label it with the client's name, a brief overview of the issue, and if you’re using a ticket system, the ticket number.

This might sound obvious, but how many times do engineers walk back into the office, drop off some faulty Man working on computer. hardware and then get distracted by something else? In this scenario, a colleague may be left scratching his head over who the hardware belongs to and why it’s here, or worse, think the hardware is “spare” and go and re-use it for another job they are working on…

Talking of spare hardware – it’s worth creating a process to deal with this too. I like to create an area of the workshop that is specifically for Hardware under Repair, Hardware under testing, and Hardware for disposal. Then, as hardware comes in…

If it’s hardware that is to be sent back to a manufacturer under RMA, it’s labeled as such and placed in the “Under Repair” area of the workshop.

If it’s hardware that may be faulty and required testing, a ticket is raised for this and it’s labeled as “For Testing” and labeled with the appropriate ticket number. The hardware is then placed in the “For Testing” area, and you can confidently give your newly employed Junior Technician something productive to do on his first day in the office.

If it’s hardware for disposal, it’s labeled with the fault and marked as “For Disposal”. It’s placed in the “For Disposal” area of the workshop and once every few weeks you arrange for a specialist IT disposal company to collect the pile and dispose of it in an ethical and environmentally-friendly fashion.

Save Time With Labels

The amount of time IT companies can waste trying to re-use faulty hardware that has simply been left lying around, or re-testing known faulty equipment is mind-blowing. A simple system of labeling such hardware saves hours of wasted time.

I hope this article has helped to describe how armed with a label printer you can build the basis of a series of systems that lay out how your business deals with client hardware. I’d be interested in hearing how your own systems for dealing with client hardware work – do leave a comment below, or get in touch!

See It in Action

Here's a quick video we found showing off some of the usefulness of one of these label printers. Very futuristic!

 

 

Richard Tubb is an IT Business Consultant who works with ambitious IT companies who want to grow their businesses in a scalable and sustainable way. You can e-mail him at [email protected] or connect with him via Twitter and LinkedIn.