Retail Solution Implementations
Fact vs. Fiction
by John Lawing and David Birdsall
After weeks, months, or even years of research, demonstrations and requirements gathering, your company has finally decided to implement a new software system. The new solution may be replacing a simple process area in your business and have relatively few organizational impacts, or it may be replacing a very complex set of processes with touch points across your entire enterprise. Either way, users are going to have preconceived notions of the new system and the implementation process. Some users will rely on horror stories based on past solution implementations, while others will claim the last system implementation was challenging (and expensive) but ultimately proved to be a wise move for their company.
Based on significant experience implementing software systems across multiple solutions and with different companies and implementation partners, Parker Avery has identified some of the most common thoughts regarding software implementations and we have classified them as F A C T or fiction:
The New System Will Fix Everything
The New System Will Make My Job Easier
The New System Can Be Implemented Right Out of the Box Design is Hard
Data Conversion is Easy
Let's take a look at these possible misconceptions and explore how understanding and proactively addressing them can help guide your own system implementation planning.
Fact or Fiction: Everyone Will Be in Agreement About the New System ￼
During the discovery period, several different types of business roles become exposed to the software, and all of them may have different interests and expectations:
- Upper Management: "We need more visibility to the information and better reporting across the business. This solution should make our company more productive and allow us to more efficiently use our resources. Overall, this system will improve our bottom line (and get me a bonus and recognition)."
- Business Area Managers: "My boss tells me that we need to implement this software. I think overall it's a good thing to do, but I am worried about the impact it will have on my direct reports. I really want to get the new system implemented successfully to impress my boss (and get more visibility to leadership and a possible promotion)."
- End Users: "My manager tells me we have to implement this software to help the business as a whole, but I am very comfortable with my current process. Yes, the current way we do things has some issues, but at least I know what they are and can work around them comfortably. This new system seems to be a lot more work. I am one of the most efficient users of the way things are done now, and I am afraid that the new system will change the way I work (and make me much more expendable)."
Depending on the end users' role and sometimes tenure within the company, opinions (and motivations) about what needs to be fixed can vary greatly. Many employees recognize the issues, but may not believe that the system will solve these issues or work better than their existing workarounds. Such users may feel that upper management – or the department responsible for implementing the solution – does not really have a grip on the existing processes, so expectations and acceptance of the system can vary greatly. A strong Change Management program instilled at the very beginnings of an implementation project can help align expectations of the system throughout the organization.
Once the decision is made to pursue a new software system, things immediately start to happen including: implementation partners and consultants appear seemingly out of nowhere and begin setting up meetings and workshops to prepare your business for the implementation; all sorts of sales people begin talking to you about how wonderful their software is and how it will improve your business. There is some truth to what they say, but early in the process, they often do not give specifics about how these improvements will be accomplished. From these initial meetings, your company's employees start to feel really good about the software and begin to share the wonderful news.
As is the case with kids playing a game of telephone, where they whisper something in the first child's ear and one-by-one they whisper it to the next child, the expectations of the system morph greatly as the news spreads. Before long, the abilities of the system can be exaggerated, and users begin to think that the software will fix everything wrong in their current process. The longer a selection process takes place, the more the new system becomes the perfect solution for all of the company's issues even before the system is designed.
It is a lofty and worthy goal to find a system that will fix every one of your company's problems, but in reality, there are several factors that can prevent a perfect solution from being implemented, including timeline, budget, resources, organizational resistance, system functionality and business process constraints.
It is expected that users will think a new software system will make their job easier. If a company decides to implement software that is doing the exact business process as they do today but with some automation, then the users may in fact have an easier job. Or the job may not necessarily be easier, but in fact more efficient, resulting in greater productivity. In reality, a software implementation is meant to enable value-add improvements to their current business processes, such as decreased manual data entry, reduced lag in systemic processing and more user-friendly user interface (UI).
Typically, when users begin to use a new system, the main realization is that their jobs are not easier or harder, but their jobs are different. This is because new systems are implemented so that a business can capture, process or handle data differently or more efficiently. With the more complex software implementations, many different business roles are often using the system, and it is likely that new integration points now eliminate many former manual processes.
On the flip side, a more advanced system will be able to handle more data sets than the retiring system, and users may have to enter different or additional data than they have had to enter in the past. Additionally, the system may fundamentally change the way their business processes are performed.
As such, some roles may actually become more time- intensive than with the current system, while others may be less time-intensive. In fact, roles formerly appropriate for business processes for the replaced system may have to fundamentally change with the new solution. However, overall the goal is to have much better visibility, productivity and cohesiveness across the company.
Additionally, any time a new system is implemented, users have an adjustment period. Since it is a different system, it takes time to learn how to use the system and what is required of their role in the system.
A prime example is in the personal computer market today. Many working individuals have learned to use Windows-based personal computers and laptops. These users are very comfortable and proficient with the systems, but the popularity of many Apple devices and the iOS operating system have influenced many individuals to switch to MacBooks and other Apple computers. The first few days are typically a huge adjustment, with many users second-guessing why they invested in a technology with which they are so unfamiliar. Users formerly very adept in Microsoft products suddenly have to do things quite differently. Most tasks in iOS – while they in essence do the same things as the PC operating systems – at first often render the user unproductive and somewhat helpless. However, after a few weeks (and sufficient Googling or formal training on iOS shortcuts, tips and tricks), most people become completely comfortable with the way the Apple technology works, and many find the differences more appealing. The same concept applies to any new type of software introduced to users, who have not used it before. It just takes a little bit of time and education to acclimate to the new software.
One of the major marketing points for software companies today is the concept of the "Out of the Box" (OOTB) solution. These systems are marketed as software that allows companies to implement a solution in an extremely quick timeframe with minimal design changes and enhancements. The vendors' presentations, software demonstrations, client references and RFP responses even seem to provide solid evidence as proof of these statements. Customers are led to believe that in one day, a representative from the software company will come into the office, install the software, and users can immediately begin using the system. Unfortunately, it is not that easy.
Every retail company has slightly different processes, and these processes are different for a reason. It could be due to having different roles in the organization or different organizational structures, unique product or service lines, special testing requirements, different overall corporate strategies, or any number of other reasons. OOTB solutions often also incorporate industry best practices, yet many companies feel their own business processes still work better for their needs. As a result, OOTB solutions can serve as a good starting point if the company is willing to adapt current process flows to align with the OOTB solution, but time and resources need to be allotted to allow for enhancements to the OOTB solution.
Introductions have been made, initial high-level discussions have been completed, and now, it is time for the major decision-making phase of the project, detailed design. Most people will agree that this is the most intense phase of a project. Different business representatives, software representatives, and support resources all pile into a conference room to layout out the future process in the selected system. Many factors can contribute to the complexity of this process, including consolidating processes across banners within a company, getting agreement among the different roles within the company on each of the business processes, and aligning current processes with the selected software processes.
This design process can sometimes be simplified if the available client resources have deep understanding of the company's current processes. Additional simplification of the design process is possible if the software company provides pre-defined best practice processes. However, using these pre-defined processes are only effective if the business areas are willing to change their current processes to align with the industry best practice processes. Many clients say they want best practices, but when it comes to changing key legacy systems or long-standing business processes, clients often deviate from these best practices. When this happens, the design process can become lengthy as the team works through the issues and determines how to merge the old processes into the new system.
Engaging only internal resources can make the design process hard because these individuals may have been running their business for the same way for the past 15 or 20 years. It is in these types of scenarios where bringing in an outside opinion becomes very effective. While internal resources typically have deep knowledge of company specific business processes and policies, they may not be familiar with best practices or what other possibilities exist. Outside implementation and design consultants can bring this objective opinion into the design process and help companies take advantage of the best practice functionality that is built into the system, and ultimately enable the company to fully benefit from the system.
One of the biggest mistakes that occur during detailed design is the estimation of integration with existing systems. During the process design workshops, integration resources make note of any required integration work. From a business user perspective, integration is easy. They want a piece of data, and the system automatically pulls that data. Unfortunately, there is often a lot of work that happens in the background to design and build that integration of data.
Since the data conversion design process cannot usually begin until the business process design has been completed, the integration delivery schedule often becomes very compact and unrealistic. During integration design, there are many factors that determine the difficulty of the integration, including the number of required integration processes and the complexity of each of those conversions. In many cases, there is not a current source system for the required data. So the data must come from spreadsheets or be manually built. In other cases, the data is coming out of older systems that may be at a different hierarchical structure, contain unstructured or bad data, or need complex transformation in order to work with the new system. All of these scenarios require significant time and effort to resolve and should not be overlooked during project planning.
Every software implementation is different due to the new system's functionality footprint, the client's business processes, and integration requirements. Most times smaller implementations can avoid some of the bigger roadblocks, but the larger implementations typically encounter most, if not all, of these challenges.
Understanding these common "Fact vs. Fiction" misconceptions during your project- planning phase can lead to a much smoother implementation. In addition to these few topics, there are many other factors that lead to a successful implementation. No matter the size of an implementation, it is also vital to make sure that you have a defined project management structure led by experienced and competent individuals, a strong business case, a detailed change management process, stakeholder and end- user support, and a thorough vetting process for any implementation partners. All of these things will help you enjoy the most efficient implementation possible.
If you’d like to learn more about our vision or understand how you might take advantage of this strategy, contact us at Contact@parkeravery.com or call 770.882.2205.Download PDF Version (2 MB)