·

First –software validation – once the CRP space has been set up and is operational, the first task is to establish a software configuration baseline, so you “know what you got.”  Create a test scenario that, using sample data, allows the team, hands-on, themselves, to step through a basic business cycle and process so the team is assured that it is working as expected, and/or any areas where this is not the case, have been identified and documented.  A vendor support consultant may be helpful at this stage – conducting, in effect, a preliminary training session.  It is vital that the team actually does the work, not just sit back and watch another demo. Use the “to-be” business process maps and documents as guidelines.

o

ERP software is notoriously configuration-sensitive.  This means that the code itself may be well written and execute properly, but that depending on various parameter and configuration settings, the result you get from a given function may not be what you are expecting, or want.  While in many cases, good vendors have in fact delivered software with actual identifiable flaws, or “bugs” in it, our experience is that configuration settings are just as much of a potential problem.  Find both kinds of problems early on, enter them into the Open Issues Tracking log or data base, and keep each of them on the radar screen until it is resolved.

o

Identifying these kinds of problems as early as possible will give others a chance to remedy them without heroic efforts while allowing the CRP team to move ahead on schedule.

o

      ·

Software configuration established and tested – a Best Practice CRP does not involve setting up new software configurations, then running them, and then repeating the process over and over.  The software vendor should be able to furnish a pre-configured version of his software that is close to what your team’s To-Be vision is. (If you aren’t sure what the To-Be vision is, then you aren’t even close to being ready for implementation!)  Install and test this one, making minor adjustments if/as needed.  We are familiar with too many projects where the entire original implementation budget was consumed and over run by this activity alone – months and months of changing the configuration, then running through the entire business scenario / process again.  Exhausting, demoralizing, discouraging, self-defeating, fantastically expensive – otherwise just fine…!

o

      ·

Repeat until stable – if bugs or missing, but expected functions are identified, unless they are minor, repeat the validation process until the software is stable and the team understands how it work, and that it DOES work as intended, and that it DOES support the To-Be process vision.  It is OK at this stage to only have a sketchy idea about the implementation, and the details of the to-be processes.  The team needs to know just enough to understand the software and make sure it works as they understand.

o

      ·

Landmine identification – as early in the CRP process as possible (or before the CRP starts), the team should identify as clearly as possible any potential issues, which if unresolved completely, could de-rail the whole project.  We call these “landmines” because they have the potential of blowing up, of undoing weeks of hard work, or worse, of seriously damaging the company.  These could be major policy issues, a potential acquisition, inappropriate leadership, or an already underway major industry change – anything that could prevent a successful, smooth transition to the new software.  Most of the serious implementation disasters we are familiar with have one or more real, serious landmines that just were ignored, swept under the rug, “not my job” or otherwise not resolved.  Deadline driven teams can easily be pushed into moving ahead even when things are not ready – almost never with a good result.

o

Open issues tracking – it is critical that every possible potential difficulty – anything that could cause the live use of the system to cause a problem – be identified, and tracked in a visible way until it is resolved.  This is a key part of the CRP team’s activities.  The project manager, or a specifically assigned team member, must “ruthlessly” pursue resolution of these as promptly as possible, remembering that the CRP team’s high priority may not be another person’s hot priority.  Don’t let any of these languish in someone’s uncompleted Task list, on a Trouble Ticket, or Inbox because they are busy.  It is the regular, energetic follow-up of open issues that is more important than the fanciness of the IT tool used to keep track of the information.

o

Initial data conversion – we prefer doing an initial data conversion, using partial or subsets of live, real data to create a set of hand-matched data that everyone already understands.  IT professionals will sometimes claim to be able to convert any data but it just isn’t true.  Why?  The “same” data in two different systems may be handled differently, giving it a different “meaning.” By doing it by hand first, the team will completely understand these often subtle differences.  We have never found an exception to this experience, often glossed over by non-users of the data, who in all honesty do not grasp these subtle differences, but that can be critical in some cases.  This deeper understanding can allow the team to help design and plan the conversion process – placing the ownership where it is most effective – with the team, not IT “experts.”  What YOU mean by “credit approval” may not be the same as what the software “thinks” it is.

o

Detailed to-be process validation and planning – this is THE critical part of the CRP process.  For this the team steps through every part of the to-be business processes, identifying every issue, policy level, procedural, work flow, and anything that affects who owns what parts of the process.

