Why not build their own internal system? They'll end up hiring SAP devs anyway, why not make use of the existing talent?
https://en.wikipedia.org/wiki/Core_competency
Google’s mission is…well, that depends on how cynical you are. But, whether it’s organizing the world’s information or spying on us with ads, it sure isn’t “develop boring payroll software, and maintain that awful boring software forever”.
Also, without knowing the exact nitty gritty of what this particular bit of payroll software does: does it manage international employees? Because just doing US compliance would be bad enough, dealing with regulations for N countries sounds like eating a bucket of bees.
Google has literally zero experience in that area, and if they tried to do it from scratch, it would take many years. Probably not less than ten years before they'd have a chance of competing with the established players. Even if they wholesale hired a team from a major player, it would still take years to reimplement the functionality and get it to a marketable state.
There's no "minimum viable product" that could succeed in that space - a system has to be able to take care of an entire enterprise's operational needs, or it's not in the running.
Google has got the database, Spanner. It's even supposed to solve a major problem that both Oracle and SAP are currently lacking. Massively distributed transaction speed: if you want a webshop, but you're the 1000lb gorilla of your industry, you need to support tens to hundreds of thousands of transactions per second. And you'd love to do this by just "BEGIN TRANSACTION <blabla> ... COMMIT", right? Well, mostly you can't do that. Oracle and SAP have always worked by providing faster single machine hardware and are not really ahead of Spanner in clustering.
Let's assume Spanner marketing and academic papers actually tell us what Spanner can do. That it can run transactions, distributed, at greater speed than anything else. Apparently they can run transactions at "double the speed of light" (apparently they don't need a cluster roundtrip to confirm a transaction, just a one-way message). Hell, maybe they've got a patent on this technique.
Second they HAVE one of the biggest business ventures of the planet running on this platform (Google Ads), and clearly working. So they have a strong argument that it can work very, very reliable.
They've got all sorts of useful stuff integrated on top of this solution. BigQuery querying, you don't even need to configure or admin read-only replicas, those come free. Plus whatever Google cloud ML does, another area where Oracle and SAP probably can't ever match Google. Companies want this. If they can get the computational power of Google cloud behind their core database, it would have clear advantages. Oracle and SAP are both building this sort of solution, but that is not their strength. They can never approach the machine power Google has.
So if Google built a dBase-like (hopefully a bit more modern) frontend on top of Spanner, make it accessible for administering huge businesses, and implement 100 example apps (warehouse management, basic (ie. ignoring the law) personnel administration, the hated hours tracking, ...) on top of Spanner, you have a solution that could be pretty tempting for huge businesses and would be a subscription based service that people seriously overpay for.
The reason you need those 100 example apps is that they're not just 100 example apps. They're a standard data format (so for instance, any employee tracked in personnel admin doesn't need to be entered again in hours tracking. Warehouses and stock, administered by different apps, already have an interface between them sharing data, ...)
They can compete here if they want, and while they're lacking one thing, they're very strong (some might say unbeatable) on another front. This can be made to work with not even that much effort.
You are of course correct that it would take 10 years to build out this business, and that would be considered very fast. But it can be done.
The other piece is the opportunity cost. Ideally, your expensive engineers are working on products and other high leverage work. Even if you want to build it, you have to find engineers that are interested in doing that when it's not the product.
Google has a NIH problem in many spaces, but the decision to scrap the ancient internal system and go with Workday (despite Workday being a nightmare) was clearly the right one.
Besides, buying SAP is Opex. Google wants its engineers working on Capex projects.
I think that is probably a big concern. I read a comment once by someone who said they worked in some kind of company that did financial audits, and it said that as soon as they got a whiff of some homegrown accounting system, the audits got way more expensive, because then they'd have to do a technical audit of the system in addition to the bean counter's audit.
If the company ran SAP or some other common ERP system, they didn't have to do that, because it was battle-tested and assumed to be correct.
The magic of these horrible ERP systems is that auditors like them because they've dealt with them before.
I've had a similar conversation about such with the owner of a company who wanted to go public on the horizon. Switching to SAP or Oracle is for this reason and this reason alone. It's such a shame that they are so awful and yet this somewhat tiny thing is the deciding factor.
I'm sure many companies have fucked up their entire internal systems and, potentially, lost out on moving forward simply because they went with these beasts. Tech turnover has got to be huge when you move to something like this. It's probably not worth it in the end, really.
Let the auditors bitch.
So auditors belief that an Oracle ERP system gives them confidence in a company audit is misguided.
Cheers
> So auditors belief that an Oracle ERP system gives them confidence in a company audit is misguided.
I'm no expert, but I don't think typical auditors are there to find things like that.
Oracle/SAP is NOT about whether the system is actually correct.
Oracle/SAP IS about whether the system not being correct is the legal liability of someone else.
We're required to obtain an understanding of the control environment (so the ERP system in this case), and if we want to rely on its outputs we have to do dedicated testing over it. You're right though that if you do alter one transaction it's probably not going to come up in the audit samples. There's a bit of a gradient though between how much you alter and how much the auditors care, because auditors deal with things on a materiality basis. The more you manipulate the finances, the more material it becomes and the more we care, but also the more likely it will be uncovered. If you're changing a few trivial transactions we more certainly will never uncover it unless you're really unlucky, but then the effects of those trivial transactions is trivial anyways so it's not really a problem.
The SAP SMEs I know have decades of implementation and training and are on a first name basis with Dietmar. I’m not sure if it’s him, but one of the founders still teaches the advanced SAP architecture courses. You go to Germany and spend 3 months in class with him.
In the meantime, Larry and Sergey are doing what? At least the other Larry is being constructive and working on his next yacht.
I work in Enterprise Software and I have experienced multiple times that tech companies first tried to build an administrative back office system and came back to the market two years later as the underestimated the complexity.
So Microsoft dont Dogfood their own Dynamics 365? No wonder why SAP is winning.
>administrative back office system and came back to the market two years later as the underestimated the complexity.
I have lots of first hand experience with it. As a matter of fact I have never seen any modern ERP replacement that works better than the old one. Because the people who do the design input tell software developers how the ERP should work dont have much experience with the actual task. They are mostly manager who thinks they know something but they dont. ERP / CRM to this day is still an unsolved problem for SME. Large Cooperate Enterprise seems to have adopted to SAP already so the skill is now officially "portable" and part of Resume Driven culture.
That takes a whole lot more expertise than repurposing an engineering team.
How much expertise does an engineering team have in corporate finance?
Imagine writing turbotax from scratch. Now imagine writing it for businesses. Now imagine coding all the tax law correctly.
They are making more money by allocating the same resources to ads related project, so why bother anyway.
So what gives? How could Google end up in this position?
Unless Google wants to get into the ERP software business, spending years developing such a system is a waste of money. Also, they'd need to maintain it for a very long time, and we all know what Google feels about keeping software maintained for long periods of time.