It's not even their first migration away from Oracle. I am fairly confident that Google used the horrible Oracle Calendar internally fifteen years ago (at least for travel?), until later GCal was able to replace it. And I remember another finance-related migration ten years ago or so, during the Pichette days. I thought they had gotten rid of Oracle once and for all, maybe it returned through the backdoor — an acquisition.
Yeah, I started at Google in early 2006 and definitely remember using the awful Oracle Calendar product for all calendaring. I know because I set up a calendar entry in Oracle Calendar for the day in 2015 that Back to the Future takes place...only to have to create it again once we moved to Google Calendar.
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.
that product was Steltor Calendar Time which then was purchased by Oracle. For the time, it wasn't terrible (it supported sync to palm pilot). But yes, GCal is a real improvement.
The funny thing is, considering they are taking on the time & cost to move their entire system to SAP, the Oracle one they have in place today must somehow be significantly worse. Imagine that.
Not hard to imagine if you've ever had to deal with Oracle apps. Sure, their DB was the gold standard for a long time, but their apps were always abysmal, and then of course many were cobbled together from acquisitions over the years.
I wonder if Oracle worth was mostly an army of salesmen with one good product and loads of persistence (pun not intended). I've dabbled with 2 applicative from the 90s based on Oracle rebranded things and they were very subpar to say the least.
My previous experiences in dealing with Oracle as part of an RFP is that it's like something out of Mad Men, in the worst possible way: we had a bunch of requirements that they didn't want to meet, because they were trying to sell their DB appliances, they berated the RFP committee for having those requirements. They laid complaints with our management line against one staffer for asking "hostile" questions.
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.
I have had Oracle, CA and Cisco sales teams do this to me, and I had one consulting company another manager brought in to work on AD forest consolidation start a campaign to get me fired after I outed their supposed SME as having no actual AD experience ("DNS has nothing to do with Active Directory" was just one gem he pushed). While unfortunately it worked for Oracle and CA, Cisco never really had enough juice with the executives to change architecture decisions after they'd been made outside of core networking.
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.
A lot of it seems to be the context that they're operating in: Oracle seems to be a really brutal environment for sales staff; I see account managers disappear every 6-12 months, and everything I've heard from people who work for resellers or Oracle in those kind of roles paints it as being absolutely ruthless in a "Glengarry Glen Ross" kind of way.
Reminds me of when a person on the Ars Technica forums posted something that upset the sensibilities of EMC, (it was something about an Avamar bug iirc) who cyberstalked the poster and called the CIO or CFO of his employer.
Ah yes those big companies have specialist "salespeople" whose job is berate the lower-ups and suck-up to the higher-ups trying to sell their overpriced crap
A non-trivial amount of cases is when you buy a software package that only supports Oracle - that was pretty much the only reason why we didn't have a campaign to eradicate Oracle DB in my first job - the most critical money-making system was dependant on it.
A little of both. Back in the day you had a few different platforms. Oracle was a safe choice and eventually a no brainer... most companies had either MS SqlServer or Oracle capability, and a smaller number ran DB2.
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.
Some of it was specific features offered by Oracle - the ones relevant to my first job were Oracle RAC and in-DB encryption, iirc. We were at the time (2008) upgrading from 3-node cluster in one DC to geographically dispersed system with hot backups.
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.
I've worked closely with the developers of a couple of such apps and in those cases it was a mainly that Oracle had some non-standard features that made implementing certain core features in the app a lot easier and faster for the developers.
I use exactly one SAP application once a month to enter how many hours I worked every day of that month. Let me tell you about it.
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".
This app you use is using 20 years old UI concept that has been replaced by SAP a few times. But thanks to the almost eternal compatibility it still works. SAP products have many weaknesses and they are always late and not the best adopting the new trends. But a lot of blame they get is caused by poor implementations in one side and the customers not adopting the newer options for another.
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
Having an application that keeps working for decades isn't particularly rare in large companies. And yet the SAP applications are systematically among the worst ones to use, worse than the IBM terminal apps or a command line utility.
It's like a framework that allows companies to build apps. The kind of apps for which every employee needs a 4-hour training (for each app) just to be able to fill some data in a form regularly, or to be able to view a list of assigned tasks and close them.
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).
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.
That's one way of viewing them and I think quite valid. Another lens is that they have a product that can be customized to meet almost any need, but as a result what you get out of the box, or with a poor implementation, is severely lacking. This also drives what you observe - Having an extremely flexible framework rather than a finished product in your sales offering means your salespeople get to run amok promising the absolute earth. Of course SAP can do what you need... it can do anything*
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.
Possibly not, but the hazards of software procurement bite bigger at that kind of scale, and it's an under-studied science with not enough assurance of quality outcomes. I'm sure that 'x percent of IT projects fail' metric has improved at least somewhat in the last couple of decades but it's still fraught with pitfalls. Not uncommon to end up with an end result only as good as, or even potentially worse, than the one you were rushing away from. Better the devil you know, and all that.
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.
Sure. Make it yourself. Very easy. In several of my companies we would create our own business layer, without the SAP bullshit.
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.
I've had some working experience with SAP. If you use their latest and greatest, it's not as painfully bad as people think it is. Large part of SAP will be in-house customization (or you pay SAP to do that), so that is a very mixed bag.
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.
It's the classic-PHP of business systems. You could build great systems in (old-school) PHP, which dramatically improved users' lives; but more often than not, you'd end up with an unmaintainable bowl of spaghetti instead, that only the original cook could understand - and very rarely users' lives would actually improve in any meaningful way.
Not comparable. PHP has at least fantastic performance. SAP is not only as ugly and illdesigned as PHP, it is mostly slow as hell. Besides expensive. PHP is free.
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.
You'd think they'd assign an in house project to X to build a better tool with the ability easily to migrate from Oracle. Dogfood it for a few years and then sell it to get their revenge on Larry.
Relative worked for the biggest bank in India. They had to use Oracle's Office suite. The relative and his colleagues swore up and down that it was worst software (not just the worst office suite) they have ever used.
That’s by design though. It’s best if you have the largest pool of payroll applicants available by way of using the most universally-known payroll system. Larger applicant pool = better eventual employees.
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.
“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.
If I remember correctly, Eric Schmidt said that one of the first things he did as CEO of Google was to move the company off of Quickbooks and onto Oracle ERP. SAP HANA is certified for AWS, Azure, and GCP and all three are trying to win SAP customers as they transition their OnPrem systems to the cloud. Oracle has long had an antagonistic relationship with its partners; I suspect this move is a strategic alignment with SAP as a key Google partner. The enemy of my enemy... probably plays a part too.
> Still, Ellison has boasted about its business with Google. During a 2019 meeting with analysts he said that when Google catalogs vast amounts of information, that data is “actually sitting in Oracle databases.”
It could be more misleading. He could have said "sitting in an Oracle database". And that would imply that Oracle can scale enough that one instance would handle it.
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, like its users, has no concept of their core competency. The only reasons I assume they'd skip building their own ERP are that it's a boring product and, if they tried to sell it, they'd actually have to support it.
Unless you squint hard enough count their cloud services, Google has zero demonstrated competency building enterprise apps. Their core competency may be a mystery, but we can rule out some things, and this is one.
G Suite or whatever it's called today isn't "enterprise apps"? And their GCP is still third in the running and bigger than Oracle's and IBM's clouds, so that's gotta count for something.
"Enterprise app" was perhaps too general. Neither of those examples remotely resemble an ERP application.
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.
I disagree. Google could be extremely strong here. Both SAP and Oracle are essentially a database with a web- and UI framework and a few example apps. They are "dBase in the (locally-hosted) cloud", evolved 10 years. And yes, a few of the example apps delivered with the DBs are certified for certain financial purposes, which Google wouldn't have. But Google has quite a few parts of this already in place.
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.
It's massively reinventing the wheel. ERPs do a lot of important things, and where it matters, they do it in a very compliant way.
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.
It is a pain in the ass, nobody really wants to work on it, it creates a maintenance risk, and Googlers are paid super high salaries.
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.
I worked on a decision like this once. It eventually came down to the financial auditors preferring SAP’s reports. Roll-your-own isn’t going to fly with anyone.
There is a famous story that the engineers wanted to way back when and Eric Schmidt managed to get them to stop by saying "Oracle is auditable" and all the engineers were like "ugh, government regulations" and that was that
Too easy for someone to use it to cook the books? Maybe it looks better in an audit if they can point to an external source for their accounting software.
> Too easy for someone to use it to cook the books? Maybe it looks better in an audit if they can point to an external source for their accounting software.
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.
I'm an external auditor, this is definitely true. Large ERPs have special audits done over their technical systems that we can rely on and not really think too much about whether the system works or not, since another auditor has already signed off that it does.
I could make any adjustment I want to posted GL transactions using SQL and knowledge of the chart of accounts and subledgers. No one would know unless it is a transaction picked for audit. This is true at least for Oracle ERP - there is no database row-level security for posted GL transactions.
So auditors belief that an Oracle ERP system gives them confidence in a company audit is misguided.
I'm an auditor, and what you're saying is probably fair, but probably not a big deal. I have a lot of clients who either use Excel for their bookkeeping or provide us their full GL in Excel, so we always have the risk of changes being made, but we're not too concerned since our regular audit procedures would uncover it.
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.
> I could make any adjustment I want to posted GL transactions using SQL and knowledge of the chart of accounts and subledgers. No one would know unless it is a transaction picked for audit. This is true at least for Oracle ERP - there is no database row-level security for posted GL transactions.
> 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.
Because it's less about engineering and more about knowing all the laws and regulations. You'd either need developers with both expertise or have these people working together finding a workable software interpretation of all those legal documents.
They’ve had 16 years with the smartest people in the room to reinvent the wheel and they’ve got... nothing.
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.
Even Microsoft runs SAP Finance and Microsoft has a lot of ERP/Finance knowledge in house. I guess building a system that supports the scale and specific accounting standards all over the world is a non trivial task.
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.
>Even Microsoft runs SAP Finance and Microsoft has a lot of ERP/Finance knowledge in house.
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.
Last time I checked (6+ years ago) even the top of the range Microsoft ERP products (which called Dynamics AX at the time) was actually pretty limited compared to SAP - in particular it's payroll module only seemed to handle the US.
It's less about confidence in the product and more about having a product that is the right fit for you. Companies like Microsoft are at the very high end of requirements and complexity. Dynamics is more targeted at small to the low end of large enterprise companies.
Build an internal finance system? Engineering is not the primary activity there - modeling business process, regulations, accounting principles, compliance and legal considerations is the hard part.
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.
Google could probably do it if they REALLY wanted to. But to handle all the small nuances and complexities is not trivial. An example - larger companies will never use Expensify because of a lot of features that it lacks compared to Concur.
This is a great and confusing question, because of all large companies Google seems most inclined to want to own their whole software stack. Plus, they have an army of engineers who surely think finance software can't be too complicated!
So what gives? How could Google end up in this position?
They may have tried already. It turns out that financial software is really complicated. The basic functionality is never too complicated, but most of these systems are edge cases that needs to be treated specially. Also, a lot of behaviour has legal implications, so it would take a long time to develop software to compete with something like SAP.
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.
Oracle used to be the most popular db for SAP along with SQL Server and DB2. That changed with SAP HANA. These days SAP HANA is the only supported DB for latest and greatest.
When I search for SAP HANA, it says it's a column-oriented in-memory analytical RDBMS; is that outdated info? Where is the actual data stored if this is in-memory?
From what I know, HANA also keeps a copy on disk at all times. The "in-memory" label is valid because a full copy of all database contents is held in memory, and all reads are performed on that copy.
Disclosure: I work at SAP, but neither on HANA nor on any part of the "SAP system". (I'm in the cloud infrastructure unit.)
Not knowing too much about Hana, it seems like they are doing their best to wrap in as much business intelligence as they can as opposed to having their users purchase other services, is this the case? Or do people generally maintain their BI stack after adopting Hana?
Oracle ate a bunch of their market by going after the BI ecosystem at large and using those apps to sneak in their DB. So SAP decided they'd do the same "downstack" and eat some of the Oracle db revenue. Hence the push for HANA.
I know Oracle has some data mining module and decent stats functions in the database engine, but what's their end-user BI offering? Or is it just baked into their ERP offerings, so it's not branded separately?
There is a reason you don't know them - you really don't want to, trust me, don't go looking for trouble. But yes, they do have loads of stuff that is not in the database. 99% of them came from acquisitions and were then smashed together in something resembling a vaguely-coherent ecosystem.
HANA works on-premise as well as in the cloud. If I had to guess, I'd bet that on-premise deployments are still more numerous than cloud deployments (although the share of cloud is growing rapidly).
Do you actually hate cookie notices that inform you you're signing your soul away? Or did you just not know you should hate the internet before the notices became required?
I know what a cookie is and never really cared. Seems like a fair trade for a wealth of entertainment and knowledge that 30 years ago would cost considerable amounts to obtain. An ad for board games because I Googled board games doesn't make me feel like I sold my soul to the devil, like some seem to believe.
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).
Before, I was not aware that by reading one tech news article, ALL of my historical personal data across all of my devices would get processed by literally hundreds of different faceless corporate entities.
Honestly I’m surprised they haven’t built something in-house. Actually, I’m not: accounting and payroll software isn’t core to what they do so best to buy it.
Google is probably the only company on earth that could spend about a year and build a vastly superior product to both Oracle and SAP that everybody would want. So why don't they?
My guesses:
1. It's boring.
2. Those are marketing-driven products and Google is engineering-driven.
I agree they won't do it, but it isn't laughable. I've worked at another FANG and have used a lot of the recruitment software you reference. That FANG rebuilt the software from the ground up internally and have successfully made their process much more effective to the point of it being a competitive advantage.
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.
ERP Implementations go well for 2 types of companies. Type 1 companies have well documented, logical consistent processes and procedures that server as clear spec for necessary ERP modifications.
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.
Google Hire was an external acquisition: it used to be called Bebop, and it came along for the ride when Google hired its CEO Diane Greene to run its Cloud operation. After Diane got the axe, Hire was promptly nuked as well.
This feels like an unnecessarily harsh reply. It is easy to find that Diane Greene came onboard with a product called Bebop: https://venturebeat.com/2015/11/19/google-buys-diane-greenes.... It is easy to find articles as well about how bebop turned into Google Hire.
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.
I find it harsh too when google first tries to on-board me on a new product and shortly after that discontinues it. Most (all?) of the work from transitioning from an other product is onto me, and now I have to do it all over again.
> This is laughable to anyone who has ever worked on development of an ERP product.
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.
To be fair, I don't think Google Hire's target customers were considering Oracle or SAP for hiring. They seemed to be more in the Greenhouse / Lever market.
> Google is probably the only company on earth that could spend about a year and build a vastly superior product to both Oracle and SAP that everybody would want.
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.
3. No one would recommend a product that is likely the next item to go on the killed by google chopping block.
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.
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.