MSPs Tag

Selecting a Cloud Services Provider

The choice of a cloud provider can determine the success or failure of your project. When researching potential cloud providers it is critical to look behind brand and market share to be sure the services they deliver fit you needs for the time frame you need them. A great company may provide a great service, but it may not fit you needs today or it may not be able to adapt to your needs as they change. Here are a few thoughts to aid when evaluating cloud providers:

  1. Demonstrated expertise in the specific services you need – Look for a provider with deep knowledge and experience delivering the specific service you need. Some cloud providers are generalists and that may be OK if your needs are not specific, but if you are primarily looking to the cloud to deploy a specific application, them look for a provider with experience deploying and hosting that application. If you need a specific service like storage or disaster recovery, then look for a provider that specializes in those services. Ask prospective service providers for a list of engagements with your proposed project. Follow up by asking what worked well in each engagement and what needed improvement and find out what corrective actions were taken to improve for the future.
  2. Vendors need a vision that matches your needs and timeframe – Seek service providers with clear vision of where their service offerings are going. Do this by understanding their roadmap. Analyse how this roadmap matches your requirements and timeframes. Will the provider have the scale you need as your requirements grow? Will their features be competitive with those of other providers over time? Do they have the administrative features you need to scale, document and manager your cloud deployment? If you a looking for a long term partner, be sure they have a roadmap that not only meets you needs, but gives them the staying power for the future.
  3. Infrastructure Capabilities – Ask your prospective service providers about their infrastructure. Understand the SLA they provide and what they do to ensure they meet or exceed it. What do they do if they have a failure? Do they have multiple data centers? If your prpject will run 24/7, do the prospective vendors have the abilities to support your team 24/7? This information will allow you to determine if they can provide you the uptime your business needs.
  4. Global expertise. Cloud services go global quickly and easily. If you plan to need a global deployment, be sure to select a partner with international experience and presence. Can they support content distribution in Europe? Do they have infrastructure in the regions important to your business? Do they have people that can communicate effectively with your international offices?
  5. Cloud integration experience – Most cloud deployments need to integrate to other cloud based services. Be sure your potential vendor has experience doing web services integration with the various services you are planning to use. Do they have other customers leveraging those services now? Can they support your efforts to integrate your project with other services?
  6. Hire a company you trust and that is staffed with people you like – You are forging a long-term relationship with the provider and they will be responsible for a big part of your business. Be sure your team’s culture matches the culture at the provider. In the end, experience and reputation only go so far. Your project will not succeed unless you trust the team sitting across the table. Be sure to do business with companies that place your company’s success at the top of their list each day.

The importance of cloud services vendor selection is possibly the most critical choice you make in a a cloud deployment. The right choice will keep your service running to meet your needs today and in the future, but a poor choice will almost guarantee failure. We often think that cloud makes everything simple and easy, any business transformation effort requires the right experience and capabilities. Be sure your prospective vendor has the right ingredients and fit for your company’s needs.

0
0

When Shared Services Break Down

Shared services offer a number of wonderful benefits for small VARs and MSPs including low-cost, efficiency, breadth of support and 24/7 operation to name a few. These are great features when your business is growing and you are new to offering services. However as you grow, your needs may shift some and the shared services model becomes less attractive.  In fact, some of the items that are most attractive about the model when you are new to selling services are the very things that make shared services so unattractive as your services business matures.  We will be discussing some of the drawbacks of shared services for mature MSPs and ultimately some solutions in upcoming posts.

Today’s topic is the fixed processes imposed by the shared services model NOC

To manage the environments for many end customers spread out across a hundreds or thousands MSPs, shared services providers must unify all their processes. This means they have one way of doing things and that way applies to all their MSPs.  This approach allows them to spread out the work across a large team; allowing any team member to do work for any MSP, since all the processes are consistent. This is fine or even preferable when you are starting your services business because you have not yet developed your own processes and your customers are likely smaller and willing to adapt or even unaware of the underlying processes. As you grow your team becomes more sophisticated and you begin to attract larger and more demanding customers. At this point you may want to specify things like what days to perform patching or how escalate alerts. In a shared services model, your provider is unable to give you his flexibility. Many will even try, but the end result will not be good, because every time they do a patch or alert escalation for one of your customers, it ill be an exception for their team and an opportunity for an error. This becomes even more problematic when you need different processes for a few big customers.

Our next post will talk about the efficiency sea-saw and delivery consistency.

 

0
0

The Importance of SLAs

In reading a post over on one of my favorite blogs, Talkin’ Cloud, I saw a discussion that caught my attention. The post itself is titled, Top 11 Questions MSPs Ask About Cloud Partner Programs, but the discussion touched on Service Level Agreements (SLA). In particular the seeming lack of importance customers give the actual SLA service provides give them.

In my experience at NetEnrich and at OpSource prior to that, our customers would spend a lot of time on the Master Service Agreement (MSA) with many conversations between their legal team and our legal team and give and take on a number of points. Naturally, these are important conversations to have, but in this negotiation process the SLA was typically given a cursory read and accepted.

As a commenter pointed out, one can argue that the ultimate SLA is customer satisfaction and a vendor with low customer satisfaction will loose their customers. While I agree with this premise, I believe customers who do not question the SLA, miss a great opportunity to get a better idea of how the service vendor will deliver on customer satisfaction. I recommend not only reading and fully understanding of a perspective vendor’s SLA to insure it meets your needs, but also to always ask the vendor a number of pointed questions about their SLA and how they operate in a number of possible incidents and then carefully gauge their responses. This is the best way for a customer to set their expectations of how the vendor will respond to incident prior to engaging. It will also help to expose areas to negotiate on the SLA along with possible areas where you may need to augment the service to maintain that ultimate SLA with your internal or external customers.

A few things to consider in an SLA:

 

  • Evaluate the promised response time based on the severity of the incident. Does this response time fit your needs, if not is there a way you can work with internal resources to deal with it?
  • Look at the teeth in the SLA. This is what happens if the vendor does not meet their commitment under the SLA. Many vendors have great standards in their SLA, but have little or no teeth in the event they fall short.
  • Understand how breaches need to be reported. Here you need to understand how long you have to report the breach and what process needs to be followed.
  • Look for  what we call the No Harm, No Foul SLA. In this SLA, if your team does not report the breach, it did not happen. In many cases this type of SLA works fine, however, if you are relying on the service to support a series customers, then this may not work as well because some of your customers may see problems you did not see and they may be too busy or frustrated to report it to you. In this setting, you may want an SLA where the vendor is required to report to you any and all breaches.
  • Lastly, be sure you can live with the performance level defined in the SLA. If you can, then you will probably be happy when your vendor out performs it.

Let us know you thoughts and please ask questions.

0
0