>, how do I know that the OTS solution would actually be much better? For example, [...] how would you have any guarantee that your third party solution would be able to support those?
For the "gaps" of missing functionality, look at either :
(1) customizations via extra programming or extra add-ons.
(2) eliminate that software as a viable choice and move on to the next OTS software for evaluation
> At least if itβs in-house you can implement the needed functionality eventually -
The vast majority of Fortune 1000 businesses replaced their "homegrown" accounting and payroll systems they built in the 1960s/1970s/1980s -- with COTS ERP systems like Oracle Financials and SAP R/3 because their internal IT teams never got around to the "eventually" option.
There's an anecdote (I think from the book "I'm Feeling Lucky") about a Google's early startup years where an employee said they "needed to buy SAP" for accounting. The co-founder Sergei Brin was dismissive, "why do we need to buy that when our programmers can build it?" Well, he was 20-something at the time and naive about the complexities of financial accounting software for a global business. He must have eventually realized the true scope of the problem because instead of building in-house accounting software, Google bought Oracle Financials. About 20 years later, they migrated from Oracle to SAP.
> Well, he was 20-something at the time and naive about the complexities of financial accounting software for a global business. He must have eventually realized the true scope of the problem because instead of building in-house accounting software, Google bought Oracle Financials.
How do we jump to this conclusion? Did he realize the true scope of the problem or was it just left to someone else once Google grew in size? It doesn't even explicitly say how Oracle Financials came to be at Google.
> because their internal IT teams never got around to the "eventually" option.
I doubt that's really the case. Same with how cloud came to be. The sales people promised massive savings i.e. bonuses for management and here we are.
Don't forget the money sinks that are any attempts to implement something differing with SAP or other big ERP systems.
You delivered extra value for customers (making you more competetive) thanks to some particular ability of your previous (even manual) billing rules? Kiss them bye bye.
That is not how any of this works. SAP is already sold to the C-suite on the basis of very fancy powerpoints and sales pitches before anyone in the enterprise can do a gap analysis. I have no experience with Oracle Finance, but I suspect the process will be the same.
The business (employees in the accounting dept and/or consultants) do a "fit-gap analysis" when evaluating potential software: https://www.google.com/search?q=fit+gap+analysis
For the "gaps" of missing functionality, look at either :
(1) customizations via extra programming or extra add-ons.
(2) eliminate that software as a viable choice and move on to the next OTS software for evaluation
> At least if itβs in-house you can implement the needed functionality eventually -
The vast majority of Fortune 1000 businesses replaced their "homegrown" accounting and payroll systems they built in the 1960s/1970s/1980s -- with COTS ERP systems like Oracle Financials and SAP R/3 because their internal IT teams never got around to the "eventually" option.
There's an anecdote (I think from the book "I'm Feeling Lucky") about a Google's early startup years where an employee said they "needed to buy SAP" for accounting. The co-founder Sergei Brin was dismissive, "why do we need to buy that when our programmers can build it?" Well, he was 20-something at the time and naive about the complexities of financial accounting software for a global business. He must have eventually realized the true scope of the problem because instead of building in-house accounting software, Google bought Oracle Financials. About 20 years later, they migrated from Oracle to SAP.