By Jeff Lucchesi – COO
The term “Managed Services” is used as a blanket term much as the word “cloud” is used today. Current-day managed services support started with the advent of SaaS and IaaS companies in the last 15 years or so, although there are roots dating back to timeshare services in the ’70s. These support models are what’s called “one-to-many” vs the “one-to-one” model also used today, especially by offshore vendors in this space. “So what?” you say. Well, you need to understand the differences if you are dipping your toe into this space, especially if you are writing an RFP. Today I have seen zero “RFP experts” include any reference to this in their proposals, and it is an important differentiator. It’s one reason why I believe we have seen so many failures by potential clients in selecting a Managed Service partner thru the RFP process.
The one-to-many model, as mentioned, started with timeshare companies in the ’70s who provided one computer to run services like ERP for many customers. This support model became more refined and very efficient when modern SaaS and IaaS companies came on the scene. Managing hundreds or thousands of customers with one common infrastructure makes sense because it needs to run in a standard fashion for all, yet meet the business needs for each of their customers. This model scales better for their type of business and provides a better path to profitability. The one-to-one model also started in the ’70s. These are the dedicated headcount models that run infrastructures for a company, usually organized by domain type.
So again, why should you care? Here are some, but not all, of the differentiators:
I mentioned the basic differences before, but here is where it gets interesting. The one-to-many model needs to keep documentation (run books) and monitoring alerts current because of the way they operate. They utilize a breadth of talent to support your operation and the “tribal knowledge” structure many companies have today is not emphasized here. The skill levels are the same, as you would expect from anyone touching a particular domain, but they are supporting many clients.
These companies will continually maintain the monitoring and documentation for you. They are also organized horizontally by level with the talent having multiple domain skill-sets, which is a definite plus when troubleshooting complex problems.
The one-to-one model would mirror how you might set up an operation in your own business, but like anyone who runs an operations staff, the run books and alerts become outdated because tribal knowledge begins to dominate. If I am a Linux technologist running one set of systems, why would I document operational processes when I already know it? I am also aware of which alerts are false, so tuning might take a back seat.
When we work with clients who are in this model today, this feedback has been consistent and has frustrated them.
Finally, keeping documentation and alerting up to date is particularly important in highly regulated companies that are audited by various agencies and audit firms.
How they make their money:
One-to-many models look at their business as to how to scale without growing significant headcount. Their success is based on efficiencies and working with you to drive ticket volumes (i.e. problems) down and to automate processes that take the labor out of the equation. This allows the vendor to add more customers without adding a lot of headcounts. Reputable vendors will take money off your monthly fees if they take enough tickets out of your environment.
These parameters are built into the contracts, so ensure the verbiage is included.
Many one-to-one models make their money on headcount. Off-shore headcount is cheaper than the U.S., so there is a tendency to overstaff an operation while still underpricing US-based service providers. We know of one case where a client who is relatively small ($500–700m) with a small infrastructure is paying for over 100 heads to support their infrastructure. Contract pricing over time can go down, but it isn’t through efficiencies. It is reducing costs by removing headcount or taking out more senior people over time and putting in less experienced staff.
Both models may also add hardware, software, and data center services to the equation, depending on how the services are defined. Both models can be a problem here because you have less flexibility in leaving should the relationship not work. Exiting is painful and expensive.
The one-to-many model is best suited for “burst capacity.” Any time an emergency occurs and it’s all hands on deck, these operations are built to handle the load coming in because they can use the array of talent they have on staff during that shift to deal with the problem and stay within their SLA’s.
In the one-to-one model, it depends on how many people in particular domains are on the account. If the client has a virtualization problem and the staffing model only accounted for one person in the deal, there may or may not be an issue depending on that person’s availability.
The one-to-many model is process-driven but flexible. For example, the more mature outsourcers running this model utilize the ITIL framework but understand the different operating needs of each company. Runbooks reflect specific needs for specific customers. Utilizing the one-to-many vendor who has a mature ITIL framework can accelerate your maturity based on your partnership.
The one-to-one model is dependent on the skills of the leaders assigned to the account, along with the training of the staff who will be supporting your environment. As people leave and are replaced, they might not be as skilled in this area and it may show in the service provided.
Both types of companies provide analytics, but you should look at the type of reports being produced to ensure there is value. Also, the one-to-many model can produce comparisons to how you are doing against other companies like yours (confidentially, without names) so you can see where you are and where you might want to improve. This is valuable information, especially to people running operations. It is easy for this model to produce the reporting because the data resides in one database (partitioned from each other for security purposes).
The one-to-one model will also produce data showing SLAs and other relevant data but it is difficult for them to share information across companies for you because a lot of these structures are using different databases for customers. In many cases, they are using your ticketing systems to produce the data so they cannot look across their customer base.
So these are some examples of the support models and how they differ in delivering support to customers. These differences should be taken into account as part of your decision-making process.