Knowledge_as_a_Service (KaaS) - cumulusIQ Blog!

A Helpdesk for the Helpdesk

Questions very often are more important than answers.  Just ask one of our consultants on the SAP KaaS Virtual Helpdesk.  Where an answer only provides whatever specific information is required to respond to the question, the question can be about anything at all.  So questions reveal what people are interested in; what they don’t know; and where you may need to do a better job of explaining.  Questions are also a handy way to tag information (as in an FAQ) so people can find the information faster. Reading (or hearing) someone else’s question may also prod you to realize that maybe you don’t really know everything you thought you knew — or that other people don’t know what to you seems obvious.

So it was at Sapience2009, when someone asked who was the intended audience for our SAP Virtual Helpdesk — regular end-users (like for password resets, etc.) or SAP super-users & professionals looking for advanced help.  After more than 20 minutes of explaining the helpdesk functions and providing samples of various questions on both the technical and business side, I had to wonder if this person had been paying attention.

The answer is SAP super-users and professionals seeking advanced consulting help.  It’s a helpdesk for helpdesks.

Of course, maybe the person asking the question was paying attention.  Perhaps the problem is with the definition of helpdesk itself.  It could be that the helpdesk has become so closely identified with the end-user for so long that the idea of a helpdesk for people providing help is just too big a stretch.  It could also be that the necessary differences between a “helpdesk for helpdesks” and a “regular end-user helpdesk” are not as obvious as they seem to us.

So maybe we should have included in our presentation a slide that compares the two.  So here goes . . . compared to the regular kind, a helpdesk for helpdesks or what we call "KaaS Helpdesk":

• Is staffed by a wider range of specialists
• Has deeper expertise in those specialties
• Is staffed by consultants skilled at helping other SAP professionals
• Employs a pay-as-you-use model because customers don’t need this much expertise all the time and so should only pay accordingly

What makes this concept possible is the cloud delivery model — a much more recent development that the helpdesk itself.  It is the cloud that lets us provide such a high level of support and scale it at an affordable price for so many customers.

We Don’t Take Questions at Face Value

Helmuth Gümbel -- Senior Research Director, Managing Partner at Strategy Partners International -- asked an excellent question at the close of my Sapience2009 presentation on Tuesday.  The presentation, titled “Knowledge as a Service,” described the KaaS concept in general and the SAP virtual helpdesk in particular.  The helpdesk allows IT staff to get answers to technical and business process questions from senior SAP consultants in the cloud, on demand. 

The helpdesk is especially helpful when you’re missing a key piece of knowledge, and that roadblock is preventing you from making progress in your business — but it may not justify spending thousands of dollars and waiting weeks to bring a consultant onsite.

Here a couple of the sample helpdesk questions I used in my presentation:

We would like to use the Capital Lease functionality delivered in the SAP Fixed Assets module.  However, standard SAP doesn’t fit our model….

and

How to default profit center on billing document without Sales order?

So, as I wrapped up, Helmuth asked a question that essentially was:  Do you take a customer’s question at face value?

What he was getting at is the fact that very often people don’t know the right question to ask.  They don’t know what they don’t know.  And they may not know what they need to know.  So, here’s my answer to Helmuth:

When someone submits a question to the virtual helpdesk, it is reviewed to see which consultants on the helpdesk have been pre-qualified in that particular area.  Then the consultant who takes the question will very often start by asking questions of his or her own -- probing the customer to make sure the right issue is being addressed.  Finally, that consultant’s answer is quality-checked by an even more senior consultant before it is sent along to the customer.

We don’t simply jump in and provide answers to questions at face value -- answers that are technically correct, but which may also be irrelevant or, worse, send the customer down the wrong path.

The Best Answer for Open Source

An article in today’s New York Times shows how Oracle’s pending acquisition of Sun Microsystems reveals an inconvenient truth about the open source movement: with only one exception (Red Hat), free software has proven economically unsuccessful. Open source companies don’t make money on their own, even by selling ancillary products and services.  Nor are they apt to make money for the companies who buy them, as Sun did MySQL and Citrix did XenSource, a virtualization company.  Rather than generate cash, these acquisitions provide technology that would otherwise have to be developed internally over a much longer time period.

