How to Become a Chief Innovation Officer

I had a real treat this week: I was invited to give a presentation to 25 CIOs at Infor's European CIO Advisory Council meeting, in Maranello, Italy. If you are not familiar with Maranello, it's famous as the town of the headquarters of Ferrari, which is an Infor customer. More on Ferrari at the end of this post.

Infor's Integration Strategy

The event was kicked off by Infor's CEO, Charles Phillips, who came into the top job last December, from his previous position as Oracle's co-President. It was a good opportunity for me to see how Charles deals up close with Infor customers, some of whom were meeting him here for the first time. Charles demonstrated a detailed knowledge of Infor's product portfolio and an ability to outline complex product strategy in business terms.

To that point, Charles gave the best explanation I've heard to date on Infor's integration strategy. Infor's Intelligent and Open Network (ION) is a lightweight middleware product that provides integration between various Infor products, between those products and third-party applications, and between those products and customer/partner developed systems. It is "lightweight" in that it is not optimized for specific transactions or point-to-point integration. Rather each application publishes a complete XML document for each transaction (e.g. a sales order), to which other ION-aware applications can subscribe asynchronously. ION stores all XML documents in a business vault, for reporting purposes and, I assume, to satisfy any regulatory compliance needs for audit trails.

According to Charles, ION is not appropriate for every application (e.g. an equities trading platform requiring subsecond response time would not be a fit), but it meets the need in a simple way for enterprise business applications, such as ERP, CRM and supply chain management. Infor is now in the process of ION-enabling each of its products for approximately 93 business transactions.

The best part is that ION ships as just three CDs, which, according to Infor, can be installed in about 10 minutes.

Infor's Challenge

So are all Infor customers ready to move forward with ION? Not quite. From group discussions and hallway conversations, it is clear that Infor's challenge is to get customers to current releases of their Infor products, where they can take advantages of Infor's new capabilities.

To be fair, this problem is not unique to Infor but common to all enterprise software vendors with large and long-standing installed bases. Many customers purchased their ERP systems years ago, and for good and not-so-good reasons they may have made hundreds or thousands of code modifications. Although they may have seemed justified at the time, these modifications now make it nearly impossible for customers to upgrade. In successful case studies mentioned by Infor executives, the only thing that seems to work is to take a clean-sheet-of-paper approach: put the latest software version in front of users in a conference room pilot and ask, "What's missing?" If you start with the assumption that each previous modification is still needed, the whole project collapses under its own weight.

How to Become a Chief Innovation Officer

This background turned out to be a good set-up for my presentation. I shared that the job of the CIO is becoming more difficult. CIO budget increases in most companies are severely limited, while at the same time CIOs are being asked to do more: support business change (which is increasing) as well as new technology innovations, such as mobile applications, business intelligence, new customer-facing systems, and social business.

The risk for CIOs under these pressures is that they may become, essentially, irrelevant. According to our research at Computer Economics, 75% of CIO budgets go toward ongoing support, leaving only 25% for innovation. With limited time and money, the CIO is forced to defer many business requests for new initiatives, and when users can't get what they need from the CIO, they begin to develop their own systems and IT capabilities. Eventually, the business stops asking the CIO for new stuff, and the CIO slowly becomes just a "Chief Infrastructure Officer," maintaining existing systems.

In such an environment, how can the CIO grow into a "Chief Innovation Officer?" I outlined the key steps.

1. Optimize the Infrastructure. The first step is to lower on-going support costs to free up money for innovation. Understand your current cost structure and where there are opportunities to upgrade and consolidate the infrastructure and applications portfolio. Adopt key IT management best practices for incident management, problem management, and change management, which further lower costs and improve service levels. Cloud computing can also play a role here as a way of quickly rolling out new systems that build upon the organization's core transactional processing systems.
2. Become a Chief Integration Officer and Chief Intelligence Officer. Once the infrastructure has been optimized, the CIO now has the credibility and ability to expand his or her role to become a Chief Integration Officer (focused on end-to-end business processes and customer/supplier integration) as well as a Chief Intelligence Officer (focused on turning internal and external data into useful information and deploying it to the organization through a variety of channels).
3. Become a Chief Innovation Officer. The CIO is now not only reacting to and supporting the business strategy but also leading the business into new IT-enabled products and services.

