First, it's important to understand that the task of building and supporting a network is primarily dependent on the size and complexity of the network, not on who's doing the building. What managed services do isn't to directly make networks cheaper, it's to apply economy of scale to network-building and support. A service provider reasons that with the efficiencies they gain from providing a hundred private networks, they can build and support a given network at a lower cost than the enterprise user. This means that managed services tend to be a better deal for smaller organizations and/or smaller networks than for larger ones. Large enterprises have enough scale on their own. The value of managed services will also depend on just where you might be in the capital cycle of network-building. A company with a mature network based on technology that has largely been written down has little sunk cost to worry about and could make a change to managed services fairly simply, at least from a financial perspective. When a network has been recently modernized and the equipment has several years of remaining depreciation, it's harder to work a deal that recognizes the residual value of that equipment. Some operators will offer buy-and-lease-back programs, but these often complicate the financial analysis of managed service benefits, and they may also create some major problems with defining service level agreements and penalties for non-performance. Watch for clauses that exempt pre-existing infrastructure on lease-back from SLAs!
The third issue with managed services is the scope of the technology that's involved. Most managed service projects involve higher-layer application services and not low-level optical or channel extension services, and my research suggests that managed router or IP services are the most common and also the most successful. Managed wide-area services are more likely to be successful than managed LAN services, according to users, but multi-national networks with managed LAN and WAN services also have a high success rate.
It's tempting to think that the network operator who sells you managed services is getting a steep discount on equipment and offering you bandwidth at a wholesale level to make the service cheap, but that's not very likely. It's true that the operators have better equipment discounts, but if you look at the internal cost justifications for managed service products, you find that only about 15% of the savings to users could come from equipment and transport sources. People savings, unfortunately, are the big political problem with managed services, or any form of outsourcing. To save support costs, you have to cut staff. Attrition can work, particularly if the labor situation in your area creates a high turnover anyway, but in most cases savings will require reducing personnel. The corollary to this is that where personnel costs are high or turnover is high, managed services may offer a good alternative.
Beware, though. Three out of four managed service buyers I've surveyed indicated that they (or their provider) had overestimated the staff reduction that managed services could permit. If you are considering managed services, the moral is that it's crucial to understand your costs and risks in rolling your own network. One reason is that many network organizations perform on-site tasks in setting up systems, diagnosing application problems, and even helping out on IT issues that aren't always recognized in a job description. You'll need accurate work logs to see just what the people are doing before you can make any assumptions about how much could be saved. You'll also need to address the personnel costs of reducing staff, both in dollars and morale.
Where most problems arise once managed services are in place is where major changes in network demand occur. Sometimes this happens due to orderly growth in traffic, other times due to application changes, and in some cases it's just a matter of a special application set that runs a couple times a year and that somebody forgot to tell the managed service provider about. The difficulty is that these things can fall between the cracks of the service level agreement that governs how managed services will be supported. If you've reduced your own staff, you're dependent on the managed service operator to fix any problem, and whether they do that without charge or with special charges will depend on the SLA.
SLAs are important in all services, but they're critical in managed services. A good SLA has three sections: the conditions under which the agreement will be valid (traffic assumptions, etc.), the promised level of performance and response, and the recourse and remedy. Getting all three is important, and figuring out how you're going to take measurements to ensure that the provider is meeting the SLA is also important, particularly if you think you're using managed services to reduce technical staff.
Managed services may be getting more common, but not necessarily more popular. My surveys of users show that satisfaction with managed services is not only about 5% lower than with self-sustained networks, but also 2% less than it was 5 years ago. The decision is clearly one that every enterprise will have to make very carefully to prevent being very sorry later on.
