Busque por posts, artigos e novidades
Fechar
Operations
June 28, 2021

10 things I wish I knew before replatforming an ecommerce operation...

10 things I wish I knew before replatforming an ecommerce operation


Ask anyone leading a digital commerce business what’s most frustrating about digital transformations and they’ll tell you it’s the process of replatforming from one commerce solution to another. Just the thought of undergoing a project of that complexity, cost and effort can elicit a long, drawn-out sigh from those in the room. While it can feel like a daunting and disruptive task (because it can be!), when a replatforming project is done well it can unlock growth opportunities that weren’t possible when you implemented your current platform eight years ago. I’ve learned that with the right approach, you can ensure your replatforming journey is a smooth one. 


As the former VP of Ecommerce at Tommy Hilfiger, I know first-hand what this kind of endeavor entails, having worked on a multinational replatforming effort spanning multiple brands and shifting several disparate solutions to a single, updated platform. As “easy” and quick as many vendors claim it may be to migrate to a new solution, there are many aspects of the process — regardless of the platform — that no one tells you before you embark on the journey. By sharing the invaluable lessons I learned from my own experience, I hope to save others from potential headaches and pitfalls — because the reasons things go wrong are often really predictable and avoidable. 


So, here are the top 10 things I wish I had known before beginning my ecommerce replatforming project:


1. Obtaining stakeholder buy-in can be a challenge


Your biggest challenge heading into this project won’t be selecting a platform vendor, it will be gaining buy-in from your C-Suite and key stakeholders. In the past, projects like this required approval and involvement from a far smaller team of decision-makers, yet as the complexity and scale of replatforming efforts have grown considerably, it is now a much bigger endeavor (and investment) than it once was. Getting all your stakeholders on board and involved in the process from the very beginning is vital to success — if you don’t, you risk significant slowdowns or re-evaluations of the budget and goals when they become aware later on. In fact, over 70% of transformational change efforts fail due to a lack of sufficient communication and organization-wide buy-in.1 Granted, it isn’t always easy to gain a consensus on the project, but here are some tips to help you quickly get everyone on board: 


  • Build a strong business case to clearly demonstrate the value that replatforming will bring in, helping the entire business meet its goals. Your ecommerce business is running, so few executives will accept “It’s just really hard to work with our current platform” as a valid reason. Think about what the business is trying to accomplish in a more holistic way — creating a fluid omnichannel experience for customers; expanding into new territories; broadening the assortment; creating a marketplace — and show how the new technology will help bring those to life.




  • Address stakeholder challenges and resistance early, asking for concerns or conditions at the very start and working to address those issues in the initial planning stages of your project.




  • The executives you’re speaking with may not have technical backgrounds. If that’s the case, don’t focus on industry terms that could be meaningless to them and try to keep in mind what’s important to them. “The new platform will finally allow us to have the homepage personalization we’ve always talked about” is far more convincing than, “The new platform is headless and microservices-based!




2. Know whom you’re working with


Among the most critical decisions you’ll make in your replatforming project is selecting the right partner to help you through the process, and the right one will take the time to get to know your business and your unique needs inside and out. But it also goes the other way — you should plan to interview the system integrators (SIs) at the same time you’re meeting with platform providers so you really get to know your partners on the project. The SIs are so integral to the success of the project that you’ll want to consider not just the software, but the software and the SIs together. You’re not hiring a firm, you’re hiring individuals from that firm. So be selective! 


  • Ask about their track record with the particular software you’re buying. Ask to speak to references who not only have the same platform but were implemented by the same SI. And ask yourself — is there a cultural fit with my team?




  • Insist on meeting your assigned team in advance and don’t be afraid to swap people who don’t meet your requirements. Essentially, hire for each key position, don’t just hire the development partner.




  • Once the ball is rolling, if there’s someone on the SI team who is not working out, let the SI partner know immediately and make a change. I can promise you it won’t get better — just get someone else.




3. Assign a primary decision-maker and know who’s doing what


To keep the project progressing smoothly and to avoid unnecessary holdups, it’s important to designate one (and only one) person on your internal team as the dedicated decision-maker for the project. This person doesn’t need to be involved in every single decision, but ultimately the decision-maker can make determinations in cases where there’s a 50/50 split or when a quick answer is needed. They will also be the primary point of contact for questions from your SI team, so be sure they understand that when conflicts arise, they always have one ultimate decision-maker to land on a solution.


Aside from your primary decision-maker, there are two additional roles to take note of who will have the greatest impact on your project. These are the Business Analyst on the SI team and your Project Manager. The Business Analyst can translate exactly what you need into requirements for developers, and a great one will be the difference between getting what you want and getting something that kind of resembles what you want. Having a great internal Project Manager will also help your team manage the numerous moving parts and requirements along the way. They’ll know the bounds of what they can handle themselves, what needs to be escalated, and can help to convey the tradeoffs of different moves — whether it’s worth pushing something to a second phase, or whether to push the timeline back to get something done now.