Furthermore, as the article says, “Many of the top open-source developers are anything but volunteers tinkering in their spare time. Companies like I.B.M., Google, Oracle and Intel these developers top salaries to work on open-source projects and further the companies’ strategic objectives.”

Just because the software is “open” -- i.e., open to outside collaboration -- doesn’t mean it has to be free.  In fact, the more successful the software the less free it tends to be.  Eventually, there has to be real money involved (or strategic advantage, which is the same thing).  Simply the opportunity to contribute is insufficient by itself

This says a lot about successful open collaboration in general -- with clear parallels to cumulusIQ.  For example, rather than a big company (like IBM or SAP) paying collaborators, our users pay.  The collaboration is equally “open,” however.  In fact, you could say it is even more open since it is clear who is paying.  That’s the same person whose agenda is being served:  the user. Other advantages of the “open” model also apply -- like the freedom to choose from among multiple collaborators for the best answer to a question.

That may also be the best answer for open source:  Users pay collaborators.  In fact, users might even pay other users, who could also be considered collaborators just for asking the right question or raising the right issue.

Help for the Masses

An article in Sunday’s New York Times, “Supercomputing for the Masses”, makes many of the familiar points about cloud computing economics. Linking up resources in the cloud -- both for raw computing power and information sharing -- gives “ordinary people with a novel idea a chance to explore their curiosity … and perhaps find something new.”  Dramatic discoveries happen faster when “ordinary people” have access to the resources previously available only to specialists inside their respective institutional and disciplinary silos.  Of course, the specialists can also reap bigger discoveries faster when they’re able to reach across institutional and disciplinary boundaries.

And that’s the problem.

Organizations don’t like sharing information with the cloud -- and their competitors.  As one scientist in the article says, “All the data that we collect in science should be accessible, and that’s just not the way it works today.”

That’s like the ERP market.  Don’t expect the ones with the most knowledge -- large software vendors, software integrators and consulting firms -- to contribute any time soon to a cloud-based initiative designed to speed innovation, lower risk, and help ordinary users become much more productive. Cloud computing isn’t just about achieving technology milestones.  It’s about helping smart people contribute anonymously so that their bosses won’t fire them.

The Suite Is the New Silo

I will be speaking at Sapience2009 (Cambridge, MA, December 8^th and 9^th).  It’s a conference about how to get the most value from an SAP solution, which is often not to use another SAP solution.  Our own example is a cloud-based helpdesk that avoids the need for help from SAP itself. The cloud alternative costs less and offers access to world-class talent that might otherwise be out of reach of the average SAP user.

The conference opens with a panel on a very intriguing topic: “How Sweet is the Future for Suites?”  It’s an excellent setup because it goes to the heart of SAP’s value proposition.  That’s the idea that a collection of resources is better served as a package than for the user to assemble resources independently.  Before ERP there were silos and without ERP there would still be silos -- and resources would still be trapped inside.

So now the cloud vendors (like us) are saying that it is the ERP suite that is the silo.  Knowledge and functionality trapped within an ERP solution are still trapped.

That doesn’t mean, however, that the cloud is the new suite.  The idea of pre-wired collections of applications that speak the same language and represent one version of the truth is still very compelling.  There is also a generation (or two) of IT professionals whose careers are tightly linked to the ERP suite.  None of that is going away anytime soon, if ever.

What will happen is that ERP will be less a silo and more of a cell (the living kind, not the jail kind) whose wall is permeable.  And just as with the living kind, the future is decided by evolutionary comparative advantage.

Where it makes sense to have things tightly connected, they’ll be tightly connected.  But evolutionary comparative advantage will go to those ERP suites that thrive within more complex organisms. Comparative advantage will also go to those user organizations that move beyond one-size-fits-all ERP. And comparative advantage will also go to those alternative providers (like the ones speaking at Sapience2009) who seek to evolve ERP rather than replace it.

The Open Collaboration Desk

