Ignoring whether or not we should (we’ll put a lot of thought into this), does anyone have any tips on what to do or avoid to make a project like this a success?
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.
So I will add this tip. Keep your user roles simple. Start with the principle of 'least privilege'. It is so much easier to add access than remove it.
And see if you can keep some of the key minimum editing in or your users will hate you forever. I've heard comments 5 YEARS later about this issue.
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.
The implementation was painful enough even so.
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.
> Go standard, don't customise, work the way the ERP wants
I've heard this quite a few times now and I think it's going to be critical. I'm keen to push for this as much as I can from our integration side.
While I don't have hard data on this (and it would be hard to establish causality anyway), most of the ERP implementation failures I've witnessed and know about stem from line of business people who firmly believe their company's processes - e.g. collection, billing, etc - are very special and unique, when it is very rarely the case; and when it is, it shouldn't be, the process is likely overly complex due to inertia or lack of will/skills to improve or just legacy. Then, the customizations that need to be implemented to support the "special and unique processes" are so complex that the project's schedule and budget inevitably explode...
ERP implementations could actually be seen as a great opportunity to revisit, optimize and document current processes before the ERP is implemented...
Number one rule of change management is: keep the number and amount of changes to a minimum. Successful projects involve changing only one thing at a time: medium (where), process (how) or goal/mission (why). If you find that the process is not optimal, or maybe even total nonsense, optimizing/fixing that needs to be a separate, pre-requisite project that is started and finished before you even start to think about the software project.
If that's not an option, then we can talk about the number two rule: it is much, much harder to get people — especially large groups of people — to change the way they do things, than to implement software to make it fit the way those people are used to operating, no matter how dumb and convoluted their process is. The reason is simple: software is predictable and does not have an agenda. In contrast, people are unpredictable, and each has their own agenda.
You need to work the way your ERP works.
All I can say is that trying to force this is, by a large margin, the primary reason why major software projects fail. Software is meant to aid, not dictate, how people work.
You don't have to take my word for it. Just look at the industry. Companies like Salesforce have become enormously successful because their products are configurable and customizable to a crazy extent, and you can make them fit into virtually any business process.
My experience is that customisation gets turned off eventually, it always breaks something. Either that or it just doesn't get used. Companies are much more similar than they would like to admit. If an ERP is not going to work for you 95% out-of-the-box you should probably find something with a better fit.
For core competencies where you do something differently from everyone else competitively, then SAP really has limited value except as a point of integration. Though I have seen some companies build entirely custom processes in ABAP for techno-religious reasons.
People who advocate for letting the ERP dictate the rules are using the phrase as a shorthand for, "If you want to customize the hell out of it you probably shouldn't use it".
Then you end up with teams having their own Dropbox and a bunch of custom Excel templates. Worse yet, employees waste 20-30% of their time manually converting their custom process into the ERP.
Then if a key employee leaves, suddenly people wonder why the ERP isn’t correctly working anymore, without realizing that person was the glue, binding the actual custom process with the mandated ERP.
Type 1: Companies with rock solid documentation for completely defined and logical processes and procedures. Said documentation is given to vendor and implemented. Success!
Type 2: Companies that acknowledge that all existing processes are stupid and/or wrong. Admit their failings, and implement the vendors default system 100% - changing to match the vendor way.
Everyone else is a delicate snowflake with processes that cannot possible change, and they pay through the nose to hammer the vendors software into submission. Was with a fortune 300 company that spent $90 million on business process redesign around the development of a new ERP system. Killed the project after two years when the first manufacturing plant to start using it pointed out how it was fundamentally broken and would slow production by 30%. Everyone associated with the program was fired.
The most important takeaway from that job applies universally. Business software must reflect business processes. If there are no processes, how do you know that your software is going to enable people to do their jobs?
Every business unit, every department, everything everywhere needs business processes that are documented. Those documents need to be maintained as the processes naturally change to reflect changing business needs. Those process changes need to be reflected in the software you're going to be working with.
If your company does not have the corporate will to establish and maintain processes and back the steps needed to keep those processes in step with reality, then any attempt to establish an ERP - whether homegrown or adopted from a vendor - will fail. Likewise, trying to maintain an existing ERP without corporate backing for process management can be incredibly painful.
Directly related, go with a vendor if you possibly can. As others have said, your business processes are usually not unique. There are adequate SaaS and FLOSS-with-support/FLOSS-with-premium-bits options available, and you as the implementer should give them a huge amount of weight compared to huge monolithic scary things like SAP.
1. The ERP software is exactly the same for everyone, but some companies thrive on it, some companies go broke on it. You and your partners are the difference.
2. Ideally your business will use commodity software for things that aren't a competitive advantage (e.g. general ledger), and custom software where you need an edge. Choose carefully.
3. If you choose COTS (commercial off the shelf software) understand how the vendor makes money from you and what you are willing to pay for. They want a constant stream of maintenance money from you, plus some discounted licenses. They will want you to upgrade regularly. Look ahead and think about how often you want to upgrade.
4. Powerpoints always work great. Actual software, not so much. Don't trust presentations.
5. A lot of ERP consultants live inside the bubble. Try to find some that understand mainstream tech and aren't zealots.
Like most everyone else said, it’s very important that you adapt the business processes to the software. That’s your first goal. Your second is to go-live with something that is embarrassingly bare-bones.
Once you’re live you should start to hold meetings about what to enhance but don’t make any big changes yet. Give your users some minor cosmetic changes or very low hanging fruit while the system proves itself.
Once you’ve been live a quarter or two—ideally the end of a fiscal year—then you can go to town making substantive changes.
How do you draw the line with this? Embarrassing that nobody can use it yet but at least there's momentum? Or embarrassing that it consolidated 3 things but everything else is still done by hand (Excel)?
For e-commerce, the needs seem to grow exponentially for the following questions:
1. What are my gross sales?
2. What are my refunds?
3. What are my net sales?
4. What are my product margins including landed & fixed cost?
This seems to be the barebones to be useful, or to convince people to go through all the trouble to even get started.
In between all of that you discover the real work. Some of your orders are gratis (PR marketing), so they need to post to a different subledger. Some orders use gift cards, and now you've opened the can of worms around deferred revenue. Some of those gift cards weren't backed by cash transactions, but marketing used the system that way to apply discounts.
You start doing backorders. Revenue can't be recognized until a product is delivered, but you only know when it was placed or shipped. You use three different shipping providers. One is a same-day provider that emails invoices.
Oh yeah, you also do "Try Before You Buy" and have inventory in customers hands before you've charged a payment provider (only auth'd). Now you've got an accounting scenario that requires a consultant.
Inventory becomes important. Suddenly you go from simple beginning/end of period (week/month) balances to purchase orders, receipt of goods, and 3PL/EDI integrations. Invoices are in EUR and entered that way, so now forex is needed.
Millions of dollars of inventory can be on the move from factory to warehouse, so now you need to account for that. Logistics team (if you have one) needs to do data entry when things ex-factory.
And of course to even get to complain about that you first need to convince someone to enter purchase orders and invoices in at a SKU level, and train them how to lookup HS codes for tariffs. Enter landed cost and another can of worms.
It feels like Alice in Wonderland, and things just get more batshit crazy complex the further you go. And of course
The more you customize your ERP, the worse off you are. The fastest, cheapest code is the code that's not written in the first place. The maintenance cost and difficulty upgrading down the road are many multiples of the sunk cost.
Their real killer though was posting multi step financial transactions without issuing db transactions, so they should fail and leave you unbalanced!
If you can still talk about it with a straight face afterwards, leave and go to work as an ERP implementation consultant!