Out with the Old and In with the New (1 of 4)

The 2013 Meriam Webster dictionary notes, “In computing, a legacy system is an old method, technology, computer system, or application program, of, relating to, or being a previous or outdated computer system.”  Based on the number of assessments being done by our various technology practices, there is no question that there is a growing trend to replace legacy systems.  It is a continuation of the evolution of enterprise computing; from ledgers, to mainframes, to distributed systems, to hosted web, to the cloud.  In many ways, moving to a new system can be even more challenging than moving from paper to the legacy system that is being replaced.  That is why any assessment of the effort and any map purported to show the path from the legacy system to a new system should be very carefully crafted and contain some critical elements that make it possible to accurately assess the effort to not only replace the legacy system, but also create enough benefit from the new system so that the investment being contemplated can be justified.  We hope that this and the next few posts in this series help you with your assessments.

Spend the first few days of any assessment asking and answering one question, “What should the new system do?”  This is, and should be, different from “What does the current system do?”  You will have plenty of time to ask that question later.  It is also very different from “What reports or metrics should I get out of the new system?”  Again, assessing the health of the processes and the effectiveness of the users is important, but you will have plenty of time to get those answers later in the assessment.  It seems obvious to even the casual reader that an assessment and the development of a glide path from a legacy system to a new system can only be performed if you have a clear target for what the new system must accomplish, but many customers struggle with that concept.  There are some tools that can be very helpful when answering the question, “What should the new system do?”

  • First, survey 5 distinct groups in the organization:  legacy system users who are individual contributors, legacy system users who are managers and executives, members of your legal team, members of your finance team, and members of your IT team that support the legacy system.  This ensures that you have a 360 degree view of the system from within your organization.  You have wide latitude in the questions to include on the survey, but be sure to include:
  • What will be the most important process(es) the system enables?
  • What routine processes should be automated?

Be sure to include your “far out” fringe users in the survey process.  The most innovative ideas in every organization are found in the fringe.

This first critical step in the process is vital to the success of the transition project.  If your current system is successfully enabling and automating all of the processes that it does or should touch, you will find that the answers to the survey confirm that.  The responders will simply parrot back to you what they like about the current system and little in the way of new functionality or automation will be included.  If on the other hand, the system being replaced does not meet user needs and expectations; you will receive a mixture of what they currently like and what they would like to see in the new system in terms of functionality and automation.  NOTE:  Be sure that the goals of your initial survey are clear (process enablement and efficiency) and that you are NOT asking the responders to describe the current system, but instead ensure that they are focused on and describing a future system.

  • Second, schedule over the shoulder sessions with individual contributors and managers who are using the current system. The assessor should be someone who is not familiar with your current system, but is familiar with your business and markets.  Your goal is to document what processes are being enabled and how efficiently they are being enabled.  Don’t focus on “how”, focus instead on “what.”
    1. What is the goal of the process?
    2. What input does the system need?
    3. What processing does the system do?
    4. What is the output of the process?
    5. What indicates that the process was successful?

Don’t be tempted by the trap to begin gathering additional minute, non-functional details such as user interface preferences, timing, problems with the current process enablement, etc.  You will have plenty of time in the next phase of the assessment.  Remember, our goal here is to define a target – what system configuration will meet the goals for process enablement and efficiency.

Assessments that start well usually end well.  There are detours to avoid to ensure they don’t stray from the path, and we will cover these in future installments.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Comments are closed.