When disruptive innovation occurs it is human nature to call it something familiar -- think “horseless carriage” or “talking pictures” -- until the point of reference seems more out of date than familiar.  That may be the case with “virtual helpdesk.”  Users do come to the cumulusIQ platform for help.  But is it “help” when a product designer reaches out to social networks for new ideas -- a model more generally recognized as open collaboration?  And is it only “help” when an SAP business user wants to enable a new workflow than the one originally envisioned by SAP developers? 

Yes, the questions we get are indeed for help -- such as to fix a technical glitch or learn how to use a particular product feature.  But often the question is really about how to do something new and innovative -- even if just a little.  In those case the virtual helpdesk becomes an ideal platform on which to conduct incremental innovation in an open collaborative way.

What got me thinking about this is an excellent article by Anrea Gabor titled, “The Promise (and Perils) of Open Collaboration” (Strategy+Business, Autumn, 2009, Booz & Co.).  The article cites “seven key strategies that pioneers of open collaboration have used to succeed….” One of these, “cultivates continuous improvements,” speaks to incremental innovation as inherent to both open collaboration and sustainable competitive advantage.  It produces products that are of higher quality, are better suited to what the user needs now, and carries lower risk of failure.  

This is another reason why our model is different from a remote helpdesk run by a consulting or SI firm.  Like them, we can handle the traditional fix-it question.  But we also support collaboration -- and incremental innovation -- that is open to anyone.

What Is a Cloud Service?

I was naturally interested in Monday’s InfoWorld Story titled “Startups take SAP consulting to the cloud” that discusses cumulusIQ and another company.

One of the questions I wish had been answered in greater detail is: What makes a service cloud-based?  Is it just technical support over the network?  That’s not new.  In 1980 Digital Equipment Corporation introduced remote system diagnosis over a network (for the VAX 11/750).

What’s different and exciting about the cloud is that it delivers Knowledge as a Service (KaaS).  KaaS is the culmination of the most important Web 2.0 concepts, like crowd sourcing, software as a service, virtualization, long tail, pull versus push, and on-demand.

In KaaS, users are not hardwired to a single group of consultants and are not even buying consulting from a vendor (unless you call the individual consultants vendors). That would be far too limiting.  Instead, users buy knowledge from sellers in a global marketplace in real time.  Any number of people can participant -- consultants to make money and gain recognition; users to acquire knowledge when and where they need it without paying for “extras” like onsite visits they don’t need.

One further comment on the story:  Jon Reed is quoted as saying that cloud services are a “creature of the recession.”  How negative is that?  It implies that our customers use us because they’re broke.  But obviously there are many situations when obtaining knowledge on-demand from a global pool makes more sense than getting it from a hardwired resource (whether onsite or remote).  It is more accurate to say the cloud is a “creature of innovation.”

Why Pay Two Service Providers?

Here’s a simple question:  Why would anyone pay for cloud-based Knowledge as a Service when they already have an expensive support contract with one of the world’s leading professional services companies?  If you are already writing a big check to your “regular” provider, why then write two checks -- one to them and one to a KaaS provider?

The answer is:  Because if you write the second check, overtime the size of the two checks together will be much smaller than if you only wrote the first big check.  You’ll also get many of your issues addressed sooner than if you’re forced to go through a big inflexible bureaucracy whenever you want to get something done right away.

Here’s how of one KaaS customer explains it:

“Every time I send a request to our outsource partner it requires 40 hours minimum billing and we won’t get delivery for 6-8 weeks.  Everything is a project, and I have to get approval from my management.  Even a small issue -- like trying to ship something to a customer -- means that one of their guys must come on site or do some changes.  You know, it’s gonna be a big 40-hour project.

“With KaaS, I just submit my question to the virtual consulting helpdesk and get an answer, usually within hours, and I only pay for the help that I need.  It’s fast, flexible and scales to my needs.  I pay much less; I get a response to my issue right away; and I don’t have to go upstairs for approvals.  Not everything has to be a big project.” 

KaaS is the answer for what users need to know Now!

Crowd Sourcing a Community

Almost since the web was created, people have talked about “stickiness” -- that it is not the number of visitors the count, but the level of commitment they show in terms of time, money and other forms of engagement.  When stickiness reaches another level, it’s called community.  People don’t just visit, have a good time, maybe spend money and leave.  They keep coming back -- not so much to engage with the site but to engage with each other.

