It is a proven and a common practice to buy and implement off-the-shelf software packages to solve business problems. Ranging from the sophisticated ERP systems like Oracle EBS, SAP to simpler packages like the many Payroll systems in the market, organizations tend to have a few of those within their applications landscape.
What is available off-the-shelf gives you a headstart with your deployment and time-to-market, provides you with heaps of the best industry and technology practices, and further gives you a risk-free approach to solve a business problem since the solution in most instances will be a proven one.
Organizations that are mature in terms of their IT practices often tend to adopt a dual vendor approach for implementing enterprise software packages such as ERP – Oracle, SAP et al and CRM – Siebel et al to name a few. The principal product vendor, for instance Oracle, will do Solutioning, Architecting and Technical Project Management, while the second vendor, usually in this instance an Oracle certified partner, will do the actual implementation.
Once the implementation is done and the engagement moves into a Support and Maintenance phase or BAU mode, it is usually the Oracle partner who will continue to provide this service.
But care should be taken to select a partner who will provide you cost effectiveness, has a proven support model, an assurance of longevity and will not cost you a fortune to do further enhancements around the implemented system.
Quite often this is not the case and the realisation sets in quite late into the engagement. Typical problems include:
- The partner is more of a projects oriented company and shares resources for doing implementation and support. While the implementation may go smoothly, the support may suffer.
- The partner will not accept stringent SLAs and response times. The reason for this is same as above. The end result is that your support will be erratic.
- Often times there are partners who are quite good in one area, and not good in others. Going back to the Oracle example, the partner will be quite strong in implementing Financials, but does not have expertise with CRM or HR or Order Management.
- You might also require some form of bespoke development around the system that you implemented. While you have a vendor with an understanding of the current enviroment, they might be found wanting in these areas.
If you leave aside the large, matured organizations with their approach described above, it is often the mid-level ones that faces these challenges. If you are stuck with such an implementation partner, what are your options.
If you are planning a new project, it will be prudent to take the approach described above. All you need to do is make sure is that the implementation partner needs to have the flexibility to deliver, the scale to deliver and the varied skills to deliver all that you want in a very cost effective manner. Your principal product vendor will play the roles that were described earlier.
If you are already in the support phase and are faced with all the challenges as described above, you should be looking out for a new partner/vendor to take over the support and maintenance. Such a vendor should have the following characteristics:
- Scale in terms of resources
- An onshore-offshore model (preferrably)
- Cost effective models of providing support – pay-per-use, on-demand, etc
- Dedicated support resources if certain support elements are critical
- Varied skills other than the product specific skills that can be leveraged in future
- A sound take-over or transition methodology from the current vendor with minimal risks (explained in detail below)
- Proven support projects with referenceable customers
One of the biggest risks you will face is how you can successfully transition the existing body of knowledge from the current vendor to the incumbent. You have to invest additionally for this. There are no short-cuts and it is extremely important that you get this right. Depending upon the scale of the installed product, it can often take from 1 month upto 4 months for this exercise to be completed.
Let’s take a look at the steps involved in this:
- The due diligence phase: This phase is where the incumbent vendor will try to understand at a detailed level how the system has been implemented both from a functional and technical perspective. The vendor will also ascertain how the support engagement can be structured and will provide you a clear guideline as to how much needs to be spend.
- The knowledge transfer phase: One of the challenges that you will face during this phase is how you can get cooperation from the existing vendor. The incumbent needs access to subject matter experts and documentation in order to successfully complete this phase. This will result in the new vendor producing a series of documents of their own that would have captured the full body of knowledge. You need to review this and sign off. The review will assure you that the phase has been successful and that you are on the right track.
- The shadow phase: This is the phase where the new vendor will shadow the existing vendor for an agreed period of time, usually ranging from 2 weeks upto a month or two, while support is being provided to the users. This phase will expose the new vendor to the types of support requests and challenges that they will have to tackle.
- The reverse shadow phase: This phase is where the new vendor will start providing the front-line support and the existing vendor will be in the shadows. Once you and the new vendor is comfortable, you will no longer require the services of the existing vendor.
This exercise will be often frustrating, demanding, costly and challenging since you have two vendors – the one losing business will be upset, not cooperative at times, and the other eager to impress! It will be a good idea to have a transition project manager who can bridge the gaps and play the role of the facilitator.