Recently, we did multiple reference calls for a client looking for a full platform of cloud-based retail solutions and a common comment we heard throughout these calls was, “whatever you have budgeted for Change Management, double it!”. One retail CIO, followed up “sorry, let me correct myself on my previous statement, triple that budget.”
There are multiple factors that drive change in retail Information Technology (IT) projects, but all require changes in the retail systems (processes, people, and technology) to be successful. These collective changes and how they are made to the system can be called Change Management. When moving any Retail solution to a Cloud environment, whether SAAS (Software as a Service) or PAAS (Platform as a Service), Change Management will take on even more importance as any out of the box solution will be built on Retail Best Practices.
With that said, a challenge is that most Tier 1 and 2 Retailers will have 10% to 20% of their current operating processes that are not based on Best Practice. In such instances, if the Retailer is looking to migrate to a pure “Out of the Box” deployment, they will have to create new retail processes and redeploy people.
Lastly, Cloud computing allows system integrators/consultants to be more agile in deploying/recommending functional improvements, however it requires a consistent change management process that is not discarded after initial implementation.
What drives Change in Retail
Prior to any project, we sit down with the project team and stakeholders of the retailer to identify the forces driving the change. Identifying these drivers up front is a required activity to set up strategic objectives and project goals that the team can mobilize towards. Change is painful, even more so in retail and understanding why it is necessary and the challenges that are being addressed, will help keep the team focused and motivated throughout the project journey. Typically, we see the following three types of change, with sample specific drivers.
- External Change Drivers
- Consumer behavior and expectations
- Market Contraction
- Economic shifts
- Product Obsolescence or invention
- Management Change Drivers
- Profit objectives
- Brand extension
- Shareholder value
- Market share
- Customer growth
- Channel growth
- Internal Change Drivers
- Operational inefficiencies
- Obsolete or replaced technology
- Recent acquisitions
With that said, most projects in the retail industry are driven by multiple factors and many are inter-related (i.e. “competition” from online retailers has changed “consumer behavior” in shopping and has shown technology and process to be “obsolete”). Once a retailer uses these drivers to identify their goals/objectives they are ready for the change.
What are the People, Process and Technology changes needed in Retail
When Shoppers purchase a new PC or appliance, they essentially just need to “Plug” it in and are ready to perform whatever operation they want to execute, “Play”. However, for Tier 1 and 2 retailers (and even most Tier 3 retailers with revenue over $100 million), most enterprise solutions are not “Plug and Play” and require Change Management for the following reasons:
- Modern Commerce IT landscapes support analytical and strategic decision making whereas in the past these solutions were meant to be execution tools. For example, in past a retailer could decide a suggested order qty (SOQ) on a piece of paper or excel, and then enter into a purchase order management system, where as now POS sales data is cleansed, sent to forecasting tool, which sends demand data to replenishment tool that takes into account on hands and on orders to automatically create an SOQ that is interfaced to the purchase order management solution
- Apart from some store systems and warehouse management solutions, most Retail solutions require some sort of in-depth training and skills partly because of their powerful downstream affects. This may not be easily seen when making a decision in the silo of one solution. Best practice store and warehouse systems, will also have major downstream affects, but most Retailers will fool proof these systems (which is also a function of Change Management) so mistakes cannot be made, are caught through an auditing process, or are mitigated in another manner
- Most Tier 1 and 2 retailers became Tier 1 and 2 by having previous iterations of innovation that will not be replaced (i.e. implementing solutions to support eCommerce, financial auditing, forecasting, price and weather optimization, etc.). There have always been “Drivers for Change” hence most of these retailers have grown and matured with specialized systems across their technology landscape. Whatever new solution is being implemented, it should continue to provide and/or ingest data and information from these legacy applications
Because retailers cannot just “Plug and Play” a solution, they will need to change the three facets of any retail system: People, Process, and Technology:
- “People’s” roles and responsibilities will change when using new processes and technology
- Operating “processes” may need to change because a manual process is now automatic, or vice versa. Or whole new processes need to be created because there was no access to new functionality. Lastly, processes can also change because better and new information is available
- The “technology”, by definition in a new implementation, is already changing and will affect “people” and “processes” and the whole IT landscape. If a required function will not be supported by an “out of a box” feature or a new process or role, so a retailer may need to create a technological tool that is outside the current solution. In these cases, Micro Services can be used to provide the necessary real time exchange of data, but a new sub project may need to be initiated to build out or acquire these external new tools
Gaps between current retail operations and Best Practices
We assume that most Tier 1 and Tier 2 Retailers operate using Best Practices, but reality is that there are very few organizations that are 100% best practice. From our experiences, even in the best run IT operations, 10 to 20 percent of retail operating processes would not be considered Industry Best Practices. These unique practices may be outdated bad habits adopted over time, but sometimes they may be the “secret sauce” for why that Retailer is successful (We had a client with unique customer financing options, that was their “secret sauce” and could not be supported with an out of box solution). In either case, a thorough Gap analysis will need to be completed and owned by the Project Team and Stakeholders.
The process to analyze each function should include the following:
- Define key retail functions that need to be addressed
- Identify Upstream and Downstream dependent systems (people, processes and technology) and corresponding functions that will be affected
- Document and review of current and/or planned business processes
- Compare current/planned business processes to Best Practices and denote Gaps
- Develop and agree on new solutions whether a change or a combination of changes to People, Process or Technology (for SAAS solutions this may be building or acquiring external systems)
In a PASS environment, technological modifications to base “out of box” retail solutions are more acceptable. But modifications cost money to produce, increase the difficulty of installing future releases of the base system to the Cloud, and increase implementation risk. Consequently, modifications should be limited to only those that are critical to the business or provide truly overwhelming benefits.
Sometimes, we kick off this Gap Analysis exercise (sometimes called “Conference Room Pilot” or “Business Impact Analysis”) prior to an implementation even starting, as most of the Best of Breed retail packages use known best practices. Retailers like this as they often can “jump start” the change management process even before the formal implementation project gets started (i.e. previous clients have engaged us to begin this process as they finish selecting and negotiating with their preferred solution provider).
If this activity is done after selection has been completed, the Vendor will be included and we often will set up a “Lab” with an out of box base retail solution, so the project team will have a hands-on experience with the new tool as we identify Gaps.
Consistent Change Management even after implementation in a Cloud Environment
The beauty of a SAAS based solution is that retailers will not have to worry about deploying upgrades as updates to the software are made automatically and deployed by Vendor/System integrator once internal Quality Assurance (QA) is complete. However, with this benefit retailers will need to create a process to test and ingest these changes as they are communicated in a Vendor’s release notes (one SAAS Vendor we work with provides software updates about once a month). This is a form of Change Management as well.
Creating automated test scripts and a uniform process to identify if these retail software updates will require changes to upstream and downstream processes, people or technology is imperative in a SAAS environment.
Typically, in an on premise or PAAS implementation, once a new system is fully implemented, users will only see changes three times with the new system:
- Minor Vendor patch updates for bugs, typically require minimal, if any, change management effort as a fix is to make system work as designed
- Major Vendor patch updates for bugs, typically should require minimal, if any, change management effort as a fix to make system work as designed, but if fix big enough, may have upstream or downstream effects
- Vendor Version upgrade (typically retailers will wait a few cycles between upgrades to implement newest version)
Conclusion and Change Management Framework
In this article, we have introduced the importance of Change Management when implementing Retail Cloud Solutions. We have also covered common drivers for Change as well as the three components where the change will be enacted: People, Process and Technology.
In future blogs, we will review the various Change Management Methodologies (i.e. ADKAR, Kotter, Lewin, Bridges etc..) that we have utilized in previous projects based on the current and future state requirements identified in the Discovery phase of the project.