Category Archives: Technology

Technological Damnation 83: Spreadsheets

Spreadsheets. You can’t run your business off of them. But you still can’t run your business without them. Despite the fact that it’s 2015, and that better, customized, back-office systems exist for every facet of your business, most business still run at least one key aspect of their business on spreadsheets.

This is, literally, the only technology worse to run your business, and supply chain, on than the ERP (which, as we pointed out in a recent post, is a supply chain disaster waiting to happen. Do you have to remind you again that Spreadsheets Will Cost You Billions? That Fidelity lost 2.6 Billion due to a simple spreadsheet error? That 1.13 Billion in Fannie Mae Shareholder Equity went out the window due to an honest spreadsheet mistake?

And do we need to remind you that trying to run a business off of spreadsheets is fraught with peril and could result in your organization tossing 20 Million into the trash on an annual basis? That your new support centre could be woefully understaffed upon switchover? That unavoidable delays will result in your projects as a result of spreadsheet gaps?

You know spreadsheets are a damnation because they still exist, five years after the Harvard Business Review told us why good spreadsheets make bad strategies. There’s just no such thing as good spreedsheets. All spreadsheets of any level of complexity contain errors. The most recent statistic, as reported in Forbes last year in Sorry, Your Spreadsheet Has Errors, 88% contain errors (and the vast majority are human. But what can one expect when one in one hundred keystrokes is erroneous?) And so will 88%+ of spreadsheets going forward as forecasts, models, and financial statements just keep getting more complex.

As long as they exist, spreadsheets will be an eternal damnation that might just burn your business to the ground if the sea of red isn’t detected, due to a human error, until it is too late. If it’s the last thing you do, get rid of them.

Infinite Scroll

Infinite scroll, I just can’t abide.
Infinity is hard to comprehend.
You wouldn’t hear my screams,
Even in your wildest dreams.

Suffocation as I scroll the page.
Scared to load the next site
In case the scroll begins again.
Content changing, it will not fix.
Ever flashing, nightmare’s Styx.
Online haze, when will it end?
And will I transcend?

Restless browse, the mind’s in turmoil!
One nightmare ends another fertile.
Getting to me, too drained to surf.
But scared to leave now, too immersed.

Now that it has reached new heights,
I do not like the restless nights.
It makes me wonder, it makes me think,
How’d we get to this? We’re on the brink!
We should be scared of what’s beyond.
Someday our brains might not respond.
We had an interest almost craving,
but do we want to get too far in?

It can’t be all coincidence!
Too many things are evident.
You tell me you’re an unbeliever.
Technophobic? Well me I’m neither!
But wouldn’t you like to know the truth,
Of what’s beyond, to have the proof!
And find out just where we’re heading’?
Techtopia? Or to Armageddon?

Help me, help me to find
the true path without seeing the future.
Save us, oh save us from
torturing ourselves, unnecessarily.

There’s got to be
More to it than this.
Or tell me why the web exists?
I’d like to think that we evolved,
and our sins have been absolved,
as technology resolved,
limitations of the past
and evolved to the point where it can be grasped!

With many, many apologies to Harris.

And, in case it isn’t totally obvious, the doctor, who has already asked what idiots brought back infinite scrolling websites, would really like to see those idiots tarred and feathered. (If they can bring back infinite scroll, which is where we started back when all we had was HTML 1.0, then we can bring back tar and feathering!)

Happy 20th, Java!

That’s right, 20 yeas ago today the first version of the Java programming language was released, and the web was changed forever. (And with the exception of James Gosling, Mike Sheridan, Patrick Naughton, and their development team who worked on Oak [which was the beginning of the Java language project] between 1991 and 1995, the doctor becomes one of the few individuals who can honestly claim 20 years experience in Java and the Java platform — as he downloaded it in May, 1995 and was teaching it in Data Structures and Comparative Languages courses as far back as June, 1995.)

It might be hard to fathom that Java didn’t exist 20 years ago considering that the vast majority of desktops run Java, that it’s been the top rated development language (on the Tiobe index, for e.g.) for most of its existence, and that many enterprise systems (including many supply chain systems) run on Java, but it didn’t.

So while you’re having your cup of Java today, think about this and wish Java a happy birthday. Especially considering that it’s ancient in internet years and still going strong!

The First Four Questions to Ask During Any Mega-Acquisition

A recent guest post over on Spend Matters on “Four Questions to Ask … During Any Mega-Acquisition” was really good. These are becoming all too common and each and every one impacts your organization, often in negative ways.

But the post could have been better. More specifically, the questions could have been more direct.

To make sure that you understand the very important intent behind each of the four questions, SI is going to rephrase them in such a way that there will be no confusion.

1. How will we get screwed over on price?

Every acquisition brings with it the promise of economy of scale and lower price, but it typically takes years to understand overlap, redefine responsibilities and organizational boundaries, and identify staff reductions. And since, in the interim, change management experts, process consultants, and other resources need to be brought on board, overhead goes up and costs go up accordingly.

2. How will we get screwed over on quality of service?

The biggest fish in the combined company gets the best resources. And just because your current organization was a big fish in the old company, that does not mean your company will be a big fish in the merged company. Your company might just be a medium sized fish that gets the “B” Team, if it is lucky.

3. How will we get screwed out of innovation?

Will the merged company continue to develop the platform our company is on or will we remain locked in to a multi-year deal as the technology we bought withers and dies?

4. How will we get screwed in new and interesting ways?

What additional layers of complexity and confusion will the new, combined, legal team try to weasel into the contract and how will that bite your organization in its backside down the road?

Sometimes acquisitions are good, but mega-acquisitions often bring mega-problems and, at least in the short term, don’t’ end up being good for anyone.

What Would the Acquisition of SalesForce Mean to the Procurement Market?

Who Cares?

While the doctor and the maverick see eye-to-eye on a lot of issues, and that’s why they have been collaborating on the new Spend Matters CPO site because there are important messages that are just not being communicated by the new press at large, the doctor believes that the impact this acquisition will have on the Procurement market, as summarized in yesterday’s post on “what would the acquisition of salesforce mean to the procurement market” by the maverick, is not as important as the maverick seems to believe it is.

While the acquisition of SalesForce is an important topic, it’s no more important than the acquisition of any non-Procurement technology vendor. (While some SRM vendors use the platform, one has to remember that it is, at its core, a CRM platform). It’s (primarily) upstream, while Procurement is primarily downstream. While the processes should connect, they are still distinct and, unless you are in the middle of a negotiation, there’s no reason to even think about it as a Procurement issue.

The real issue is what does the acquisition of SalesForce mean to the technology market, and the market at large?

And while the doctor knows that he’s not just stirring the pot but the entire honeycomb on this subject, it’s a subject that needs to be addressed. So what does it really mean?

Simply put, too big to succeed!

One of the biggest problems with the technology market is that the misconception that bigger is better, and too big to fail, is a reality. The whole point of big was to benefit from economies of scale. But economies of scale have a limit. A single factory with a single production line can only produce so much going 24 hours a day. To go beyond that, you have to add another production line, or even another factory. If you do so, and you only reach half of the capacity, you don’t have the same economy of scale on the overage.  The biggest economy of scale was when you were at full capacity on the one line.

In other words, if you expand faster than demand, you waste time, money, and resources. This situation is bad, but the situation that occurs in an acquisition is much worse. Not only do you have more capacity, but you have a huge debt load as a result of the acquisition. So you are paying more to produce, and then you are paying even more to service the debt that you took on to produce more than you needed to.

But even this situation isn’t as bad as the situation where you are talking about technology companies that don’t produce physical goods, don’t have demand that typically rises with population increase or market growth, and have valuations that are many multiples of annual revenue — not profit, revenue. And we all know that the misconception that the product has already been built and the residual cost of sale is minimal is incorrect. Software has to be maintained, debugged, and constantly improved in order to be saleable to the mass market. That is costly. Whereas a product has a single production cost, possibly a single repair cost under warranty, and possibly a single reclamation or disposal cost, that’s it. The cost for each product is essentially one-time, whereas the cost of software is continual and adds up everyday it is in use.

As a result, you have software that typically:

  • cost millions to build
  • costs millions to maintain

and now you want to

  • add millions to the cost just so you can change ownership and assign a different name

It doesn’t make a lot of sense. Especially when you are talking about the acquisition of an 800 lb gorilla which already has a (relatively) complete solution. In this situation the acquirer is essentially admitting that either

  • its solutions are totally inadequate and it wasted millions of its customers dollars on its solutions (versus realizing that it has some good solutions, is missing a few key elements, and just needs to acquire a few point solutions from smaller vendors to fill the holes) or
  • it has no inherent capability to enter the space (and maybe it shouldn’t be entering the space to begin with).

And the acquiree is essentially admitting that

  • it cannot maintain (rapid) growth on its own anymore (which may not be bad if it’s the dominant player and has a very large recurring revenue and could continue to increase profitability with improved efficiency) or
  • it’s shareholders are greedy and impatient and don’t care what’s best for their customers and just want a quick payout.

Neither situation is good for either party. Nor does it make sense for any of the de facto tech giants who would likely acquire SalesForce to do so. None of the six AMIGOS (Amazon, Microsoft, IBM, Google, Oracle, and SAP) should acquire SalesForce. Here’s why.

  • Amazon
    They are an online e-commerce giant, with inherent ability to be a commodity supplier to large enterprises. They are not a software provider and beyond insuring quality, and receipt of goods, would not benefit from CRM. Sure the Force.com platform would allow them to offer even more apps, but they can already offer Android apps and sell online software, so it’s not a huge leap in capability.
  • Microsoft
    They already have huge back office suites that they have made huge investments in, including investments to port these suites to the cloud. Plus, their focus, and strength*, is back-office apps. They’d be taking a huge-write off on existing technology and would have to rewrite a lot for a whole new platform. They already run on Windows and Mac, that power the vast majority of office desktops, so why do they need the Force.com?
  • IBM
    IBM already has platforms for just about everything, including Alliance for CRM, have heavily invested in Watson, and need to keep building on the workflow and integration platforms they spearheaded in the early naughts.
  • Google
    the doctor will admit that it almost makes sense for Google, but Google’s market, and expertise, is apps, and it is still learning how to make money off of enterprise apps. It’s not ready for SalesForce, would have to let it run as a completely separate division, and take a huge hit to its balance sheet to pull of the acquisition. And while it’s the one company that could probably pull of a successful integration in a reasonable timeline without bleeding blood red everywhere, it would likely be quite a divergence from its other projects.
  • Oracle
    Oracle has too many CRM platforms as it is (with Siebel, PeopleSoft, CRM on Demand, and integration to about a dozen other platforms) and needs to continue to integrate and build on what it has. What makes Oracle strong, and great, is that it has always believed in eating it’s own dog food (while Microsoft ran off of third party databases even after SQL Server was released and has demoed Windows software releases on MacBooks on more than one occasion), but even Oracle can only integrate its acquisitions so fast. It’s still catching up on acquisitions past (and it took about 3 years to integrate the majority of Sun applications into its “single instance view”), so just imagine the effort to do a true end-to-end integration of SalesForce. Plus, it’s still a database / ERP company and with SAP so aggressively pursuing its marketshare in the US, with IBM and Microsoft still aggressively pursuing its global market, and with some companies (still) proclaiming that non-relational or in-memory databases can be faster and better for the average application, it has to focus on winning that fight.
  • SAP
    SAP is an ERP company with a very heavy focus on SRM, as evidenced by the huge amount of money it has dropped on Procurement, T&E, and Supply Management vendors over the past few years. This is where it has to focus to not only break-even on its acquisitions, but generate future value. And it still has a lot of integration to do. A lot.

the doctor‘s sure not everyone will agree with him, especially since people seem to get a little blind when such big numbers start flying around, but someone has to start putting this in perspective.

And now to put up the tarps in expectation of the reactionary mud-slinging from third parties not inclined to think deeply about the issue.

* And yes, the doctor cringes when he says this because most of their software, in his view, while standard, is sub-par — but they are the de facto solution and their Office apps, when you cut through the clutter (and the ribbon), work very well.