7 ms·

I’m a software engineer and likely to be involved in implementing an ERP at the company I work for. Ignoring whether or not we should (we’ll put a lot of thoug

I’m a software engineer and likely to be involved in implementing an ERP at the company I work for. 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?

superbrane 7y ago
- Make sure business stakeholders have realistic expectations about deployment, data migration, cost of working in parallel if another system exists, etc - stay away from customizations when possible. Each ERP comes with its own way of doing things. It's sometimes best to adjust the business to the ERP than the other way around :)
- gav 7y ago
  To echo this point: in my experience, a lot of businesses seem to believe that their internal processes are unique for a reason and offer some competitive advantage instead of being that way because somebody made a decision years ago and that decision stuck. 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.
arethuza 7y ago
I'd recommend not getting involved in the 'technology' used to customize ERP products - this tend to be 'eccentric' at best. Personally I'd try and stay on the right side of a sensible API or database structure if you can find one.
- jimnotgym 7y ago
  Netsuite has a pretty handy javascript based internal system that is alright. But do insist on am API!
jimnotgym 7y ago
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!
- NicoJuicy 7y ago
  I think adjusting to how the ERP package works and not invert it is the most important comment to save money and to make it a success.
  - jotakami 7y ago
    Not only for the initial implementation, but also to reduce the gnashing of teeth when it’s time to upgrade
  - privateSFacct 7y ago
    And is the hardest thing to do in a big org. 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.
cromulent 7y ago
Some quick thoughts, I've done a bunch of these. 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.
slumdev 7y ago
Learn as much as you can throughout the process. If you can still talk about it with a straight face afterwards, leave and go to work as an ERP implementation consultant!
McGlockenshire 7y ago
I maintained a home-grown corporate ERP for ten years. 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.
wombatpm 7y ago
There are two types of companies where ERP implementations go well. 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.
- sparrish 7y ago
  I cannot agree with this comment more! If your org is not a type 1 or type 2, don't roll out an ERP change. Get to 1 or 2, then do it. You're just asking for pain and will lose a lot of great employees who refuse to go through that pain with your org.
jmngomes 7y ago
Try to adapt the business processes to the ERP, instead of adapting the ERP to the custom business processes. 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...
- J_cst 7y ago
  I totally agree. Main mistake is customizing the ERP to the company. I also noticed that what usually goes smoothly is the accounting. I believe that the reason for that is that accounting - at least in italy - is a quite standardized process and rarely companies have a special kind of accounting, so there's no need to customize it and screw it up.
  - toyg 7y ago
    That’s probably because accounting typically gets “massaged” later on with systems that are more focused on specific tasks (consolidation, reporting, analytics etc). I work in that space... numbers are typically extracted from SAP as soon as possible then handled elsewhere in whichever tool actual accountants prefer (well, all accountants would rather do everything in Excel, if they could, but beyond that they do have preferences. Sometimes the preference is whatever their boss decides to use while on a golf course with the vendor, but hey, whatchagonnado).
- enraged_camel 7y ago
  I've been working in this field for nearly 15 years, and what you said is the exact opposite of reality, in my experience. 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.
redbeard0x0a 7y ago
don't make a table called Transactions that everything needs to go through to balance. It will create a bottleneck that slows _everything_ down (I'm looking at you Axapta/Dynamics AX - at least older versions, dunno if they ever fixed it).
- jimnotgym 7y ago
  I have seen this with Coda/Unit4 plus broken stats in Oracle db that made it unusable. Their real killer though was posting multi step financial transactions without issuing db transactions, so they should fail and leave you unbalanced!
