Guidelines for Selecting & Implementing an Enterprise System

A quick list of suggestions for evaluating & implementing enterprise systems…

• Consider the phasing/sequencing if you’re changing more than one system.  Modern systems have multiple modules with nice integration and package pricing (if you go for an all in one), but licensing and changing everything together ratchets up risk and organizational whiplash.
• Integration challenges are easy to underestimate and are often ignored by business leaders.  Be wary of “best of breed” thinking.  Structure your system evaluation as a single committee with an agreed approach to minimize political risk of choosing a standalone system for HRIS, Payroll and ERP because those leaders wanted the A+ solution their team loves, rather than an A- which integrates to all the others and gives you “one throat to choke” when something goes wrong.
• Get to a list of finalist platforms with market research (Gartner magic quadrant, vendor input etc), maybe watching demos on Youtube, but skip their bright & shiny onsight demos and take them each through a structured demo where you send them sample data and a list of actions you want to see them walk through (the most critical/common processes AND anywhere you think your process is unique).  You want to do this for all the modules your company might ever be interested in.  It’s some prep work but it’s worth it to sidestep their smoothly scripted tour of all the best and none of their worst features.
• Having a scorecard is helpful for evaluation of each step and overall impressions, ease of use, training/support, etc.  If you think it will be a close call, also score the importance of each line item, to enable you to get to an objective average/total for each system.  These enable price vs. score conversations internally which are a lot more productive vs. favorites and political influence.
• As noted above, if possible, separate the launch dates of the modules to minimize/isolate the risks.  This does create a need for interim integrations/dataloads etc. but in my experience that is a solvable problem WAY easier than opening the risk of issues hard to isolate at multi-module launch.
• My best playbook is to replace the system first whose users are suffering the most today.  They’ll be more motivated to power through obstacles and challenges, which are certain to arise.
• Start with a small number of seats and low expectations in initial conversations – really only need seats for the implementation team and testers/trainers, etc.  BUT lock in pricing for the full number of seats you’ll need in a few years for that first module, and pricing for all the other modules, and an ability to buy incrementally as needed.  As you rise in license count you should be able to get significant per-seat cost savings.  Usually companies will offer this for at least a 24 month horizon as a “coupon in the bag”.
• See if they’ll throw in some goodies (free months, extended time, free users above <x>, free tickets to their user conference for x years, etc).  Especially at quarter-end in a recession if you make them a little nervous they might not get the deal, software salespeople get aggressive with discounts (software has a VERY low incremental cost for them to add users).
• Interview the implementer very carefully, and ask for the ability to interview their team before they’re assigned, whether it’s a third party group or the software co themselves (some don’t do installs, or only for large clients).  An implementer should ideally have experience with all or most of your existing systems and with projects moving to the new one.
• Test as often as is possible, including the loading/reconciling of history 2x+ prior to go-live.  Have a test script to follow so it can be divided/conquered etc.
• Historical data is very valuable to load for reporting trends, etc.  The implementer will try to convince you to skip it but push on this.
• The implementer should have significant reconciliation reports to make the auditors comfortable (they’ll want to see all that as part of the testing at year-end)
• Don’t succumb to pressure to hit a target date.  If it isn’t ready it’s not worth it.  And don’t cut scope from what people were promised initially – not just neutral to what they have today, but ideally better.  Only one chance for a first impression.
• Project management discipline (burn-down graphs etc.) are very helpful – ask the team to frequently re-estimate the remaining work.  (Estimating tech work could be its own set of suggestions really..  Let me know if you’d like help on that front when the time comes.)
• Don’t underestimate training.  You don’t want to do it too early (use it or lose it) but also don’t want to cram it in at the 11^th hour.  I’ve had a lot of success starting training as soon as the final test system is ready – likely 1 month before launch.  If you spread out training over lunch & learns, etc. but keep them going you avoid use it or lose it, and it’s an easier way to digest change.  Lots of printed reference guides of the old way vs. how to do it in the new so they can tape them right next to the screen, etc.
• Contract or get surge resources from the implementer for a swat team on day 1 ready to QUICKLY help answer any questions which pop up or even do some of the work so users can watch over the shoulder etc.  Blackout vacation for anyone who can help on these days – which means probably don’t want to do it around a holiday, etc.
• Have the old system on standby (read only) just in case, and for later research, etc.
• Gather feedback on the first launch so the others can be improved further, and to show you care and you know you just rocked peoples’ worlds on how they do their work.