Google will stop using Oracle’s finance software and adopt SAP instead
cnbc.com
cnbc.com
This isn't new information. Google has already been saying this on a (very obscure) blog months ago: https://support.google.com/corporate-suppliers/announcements...
They are changing over on May 3.
Re: finance, I remember using Oracle iExpense around the same time for business expenses and then at some point a couple years later we switched to another company's product. I don't think it lasted until the Pichette days, though...I'm almost certain it was replaced during Reyes' tenure as CFO and before Pichette got installed around 2008.
When they didn't get the decision they wanted, they quickly escalated to exec and director level, and the exec of a major shareholder to try and get the decision overturned.
It wasn't an especially pleasant experience personally, because obviously it involved a lot of very personal attacks by a vendor, but at the same time it was fascinating to watch how they networked from the top down to try to get the decision that they wanted, and run roughshod over the SMEs and process.
Some years later one of the sales team sent me a "Virtualisation for Dummies" book and told me I could learn something from it.
It's made me always work to get Oracle and CA products replaced wherever I have a voice as a result. They may have scored one small $500k deal at that previous employer. I've often found I'm not alone in my dislike for these companies for their shady sales practices, and at least for Oracle enough of us worked together to lose them an 8-figure deal by showing we could do something different for far less once.
Open source created modern Oracle. I worked for a company built around Informix, and that database engine was one of the largest expenses of the company. I think we paid like $40k/socket in 2000. Today, you use an open source database to build your product.
So Oracle had to start selling integrated solutions. They do evil shit like pay higher commissions for salespeople to cross-sell their colleagues. So the Oracle Financials guy gets paid more to sell Identity crap than the identity guy. So the sales idiots form all sorts of weird alliances and kill each other.
Thing is, the vendor simply happened to build upon Oracle. If the software supported DB2, or more likely, supported a migration path from Oracle to DB2, I suspect we would have gone with that.
On another hand...
A lot of "Oracle required" software uses a ton of Oracle-specific stored procedures and other components, in fact, I have encountered an MRP software package that was written entirely inside Oracle database. All PL/SQL, with some bits of embedded Java.
The main issue is probably just that SAP is not as litigious as Oracle.
Maybe they have some nicer ones somewhere else but the ones I have used have been buggy, slow, painful messes- I get the strong feeling that SAP is a sales first organisation and engineering is a necessary byproduct.
So therein lies the issue - Evaluating a fully customizable software product that will be critical to your business is very difficult to do before it is actually crafted into what you have in mind. So the procurement and implementation processes are often an uphill battle against magical thinking where people are imagining a certain wonderful outcome but without careful, critical attention what you'll end up with is a heap of shit.
I have a policy of not working for organizations that have either oracle or SAP in the core of their environment, unless my purpose in coming onboard is to move them off it. This limits me in many ways, but I know from experience I'm avoiding a significant amount of pure bullshit, enough to make it worth the rule.
*if you're willing to fund an as-yet-unknowable level of customization effort to reach your organization's particular nirvana.
tl;dr the future SAP has sold to Google may indeed look better than the Oracle reality they're currently living, but it doesn't necessarily follow that their SAP reality will be any good. Such are the perils of procurement.
Regarding altenatives at that scale, I've not been involved in a project at that kind of scale, biggest SAP implementation I was involved in was ~10k employees and Alphabet is sitting at ~130k right now. I don't want to dive too much into speculation, perhaps Google will get a good outcome with this approach and since they're coming from a bad place with Oracle the future might still be crap but perhaps just a bit less so.
The biggest issue with procurement of SAP and it's ilk is it shifts a fundamental burden from procurement to implementation. With a defined software/SaaS solution that's ready to go out of the box, you get to answer a lot of the yes/no functional questions at procurement stage. It can do it or it can't do it and you get to decide how important that is to you. With SAP, every requirement is answered with 'it can do that' with the massive asterix that to make it do what you need it's all going to need to be customized to do so. That opens you up to a lot of risk IMO.
It's cheaper, it's faster, it doesn't need training and cheat cards, it's self explanatory, and you can maintain it by yourself. Plus you know it inside out. Plus you can add much better features, like graphical reports on top of it easier.
The other part is; SAP supports things forever. You can run their old buggy DB from 2003 in 2021 with paid support. Bug-for-bug compatible on Windows Server 2019 probably too. That has a lot of value for a lot of SAP customers.
I would also remind that SAP (and DTAG) built the german corona tracing app, which was delivery in about 2 months, open source under Apache2.0 and very privacy aware. And well within budget no less.
First, the width of the app window is fixed and cannot be resized. And some wide columns are fixed in place too, meaning that I can only see three columns at the time (out of 30) and therefore I am constantly scrolling left and right. On top of that, every time the window loses focus it does a weird 2-3 seconds refresh when you come back. As a result, we all write everything in Notepad first and only open SAP when we know we won't need to click away anymore.
Every single cell in that "spreadsheet" can do at least 50 things, but I have never managed to get them to do what I need. If I need the specific code of my position I copy-paste it from last month because that cell's search function has never returned anything useful. But if I check last month's data I lose the data of this month that I didn't save (plus the weird refresh thing happens here too). And if I save something it's there forever and cannot be edited. As a result, if I don't have my employee and workplace codes at hand at the beginning it's faster to throw the partial data away and start all over.
Some fields auto-complete, but I'm not sure under which circumstances. A colleague found that double clicking in a specific cell triggers this, but none of us knows why this specific cell.
This is a single app I use exactly once a month. Imagine having to use something like this every day. Even worse, imagine testing this app and saying "yes, this expensive, slow, uncomfortable app is exactly what my company needs, and I'm glad to know that you expect me to adapt to it instead of the other way around".
SAP apps are internal and very sensitive to changes, so usually they don’t get priority, but at least you can thank that using such an old app designed for old windows terminal still works. It should just be replaced, but SAP usually leaves that decision to customers and this delays the change a lot
Note that after that training, the employee will need his notes to complete the task every single time, and will only complete the task rapidly after several years of experience with the software (and undocumented tips from older coworkers).
It's the same with SAP.
To run a simple non-official query, you would need to aquire a timeslot on Friday evening running over all 100.000 records, because the thing will run for half an hour. Not kidding.
I talked to the sales agent why they don't add indices to their database, and he answered "we don't need explicit indices. Our system is so advanced, it does auto-indexing". Lol. They really believe their own bullshit. Looks like their idea of a JOIN are 3 nested for loops.
Yeah that's the point, its meant to somehow magically work for everyone. And thanks to that, it doesn't really work for anyone and feels awful for everyone.
From the article:
“The move relates only to the software Google uses to track finances, and there’s no indication that the company is moving other systems off Oracle.”
They’re just moving payroll. Nothing at all about recruitment or retention.
Unless you’re saying that being able to change my direct deposit rapidly is critical for employee development. Which, not exactly high up the list of important stuff.
[1] https://news.ycombinator.com/item?id=26180785 [2] https://www.businessinsider.com/citigroup-accidental-wire-tr...
Why? Is not like Quickbook is so small tiny startup.( Did a Google Search and couldn't find anything )
That's as misleading as it gets.
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.
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.
Besides, buying SAP is Opex. Google wants its engineers working on Capex projects.
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.
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.
They are making more money by allocating the same resources to ads related project, so why bother anyway.
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.
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.
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.
Disclosure: I work at SAP, though not on HANA.
Disclosure: I work at SAP, but neither on HANA nor on any part of the "SAP system". (I'm in the cloud infrastructure unit.)
https://aws.amazon.com/blogs/aws/migration-complete-amazons-...
Interestingly, Oracle gave Amazon 97.5% discount on the Java license so Amazon would use Java on Kindle instead of Android
https://the-digital-reader.com/2016/05/19/oracle-gave-amazon...
https://www.oracle.com/erp/financials-cloud/
If you're a big enterprise like Google, managing your financials is super-non-trivial. Solutions like Oracle or SAP are pretty much the only options.
I hate the cookie pop-ups with a passion, its done nothing but discourage visiting new sites, which is awful for the internet. It pushes you to use sites you already know of (which are generally quite big).
> oracle to SAP
How?!
My guesses:
1. It's boring.
2. Those are marketing-driven products and Google is engineering-driven.
3. ???
And why not? Because if they spend the time elsewhere they'll make more money. Opportunity cost
This is laughable to anyone who has ever worked on development of an ERP product.
Here's a thought experiment. Let's take one part - one part only - of the whole ERP / enterprise software spectrum.
Let's pick HR for an example.
Now let's pick one part - only one part - of the whole HR product spectrum.
Let's pick recruitment. How about of Google did what you say, but just in this tiny space? How much overkill would that be?
It turns out, Google did launch a product in this space. It was called Google Hire.
By your measure, Google should have smashed the life out of this little part of the bigger enterprise software space.
Instead, they shut down within 2 years in a burst of failure.
There's a tradeoff with building software internally and I agree is almost always isn't worth it. But the advantage is that the software has only 1 customer: yourself. That allows a level of product market fit that just isn't achievable with off the shelf software.
Type 2 companies admit that everything they do is wrong and they are willing to change all of their processes and procedures to match those of the ERP system.
Everyone else is deluded into thinking they can modify the ERP to adapt to their business. 10 months into the development cycle, team members realize that the firm requirement that A customer has One customer number is incorrect, and it happens to be a major customer, and there is not a workaround. Sales insists that it is a one to one relationship most of the time and refuses to believe this a big deal. Accounts Receivable thinks they could develop a manual workaround. Modification proceed until the money runs out, and the consultant move on to the next victim. 10 years later the new CEO want to embark on a modernization project for internal backend systems and the cycle repeats.
All I see is one day Google pushing for people to use Google hire and the next day shutting it down.
Personally I think this was fascinating. We got a glimpse at how Google decides to create products and later kill them. In this case - executive pet project that died with the executives departure.
Excuse me if I'm a bit harsh over that.
I was going to write a very similar sentence in another reply.
This is just a case of people not having the slightest clue of what's involved with large enterprise financials. Google has never developed any system that even resembles that.
4. Oracle and SAP have actual customer support that people will want to call when the product crashes. Google will cancel your account for spamming them.
5. Oracle and SAP have sales engineering teams that spend as long as you have budget for to implement the solution.
Yea... it would be nice to have a not Oracle and not SAP product... but Google wouldn't be my first, second, or third choice for a company to buy it from.
You're making three assumptions:
1) Google could build a vastly superior replacement to Oracle's and SAP's products.
2) Google could do it in a year.
3) Google is the only company on Earth that is able to do that.
I don't see a reason to assume any of these three points.