I finished with a warning. Becoming a Chief Innovation Officer is not a one-time promotion. Today's innovation becomes tomorrow's infrastructure. Just as personal computers and email were once seen as innovations in IT, today they are just part of the infrastructure. Any CIO today who is focused on PC maintenance or email administration risks becoming irrelevant. So also, tomorrow, mobile applications, tablet computing, and business intelligence will become commonplace as elements of tomorrow's infrastructure. The CIO's challenge is to continually learn and grow.

The Need for Speed

Our two days together were not all work and no play. As part of the event festivities, Infor arranged a tour of the Ferrari Museum and a Ferrari test drive around Maranello for all the attendees. I put together a little video of my Ferrari driving experience, which you can view here.

Disclosure: Infor paid for my participation in this event.

Related Posts

New details on Infor's Lawson acquisition

Risks and Opportunities with SAP's Platform Economics

Unless you hang around with SAP developers or independent SAP analysts, you may not be aware that there is a conflict brewing over how SAP wants to charge for its new technology platforms. Specifically, the Sybase Unwired Platform (SUP), which SAP acquired for developing mobile applications, and the SAP Netweaver Gateway, which SAP built to allow third-party applications and devices to connect seamlessly with SAP back-end processes.

The conflict is this: SAP wants to make money, on some basis, for SUP and the Netweaver Gateway, while any fees charged for these platforms discourage third-party development and increase the cost for customers.

Dennis Howlett has been hammering on this subject for many months, encouraging SAP (pleading might be a more appropriate word) to offer these platforms at low-cost or no-charge. He calls it the "Apple model," in recognition of how the free-nature of Apple's development platform has enabled thousands of developers to write third-party applications for Apple's iPhone and iPad. At SAP's annual user conference in Orlando this year, I heard him bring up this point directly with SAP co-CEO Bill McDermott. Bill appeared interested, but non-committal. After the conference, Dennis wrote about SAP's mobile platform, on a downbeat note:

The main problem comes in the licensing model. I find it staggeringly backward thinking that SAP almost invariably finds it necessary to monetize everything that has running code attached to it. That world has been left behind. If SAP could mobilise itself to think differently to the way it is accustomed it could (almost) easily bulk up without having to find another mega acquisition that inevitably amplifies disruption.

Now, just this week, Dennis called my attention to a post written by a third-party SAP developer Graham Robinson on SAP's own SDN site, which strongly confirms SAP's problem:

So let's say I come up with my own killer app. It is an all-singing all-dancing mobile application that will provide huge business benefit to lots of SAP customers. In fact it is so good I can sell the idea to my favourite customers (those that trust me) with a business case that they will jump at. So I have the idea, I have the funding and foundation customer commitment - I am ready to go. So time to decide what technology I should use to build my application with. Let me focus on NetWeaver Gateway but I think similar arguments apply to the [Sybase] Unwired Platform.

....I see NetWeaver Gateway as a programmer productivity tool. It provides a method for exposing SAP functionality using those standards mentioned - but we ABAP developers have been able to do that for years....I am not saying I am not interested in a toolset and/or framework from SAP that does this sort of thing as well, I am. But really the value proposition is that NetWeaver Gateway will save me development time on the backend in publishing the services I want to consume in my application.

BTW - I do not believe NetWeaver Gateway saves me any time developing the front end application despite all the great "app in a minute" demos we have seen. Whether I use NetWeaver Gateway to expose services or I handcraft my own as long as I conform to industry accepted standards the front end development tool should be able to introspect and the runtime consume these services identically.

