5 ms·

> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't

> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is. SAP is SAP. It doesn't care about your USP. Or your custom approach to business. As far as SAP is concerned all businesses are the same, they do the same things, and all must conform. Resistance is futile. I've worked in companies making decisions around which ERPs to implement. You have two options: roll your own ERP or adapt your processes to an existing one. The first approach means that you are basically committed to becoming a software company. At a minimum an ERP needs to tie together your accounting, supply chain and inventory. So it's not a simple endeavor and it's easy to mess up. You'll need a team of people to build it and you'll need ongoing support. Compared to these costs, the price that SAP or NetSuite will charge you for their ERP is trivial. Alternatively, you can adapt your processes to an ERP. In many cases, this is the right thing to do. It means that you can use readily-available software and have practices that are good enough.

gfs78 7y ago
Agree. It´s buying what doesn´t add much value/differentiation to focus on the things that are important to the company.
dvtrn 7y ago
A few years ago the company I’m at now tried doing the former while also trying to launch a SaaS application while also also trying to be a service provider. Five years later (of which I’ve been on board for 3) they’re still trying to dig themselves out from under that with a development team of exactly four developers, and management finally got the first time today said what a horrendously bad idea it was, but refuse to move on because someone in leadership loves their sunk costs.
cr0sh 7y ago
I once worked for a company that let me go because I looked bad on their bottom line and they were looking to sell the company, around 2003. So, severance package in hand, and one week later I had a new position at another company making much more than I was originally. Anyhow - I was essentially the sole developer of a simple ERP system written in VB6 and using an Access 2003 MDB file for storage. It was being used in-house by most of the company at that point, from billing, to shipping software and patches, to other reporting, CRM, etc. I looked bad to the bottom line because my salary was going entirely into this in-house developed product, that was producing no revenue for the company. I was a literal cost center; I don't blame them for letting me go - it was probably a good business decision... When I was let go, I was trying to transition to postgresql for the backend (away from the MDB file), and hopefully move the frontend away from VB6 - and make the whole thing a web application in some manner. They told me when I was let go they told me they were looking into other options to replace the software I had almost single-handedly written to manage the business. So - I was let go, and the business was sold. Twice. Today, it's part of HP, last I was aware - about 3 years ago. That was about the time that I had to look for a new job, and talked to my former supervisor there (he'd since become VP of his department). Yep - still using the same old software, with virtually no updates or fixes. Still running on the MDB file. And somehow, it was still all working, nearly 15 years later. I'm amazed, impressed, shocked, and also in complete wonderment how it hasn't fallen over hard since then. As far as I know - they are still using it. I've been told that both the original company that bought them, then HP (after they bought that company), both looked at the software and wanted to monetize it - everyone who's seen it has been fairly impressed with it, from what I understand. But, because it's so tightly integrated with the business, plus that it was never designed to be modular and salable, has meant that without a major refactor, it can't be easily done. Honestly, I'm glad it can't - I'd do so many things differently today that I didn't do then (and if done, they could probably sell it as well); it's the kind of code that I know some developer will look at, then want to track me down for a good ol' fashioned murdering - or at least to beat me with a baseball bat.
- bgun 7y ago
  Reminds me of a recent HN post about the uncanny survival of MS Access https://news.ycombinator.com/item?id=21401198 https://news.ycombinator.com/item?id=21401198
  - cr0sh 7y ago
    I probably posted to that one as well...
    - notlukesky 7y ago
      I should have posted to that.
- S3raph 7y ago
  Great story, I don't want to know the number of companies that run business critical stuff on excel vba macros + access DB some guy wrote 15 years ago.
  - qubex 7y ago
    My family business was very happily centralised on IBM’s (admittedly legacy) ADB package running on an ultra-reliable AS/400 (later iSeries). SAP was a disaster.
- user5994461 7y ago
  That must be the magic of Windows in action. Software still running after 15 years. I have to do some maintenance or decommissioning of very old apps in an old bank. I find anything Linux and C or C++ related is the worst, because the system libraries themselves are unstable. Applications fail because of .so dependencies breaking, both system libraries and application libraries (themselves forming a tree of dependencies). It can be extremely hard to rebuild and relink the software with the whole chain of dependencies for the current platform. Linux executables die along major OS releases every few years, but Windows binaries can keep working for more than a decade easily.
mark-r 7y ago
There's a third option - customize the ERP to conform to your existing processes. The last place I worked chose that option, they were a medical device company and didn't want to change their processes. Of course it made a huge amount of extra work, much of which was done by expensive contractors.
- NikolaNovak 7y ago
  That option is a long thick gray line. Every ERP will be "customized". It has to be - provide your own chartfields, business units, workflows, decision points, etc. It's the amount of the customization that makes the difference. I've been on ERP implementation projects that were 28 days long, and 5 years long. I am the "expensive contractor", and I have never ever in 20 years met another expensive contractor who did not fight, tooth and nail, to minimize customization. From the initial business requirements and scoping, to the constant CRs likely to be encountered during implementation. On average/as a generalization, contractors/consultants have seen many businesses and see the commonalities, seen dangers of customizations, and fight them; clients know only themselves, believe in their uniqueness, and don't have a good vision or image of themselves post-transformation - how they could possibly do things differently. Consultants want their Time & Material bills, sure; but even more want successful project and references - not to mention sanity, semblance of life, and feeling like they did good work and helped the client.
  - wdb 7y ago
    Yes, after all the customizations they decide to upgrade to a new version of SAP. The whole shebang can start over again. At least these days it's all SAP S/4HANA. HANA is not bad actually.
    - john_minsk 7y ago
      And you need to pay up every time you data grows by 64 GB. I guess sap is happy
  - jandrese 7y ago
    Every customization is technical debt you'll have to drag forward on every new release.
jboy55 7y ago
I've lost track of the months I've spent building for some specific custom request. I haven't done ERP, but back in the 00s I did a bunch of work customizing software for the 'big enterprise' potential customers that were going to 'save the day'. Months being, one month for each weird request, because somewhere a Karen or Dave says we 'always have done it this way'.

gfs78 7y ago

Agree. It´s buying what doesn´t add much value/differentiation to focus on the things that are important to the company.

dvtrn 7y ago

A few years ago the company I’m at now tried doing the former while also trying to launch a SaaS application while also also trying to be a service provider. Five years later (of which I’ve been on board for 3) they’re still trying to dig themselves out from under that with a development team of exactly four developers, and management finally got the first time today said what a horrendously bad idea it was, but refuse to move on because someone in leadership loves their sunk costs.

cr0sh 7y ago

I once worked for a company that let me go because I looked bad on their bottom line and they were looking to sell the company, around 2003. So, severance package in hand, and one week later I had a new position at another company making much more than I was originally. Anyhow - I was essentially the sole developer of a simple ERP system written in VB6 and using an Access 2003 MDB file for storage. It was being used in-house by most of the company at that point, from billing, to shipping software and patches, to other reporting, CRM, etc. I looked bad to the bottom line because my salary was going entirely into this in-house developed product, that was producing no revenue for the company. I was a literal cost center; I don't blame them for letting me go - it was probably a good business decision... When I was let go, I was trying to transition to postgresql for the backend (away from the MDB file), and hopefully move the frontend away from VB6 - and make the whole thing a web application in some manner. They told me when I was let go they told me they were looking into other options to replace the software I had almost single-handedly written to manage the business. So - I was let go, and the business was sold. Twice. Today, it's part of HP, last I was aware - about 3 years ago. That was about the time that I had to look for a new job, and talked to my former supervisor there (he'd since become VP of his department). Yep - still using the same old software, with virtually no updates or fixes. Still running on the MDB file. And somehow, it was still all working, nearly 15 years later. I'm amazed, impressed, shocked, and also in complete wonderment how it hasn't fallen over hard since then. As far as I know - they are still using it. I've been told that both the original company that bought them, then HP (after they bought that company), both looked at the software and wanted to monetize it - everyone who's seen it has been fairly impressed with it, from what I understand. But, because it's so tightly integrated with the business, plus that it was never designed to be modular and salable, has meant that without a major refactor, it can't be easily done. Honestly, I'm glad it can't - I'd do so many things differently today that I didn't do then (and if done, they could probably sell it as well); it's the kind of code that I know some developer will look at, then want to track me down for a good ol' fashioned murdering - or at least to beat me with a baseball bat.

bgun 7y ago
Reminds me of a recent HN post about the uncanny survival of MS Access https://news.ycombinator.com/item?id=21401198 https://news.ycombinator.com/item?id=21401198
- cr0sh 7y ago
  I probably posted to that one as well...
  - notlukesky 7y ago
    I should have posted to that.
S3raph 7y ago
Great story, I don't want to know the number of companies that run business critical stuff on excel vba macros + access DB some guy wrote 15 years ago.
- qubex 7y ago
  My family business was very happily centralised on IBM’s (admittedly legacy) ADB package running on an ultra-reliable AS/400 (later iSeries). SAP was a disaster.
user5994461 7y ago
That must be the magic of Windows in action. Software still running after 15 years. I have to do some maintenance or decommissioning of very old apps in an old bank. I find anything Linux and C or C++ related is the worst, because the system libraries themselves are unstable. Applications fail because of .so dependencies breaking, both system libraries and application libraries (themselves forming a tree of dependencies). It can be extremely hard to rebuild and relink the software with the whole chain of dependencies for the current platform. Linux executables die along major OS releases every few years, but Windows binaries can keep working for more than a decade easily.

mark-r 7y ago

There's a third option - customize the ERP to conform to your existing processes. The last place I worked chose that option, they were a medical device company and didn't want to change their processes. Of course it made a huge amount of extra work, much of which was done by expensive contractors.

NikolaNovak 7y ago
That option is a long thick gray line. Every ERP will be "customized". It has to be - provide your own chartfields, business units, workflows, decision points, etc. It's the amount of the customization that makes the difference. I've been on ERP implementation projects that were 28 days long, and 5 years long. I am the "expensive contractor", and I have never ever in 20 years met another expensive contractor who did not fight, tooth and nail, to minimize customization. From the initial business requirements and scoping, to the constant CRs likely to be encountered during implementation. On average/as a generalization, contractors/consultants have seen many businesses and see the commonalities, seen dangers of customizations, and fight them; clients know only themselves, believe in their uniqueness, and don't have a good vision or image of themselves post-transformation - how they could possibly do things differently. Consultants want their Time & Material bills, sure; but even more want successful project and references - not to mention sanity, semblance of life, and feeling like they did good work and helped the client.
- wdb 7y ago
  Yes, after all the customizations they decide to upgrade to a new version of SAP. The whole shebang can start over again. At least these days it's all SAP S/4HANA. HANA is not bad actually.
  - john_minsk 7y ago
    And you need to pay up every time you data grows by 64 GB. I guess sap is happy
- jandrese 7y ago
  Every customization is technical debt you'll have to drag forward on every new release.

jboy55 7y ago

I've lost track of the months I've spent building for some specific custom request. I haven't done ERP, but back in the 00s I did a bunch of work customizing software for the 'big enterprise' potential customers that were going to 'save the day'. Months being, one month for each weird request, because somewhere a Karen or Dave says we 'always have done it this way'.