> 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.
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.
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.
It's possible to make statically linked applications but it's pretty much never done.
And it's against the linux packaging mantra, where you should be able to "apt-get install libqt" for example (noting that libqt package is completely detached from the release cycle of your application).
This leads to a ton of accidental dependencies and they're tied to the OS release. Even the simplest of apps might eventually depend on libc, pcre, openssl, etc...
Windows is simply different on this aspect. It's more friendly to static builds and the system libraries are more stable. If you built against some win32 API or the Visual Studio 2005 SDK, the DLL are still present and working.
Even in the dotnet era, you have WinSxS and exe/dll specific manifests pinning specific library artifacts with apps and a loader that keeps a repository of every version referred to on the system. The linux/ELF ecosystem on the otherhand decided to try to implement various degrees of semantic library versioning, with differing (often poor) degrees of success.
When your target is a system image thats rebuilt entirely from source you can get away with the latter somewhat more easily, but its definitely no panacea. Just look at OpenSSL. (libmemcache is another personal 'favorite' of mine.)
It's why MS tried to push the British gov to accept their shitty ODF format rather than a proper one.
Because they wanted backwards compatibility with their modern and stoneage office suite versions with their own quirks and issues.
They're obsessed with backwards compatibility and it has it's own issues.
Microsoft Office's native format is OOXML (Office Open XML). The ODF (OpenDocument Format) is the native format of LibreOffice, and the UK decided to go with this one (despite Microsoft's lobbying).
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.
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.
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.
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.
That's so true. We are running SAP, which is so heavenly customized (someone 10 years ago thought it was a great idea, thanks!) that applying patches is nearly impossible and requires months of pain and expensive contractors.
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.
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'.
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.