So back to my killer app. Why should I take the funds my customer has committed to my app and pass some of them onto SAP? Even assuming I could get a straight answer from SAP on what the price would be - why should I do it unless the benefits outweigh the costs? How can a recurring pricing model on a piece of technology be weighed up against the value of saving me development time on a project I already have approval for? And why should I just let dollars go to SAP for my idea? And by the way my customers' employees (the target audience for my killer app) are already licensed to use SAP anyway. Why should they pay again? ....

Returning briefly to the [Sybase] Unwired Platform - how do I justify the cost (albeit unqualified) of this platform against the benefits of my single, albeit killer, app? I can't. And even if I could why would I confuse my customer with extra technology and extra licensing when I don't need to? I wouldn't
....

The real problem is that SAP are struggling to find a way to monetise the millions, probably billions, of users they envisage connecting to their customers' SAP systems via the internet. These will be their customers' customers, their customers' suppliers, their customers' prospects, Joe Average searching for the cheapest widget. Basically it could be everyone in the world with a smart phone.

This is a new-ish problem, but I am sure SAP looked for old business models to learn from. I suspect the business model they took on board is that of the utility companies. IDEA! Let's put a meter on the edge of the SAP landscape and charge for use just like the electricity, gas and water meters on the edge of everyones property. (In case I wasn't obvious enough - SAP NetWeaver Gateway is the meter) Kar-ching! Brilliant! [Emphasis mine.]

Read the whole thing, as Graham goes into more depth in his full post.

Some Monetization May Be Appropriate

After reading Graham's post, I reconnected with Dennis Howlett on this subject. Interestingly, Dennis does see an opportunity for SAP to monetize these two platforms for a select group of customers--its largest customers, who will use these platforms for their own revenue generation. Dennis writes:

SAP believes its largest customers will pay for SUP because they will use it to develop apps for their own purposes from which SAP would likely see little or no economic benefit. These companies - as Gartner has indicated - could easily turn into applications suppliers in their own right, building their own IP on the side of what SAP can offer for the benefit of their ecosystems. The nearest equivalent would be the proprietary EDI mechanisms the likes of Toyota and Dell created which went right through their supply chains.

That's a model I would expect to emerge because the value that can be driven is clear, clean and in the control of the channel master. Therefore, there is a case for SAP charging that fits their model and satisfies the needs of those very large customers. But it will be limited to SAP's top 400-500 customers and does not bring with it a sustainable model. At best it is a series of one-off deals that in total would likely be worth no more than $2 billion in license revenue and $450 million in annual maintenance, based upon past performance, Sybase pricing, discounts, bundling and the like.

However, such models cannot hope to cover all eventualities or for that matter the whole of the market. We can envisage thousands of situational, ad hoc, even one-off applications where the need for fast tracking is paramount or where value comes from volume usage. This is already happening in the Salesforce.com universe where cloud brokers like Appirio are working on a 4-6 week develop/release cadence for proof-of-concept to initial deployments. Having ready access (which has to include easy, clean, cheap licensing) is the only model framework that will encourage those types of developer shop to flesh out the 80% SAP claims it wants to see from its ecosystem. In other words, it is no longer about the fear of leaving money on the table. It is about investing now for benefit that accrues to everyone.

He concludes, "If SAP does that, then it will fulfill its promise of being a good citizen in the enterprise apps landscape."

SAP at a Tipping Point

I'm not sure SAP realizes how precarious its position is, and it works two ways.

1. SAP charging for the SUP and Netweaver Gateway creates "friction" for both developers and customers. As Graham points out, he has no real economic incentive to develop for these platforms, which will eat into the budget his customers have allocated for his development projects.
   
   
2. The desktop analogy: when you license SAP, do you pay an additional license fee to use your desktop computer as a user interface? Of course not. SAP customers are already paying maintenance fees for enhancements to their SAP products. Why should those customers have to pay SAP an additional license fee to use a mobile device instead of a desktop computer? Even if those mobile applications add functionality to the SAP applications the customer has licensed--isn't that what the customer is supposed to get by paying maintenance fees?
   

