I have spent a lot of my career fixing botched implementations. And I have seen it go perfectly...
Write your requirements for the system in plain English bullet points. Give this to vendors.
Write a plan of what you would like to see on the demo. Btw you want to see the boring stuff, not the colourful charts. Book a whole day. Take a person from purchasing, accounts, sales. Get them to create a sku and a supplier, get them to buy it. Get them to receipt it, get them to show the accountant how that affected the ledgers. Move it sell it, collect the cash etc. Now you know something about whether it will fit and whether you rate the vendor.
Could the company afford it costing twice what you planned? If not then maybe ERP is not for you.
You need a test system.
Allocate a lead person for every department. Let's call them the power user.
At key check points the vendor should want you to do testing. Write a test plan for end to end transactions like my demo example. Get your power users to do the test, this gives you buy-in, sign off and critically, job specific user training.
Allocate a huge sum of money for user training. Trainers are expensive. Job specific training is the only thing of value. There are often several ways to do something, only train in the one you have chosen.
The trainers need to be on-site for all of go-live week. Budget for this.
Don't train too early
Go standard, don't customise, work the way the ERP wants
On a phone but this feels like it would make a blog post!
My one addition -> focus not on the new things the system will do for you (which is what the bosses are into) but focus on what will change / be lost compared to the system you are using.
Oh, we can't edit transactions anymore ever? OUCH. Everyone edits all the time.
People should not be able to edit transactions. Mistakes should be revised with a separate (correcting) transaction, for auditing and integrity purposes.
I don't think you've worked with ERPs or auditors. This is how Netsuite and Oracle actually work, and the two combined own more than half of the ERP market.
The time for editing a transaction is before it gets committed to the ledger. In Netsuite, this is accomplished by requiring (or allowing businesses to set a requirement) for entries to be reviewed and approved before posting.
Having the transaction log lets auditors audit the process by which the company generates its financials, and to identify where mistakes were made (if any). It's invaluable to both auditors and their clients, and its saves thousands of man-hours to be able to do this.
ERPs that allow editing maintain a transaction log of edits.
What users like about editing is they can run reporting for LOB's, then edit based on feedback / coding / miscoding, then rerun reports that are clean from a detail perspective without 100's of in/out offsetting entries you get when folks have to post reversing entries to back out errors. It's actually easier to review for correctness if you don't have to wade through 100's of junk entries that are reversed out.
Different systems allow edits in different ways. Some are journals under the hood with the initial and reversing entry marked to hide visibility for non audit situations. Others maintain a log of edits, the date and time and items edited.
All of this can be turned off at a permission level. Generally no line staff can edit, and closing a period to all edits is up at the top. And even when users can edit, they are always locked out as periods close.
Yes - auditors do flip out if you edit into a closed period (understandably because they have to re-audit it). Users have gotten that confused with auditors not liking changes in periods that are not closed - actually - auditors want users to prepare the most accurate financials possible to submit in as simple a format as possible. Editing often allows that.
Anyways, netsuite allows users to delete reversing journals from the original entry, oracle allows editing GL distributions on a posted entry (and uses an audit log for this) because if you had to deal only with reversing entries to fix stuff or had to reverse reversing entries to fix stuff it would drive everyone crazy.
Years ago I sat through presentations by three or so consulting companies proposing to manage an implementation of Peoplesoft. At the end, I reviewed the notes, and found that all of them essentially said, "We're going to fit your processes in Peoplesoft's way of doing things."
You want to make an ERP vendor (better: the ERP implementation consultants) sales rep nearly slip into a coma thinking about the giant boat they're going to buy with the commission check? Tell them "we're a special snowflake company with our own magical business processes, and we need you to adapt your software to our business. Because we know more about business than you."
You probably don't. And even if you do, adapting your business processes to how the ERP does it will probably make things like inter-operating with other vendors and managing compliance much easier.
Write your requirements for the system in plain English bullet points. Give this to vendors.
Write a plan of what you would like to see on the demo. Btw you want to see the boring stuff, not the colourful charts. Book a whole day. Take a person from purchasing, accounts, sales. Get them to create a sku and a supplier, get them to buy it. Get them to receipt it, get them to show the accountant how that affected the ledgers. Move it sell it, collect the cash etc. Now you know something about whether it will fit and whether you rate the vendor.
Could the company afford it costing twice what you planned? If not then maybe ERP is not for you.
You need a test system.
Allocate a lead person for every department. Let's call them the power user.
At key check points the vendor should want you to do testing. Write a test plan for end to end transactions like my demo example. Get your power users to do the test, this gives you buy-in, sign off and critically, job specific user training.
Allocate a huge sum of money for user training. Trainers are expensive. Job specific training is the only thing of value. There are often several ways to do something, only train in the one you have chosen.
The trainers need to be on-site for all of go-live week. Budget for this.
Don't train too early
Go standard, don't customise, work the way the ERP wants
On a phone but this feels like it would make a blog post!