Category Archives: Technology

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.

Societal Damnation 47: XaaS (Part II)

In our last post we introduced you to XaaS, Everything as a Service, and told you that this latest craze is going to cause your Supply Management organization nothing but suffering and pain. Why? Because even though, historically, the transformation of a non-core but essential function or utility to a service was a good thing that made your life easier, like all good things, there is an end to the goodness. Taken too far, nothing but chaos will result by handing over a function to a third party that is not well equipped to handle your service needs because they do not have the expertise, cannot achieve the necessary economies of scale, or just can’t be managed effectively.

For example, let’s say sales and marketing decides that IT just isn’t cutting it and decides to outsource IT support for marketing to a third party, and the organization is a CPG company that depends on all communications, orders, and marketing deliverables being properly archived in the ERP and Marketing Procurement system for compliance, cost management, and post-campaign/event analytics. This brings with it a host of problems. One, the systems are not being managed by IT or the support organization IT recommends. This increases 3PM overhead, causes the organization to lose out on better rates that come with more volume, and could result in core systems being bypassed (if the provider is inept and can’t figure out how to push critical data into the core systems). Two, it sets the organization up for a compliance nightmare down the road (when audit trails go cold due to missing data). Three, it opens the door for over billings, duplicate billings, and even fraudulent billings when AP can’t find all of the associated PO and contract data to m-way match an invoice. Four, instead of providing Supply Management with an opportunity to determine why IT isn’t meeting Sales and Marketing needs (which could be due to a misunderstanding, lack of staff, or other issue that could be easily solved by Supply Management) and identify a solution that would benefit the entire organization, it instead opens the door for each OU to hire their own provider (since Sales and Marketing did it), and burden the organization with a 3PM nightmare in IT.

And this is just the tip of the iceberg, as IT has been commoditized for over a decade now, and there are methods to manage this madness. The real problem is when different Business Units decide that anything they don’t feel is critical to manage in-house should be a service and the marketplace adjusts to that mindset. Product Design as a service. (R&D) (Hey, all we need to do is approve a design since we just need something to sell, right?) Supplier Management as a service. (Engineering) (We’ve approved the design, who cares who builds the product and how they do it, right?) 3PL Transportation, Inventory, and Distribution Management as a service. (Logistics) (Who cares how it gets to the shelves as long as it eventually gets to the shelves, right?) Campaign Management as a service. (Marketing) (Once we’ve defined the message we want to get across, we can just hand it off to a local marketing management firm to best tailor the message to the region and produce the ads, right?)

Each of these services can lead to massive headaches, fines, and reputational damage if the service provider does not understand the needs of the organization, does not employ proper processes and procedures necessary to ensure quality and reliability, does not have the right certifications and insurance, does not have a proper focus on sustainability and Corporate Social Responsibility, and does not ensure fair and equitable treatment to workers throughout the supply chain. For example, a design that does not adequately consider product safety and results in an electrical appliance electrocuting a consumer during normal use (due to lack of safeties and blowout circuits) will result in massive lawsuits. Poor supplier management could result in missed deliveries, poor quality, high defect and return rates, and even the inclusion of banned chemicals or compounds in the product which will result in costly recalls or border seizures. Poor logistics management will lead to high stock-outs on the shelves, and lost sales, which, if significant, could make the difference between profitability and impending bankruptcy for the organization. And a poor marketing campaign, that includes phrases or images offensive to members of the local community, will result in a media onslaught that will result in massive damage to your brand. And that’s just the beginning.

Services are good. But Everything-as-a-Service is a ridiculous concept and any organization that buys into it is just asking for trouble.