"IT budget reduction" garnered a 30 percent weighting in our report card because the prime motivator for the RFI was to save money. Period.
Savings without service is worthless, so our secondary goal, weighted at 30 percent, was service-level management. Billing credits, SLA structure, transition management, and outage management and response played the biggest roles. We broke the service category into two parts: What was going to get monitored and what happened when a service didn't meet the agreed upon level. For the former, we asked for specific availability percentages of 99.9 for stores and 99.99 for warehouses.
Although these service-level management activities are readily understood, the service-management best-practices category is more of a catch-all bucket meant to get at the kinds of project management and preparedness each vendor implicitly or explicitly put forth in its RFI responses and subsequent answers to our many questions.
The low weight of 20 percent may seem to indicate a lower importance, but it is actually a reflection of what was claimed. Because we didn't test or engage the providers, it would require due diligence to check out their personnel practices, data centers, trouble ticketing, response times, and training, for instance.
Finally, we only gave reporting only a 10 percent weight, again, for a couple of reasons, neither of which were because reporting doesn't matter. After all, reports are the window into the network's application and business delivery success or failure. But again, we didn't use these products, and we found that from the demonstrations and descriptions provided, the differences were not huge. Some appeared to be better than others, but it seemed that, overall, report distribution and metrics monitored were similar across all products.
More important, reporting is a Catch-22 for outsourcers. Although the reporting did offer very granular network-performance metrics, no one left on TacDoh's staff had the network chops to understand the meaning. This is somewhat of an exaggeration--it doesn't require network expertise to understand all the reports--but relating errors and CPU utilization on a router interface to slow response time, isn't a simple correlation. Although the reporting is nice, TacDoh, and any company that goes this route, will need to rely on the outsourcer to make these of correlations and suggest fixes.
RSS