In classic marketing, this is an “affinity group” -- a self-identified bunch of people brought together around common interests and affiliations, which in web communities are formed mostly online.  When communities happen it’s less about the website that hosts the community and more about the people.  If you’re sticky, you have a great website.  If you have community, you have great people.

So where does crowd sourcing fit in a community?  Can you have both a crowd and a community at the same time?  Crowds are generally large and anonymous -- not how most people would define a community.  But crowds are also a huge source of ideas and information -- the raw materials from which KaaS is built.

But without a community, the knowledge is just that -- raw material.  It takes a community to build KaaS.

When knowledge providers are successful they become known as experts. Users keep coming back here because the experts’ knowledge has value.  They also come back to share knowledge with other users.  Affinity happens because of personal affiliations, personal recognition, and the psychic and monetary rewards that come with helping people

So, yes there is a KaaS community here. You could say we crowd sourced it. 

Pricing Should Be “Open” Too

One thing you can say about KaaS -- and many other cloud services -- most customers tend to pay the same for the same service.  One example: our “SAP Helpdesk in the Cloud,” where each customer pays a flat per-answer fee for each consulting question they pose.

Other crowd sourcing offerings -- on this site and others -- may employ other pricing models, such as cash awards for custom software solutions -- awards that can be set by the buyer, the seller or the site.  Regardless of the particular formula, however, the price tends to be two things:  1) open, in that everyone knows what it is, and 2) the same for everyone.  Of course, the fact that the price is open also tends to make it consistent. 

But other factors also favor a level price -- like the need for efficiency. KaaS sites are successful to the extent they attract lots of traffic.  Providers will come only if there are lots of customers.  And customers will come only if there are lots of providers.  Both are more likely to come only if buyers and sellers can move in and out of the market quickly.  And if users must negotiate a price for every transaction, that will just slow them down.

But if you look at more traditional ways knowledge gets sold -- for example, as software or as software support -- helping people move faster seems like much less a priority.  

Take SAP’s pricing policies.  As Helmuth Gumbel recently observed, there is a contradiction between SAP’s endorsement of openness when it comes to service oriented architectures and the extra licensing fees it charges when you actually allow non-SAP apps to use SAP services.  Depending on how much clout you have, SAP may classify those non-SAP apps as “technical users” and require you to pay extra.

Let’s just say that if you can make it worthwhile to SAP -- say, by buying more licenses -- SAP may cut you a special deal.

That kind of nonsense is less likely to happen in KaaS if only because the pricing really is “open.”  It has to be for this model to work, and because the old models don’t let you move fast enough.

 

 

In a Flat World Where Can Systems Integrators Stand?

SAP maintenance prices increase to 22% of license fees.  Dell buys Perot Systems.  Xerox acquires ACS.  Rimini Street achieves amazing growth.

Is there a pattern here?

How about -- service is where the money is?  Or, possibly, the days of the independent systems integrator are numbered?  If service is where the money is, why then are we not seeing a lot of cash-rich systems integrators buying cash-starved systems companies?

There are lots of reasons why both product companies and end-customers might want to eliminate the middleman.  Product companies don’t want to concede account control.  Customers don’t want to play finger-pointing games whenever problems occur.  Both sides want to keep as many of the support dollars for themselves as they can.  Meanwhile, Rimini Street thrives by staying outside the product company’s value chain.  It only supports legacy implementations -- in other words, companies who have already opted out as a system company’s customer (at least for awhile).

The fact is that in a flat globalized world the difference between knowledge and product is fading.  Products merely encapsulate knowledge in a different form.  In that context, the independent systems integrator may be an unnecessary abstraction layer.  In the cloud, anyone can be a knowledge provider and knowledge providers will compete increasingly on (and be compensated for) the utility of knowledge itself -- not on arbitrary hierarchical organizational structures.

Customers will seek efficiency and speed in the way they acquire knowledge.  No systems integrator, no matter how big, knows everything about anything.  So why limit yourself -- or take the time -- to contract with a single provider?   In a flat world, customers will increasingly gain knowledge horizontally via the network rather than vertically through the SI’s hierarchy.