o

Example:  The As-Is business process calls for new customer accounts to have their data gathered by a customer service rep, written up, then forwarded to someone in the credit department who then approves it and enters the new account in the system.

o

The To-Be process allows the customers to open a new account by themselves via an Internet accessible web site/page.  Who is responsible for credit approvals?  The CRP process must identify and resolve this question – and all others like it – until every step in each process has been worked through, whoever is needed consulted, approvals obtained, policy conflicts resolved, documentation updated – whatever is required.  Do not let schedule push you ahead regardless of actual preparation progress.  If needed, schedule extra work sessions, enlist additional help to offload team members in their regular jobs to catch up.  Take the rug, under which problems can be swept, out of the CRP work room.

      ·

Training materials and plans – how to adequately train everyone so the Go-Live event and subsequent business operations will be smooth and uneventful, free from lingering unresolved problems.  This includes who the instructors will be, what training sessions will be required, when, and who the participants will be.  The materials, of course, must be company-specific to be effective, although they can be adapted from vendor-furnished material to some extent.

o

      ·

To-Be Adjustments - to the To-Be process maps and work flow documentation where needed.  Some of these will be improvements, and some may not.  There may be (new) workarounds or other less-than-desirable actions required.  Many new software systems involve some trade-offs – powerful new capabilities but loss of familiar, custom-built functions that did the old system did well.  Much is learned during this work, and changes to original visions, plans and understandings are inevitable, even desirable.

o

Validated software configuration – the team will know what the software does, how it does it, and be able to say with confidence how the business will succeed using the new software’s capabilities.  This is a critical aspect to eliminating the risk of the project.  This is NOT a technical issue.  However, complex parameter settings and control tables that control the software’s functioning may be a technical factor.  Large ERP systems can have thousands of settings, hidden away, but controlling functions anyway.  The team does not have to understand how these work – how could they?  Typically the vendor does not have anyone who understands them all either; no human being could – just make sure the configuration you have works in a way you understand and control.

o

Tested, validated data conversion plan – data conversion, both software performed and manually entered, requires multiple iterations to overcome a wide variety of often-subtle challenges.  The only way to prevent the wrong kind of surprise after Go-Live day is to prepare, run / perform the process, test and validate the results until it works as well as possible.  This is another critical risk-elimination step, often the source of serious problems after Go-Live but fortunately completely avoidable.  Key aspects of data conversions to bear in mind:

o

Software performed – required for all large volumes of data; careful design of the process (there are excellent conversion mapping tools available, but apply thought carefully to their use), then test, re-test, and re-re-test the results by using the data in simulated live use.  The key – can the to-be work flows and business process steps be correctly, reliably performed with the converted data?  Data conversion software does not know the answer to this question, nor can it.

o

Manually performed – this is data that is printed out, possibly adjusted in some way and then entered by direct data entry process into the new system.  We recommend this method everywhere possible, because problems stemming from these data are rare.  Even with sizeable volumes it is possible to hire temporary help or otherwise “crunch” the data into the new system in a short time period.

o

Go-Live Cutoffs - These are always difficult especially for 24/7, global businesses.  However, careful, thoughtful planning will usually enable the implementation team to separate truly high-volume, transaction data from more permanent data so absolutely everything does not have to be converted a few hours before the Go-Live event.  Some ways that help:

o

      ·

Convert through a date before Go-Live ahead of time.  This means only the last few days of transaction data has to be converted at the last moment.

o

      ·

Stratify by degree of activity.  Some groups, contracts, products, services, etc., are inevitably less volatile than others.  By converting the slower-moving data ahead of time, the last-minute conversion will be shorter and quicker.

o

Volume testing – the software has been tested under high-volume circumstances, so possible response time problems have been flushed out, fixed and will not cause people in the company to be unable to do their jobs because the system has gotten bogged down.  This has been a cause of a number of serious implementation shortfalls and difficulties and must not be neglected, even though it is hard to perform.

o

Well publicized, major ERP implementation failures have multiple causes.  One of the most horrifying, though, is that “everything works” but the system collapsed due to major overload on key servers, network bandwidth, or other killer factors.  Just because computers hardware has gotten a LOT faster and MUCH more capable than it used to be does not repeal the Computer Law of Nature – which says that ANY computer, ANY network, CAN be overwhelmed.  Make sure you find out BEFORE Go Live day.