What are Managed Services? (Part One)

Today’s topic may seem like an obvious one, but I have found over the years that multiple clients and partners have very different definitions and expectations about Managed Services.  So, in this blog, I’d like to take some time to compare support and managed services and talk about iArch Solutions’ approach and offerings in this space.  So, let’s get to it.  What follows is the first part in a three-part series.

What is IT Support?

At its core definition, IT support is a technical expert (or subject-matter-expert, often abbreviated as SME) assisting a group of people or an individual to accomplish a technical task.  This technical task can encompass an array of options and technologies from desktop support, to server or network configuration, to support of a specific technical application such as a finance suite…the possibilities are endless. 

Because there are so many possibilities, and because no single person can answer all possible questions or be a SME in all IT areas, IT staff tend to be made up of individuals versed in a few specific areas.  This specialization has led to IT organizations that are both broad and deep; made up of dozens and sometimes hundreds of individuals.

As an end-user, perhaps looking for someone to add software to their laptop, setup a printer, or assist with that ODBC data source that isn’t connecting to the database, finding the right person can be a challenge.  The solution to this was to provide a way to connect the end-user request with the proper technical resource; and thus, the Help Desk was born.  The Help Desk (whether automated or staffed) serves the purpose of identifying and routing an end-user need to the technical resource capable and responsible for addressing it.  With the Help Desk came the ticketing system for tracking and routing issues.

So far, so good.  The problem with this model is that it is entirely reactive.  The end-user in this scenario is responsible for identifying an issue, making a request, and then opening a ticket.  If there is a system issue with a server or an environment, the user is identifying IT after-the-fact, with the end result that users are impacted and awaiting a resolution.  A standard flow is something like this:

• End-User identifies system issue or has it reported to them

• End-User opens ticket

• Ticket has an SLA (Service Level Agreement) or wait period before it has to be acted on

• IT agent accepts the ticket and begins working/investigating.

  • This step usually includes some back and forth with users to gather more information, etc.

• IT agent identifies a solution or workaround

• Issues is resolved and problem fixed, or service restored

Now the issue with this is the time involved, especially in the bold steps above.  An issue could be a problem before a ticket is opened, and it persists as an issue while a ticket is opened, accepted, and acted upon.

Over time these drawbacks have made ‘support’ a proverbial four-letter word.   System users are frequently frustrated by the lack of response from IT resources, who are in-turn frustrated by end-users who don’t provide sufficient information to troubleshoot and resolve issues in a timely fashion.  It is a classic Catch-22. 

Additionally, while not the prime driver in support models changing over time, there is also a cost and staffing aspect in play.  Modern companies have dozens, if not hundreds, of individual systems.  The systems are often written by different software vendors, with differing hardware requirements and levels of expertise required to support them.  As such, staffing an expert (and a potential backup expert) for all of these systems is not possible from a resourcing or cost perspective. 

This is where companies found themselves approximately 10 ago.  To reduce costs, a number of organizations made major staffing choices to move IT resources to cheaper off-shore resources.  Conceptually, more and cheaper staff should have allowed for more and cheaper expertise.  This certainly seemed to save costs.  But there was a lot of hidden overhead. 

For starters, the shift to off-shore resources often encountered both technical and cultural barriers.  End-users found that the new IT staff weren’t always as technically qualified as advertised, turnover in offshore resources was high, and sometimes language issues made resolving issues challenging for all parties.  This is where the overhead costs began to creep in, as issues took longer to resolve, and led to longer system outages, with a corresponding ‘hidden’ cost to overall corporate operations.  So companies saved IT cost in the short term (and it even looked good on the books at first glance) but overall productivity and efficiencies were lost, resulting in the off-shore support model looking less rosy over the long term.

Now off-shore support still had a great role to play in backed systems support, in supporting 24x7 staffing models, and in a number of other areas of expertise.  Yet, the gaps noted above had management teams questioning the overall ROI of moving all support to off-shore teams. 

What was needed was a hybrid model, which support services evangelists were already discussing and/or building.  That model became Managed Services, which we will discuss in Part 2.