For major projects like an IBM i system upgrade, most companies will readily recognize the need for specialized, outsourced services. In many cases, this means seeking out a traditional managed service provider (MSP) to handle the system essentials – from performing the upgrade, to troubleshooting system problems, to ensuring stable OS performance. For the same project, that same company may also need application expertise and support — in other words, an additional resource to perform the application upgrades that are required to stay compatible with the upgraded OS.
Although the two needs are related, they rely on different skillsets — and may therefore be contracted out accordingly. But in doing so, there’s a concerning gap. What’s missing is the key middle-ground service and expertise needed to resolve issues that arise between the OS and the applications. Time and time again, I’ve seen it happen: issues arise due to the overlaps and interdependencies of the OS and its applications – many of which pose significant operational risks. Such issues often go beyond the scope of expertise of a traditional managed service provider; and to resolve, they require the expertise of an integrated managed service provider (iMSP). In this blog, we’ll discuss three risks in particular that can potentially impact your business – and discuss the importance of evaluating your provider needs upfront in order to avoid the challenges associated with those risks.
Risk 1 – You lack an assigned resource to handle the grey-area issues.
In keeping with our example of an IBM i system upgrade project, consider the following scenario. A company’s IBM i system upgrade is to be performed successfully by a traditional MSP. Meanwhile, all application upgrades are planned, tested and rolled out according to schedule. However, a few months in, problems become evident during the user experience, such as issues with the query application on users’ screen. The MSP characterizes the problem as a communication error. Yet after checking the wires and performing the needed troubleshooting steps, everything is seemingly fine. So now what? In this case, it’s discovered all too late that additional expertise is required to take the problem one step further; that a dedicated resource is needed to make the connection between the system, the applications and what’s happening with the user. This describes just one of many scenarios in which an iMSP is needed to swiftly resolve those “grey area” problems before they impact daily operations. As such, the bottom line is this: as your organization evaluates its outsourcing needs, it’s crucial to account for all potential scenarios at the onset of a project, so you can plan your resources accordingly and determine if a traditional MSP is enough.
Risk 2 – You experience costly delays.
As mentioned previously, organizations may outsource services in a silo — which inevitably creates gaps in “middle-ground” responsibilities. In addition to the frustration this causes among resources, it’s important to be cognizant of the costs of such a scenario. The zoomed-in focus areas make it much more difficult for multiple parties to arrive at quick solutions to overarching problems. Time is lost on frequent back-and-forths, and frustration and finger-pointing ensue as users continue to report performance problems. The project timeline is delayed, causing increases to the initial budget. Meanwhile, there are operational slowdowns and downtime that are impacting operations (which, for some companies, may even result in additional fines or downtime fees from customers.) Here again, this scenario can be avoided by leveraging the comprehensive expertise of an iMSP from the start — as it will, in effect, remove the silos, simplify the troubleshooting process and ultimately prevent time-consuming, costly scenarios.
Risk 3 – A gap in expertise leads to negative, broad-scale business implications.
On top of resource frustration and costly delays, failing to recognize the need for an iMSP can lead to large-scale implications that can potentially halt operations, put a strain on your customer service team, and tarnish your business’s overall brand. Keep in mind, as you’re considering your needs in a provider, be absolutely sure you’re thinking beyond system expertise AND beyond application support alone. Ask yourself if you have the right resources in place to handle issues that impact operations, distribution and commerce. Think about whether your provider is prepared to handle the broader business implications of, say, communication error downtime. In a recent example, I’ve seen this result in something as critical as trucks being physically held up at the warehouse for almost an entire day. In this case again, an iMSP would have had the middle-ground expertise to make the critical connections that are required to resolve the broader business issues. (Read about a similar example in our latest PSGi Case Study.)
All in all, traditional MSPs are certainly a sound choice for system-related services like an IBM i OS upgrade. And in many cases, an iMSP can serve as a partner — not a replacement — to a traditional MSP. However, as you evaluate your provider needs, it’s important to understand the distinct roles and skillsets of an MSP and an iMSP. By evaluating this upfront, and understanding the full range of service and expertise your project requires, you can avoid these major risks and stay on track to project success.