SAP charging for the SUP and Netweaver Gateway further opens the door to competitors, such as Workday, who are bundling mobile applications at no charge. I fear that SAP is just giving customers another reason to consider alternatives to SAP.

My own work with SAP customers tells me that, in many accounts, SAP is not at the center of the action as it thinks it is, especially when it comes to line-of-business users, which SAP hungers after. Many of these customers are actively looking for new functionality, and they generally take a look at SAP's offerings. But it doesn't take much to nudge them into the welcoming arms of another provider, whether it be for CRM, customer service, or --yes--mobility applications. SAP argues that the integrated nature of its Business Suite and ability to support end-to-end processes gives it a strong advantage with its installed base. My work with SAP customers tells me otherwise. Yes, there are benefits to integration. But that alone is not enough to keep customers in the SAP fold when there are strong economic incentives, or perceived functionality advantages, from competing solutions. Throw up an economic disincentive to adoption of SAP's SUP or Netweaver Gateway, and customers may be quick to look elsewhere. Many won't migrate away from SAP, but they'll wall it off and implement new stuff around it from competing suppliers.

The Entitlement Mentality

What concerns me about SAP's attempt to monetize these two platforms is, once again, the mentality of entitlement. We saw it previously with the battle over SAP's attempt to increase its maintenance fees across the board to 22%. SAP consistently gives the impression that, because of its market dominance in the past, that it is somehow entitled, not only to continuing revenue from its customers, but an increasing share. It does not give the impression that it is concerned about losing ground to upstarts in the cloud, such as Workday or NetSuite, or its traditional competitors, such as Oracle, Microsoft, Infor, IFS, or dozens of others with niche industry functionality.

SAP apparently views its SUP platform and Netweaver Gateway as a way to gain new revenue. I view them primarily as a way of keeping the revenue it's already receiving.

SAP's Opportunity

If SAP can free itself from its entitlement mentality, it has an enormous opportunity with its installed base, which is the largest in the world, including many or most of the world's largest companies.

Such companies have a huge legacy investment in SAP, both in terms of historical data and business processes built around SAP software. Many of these customers would love to stick with SAP for mobile applications, which by most accounts will become the primary way that business users connect with business applications. If the SUP is low or no cost for the majority of customers, it will encourage thousands of developers, such as Graham, to embrace it, and tens of thousands of customers to make it part of their applications infrastructure. The same economics apply to the Netweaver Gateway. If SAP really wants to lock-in its customers, it should offer these platforms to the majority of its customers at low or no charge. This will liberate business value to SAP's installed base, ensuring SAP's relevance for years to come.

Whether SAP truly recognizes this risk and opportunity remains to be seen.

Updates: Others have been pounding away on these points for some time. Here are some other good perspectives on this subject.

• Jarret Pazahanick: Is SAP Using the Right Mobility Strategy. Jarret, an SAP mentor, outlines several ways in which SAP could make more money by not charging for SUP.
  
  
• Dennis Howlett, John Appleby, and Vijay Vijayasankar discuss in this 13 minute video the need for SAP to roll out an Apple-style apps store model, including – in their view – the need to give away the platform. SAP’s progress on mobility is assessed, and they ask, “Is SAP Listening?”
  
  
• Jon Reed covers a lot of ground in his post on SAP at the Crossroads, but be sure to read section 4 toward the bottom on "How Can SAP Win the Hearts and Minds of Developers?" As a bonus, there is an excellent video interview of Graham Robinson who makes many of the same points as he did in his blog post quoted at the top of this post.
  

I'll add more links as I come across them.

Related Posts

Mad as hell: backlash brewing against SAP maintenance fee hike
SAP innovating with cloud, mobile and in-memory computing