AdrianB1 7y ago
My company paid over the years over 1 billion dollars to SAP and the amount is increasing as the time goes by. What I learned in ~ 6 years in the IT areas using SAP is that the quality of the design and the quality of the implementation are critical for success, while a very strict change management process can keep it alive. Mediocre consultants doing the implementation are one of the biggest problem; SAP is not that hard, but definitely not simple, a few good architects are critical, getting unqualified consultants by the dozen is bad and moving code to production without very thorogh testing will kill it (no CI/CD, it's not a game to play it with bug fixes coming on a daily basis).
halfnormalform 7y ago
Some management-type probably told the end users it will make their life easier and they are going to want you to include new features from day one. Do not do this. It will kill you. 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.
- tomnipotent 7y ago
  > embarrassingly bare-bones 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

superbrane 7y ago

- Make sure business stakeholders have realistic expectations about deployment, data migration, cost of working in parallel if another system exists, etc - stay away from customizations when possible. Each ERP comes with its own way of doing things. It's sometimes best to adjust the business to the ERP than the other way around :)

gav 7y ago
To echo this point: in my experience, a lot of businesses seem to believe that their internal processes are unique for a reason and offer some competitive advantage instead of being that way because somebody made a decision years ago and that decision stuck. 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.

arethuza 7y ago

I'd recommend not getting involved in the 'technology' used to customize ERP products - this tend to be 'eccentric' at best. Personally I'd try and stay on the right side of a sensible API or database structure if you can find one.

jimnotgym 7y ago
Netsuite has a pretty handy javascript based internal system that is alright. But do insist on am API!

jimnotgym 7y ago

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!

NicoJuicy 7y ago
I think adjusting to how the ERP package works and not invert it is the most important comment to save money and to make it a success.
- jotakami 7y ago
  Not only for the initial implementation, but also to reduce the gnashing of teeth when it’s time to upgrade
- privateSFacct 7y ago
  And is the hardest thing to do in a big org. 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.

cromulent 7y ago

Some quick thoughts, I've done a bunch of these. 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.

slumdev 7y ago

Learn as much as you can throughout the process. If you can still talk about it with a straight face afterwards, leave and go to work as an ERP implementation consultant!

McGlockenshire 7y ago

I maintained a home-grown corporate ERP for ten years. 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.

wombatpm 7y ago

There are two types of companies where ERP implementations go well. 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.

sparrish 7y ago
I cannot agree with this comment more! If your org is not a type 1 or type 2, don't roll out an ERP change. Get to 1 or 2, then do it. You're just asking for pain and will lose a lot of great employees who refuse to go through that pain with your org.

jmngomes 7y ago

Try to adapt the business processes to the ERP, instead of adapting the ERP to the custom business processes. 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...

J_cst 7y ago
I totally agree. Main mistake is customizing the ERP to the company. I also noticed that what usually goes smoothly is the accounting. I believe that the reason for that is that accounting - at least in italy - is a quite standardized process and rarely companies have a special kind of accounting, so there's no need to customize it and screw it up.
- toyg 7y ago
  That’s probably because accounting typically gets “massaged” later on with systems that are more focused on specific tasks (consolidation, reporting, analytics etc). I work in that space... numbers are typically extracted from SAP as soon as possible then handled elsewhere in whichever tool actual accountants prefer (well, all accountants would rather do everything in Excel, if they could, but beyond that they do have preferences. Sometimes the preference is whatever their boss decides to use while on a golf course with the vendor, but hey, whatchagonnado).
enraged_camel 7y ago
I've been working in this field for nearly 15 years, and what you said is the exact opposite of reality, in my experience. 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.

redbeard0x0a 7y ago

don't make a table called Transactions that everything needs to go through to balance. It will create a bottleneck that slows _everything_ down (I'm looking at you Axapta/Dynamics AX - at least older versions, dunno if they ever fixed it).

jimnotgym 7y ago
I have seen this with Coda/Unit4 plus broken stats in Oracle db that made it unusable. Their real killer though was posting multi step financial transactions without issuing db transactions, so they should fail and leave you unbalanced!

AdrianB1 7y ago

My company paid over the years over 1 billion dollars to SAP and the amount is increasing as the time goes by. What I learned in ~ 6 years in the IT areas using SAP is that the quality of the design and the quality of the implementation are critical for success, while a very strict change management process can keep it alive. Mediocre consultants doing the implementation are one of the biggest problem; SAP is not that hard, but definitely not simple, a few good architects are critical, getting unqualified consultants by the dozen is bad and moving code to production without very thorogh testing will kill it (no CI/CD, it's not a game to play it with bug fixes coming on a daily basis).

halfnormalform 7y ago

Some management-type probably told the end users it will make their life easier and they are going to want you to include new features from day one. Do not do this. It will kill you. 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.

tomnipotent 7y ago
> embarrassingly bare-bones 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