Enterprise Concerns About MSP Services

Enterprise Concerns About MSP Services

MSP services are normally a very attractive option for the enterprise. However, there are upsides and downsides for the corporate enterprise advocate to consider. These issues must be overcome in order to penetrate the enterprise, and to offer service at a level needed to sustain the MSP. A few of these issues are:

1. Cost control

2. Quality of service

3. Technology capabilities

4. Corporate IT downsizing

5. Loss of control

6. Reliability/Quality

First, let’s address the upsides:

1. Cost control. Often, local IT departments are inexperienced in forecasting accurate IT budgets. Additionally, this is complicated by market opportunities unforeseen during the budget process. Whereas the corporate IT department would need to allocate substantial outlays in capital ( for lab, production, test, simulation) and training funds (for equipment and personnel), the MSP has already incorporated this in the COGS model. With MSP services, these costs are substantially factored in contractually, and can be contained with minimal politically adverse blowback for the corporate IT department.

2. Quality of service. MSPs tend to be experts in their offerings. And because of their larger market access, the partnering vendors are more readily able to support leading edge implementations. MSPs tend to have worked with the technologies and offerings marketed, knowing that their reputation and business rests upon performance, knowledge and expertise of the offering in a production environment. MSPs also tend to have tried and tested processes built around the offerings, with best practices incorporated from multiple sources, such as industries, vendors, experts, and trial and error. With a commensurately large contingent of infrastructure, backed by SLA obligations, MSPs are loath to try to just “get by” in service levels, reliability, or efficacy, as all three of these contribute to the competitiveness of not only the customer’s business, but also the MSP. Lastly, the MSP is duty bound to offer reporting on specific metrics. This means that the MSP is ALWAYS under scrutiny, hence no margin for subpar performance is tolerated.

3. Increased technology capabilities. Labs, certifications, vendor assistance, experience, etc. are already in motion, if not operational. Potential obstacles and shortcomings have already been addressed, compensated for, or eliminated. MSPs tend to target multiple companies with customized offerings, which keeps costs lower than a comparable corporate IT shop, and eliminates or reduces training and equipment ramp up times. This offers the customer’s business a much quicker time to market/implementation, with quantifiably fewer program/project/infrastructure failures, false starts or showstoppers.

Secondly, let’s confront the elephant in the room. Perceived downsides:

1. The IT department will be concerned about “outsourcing, and the commensurate loss of jobs. Although job loss occurs with regularity in conventional outsourcing, true MSP services tend to AUGMENT existing personnel. The core IT department tends to have X personnel doing Y tasks. Many of the Y tasks take a very high level of expertise in order to not only manage and maintain at an acceptable level, but also to gain a competitive advantage. This level of expertise takes time, resources and experience. None of these tend to be abundant in today’s corporate IT environment. MSPs enable enterprises to augment IT staffs quickly, economically and expertly.

2. IT management will be concerned about loss of control, i.e. unable to make quick configuration changes, lack of access to security settings, etc. This showstopper is a real and justified concern, but can be mitigated by well-written contracts, mutually agreed upon standards and a continually evolving process customization mentality. In short, the MSP should have the expertise to bring in best and common processes that are easily agreed upon by the customer. Building upon this, customized processes should be put in place to address the customers unique business, viewpoints, biases and environment. An ongoing iterative process review procedure should ensure that this is a living relationship maturing over time.

3. Corporate executive management will be concerned about reliability/quality. Downtime can be measured in loss of income, loss of opportunity, market embarrassment, or even in the case of security breaches, loss of business viability.

This concern can be addressed multiple ways:

1. The SLA with its penalty clauses. These clauses work both ways and cover the gamut from unauthorized changes, through to loss of business. Both sides should make sure their considerations are explicitly addressed.

2. Reporting of metrics. This is appears to be one of the most difficult agreement points. Often, the metrics the customer wants/needs reported have little if any real meaning from a technical point of view. So be it, if the customers wants it – report it, realtime if possible. The MSP should provide a non-Service Desk interactive way to generate reports, e.g web site dashboard. The MSP should, of course, track internal statistics/metrics needed to run the services in the manner needed to cost effectively meet the customer’s/SLA needs, and enable forecasting. Additionally, the MSP should schedule periodic meetings (face to face or teleconference) to address the “State of the State”, i.e. how things are going contractually, technically, and B2B.

3. Customer input process. The MSP must establish a customer input process that feeds directly into Service Desk flow. ITIL is a great methodology to embrace. The process must be agreed upon by the customer, and recognized as necessary to keep issues from “falling between the cracks”. In order to keep customer costs down, executive management on BOTH sides must comply with this process. Bear in mind, this does not mean that issues are not, or cannot be introduced outside of the process, and frankly this is sometimes the quickest way to bring attention to an issue. But, the issue reconciliation process should be built such that recognition of these “end arounds” will occur, and how to feed them back into the incident/problem/issue resolution tree.

The above are just a few considerations for deciding whether to look into using a MSP. Other papers by this author more extensively cover each of the above aspects, and additional important points including business and infrastructure.