This blog was adapted from a live expert webinar with our partner, Open Sky Group.  If you’re in the supply chain industry and crave a templatized approach for scalability, you’re not alone. Standardization is winning out after years of...

This blog was adapted from a live expert webinar with our partner, Open Sky Group. 

If you’re in the supply chain industry and crave a templatized approach for scalability, you’re not alone. Standardization is winning out after years of customization. But there’s still a disconnect between what companies think a solution should look like and how it’s actually implemented. 

This is where mock Go Lives come in: They mitigate implementation risk by reducing reliance on actual Go Lives as replacements for proper regression testing. Renewing focus on quality assurance (QA) lowers the likelihood of shortcuts and leads to all-around more successful implementations.

The Disconnect: Idea Versus Execution

In an attempt to reproduce time-worn processes, companies have for too long opted to implement heavily customized warehouse management system (WMS) solutions. 

But if businesses simply reproduce the same things they’ve done for years, why are they implementing a solution in the first place? More customization means more real, long-term risks to system performance, stability, and upgrades. Instead, implementations need to match business needs.

Supply chain industry veterans aren’t always comfortable with change. But change isn’t about introducing business risk: It’s about giving everyone a seat at the table, making changes win-win instead of lose-lose. Change management actually minimizes risk.

SaaS providers implementing WMS need to understand clients’ ultimate business objectives — and talk to clients about those objectives. When business, IT, and QA functions converse as early as possible, WMS implementations are more successful. And the more successful implementations you have, the more you understand this crucial step in the process.

Consultants who have worked with multiple clients across different sites see it all: The good, the bad, and the ugly of WMS implementation. The power of learning from an experienced vendor is that they know where to streamline for real business success. They have a bird’s eye view.

Goodbye Upgrades: How Strategy Impacts Solution Design

When you have a bird’s eye view, you see and understand industry-sweeping changes. One such change is the fact that a more regular cadence of incremental iterations may spell the end of upgrade culture.

In the race for cloud-native architecture, hosting, and centralization, software vendors and original equipment manufacturers (OEMs) alike are angling for versionless releases. The implication of this shift is that organizations need an increasingly positive view of change and should be able to adapt accordingly:

On-prem to on-prem: Traditional on-prem upgrades are common, with heavy customization. It’s not unusual to see clients up to five years behind the curve on strategy — having skipped multiple major version releases — but who also want to migrate custom code bases with the upgrade. On-prem to SaaS: Organizations ask which customized processes are truly business-critical: Should they be migrated? If they are business-critical, how will they be migrated to the new SaaS environment?The aim here is twofold: (1) satisfy business-critical requirements with standard features and functions in a templatized approach and (2) eliminate as many customizations as possible without increasing risk. This shift is too major to be an upgrade: It’s an all-new implementation. SaaS to SaaS: This migration should already entail a templatized solution, with organizations utilizing standard features and functions out of the box. It’s these organizations that can benefit most from automated regression testing — easily and efficiently. Regular testing means organizations stay current, with new iterations almost seamlessly providing features and functions, instead of building on top of heavy customizations.

Whatever the type of migration, fostering a culture of innovation and change is essential. But you need proper testing to support the changes.

Deprioritized Regression Testing Increases Risk

Just about everyone can hold their hand up and say they’ve resisted change — even if the strong operational ROI of the change is clear. But we often perceive change as taking too much time and effort to test.

What happens when organizations don’t embrace necessary changes? Either they don’t improve operations, or they hesitantly make the changes but without regression testing. And even if organizations are willing to make the changes, they let their confidence in thinking they can fix any fallout override the need to test.

The key to a successful implementation isn’t merely having a can-do attitude toward fixing whatever comes your way. Rather, it’s knowing you’ve done everything you can do to avoid problems by minimizing risk so that you can go home at the end of the day.

One of the most effective ways for businesses to decrease risk is to give QA leadership a seat at the table. Digging deeper — earlier in the process and with more upfront collaboration — minimizes the chance of avoidable bugs popping up during Go Lives.

A Coherent Testing Strategy

Many companies see Go Lives as a replacement for regression testing. They use mock Go Lives as quality checkpoints, assuming that if an issue doesn’t show up, things should work well in production. But this isn’t true.

While mock Go Lives are an important part of testing holistically, they’re not a stand-in for any other form of testing. Testing is necessarily part of any cohesive quality strategy and takes many forms: 

Regression testing to understand whether new changes will adversely affect existing business processes Scalability testing from the perspectives of performance and volume Concurrency testing to understand system and supporting application infrastructure boundaries, so businesses know when they’ve gone too far for a system to handle User acceptance testing (UAT) because there is no replacement for business expert sign-off on system changes Physical testing, which includes mock Go Lives on physical system infrastructure and processes

Businesses need all of the above for a QA strategy that reduces risk. It’s not feasible to rely on any single form of testing in isolation. Regression testing can’t replace acceptance testing, for example, but it can make acceptance testing more efficient. 

Having the proper tools, like test automation, helps organizations ensure the success of their testing.

Mock Go Lives Are Testing

Sometimes customers assume mock Go Lives are like conference room pilots. But implementing a system from a conference room is no guarantee that it will work in production. Mock Go Lives are highly intricate, testing not just the system but every detail of the process. 

Going through multiple mock Go Lives encourages a process of ongoing learning and improvement that closely mirrors a future where regular, iterative testing is the norm. Organizations that test a system’s ins and outs best align business objectives with software that works as intended.

Company cultures that challenge existing processes during upgrades benefit much more in the long term than those that attempt to recreate what they’re already doing. These proactive cultures are a wellspring for the curiosity and innovation such a future of iterative testing demands.

Are you interested in learning more about implementing test automation in your warehouse system implementation? Check out more of our blog posts or learn more about the Cycle platform.

The post Go Lives Are No Replacement for Proper Regression Testing appeared first on Cycle Labs.

---

View Entire Post