President's Perspective
Free Mobile Devices Support: Ask your Kid
 Lately
we've been talking a lot about mobile devices and how to manage iPads, iPhones,
Androids, etc. at the enterprise scale. How do you secure and protect your organization's
intellectual property when it resides on these devices? How do you establish password
standards? Etc.
But what about all those niggling little "day to day" issues? Learning
to navigate the features of a mobile device is not always easy. Where can you turn
when you have questions about how to use the device itself? Perhaps you want to
change the ring tone or background color. Maybe you need some tutoring on the "basics,"
such as how to send a text or snap a photo. Where do you go for this type of support?
Sure you could go online or plow through a manual, but chances are you're in a rush
and looking for a faster solution. If this is the case, I recommend you do what
I do: ask your kid.
Kids spend more time on mobile devices than any other class of people. They know
how to make those cosmetic or annoying problems go away. It doesn't matter if they
don't have a device like yours (chances are one of their friends does) or if they've
never encountered this problem before. Chances are your kids will be able to intuitively
figure it out. Kids just seem to know more about this stuff than we do.
Think your kid is too young to be of help? Think again. Last month at a family holiday
party one of the guests was showing everyone else how her two-and-a-half-year-old
grandson knew how to find the photos on her iPhone. As everyone watched she handed
him the phone, he pushed the correct icon and then laughed happily at all of the
photos of himself and his sisters. Like I said, if you need help with your mobile
device, the fastest and easiest thing to do is to simply ask your kid!
Mike Faster
President
Technical Editorial
The Escalation Process: Getting Issues Resolved
While your kid may be a great resource for solving problems on a mobile device,
when you have a real IT emergency, there's no substitute for having efficient processes
in place to resolve the immediate crisis, troubleshoot the Root Cause (see our blog on Root Cause Analysis) and prevent it from
recurring.
You know the drill…it's nine o'clock in the morning and the phones are lighting
up in the IT department. The email system is down, and everyone from the President
to the Receptionist is calling to say there's a problem. Of course, thanks to their
monitoring system, IT had already noticed that something was wrong – but the calls
are providing immediate feedback regarding how widespread the problem is. Because
email is a mission-critical system at this company, if the Tier 1 engineer cannot
quickly fix the problem, the organization's formal escalation process will kick
in.
What is an Escalation Process?
An escalation process is a formal process for addressing IT issues and problems
when they arise. All IT departments should have a written escalation process in
place, with the entire IT staff trained on its use. The process assigns priority
levels to different types of issues, delegates responsibilities to specific personnel,
and defines how much time personnel at different support levels will spend attempting
to fix a given issue before the problem is "escalated" to the person or
people at the next support tier. Just as important, one of the purposes of the escalation
process is to have a plan in place for informing and alerting those who are impacted
by the problem itself.
The Components of
an Escalation Plan
A formal Escalation Plan needs to address each of the following items:
- Support Personnel – A clearly defined tier of support personnel,
including each person's name, title, contact information and expertise.
- Service Priorities – A chart listing all of the services provided
or managed by IT, with each ranked on importance level based on the number and type
of people affected by the service. For example, mission-critical services like email
might be designated "P1," while less important services such as a particular
printer might be designated "P3" or "P4." For more information
about categorizing services and issues into priority levels, see our article on
Best Practices
for Configuring Your Network Monitoring System.
- Response Times – For each priority level, a definition of how much
time the personnel at a given support tier can spend trying to fix the problem before
it is escalated to the next tier.
- Communication Standards – Standards for how the IT department will
communicate with affected users and user management during the problem resolution
process. Who will be communicated with, what communication method(s) will be used,
and how frequently will this communication take place?
The Escalation Process in Action
To see how all of this works, let's get back to our email outage example...
The escalation process usually starts with a user notification, monitoring alert
or service outage. In this case it was all three! At the first level of support
the responsibility is to identify the issue's severity and priority level, and to
attempt to resolve the issue in an efficient manner. Our Tier 1 support person determined
that the email outage is a P1 issue, which means that he's got about 10 minutes
to solve the problem. He checks to see if he can get into email (he cannot), checks
if the problem is company-wide (it is), and checks for connectivity to the email
servers (not there). He determines that he can log in to the mail server, but the
email database won't start.
He is now out of time, so he calls the lead or manager to let them know what's going
on. After asking the Tier 1 support person to keep working on the problem for another
15 to 20 minutes, the manager informers the user managers and user group of the
situation.
In this example, after the additional 15 minutes at the Tier 1 level the problem
is still not resolved. The Tier 1 support person contacts the lead or manager again.
The manager makes the decision to escalate the issue to Tier 2.
The issue is then escalated to the Tier 2 person. The Tier 1 person informs the
Tier 2 person about the issue status and what he has done so far towards resolving
the problem. Meanwhile, the manager opens a phone bridge (i.e., a live conference
call), as per the Escalation Plan. The phone bridge enables everyone involved with
the issue to dial in at any time to get a real-time status update.
Based on the written Escalation Plan, the Tier 2 support person might have 20 to
30 minutes to resolve the problem. In this example, the Tier 2 person uses up all
of his time getting the email database to start – only to discover that the issue
still isn't resolved. The manager decides that it's time to escalate the issue.
In this example, the organization has three tiers of support. Many organizations
only have two; in this case, the issue would be escalated to a third party vendor.
When the switch to Tier 3 is made a status report announcement is made to the user
manager and user group, and the phone bridge is kept open. Every two hours another
status report announcement is made, until the issue is resolved. While the best
practice would be to make these announcements via email, in this particular example
it is the email system itself that is down. Announcements are therefore made via
telephone or text message.
Back to our example…The Tier 3 support person determines that the email database
itself has been corrupted. He makes a temporary switch over to the disaster recovery
site, which gets the company's email back online, and then fixes the corrupted database.
The manager sends out an announcement letting everyone know that email is available.
However, if the Tier 3 person could not fix the problem within the allotted time,
the next step would have been to escalate the issue to the product vendor's support
team.
Are All Escalation Plans the Same?
No, but they are similar. What usually differs is each organization's priorities,
response times, communication commitments, and so forth. The important thing, though,
is to have a plan in place.
Mohan Reddy
Title Goes Here
Coyote Creek RMM
Are Frustrations with Exchange Driving You to the Cloud?
Microsoft Exchange is the lifeblood system for many organizations, but it has become
increasingly complex to operate. As a result, a lot of people are so frustrated
with Exchange that they're considering switching to hosted Exchange or other cloud-based
solutions from Microsoft and others.
What we see out in the field is that these thoughts typically begin after an organization
experiences an Exchange-related "event." Perhaps there's a problem with
on-going outages and failures. Maybe people aren't getting their email or they're
having calendar issues. And so forth. If the problems don't seem to be going away,
it's easy to think that getting rid of Exchange and letting somebody else run it
would be a great idea.
Other times organizations are tempted to switch to the cloud because they think
it will save money. After all, the price usually looks attractive at the start.
But when you run the numbers you quickly find that although the "starter"
price is great, the price tag quickly grows as you add necessary functionality.
The bottom line is the cloud is not for everybody. The
two main reasons for this are:
- Interconnectivity – Most organizations have other systems interconnected
with their Exchange server, such as their voice mail, telephone system and email
archiving. These things either don't work or don't work well in the cloud.
- Security – If you have concerns about your intellectual property,
and much of your intellectual property is contained in your email system, having
all of this off-premise – and potentially co-mingled with other company's data –
is probably not a great idea.
But there is another solution. Coyote Creek hosted a webinar for IT decision
makers, CIOs and CFOs about alternatives to moving to the cloud. You can get the
best of both worlds: keep your Exchange system in-house so that you have complete
ownership and control over your environment, but also get enterprise-class help
in operating it.
Whether you've been considering moving to the cloud or you're just frustrated with
issues surrounding the day-to-day care and feeding of your Exchange system, this
webinar is for you. Register today! Wednesday, February 22, 2012 at 11:00 am
PST.
Mike Faster
President
|