One size doesn’t fit all, so be discerning in what you really need




4. One size doesn’t fit all, so be discerning in what you really need


It’s important to recognize that “out-of-the-box” capabilities mean different things to different platforms and, in most cases, a one-size-fits-all approach will not, in fact, work for everyone. Your business is unique and you will undoubtedly have particular needs and requirements that need to be supported by the new platform. If there are “out-of-the-box” functionalities that you want to customize to your individual business needs (or to remove completely), ask early on how difficult it is to make those or other changes. 


While these modern platforms are sophisticated — far more sophisticated and flexible than when you last went through this process seven or eight years ago — it can still be time-consuming to change or remove a built-in functionality. It’s important to be very, very specific on what your needs are and to see them reflected in a demo to gauge how your vendor will handle your specific requirements. You may find that some capabilities are worth the extra time and effort, where others you might do without. Using the “MoSCoW” method can help you prioritize your wishlist of capabilities:


  • Must-haves: We absolutely need these capabilities to meet our business goals;
  • Should-haves: These capabilities would be nice to have if possible, but the overall success of the platform does not rely on it;
  • Could-haves: Capabilities that we could add, as long as they don’t affect the delivery or scope of the project;
  • Would-like-to-haves: We’d like to have these capabilities eventually, but it is okay if we implement them at a later time.




5. Don’t forget this goes beyond just a commerce platform


Your replatforming project not only requires scoping for your commerce solution, but you also need to ensure you’re attaining complete system alignment among all your existing systems of record. A great way to get started with this is to hold a kick-off meeting involving all of the stakeholders who will be touched by this project, which in most cases will be a large group stretching across marketing, finance, distribution, customer service, legal and so on. Each of these stakeholders works with systems of engagement or record that need to be taken into account and assessed in terms of what will change or need to be re-integrated. This is also a great time to ask them what current issues they have with their systems or tools and see if there are ways to incorporate improvements during the replatforming process. 


You’ll want to work closely with your SI to help you outline exactly what will be needed from each of the stakeholder groups over the course of the project and to establish clear expectations. There’s no way around it — you’re going to need help and input from each one of them, sometimes a lot of it. So be upfront and precise about what will be needed, and send them something nice at the end of the project to show your appreciation.


6. The technology should always be driven by the business needs and objectives


As I mentioned earlier, it’s critical to ensure your replatforming project remains closely aligned to your underlying business objectives, from start to finish. In many instances, it is the IT department driving this type of technology initiative when they are often oblivious to the broader needs and goals of the business. As much as we evangelize “customer-centricity”, it’s surprising how often that gets lost when it comes to technology selections and implementations. Yes, in the first phase of your replatforming journey you may have to make tradeoffs between functionalities that benefit your users and those that benefit the customer — this is a challenging transition and you need to ensure your team sees the immediate benefit of replatforming. But that doesn’t mean you should lose sight of the business goals and customer benefits ultimately driving the change in the first place. 


The key here is to ensure the business objectives stay top of mind — even if this means creating posters outlining your project goals and plastering them to the walls. It’s easy to get bogged down in the gritty details, but having something to point to, literally, when your team is struggling for the right direction or grappling over various alternatives will help keep things moving toward the right end-goals.






7. Budget your timing generously


While the initial instinct might be to complete the project as quickly as possible to lessen disruption and prove ROI faster, speed isn’t always a good thing and can jeopardize what you get as an end result. On the one hand, if things start moving more slowly than originally anticipated, you can always opt to scale back scope and push certain features out to a later time to keep your launch date. But in many cases, the best move is to simply push out your launch date to avoid backing yourself into a corner and sacrificing the functionality you’re going to wish you had. 


When it comes to budgeting out a timeline, it can help to create a work-back schedule from your ideal (yet flexible) launch date. Include allotted time and target completion dates for important milestones, with smaller actionable checkpoints along the way. Two areas in particular that always end up taking a surprising amount of time are handling the catalog execution from your current system (and then loading it into your new system), and connecting the new platform to your company’s other systems, like your ERP, for example. You’ll also want to note any dependencies — tasks that can’t be completed until others are done — and factor those into your timing. With your major milestones, checkpoints, and dependencies mapped out, you can start assigning individual tasks to your stakeholders and project leaders so everyone knows exactly what is needed of them during each phase. 


Even with a detailed work-back schedule, it’s important to remember these projects are complex and often take longer than you think. Whatever amount of time you initially budget for, it likely still won’t be enough, and that’s okay. The bottom line is you’re better off going into it with a flexible time frame to allow for a thorough execution that will maximize the impact of your new platform while also allowing for inevitable hiccups. 


This brings us to my next point…


8. Set reasonable expectations, and expect some bumps in the road


