Considering An Ecommerce Replatform Project, Address These Issues First
Having been employed by such technology titans as AT&T and IBM, I have seen far too many situations where companies move to a new eCommerce platform but didn’t understand the reasons why. I remember a B2C site that suffered from sluggish performance from day one. I was told after the fact that the company didn’t have to migrate to a new platform if someone had known to update a configuration file to allow the site to consume more available memory than the default settings allowed. To avoid these types of expensive mistakes, the purpose of this article is to provide you insight on some of the issues you need to ask to insure a re-platform of your eCommerce platform has merit.
INVESTMENT VS COST DECISION
An important aspect of the decision making process is how the executive team views the expense of a re-platform project and why is it being done. Is it more cost effective to fix the ailments of your current eCommerce platform (“EP”)? Would the money spent on a re-platform project have a stronger internal rate of return and generate a higher positive cash flow of that investment versus other projects competing for the budget? Executives that lead growth-oriented companies understand the trade-offs of cost versus rate of return. If business value can realistically be achieved by migrating to a new EP, then the decision is based on strategy, not tactics and the expense is viewed not as a cost, but as an investment to meet the future growth objectives of the company. When decisions are made from an investment perspective, conditions are more favorable to get what you want.
SETTING PROPER EXPECTATIONS
The Kitchen Sink Syndrome. A common problem during a re-platform project is trying to do too much at once – throwing everything into the project. Projects that gain in scope have a higher rate of failure when too much change is thrown in. Moving an online storefront from one EP technology to another while trying to maintain most of the functionality is difficult enough. Adding new features only increases the chance that something will go wrong. If added functionality is needed, schedule those updates in future phases after the site has gone live and any necessary tweaking and tuning has been done. It is far simpler to identify and promptly fix production problems when there are less changes to the site to consider. Breaking a project into multiple phases simplifies the scope for each phase and increases the probability the project will be managed within budget, time and quality expectations.
Test And Verify. Make sure the executive(s) that approve the decision for a re-platform project, understands what the scope of effort is and what will be gained when the project is completed. Recent market studies have found that a majority of companies make their decision to migrate an online store to another technology platform based on “gut feel” or the proposed EP works for the competition. This guess work comes in the form of perceived financial gains, derived from a new set of OOTB features or a company wish list. Very little research or testing is performed upfront to validate these additional capabilities have the financial merit. Instead of going down an untested path that may not generate the returns you expect, conduct a Proof-Of-Concept first and let your customers have a vote as to what needs to be done, since they will be the final arbiters of the success of your site.
DRIVERS PUSHING A RE-PLATFORM DECISION
Make sure you understand why a re-platform of your eCommerce technology is being discussed. Know exactly what the problems are, write them down, then make sure they are not found in the EP you’re considering migrating to. The worst decision you can make is to migrate from the old online storefront, only to find out those same issues exist on the new EP. Providing generic reasons to re-platform like, “the old site never worked right”, “it is too complex to understand”, or “it takes an Act of Congress to add new features”, are explanations that are all too vague. Do your homework and mitigate your risks – otherwise you may end up spending a bushel full of dollars and encounter the same set of problems all over again.
Dual Platform Support. When you take on a re-platform project, you support the cost of two EPs, such as maintenance contracts, infrastructure costs and the expense for multiple development and support teams. Additional expenditures may include the time to train staff, learning to use business tools on the new platform and hiring new support personnel. Individual staff members may also be asked to mentor end-users with the new solution as well. Multi-tasking a small staff across two platforms is a daunting task and is a potential for mistakes to occur as personnel are overworked toggling from one environment to the other. Supporting dual EPs is a time-consuming, resource-intensive and costly proposition that can break the budget of the best laid plans. It is important to develop a well thought-out strategy for re-platforming to mitigate risks and eliminate surprises.
Hiring Personnel. The eCommerce marketplace has a large demand for experienced EP staff that exceeds the supply of qualified EP experts. As a result, EP talent is expensive (typically, a low six figure salary in the U.S.), which drives up the cost of hiring and retaining top talent. This trend is expected to continue for the foreseeable future. Regardless which EP is chosen, finding a qualified subject-matter expert can be a difficult and time-consuming task. Alternatively, consider that working with a competent eCommerce solution provider (“ESP”) may be the best short-term or preferred solution for the reasons listed below:
⦁ ESPs come equipped with the industry and product expertise the customer requires for their site.
⦁ The hourly rate for a full-time employee is less than an ESP but the total employee costs will likely be higher.
⦁ There is greater staff flexibility to accommodate fluctuating workloads or part-time needs.
Choosing a Partner. Migrating to a new technology platform will likely require the selection of a new ESP. There is a certain amount of scope creep unpredictability to consider for these project because there will be unforeseen problems the ESP was not made aware of but still needs to address, such as the “discovery” of additional customized code that needs to be migrated. These types of surprises cause large re-platform implementations to be delayed by an average of four months according to a Monetate re-platform study. Make sure the ESP you select has an experienced team whose focus is eCommerce, has subject matter experience on the technology platform selected and can reference multiple re-platform projects. If at all possible, identify the members of the ESP that will work on your project, interview them, then make sure they are assigned to your project contractually.
OOTB (Out-Of-The-Box) FEATURES
Rarely do competing products match up feature for feature which makes an “apple for apple” comparison difficult when estimating the actual effort required to migrate from one EP to the other. Know which features you want to implement before you commit, then determine how many OOTB features are inherent in the EP you’re considering. Any missing OOTB features or any OOTB features that require customizations, mandate that the ESP list what those added costs are so you have a realistic cost estimate. Demanding these added costs be specified upfront helps to alleviate the unwelcomed surprise of additional costs related to change order requests after the proposal has been countersigned.There is a common misconception among executives that lower development costs occur by leveraging OOTB functionality. OOTB features are pre-built for a generic online storefront and require customizations to fit the unique business model and workflows of most organizations. Very few OOTB features don’t require customization, as discussed below:
⦁ Adapt Or Customize. The vast majority of OOTB features require the buyer to either adapt their business processes to the workflow of the EP or customize the EP solution to fit the customer’s business model.
⦁ Customization Cost Dilemma. Customizing a site translates into increased initial costs and future migration expense to carry these customizations over. There is no EP on the market today that offers an OOTB turnkey system that does not require customizations.
⦁ Turn-Key Solution Limitations. Since no OOTB exists that has all the features and functionality built into it as a turnkey OOTB solution, buyers have no choice but to customize or add functionality to the solution. Customizing or adding features impacts costs, time-to-market, future migration costs and total cost of ownership.
Customization and application integration services generally represent the highest cost categories for implementing an eCommerce store. All EPs are complex due to the fact these systems do not stand alone and have connections with existing back-office and external applications. A key attribute for an EP is to have excellent integration functionality because an eCommerce site is just a front-end application that serves up and processes orders, then hands off the orders to the back end applications to process, fulfill and ship. Configuring, customizing and testing each component and interface must be done to ensure the level of service will be duplicated by the replacement platform. Application integration in addition to data migration is a tedious, expensive and time consuming process. More than 50% of the cost of a re-platform project will involve customizations, application integration and data migration.
Considering an EP re-platform? Migration? Cost Analysis? Have other related issues about OOTB features? We would be happy to hold a more in-depth conversation with you on this or related topic. Please allow NetSphere Strategies to help guide you along this process.