Low-tech Planning for Automated Administration

Sheldon Malm

If you're looking for a solution provider, or you're looking to provide solutions, chances are you've thought about automating administration. We all know the benefits of automation: reduced support staff; faster processing of requests; satisfied clients; and getting back to real System Administration. So, which would you like first: the good news or the bad news?

If youre looking for a solution provider, or youre looking to provide solutions, chances are youve thought about automating administration.

The good news is, technical solutions are everywhere, and that gives you a lot of choices. You can script the solution yourself, have someone script it for you, or peel the shrink-wrap off products from A to Z. Chances are you'll have a solid technical solution.

Now for the bad news: technical solutions are the easy part. Most implementations in this area fail because we miss the most important part of process automation in our planning. No, it's not the automation. Before you even THINK about automation, you have to establish your manual processes. It takes a little bit of time to put the workflow in place, but I guarantee that it will allow you to introduce automation seamlessly, overnight.

I've been through dozens of these implementations - from a 500 user shop, to an enterprise with over 70,000 clients - and the key to success has always been 3 basic components: pre-implementation, coding, and post-implementation. I'll take you through the 7 steps to prepare for automation. If you nail these down, the coding and post-implementation are so simple, even Tivoli could deliver them. Each of these components warrants an article on its own, but I'll keep it to 500 feet or better for this session.

The first thing you need is a reliable Enterprise Directory. If you don't know who your clients are, you can't administer them. This part is easy to put together, most of the time, but again: the technical piece is the easy part. Any relational database will do, although I've found SQL to be the easiest to work with. The foundation to a solid Enterprise Directory is a unique identifier, like an employee number. Once you've tagged your users, you can give them whatever attributes you think are useful.

Next, you need to have a Standard Request Form. Before you go down the VB, ASP, or shrink-wrap path, you have to evaluate how you get these requests today. Most companies have a mixed bag of telephone requests, various e-mail forms (usually one for each product), and the enlightened minority have one or more web forms. Your goal should be a single form that gathers personnel info once from the requestor, and lists the various products and services that your IT department(s) offer. What you do with that information depends on who is responsible for what, behind the scenes.

Clearly defined Roles and Responsibilities are crucial to successful process. In a centralized, cross-functional environment, this will include the processing of several requests by a single administrator. If you have product-specific admin teams, you'll want to keep this hidden from the clients. That way, when you reorg (and you WILL reorg), you don't have to retrain your clients. So, how do you spread the requests among the various support teams or admins?

Communication is vital to turning a high volume of requests around in a reasonable amount of time. This includes communication among support staff, as well as communication with the client. The easiest way to ensure communication between support staff is to get your teams on a common Problem/Change Management tool. There are a bunch of Help Desk software solutions out there that can give you this, and the added value is performance reporting, which I'll cover further down the article. Communication with the client centers around scheduling if a desktop visit is required, and updating the status of their request(s). So what is a "reasonable" amount of time for processing a request?

Setting Client Expectations is the only way to ensure customer satisfaction, and customer service needs to be your primary concern. If it isn't, don't bother reading any further. Even if security or stability of the network is your focus, don't forget that you're doing this to keep the users up and running. No matter how informal, this amounts to a Service Level Agreement. If you and the client agree to standard deliverables, your success is measured by your ability to meet those targets. A client would rather have a request processed in 2 days when they expect it in 3 days, than in 2 hours if they expect it in 15 minutes. Once these targets are established, you need to monitor your ability to meet them.

Measurables are generated from reports, and most Help Desk products offer solid reporting out of the box. By measuring individual and team performance, you can establish the added-value of automation. You may be able to show a potential decrease in support staff requirements, or you can set more aggressive targets for your SLA's -- sometimes both. These measurables will build your business case for introducing automation.

The final piece of the process is Escalation. This is the mechanism that clients can use when targets are not met, or when technical issues must be passed on for resolution. By putting the first 6 pieces in place, this will allow you to escalate technical issues efficiently, and to address client concerns quickly.

Executive summary time -- the 7 keys to preparing for automated administration are:

    1. Enterprise Directory
    2. Standard Request Form
    3. Clear Roles/Responsibilities
    4. Communication
    5. Establishing Client Expectations
    6. Measuring Performance
    7. Escalation Procedures

Once your manual process is in place, phase two is to automate the workflow for authorizations, etc. In phase 3, you can script the actual administration tasks using ADSI, or 3rd Party tools. One other piece of bad news: once you've implemented the automation successfully, no one will realize how much you helped them -- I guarantee it.

This article was originally published on Jun 26, 2000
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date