Replatforming often turns out to be more complicated than you may have first expected. Your existing systems might prove to be more technically complicated than was originally thought, or you might run into certain capabilities that require custom implementations. There will be things that run smoothly and then there will be those headaches that pop up unexpectedly and bring things to a screeching halt. This is precisely why it is important to set realistic expectations with your stakeholders from the get-go and make sure everyone understands there will be inevitable delays and bumps in the road — especially those stakeholders who don’t have a technical background. They will be eagerly awaiting the ROI from this project that’s costing a pretty penny and may be surprised to learn the kinds of challenges and bugs that can arise along the way, even as you approach go-live. It is critical to establish transparency and manage expectations from the start — and then remind them again, and again, and again — in order to keep confidence high and avoid frustration throughout the project.


The technology should always be driven by the business needs and objectives




9. Be prepared for the resistance to change


You will likely be met with some resistance to change, because, after all, we as humans inherently hate change. As obvious as it may be to you that your organization needs a new, modern solution, there will be those who think the old ways are “just fine” and may push back. No matter how impeccably the new platform implementation goes, it will only be as successful as its adoption across the business. Establishing a change management strategy will help to get employees on board (and literally on-boarded) with the new platform. Here are some tips to get you started:


  • Leverage a top-down approach — get business leaders and managers who are already on board to help support and encourage adoption throughout the rest of the organization.




  • Get your HR team involved, too. They may have prior experience leading change management efforts and have valuable practices to implement.




  • Clearly convey to individual user groups how the new technology will help them succeed and improve processes, both for their own roles and the business as a whole. Also, incorporate a thorough training process and allow adequate time to get everyone up to speed — the more comfortable people feel navigating the new platform, the more likely they are to be supportive and successful with the change.




  • Be empathetic — let your teams and employees know that while this is a challenging transition and may result in adjustments to how they perform their jobs, it will also bring numerous improvements and growth for the company as a whole. Taking part in a replatforming project is a valuable experience for anyone building a career in ecommerce while also providing visibility into how the entire organization works together. 




10. Have a strong UAT leader and test plan


During the replatforming process, you will likely have to balance keeping functionality exactly like it was in your old platform or adapting to the way the new platform does it. While your SIs will have done their own round of testing, you will still want to conduct your own UAT (User Acceptance Testing) to ensure everything is running smoothly from a user experience standpoint.


  • Make sure you have a strong UAT leader that understands the business processes that your team goes through on a day-in and day-out basis — merchandising, content updates, promotions, SEO modifications, catalog changes, landing page creation, etc. Tailor your UAT to focus on the jobs your business team does and validate that the site performs as expected.  




  • Verify transactions in your back-end systems — OMS, ERP, payment, tax and so on — and simulate a close to ensure all the data passes through appropriately. Your accounting department or CFO will likely want to verify the transaction history, as well. Don’t forget to also test other processes like returns, customer service and call center handling times with the new system.  




  • Map out how you will deal with orders that were placed in the previous system.  Will your call center agents have to work with the old system in parallel? Or will you migrate a certain number of orders (e.g., the last 30 days) over to the new system to process returns if needed?




Bonus item, but one that cannot be overlooked!






Performance Test


Nothing can be more disappointing and embarrassing than getting to the end of your replatforming project and going live just to find out that the system cannot tolerate the load. Or you go live and initially things seem fine, but when you reach peak periods the system falls over. Conducting a thorough, realistic performance test can help you avoid these pitfalls. 


  • Make sure you run the performance test with a load representative of what the system will handle during peak times and growth beyond that. This means making sure you have accurate content, the typical promotions running as they normally would, the search rules configured to represent your boost and bury rules and that you design the tests with a representative load of browsing, registration and checkout users to simulate the real-world load on the system.




  • If you are interfacing to back-end systems for OMS, inventory, payment, tax, etc., make sure that these systems are part of the test as well, and don’t forget to simulate some types of failure — for instance, take your tax service down and see how the system responds.




  • Increase the load on the system until it breaks. Know what your traffic limitations are so you can plan accordingly for flash sales or peak holiday periods so you can increase capacity appropriately.




So there it is, the top things I wish I knew before embarking on replatforming ecommerce operations from my past life as a practitioner. What are the top things you wish you knew? 


If you have questions or concerns about replatforming or want to see how VTEX can help? Reach out: [email protected]




Under Armor_VTEX






Calimax_VTEX









The CCX Company, in collaboration with VTEX Commerce Cloud, expresses gratitude for having had the opportunity to enhance its understanding of the advantages, trends, and other elements addressed in the current topic. This article was jointly developed and is brought to you by the VTEX Commerce Cloud team.

Subscribe to our newsletter

Thank you for subscribing to our newsletter.
Oops! Please try again.
Newsletter CCX

Others also liked

Entre em contato pelo icone do whatsapp