Enterprise IT Buyers: Don’t Listen to Financial Analysts

When it comes to enterprise IT decisions, I have come to the conclusion that buyers shouldn’t read the financial press. There are industry analysts and there are financial analysts, and they address two distinct audiences.

Exhibit A is this Business Insider post, entitled, The Awful Economy Is Really Going To Hurt SAP. Here’s the post’s lede:

SAP's hot new software, HANA, has been a relative flop, said BofA Analyst Chandra Sriraman this morning.

HANA was hailed as groundbreaking when it was introduced about a year ago. It sits in a computer's memory so it literally runs while the computer processes transactions.

There's just one problem: No one is buying it.

The post goes on to quote Sriramen concerning why he feels that SAP “will be hurt by slower demand from its key manufacturing customers, depressed business confidence and the financial mess in Europe.”

Now, what are prospective buyer of SAP’s software supposed to make of this commentary? That the prospect should not move forward? If I am an SAP customer, should I be concerned?

The answer, of course, is no--because financial analysts, like this one, do not have SAP customers or prospects as their audience.

Two Stakeholder Groups

Putting aside the cute part about "HANA…literally [running] while the computer processes transactions" and Sriramen’s conclusion that SAP faces an "awful" 2012 (I happen to think he is wrong), let's understand the difference between a financial analyst and an industry analyst.

Every publicly-held enterprise IT vendor (or any publicly held company) has many stakeholders: shareholders (investors), customers, employees, business partners, suppliers, and the community at large. But for purposes of this discussion, let’s focus on the two primary groups of stakeholders: customers and investors. What are the objectives of these two groups?

• Customers are interested in the value of the vendor's product (its benefits and costs), the quality of the vendor's service, the vendor’s ability to innovate, and the long-term viability of the vendor itself.
• Investors, of course, are also interested in these things. But--and this is the key point--investors are not interested in these things directly. They are interested in these things in terms of what they mean for the stock price, short-term and long-term.

Investors want to see that the product has value, because companies that offer such products tend to have growing stock prices. They want to see excellent customer service, because it contributes to customer retention, which has a positive effect on the stock price. They want to see that the vendor is innovative, because innovation drives growth and growing companies command a higher price-earnings ratio. Moreover, they want to see a long-term sustainable business, because this protects the stock price.

But there are also some things that investors are interested in that customers should not at all be concerned about.

• Intrinsic value of the shares. Investors spend a lot of time comparing the intrinsic value of the vendor’s shares (what they should be worth based on fundamentals) versus the current stock price. Stocks that are undervalued by the market tend to rise over the long term.
• Market expectations. Investors—especially short-term investors—spend a lot of time trying to forecast prospective company financial performance for the next reporting period versus management guidance and market expectations. Companies that outperform market expectations will usually see a jump in their stock price.
• Economic outlook. Investors also spend a lot of time refining their outlook for the economy in general or for the industry sector and geographies that the vendor serves, because the vendor’s stock price tends to rise and fall according to these economic outlooks.

It’s easy to see, then, why customers should not be concerned about these things. Consider, for example, a prospect that is considering SAP’s HANA. If HANA is a good choice for that prospect, it makes no difference how HANA affects SAP’s share price. The market may be underestimating or overestimating HANA’s contribution to SAP’s financial performance. But either way, that has nothing to do with whether HANA is a good choice for that prospect.

Generally, financial analysts do not have the depth of understanding that good industry analysts do, concerning a vendor’s products or customer experiences. They may do reference checks, as best they can, but because they do not deal with customers of the vendor on a day-to-day basis, they lack the direct experience in seeing how the vendor actually performs in the field.

For example, last week, Alan Lepofsky and I provided a short briefing call for a financial analyst from a well-known Wall Street investment firm on the subject of CRM vendors. At the end of the call, the financial analyst remarked that what he liked about our call was our ability to refer to specific examples with specific customers. This is why financial analysts ask for briefings from industry analysts, but seldom do you see the reverse.

Another example: Ray Wang recently gave a short on-camera interview with CNBC on the news that SAP had made a bid for SuccessFactors, an HRM cloud computing provider. Ray deals with enterprise IT sellers every day. But the questions from the CNBC hosts had nothing to do with whether either SAP or SuccessFactors were good choices for buyers. Rather, their only concern was what SAP’s bid for SuccessFactors meant for investors. Here are some examples of the questions they asked Ray:

“What are the big names that pop to your mind here that could be the next ones to [be acquired] in the cloud space?”

“What about the pioneer in the SaaS market, valued at $17 billion, Salesforce.com [being acquired]?”

“So, Ray, NetSuite is up nearly 10% today, which is I think an all-time high. Would you rush into this stock right now or is it too much, too fast?”

“Hey Ray, how does this make you feel about SAP here? SAP is a company that for the most part trailed Oracle, it stayed out of the M&A game, it seems very hungry to do deals here—that’s great, it worked for Oracle…but are they getting out of their core competency, are they spending more [for SuccessFactors] than they should here?”

Now, are these questions that enterprise IT buyers would be asking? I think not.

The Right Advisor for the Right Audience

Lest anyone think I am railing against investors--I am not. As a free-market capitalist, I believe that private investment is the best way to pick winners and losers in the marketplace. I trust individuals and organizations putting their own capital at risk more than I trust some government bureaucrat deciding which organization or industry to favor.

Furthermore, the best financial analysts often have interesting insights. I do read them from time to time, because they see things from a different perspective (the investor’s perspective). As my late business partner used to say, financial analysts are using “a different algebra.” Seeing things from the investor perspective can help me, as an industry analyst, understand why a vendor may be behaving in a certain way. For example, why a vendor is targeting a certain market segment or de-emphasizing a certain line of business.

But I do believe it is important for enterprise IT buyers to understand that their objectives and success are not always aligned with the immediate interests of investors, and they shouldn't pay too much attention to the short-term stock market performance of an enterprise IT provider.

So, just as shareholders shouldn’t ask me for investment advice, enterprise IT buyers shouldn't read financial analysts for advice on technology decisions.

Update: my friend Jon Appleby has a great post, critiquing the same financial analysis post I referenced here. My friend Vijay Vijayasankar also has a good post on the Bank of America analysis, and has added a comment to my post here.

Related Posts

SAP in Transition on Mobile, Cloud, and In-Memory Computing
IT Budgets vs. Tech Industry Spending: What's the Difference?

SAP in Transition on Mobile, Cloud, and In-Memory Computing

I attended two days at SAP’s SapphireNOW conference in Madrid earlier this month, at the end of a month-long trip to Spain and Italy. The trip to Madrid gave me a good opportunity to catch up with the latest developments with SAP since the Sapphire conference last May in Orlando.

Jim Hagemann Snabe gave the Wednesday keynote, which I found tighter and more balanced than similar messages delivered in Orlando. Back then, the keynotes seemed to overly emphasis HANA, SAP’s new in-memory database technology. Although HANA is still hugely important to SAP, the message is now more balanced between SAP’s three focus areas of innovation: mobile, cloud, and in-memory computing.

I also appreciated Snabe's tone, focusing positively on SAP’s roadmap and customer success stories. This was a welcome change from recent keynotes by the CEOs of some of SAP’s competitors, whose bar-room brawling style might be more entertaining but doesn’t provide much real insight. Personally, I find Snabe’s low-key approach much more palatable, and I have to believe customers feel this way also.

So, in a nutshell, here is my bottom line: I see SAP in a period of transition with cloud computing, mobility applications, and in-memory computing. There is progress, but success is not ensured.

Business ByDesign Has Momentum, but Line of Business Apps Lagging

SAP has two major cloud initiatives: its Business ByDesign (ByD) ERP suite for small businesses and its Line of Business (LoB) SaaS applications, which complement its Business Suite.

Concerning ByD, SAP is on target to reach 1,000 customers sold by year end, although SAP executives indicate that reaching that goal might come down to the wire. Although reaching or exceeding that number will matter to some SAP folks’ year-end bonuses, I would view anything close as being a significant accomplishment. My consulting team at Strativa recently evaluated ByD in a competitive deal and came away favorably impressed. Customer reference checks during the Madrid conference were also encouraging. I believe SAP has a winner with ByD: both for subsidiaries of its large customers and in net-new small business deals. Those who question the viability of ByD at this point should reconsider their assumptions.

On the Line-of-Business side, progress is not as impressive. SAP has one SaaS application—Sales On Demand—in general release. But don’t expect to see other applications any time soon. Travel On-Demand (mostly expense reporting) will go into beta in Q1, 2012, according to Sven Denecken and Kevin Nix, who head up LoB development. Career On-Demand is scheduled to go to the first beta customer in Q2, 2012. In addition, Kevin and Sven told me of another LoB application now in development: Social Service and Marketing On-Demand. I have no target date for this product.

SAP positions these LoB applications as people-centric applications, helping end-users accomplish their daily activities. Although this is an interesting approach, the LoB apps do not have very broad functional footprints. For example, Sales On-Demand is primarily focused on the collaboration of pre-sales teams and others as they coordinate their activities for specific prospects. It is by no means a complete CRM package—it is not even a complete sales force automation app. Likewise, Career On-Demand is not a complete talent management system. Rather it is focused on helping people manage their goals, objectives, and daily activities and to see what others across the organization are working on. Finally, Social Service and Marketing is narrowly focused on processing incidents originating from Twitter and other social media channels.

In my view, the LoB applications are a defensive play by SAP, aimed at keeping its installed base from leaving the SAP-fold for newer cloud-based providers. For example, in my view, Sales On-Demand is aimed at keeping SAP CRM customers from considering Salesforce.com. Likewise, Career On-Demand is meant to keep SAP HRMS customers from considering Workday. Finally, Travel On-Demand is SAP’s answer to Concur’s expense management system. SAP may be successful in getting its installed base to adopt some of these LoB applications, but because they are not complete solutions, I do not think they are an adequate response to the threat from Salesforce.com, Workday, Concur, and others. Furthermore, it is hard to imagine non-SAP customers purchasing these solutions.

The other problem with the LoB applications, frankly, is that they are a late response by SAP. Salesforce.com, Workday, and Concur have been developing and marketing their applications for years. In the case of Salesforce.com, over 10 years, and SAP is only now starting to respond? It’s like the student who turns in (hopefully) a well-written essay, but misses the deadline.

So, on my scorecard, SAP gets an “A” for ByDesign and a “C” for its line of business applications.

Turning the Ship on Mobile Applications

On the mobility front, SAP appears to be making good progress. Based on a briefing I received, there are now 50 mobility apps available in the new SAP Store. Of these 38 are authored by SAP and 12 are from partners. There are 200 more in the development pipeline (split between SAP and partners is not clear to me).

All of the current apps in development are based on the Sybase Unwired Platform (SUP), and this is where there are some issues. The SUP is a general platform for mobility device development and management. It allows a developer to write an application and have it deployed on multiple devices, such as RIM’s Blackberry, Apple’s iPhone/iPad, Android devices, and Windows phones. It also provides an enterprise-class management platform for back-end data access, application provisioning, user and device management, and security. So from the perspective of ensuring that its mobility apps are enterprise-class, I can understand why SAP would want mobile applications developed by partners to be certified for SUP.

The problem, however, comes from the developer perspective. Many of the best mobile apps development these days are coming from small shops, and current SAP licensing practices by SUP are, shall we say, burdensome for small developers. Based on briefings we received, it appears SAP understands the obstacles in the way of small developers and wants to show some flexibility on this issue. There is talk of allowing developers to work outside of SUP and then submitting their applications for certification. There was even talk at some point of allowing apps to be sold via the SAP Store that do not run on top of SUP, but that is by no means current policy.

My colleague Dennis Howlett has a deeper dive on SAP's mobility progress.

So, it would appear that on the mobility front, SAP is in transition. They are making good progress, but they need to follow through on their good intentions to become more developer- and partner-friendly in mobile apps development.

In-Memory Computing Still Rings SAP's Bell

Although the Madrid messaging was balanced among the three areas of innovation, you can still sense the excitement among SAP executives when they come to the subject of in-memory computing. They honestly feel that its in-memory technology (HANA) will leap-frog SAP over its competition. In a small group briefing with Vishal Sikka, he spent significant time talking about the value proposition of in-memory computing to provide faster answers to business queries, without the constraints of data structures such as cubes. The value of HANA has already been demonstrated in a limited number of one-off proof of concept projects for select customers, many of whom were featured in the Orlando conference.

The next step is to scale up HANA adoption by using it as a customer platform for SAP’s business warehouse (BW) deployments. In a sidebar conversation with Sanjay Poonen, SAP’s President of Global Solutions, he indicated this is where most SAP customers will first realize the value of HANA.

Ultimately, though, SAP intends to bring in HANA underneath parts of the Business Suite—we had one briefing from a customer looking to run HANA underneath its trade promotion processing to more quickly analyze pricing trends. SAP has a far-reaching vision for HANA to ultimately become the data platform for many of its products.

So SAP is also in transition with in-memory computing: moving it from a small number of proof-of-concept case studies to a broader adoption by its customer base. This migration has only just begun.

Can SAP Make The Needed Transitions?

For the largest enterprise software vendor in the world, the roadmap is good. But is it possible for SAP to complete the needed transitions? There are strong economic rewards up front for HANA, which are big ticket license sales. But will SAP be willing to devote the resources necessary for its cloud solutions and mobility applications to be successful, where the deals are smaller? The signs are encouraging, but success is not ensured.

1. Progress is good with mobility apps, but the partner model needs to be improved. When small mobile developer partners, like Graham Robinson, tell me they are happy with SAP’s support then I will be convinced that SAP stands a good chance of being successful. The words coming from SAP executives are the right sounds, but I’m waiting to hear confirmation from small developers that SAP’s actions are following its words.
   
   
2. It is going to be interesting to see how SAP’s cloud computing programs proceed. For SAP, cloud is both a sustaining innovation and a disruptive innovation (to use the terminology of Clayton Christensen). From the standpoint of SAP’s large customers with many small subsidiaries, ByD is a sustaining innovation because it gives them something to offer for their subsidiaries. Many competitors, such as Microsoft Dynamics, Epicor, NetSuite, and Plex, are targeting these subsidiaries in a so-called "two-tier ERP" strategy. Thus, ByD preserves and extends the revenues that SAP receives from these large customers.
   
   The larger question is whether ByD can consistently beat out cloud-based competitors such as NetSuite, Plex, or Rootstock for net new deals in small organizations. As I indicated, the signs so far are good. But will SAP be willing to invest what it takes for such small deals? Furthermore, will SAP be willing to let ByD naturally grow up-market and start to disrupt (cannibalize) its sales of SAP All-in-One or even its Business Suite? If so, then I would declare victory for ByD as a truly disruptive innovation.
   
   I do not view SAP’s LoB applications as disruptive. These apps are targeted primarily at SAP’s installed base and are therefore a sustaining innovation for SAP. They do not need to be best-in-class. They only need to be good enough to keep customers from going with SFDC, Workday, Concur, or other pure best-of-breed cloud solutions. But, as noted earlier, these are not complete solutions and may not be enough to keep SAP customers from looking elsewhere. Also, they are unlikely to find much of an audience outside of SAP’s installed base.
   
   
3. Although I would agree generally with Vishal’s assessment about HANA, from an economic standpoint, in-memory computing does not require SAP to transition its thinking or business model. From an economic standpoint, in-memory computing is a sustaining innovation for SAP. SAP can use in-memory computing to continue to sell big-ticket licenses to big-ticket customers and receive large annuities in the form of maintenance fees. It is not like cloud and mobile which require that SAP make changes in its expectations on how it will make money in the future.

So in terms of transition, I think SAP has made the most progress with cloud computing, with Business ByDesign but not with its line of business applications. The direction with mobility applications is good, and SAP is making the right noises about working with small developers, but it is too early to see words translated into action. Finally, even though in-memory computing is still early in its roll out, it stands a good chance of success if SAP can gain adoption beyond its initial proof cases, because it does not require SAP to change its business model.

I made some of the same points in a very short interview with Dennis Howlett, during the Madrid conference. You can watch the interview below.



Postscript: I’ll repeat here what I said to my SAP host when I bid goodbye from the Madrid conference: I know some of us often give SAP a hard time. But we do it for one reason: we care about SAP’s customers, just as SAP does, and we want SAP to be successful for their sake.

Disclosure: SAP paid part of my travel expenses to attend the Madrid conference.

Cutting Through the Fog of Cloud Computing Definitions

In recent years, the term "cloud computing" has been used and abused by vendors and their marketing groups to denote just about anything the vendor offers other than on-premise systems. Analysts too have piled on, each offering their own definition of cloud computing. This 2009 Wall Street Journal article outlined the confusion. The result has been fruitless arguments over what is "true cloud" or "false cloud," as in the recent tit-for-tat speeches by Larry Ellison and Marc Benioff during Oracle Open World.

Such debates are likely to continue, but now there is at least one official source for the definition of cloud computing. The National Institute of Standards and Technology (NIST), an arm of the US Department of Commerce, has now published The NIST Definition of Cloud Computing. Though other standards bodies may (or may already have) published their own definitions, NIST carries particular weight as it is often referenced in U.S. governmental procurement. The NIST definition is vendor-agnostic and buyer-centric.

The NIST Definition

The NIST document is short--the body of the document comprises just three pages, with the definition itself taking up less than two pages. In it, the authors describe the essential characteristics, service models, and deployment models for cloud computing.

• The five essential characteristics are: on-demand service, broad network access, resource pooling, rapid elasticity, and measured service.
  

• They go on to then list three service models, which should be already familiar to most observers: software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS).

• Finally, they list four possible deployment models for cloud computing: private cloud, community cloud, public cloud, and hybrid cloud.
  

In my mind, the section that is most useful for distinguishing what is or is not cloud computing is the first one, the "essential characteristics." So, let me quote NIST directly (emphasis mine).

Essential characteristics:

• On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
  
  
• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
  
  
• Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
  
  
• Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
  
  
• Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

Keep these key points in mind.

Cutting Through the Ellison/Benioff Fog

So, let's apply these characteristics to what Larry Ellison and Marc Benioff each describe as cloud computing. In my opinion, both are right and both are wrong.

Benioff's service, Salesforce.com, certainly meets the NIST definition of cloud computing, both in its CRM application, which meets NIST's definition of SaaS, and in its Force.com offering, which meets the definition of PaaS. He is also correct in criticizing the labeling of Oracle's Exalogic hardware as a "cloud in a box." By my reading of NIST's essential characteristics, one could construct a cloud service using Oracle's hardware, but the hardware itself should not be considered a cloud.

But if Benioff is referring to Oracle's newly announced Public Cloud Services as a "false cloud," he is wrong. Oracle's Public Cloud Services certainly meet the NIST definition of cloud computing. But it is primarily an IaaS offering, similar to Amazon's EC2. Assuming that Oracle will offer development capabilities on top of its Public Cloud Service, those would be PaaS, and if it chooses to run applications on top of its Public Cloud Service, such as Oracle CRM On-Demand, those would be SaaS.

On the other hand, Ellison is wrong to label Salesforce.com's PaaS offering as a "false cloud." Ellision's argument is that Force.com utilizes proprietary extensions to Java and other programming languages, which make it difficult to migrate applications to other cloud providers. But there is nothing in the NIST definition of cloud computing that requires interoperability between different cloud service providers, as desirable as that may be. Ellison is simply turning what he sees as a disadvantage of Benioff's cloud into an argument that it is by definition not a cloud.

Cutting Through the Application Hosting Fog

The NIST definition is also useful for cutting through vendor marketing efforts to label anything they do off-premise as cloud computing. In particular, application vendors that simply host their on-premise solutions in their own, or partner, data centers should not be labeling those as cloud computing. In particular, simple hosting of an application does not qualify as cloud computing because it lacks the essential characteristics (see bolded sections in the quoted definition above).

With a hosted application, the customer generally cannot "unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction." In addition, with a hosted application there is generally no "sense of location independence." Rather, the customer usually knows the data center and may even know the data center, cage, or rack in which his hosted application resides, even if the application is hosted on a virtual server. Finally, with a hosted application, computing resources generally cannot be "elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand." Rather, the customer must negotiate provision of additional computing resources.

Notice also that the NIST definition does not mention anything about how cloud services are contracted. Some vendors point to subscription pricing as evidence of their hosted applications being cloud offerings. According to NIST, how the customer pays for the service has no bearing as to whether the service is cloud computing. It could be subscription pricing, it could be a perpetual license, or it could be something else.

The marketing hype and confusion over cloud computing will no doubt continue. But at least now NIST offers a reasonable and objective definition.

Related posts

Salesforce.com: more than an itty-bitty application
The inexorable dominance of cloud computing
Lawson's cloud services: good start, but no SaaS
A game-changing play in enterprise software

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

Breakthrough in Material Planning: Demand Driven MRP

For the first time in over 30 years, Material Requirements Planning (MRP), is undergoing a fundamental improvement. A major new development, dubbed Demand Driven MRP (DDMRP) is moving from theory to practice, and the results are impressive. If you care about manufacturing ERP, you would be wise to pay attention.

Carol Ptak recently called my attention to her work with Chad Smith at the Demand Driven Institute, which they founded in 2010 to promote the concepts of DDMRP. I've known Carol for many years, through her work as past President and CEO of APICS and her time at PeopleSoft, where she was an early proponent of making MRP more "demand driven." I wrote a brief blog post in 2003 covering this subject (see: PeopleSoft Strengthens Its Manufacturing Offerings by Acquiring Demand Flow).

So, I jumped at the opportunity to set up a briefing on DDMRP with Carol and Chad for me and my associates Bob Gilson and Nick Hann at Strativa.

Bringing MRP into the 21st Century

Before we look at some of the key concepts of DDMRP, let's review the history of material planning.

MRP, first developed in limited fashion in the 1950s and 60s, really took off in the 1970s, when computer systems enabled widespread adoption and APICS undertook the "MRP Crusade" to popularize it. It was a great advance over previous material planning techniques, such as statistical order point (popularized during the Second World War), which viewed each inventory item separately. The big conceptual breakthrough of MRP was to separate dependent demand (sub-assemblies and purchased items) from independent demand (e.g. finished goods and service parts). MRP, therefore, provided a holistic, or system-wide view of inventory.

MRP (material requirements planning) morphed in the late 1970s and 80s into MRP II (manufacturing resource planning) and ultimately ERP (enterprise resource planning). But the heart of today's ERP systems (at least in the manufacturing sector) is still the MRP processing logic that is essentially unchanged since the 1970s.

In practice, MRP relied heavily on demand forecasts to drive planning and used safety stock inventory to cover variability in lead-times and forecast errors. The results, though far better than the old order point systems, were often excess inventory and less-than-acceptable customer service levels.

Just-in-Time (JIT) inventory and lean manufacturing techniques were, in part, a reaction to the complexity of MRP and a desire to obtain better outcomes. Introduced in the 1980s, JIT was a simplification in material planning and it took inspiration from the quality management movement and Toyota Production System in Japan. JIT is essentially a "pull system"--relying upon simple demand signals, such as Kanbans, from customers to suppliers up and down the supply chain, often with little or no computerized support. Unlike MRP, which viewed inventory as an asset, JIT viewed inventory as a "waste" and sought to minimize it wherever possible by minimizing variation in supply and demand, and reducing setup times to enable smaller lot sizes. But its emphasis on inventory reduction, lack of a system-wide view of inventory, and incomplete planning equation created brittle supply chains, subject to disruptions.

Embracing and Extending MRP and JIT

Demand Driven MRP is not a completely new method: it builds upon and extends the concepts of MRP while borrowing the best features of lean manufacturing. Like lean manufacturing, it seeks to "align efforts and resources as close as possible to actual demand" (a so-called pull system) while at the same time, like MRP, provide "visibility to the total requirements and status picture across the enterprise."

The authors' background in the Theory of Constraints is evident. They are not looking to compromise between MRP and lean manufacturing. Rather they recognize and seek to satisfy the legitimate objectives of both. For example:

1. The greatest extension of DDMRP is the introduction of supply chain modeling prior to generating material plans, as shown in steps 1-3 in the Figure at the top of this post. Here, the organization determines the optimum places where inventory should be held. This is a step that MRP simply does not address. MRP and even Advanced Planning systems (APS) generally take inventory stocking points and safety stock levels as givens and plans within them. At the opposite end of the spectrum, JIT techniques are blind to the overall supply chain. Each node of a pure pull system is only sensitive to the demand at the next downstream operation. DDMRP, on the other hand, models where inventory should be held in order to minimize lead times and reduce variability where it matters the most.
2. In terms of inventory, DDMRP stakes out a middle ground between MRP and lean manufacturing. It does not view inventory as a waste, as lean manufacturing does with its goal of "zero inventory," and it does not seek to establish safety stock levels in a static way, as MRP generally does. Rather it seeks to hold the right amount of inventory at the right place in the supply chain "to promote flow but minimize working capital," and "to size and dynamically adjust those strategic stock positions" based on a set of rules dominated by six factors.
3. DDMRP deals with lead times in a more realistic fashion than traditional MRP, which in calculating manufacturing lead time assumes all components are in stock, or in calculating cumulative lead times assumes nothing is in stock. Neither are good assumptions in most environments today. DDMRP introduces a concept it calls Actively Synchronized Replenishment (ASR) Lead Time (ASRLT), which represents "the longest unprotected sequences in the bill of material" where "protection" is defined by strategic stocking points. These points decouple, compress, and ultimately define the calculated lead time of an item.
4. MRP is only a planning tool and JIT is only an execution tool, whereas DDMRP is both a planning tool (in the modeling and planning stages) and an execution tool, in the execution stage (see Figure at top of this post).
5. DDMRP greatly reduces the emphasis on accurate forecasts in driving supply plans. Demand is driven entirely or largely by actual customer demand (typically sales orders), which can then be satisfied from compressed lead time due to the strategically placed inventories at the subassembly or component level.

These are just a few of the key concepts of DDMRP. For a more complete view, see the additional resources listed at the end of this post.

If there is any doubt that DDMRP is a major breakthrough, consider this: the book everyone considers the "Bible" of MRP was written in 1974 by the late Joseph Orlicky, and the second edition was authored in 1994 by the late George Plossl. McGraw-Hill, publisher of Orlicky's Material Requirements Planning has just released the third edition, which is authored by Carol Ptak and Chad Smith, the brains behind DDMRP. This third edition now incorporates the concepts of DDMRP, building upon the work done by Orlicky and Plossl, two of the fathers of MRP.

Proof in the Pudding

Think DDMRP is just a nice theory? Not so. The benefits have already been demonstrated by at least two early adopters:

1. Oregon Freeze Dry, after adopting DDMRP, saw a 20% increase in sales 20% and 60% inventory reduction in one division, along with 60% reduction in make-to-order lead-time and 20% inventory reduction in another division.
2. LeTourneau Technologies (LTI) is an interesting case study in the natural resources sector. The firm implemented DDMRP in one of its two plants, while letting the other plant continue with traditional MRP. Both plants had similar resources, bills of material, and material planning personnel.
   
   During a boom and decline cycle of 2005 to 2008, the DDRMP plant grew revenues from $270M to over $620M, while growing inventory by only about $80M. In contrast, the traditional MRP plant experienced the similar growth in revenues, but inventories grew at the same pace. When the recession hit in 2008, the DDMRP plant , however, was well positioned with lean inventories while the traditional MRP plant was exposed to a huge amount of inventory liability.

Additional case studies should begin to appear as other organizations gain experience with these new methods.

What's Next?

I believe that enterprise software vendors, especially those focused on supply chain management, are going to move quickly to begin to incorporate DDMRP concepts into their systems. So far, there is only one software provider that has done so, Replenishment+® from Demand Driven Technologies, of which Chad Smith is a paid advisor. However, I see indications that some other vendors are moving in this direction. In other words, I do not believe availability of software is going to be an obstacle.

If there is any obstacle to wholesale adoption of DDMRP, it is going to be in the general level of resource planning skills in many manufacturing organizations. The concepts behind DDMRP are not simple. Many practitioners tasked with responsibility for MRP systems today do not have a deep understanding of MRP principles, even of traditional MRP circa 1974. How are they going to grasp the concepts behind DDMRP? I think this will be the key limitation hindering widespread adoption, unless manufacturing organizations are willing to re-invest in professional development in a sustained way. Conceptual education--not just software training--is going to be key.

A corollary observation is this: production and material planning is going to become an even more critical function for manufacturing and distribution firms. It always has been, of course, but it will become even more critical in industries where some players have the skills to adopt DDMRP and others don't. No longer just a back-office function, resource management should once again become an inviting career path for young people.

Additional Resources

There is much more to DDRMP than I can outline here, such as its ability to accommodate seasonality, ramp up/down in production, and end-of-life scenarios, all of which are troublesome for traditional MRP systems and especially lean-manufacturing systems. Therefore, it is best to point readers to the following resources.

• Demand Driven MRP. The flagship DDMRP website maintained by Carol and Chad, with a good introduction to DDRMP. Free white papers, videos, and podcasts are available on a number of DDMRP topics.
• Demand Driven Institute. The educational and consulting organization promoting the concepts of DDMRP. The textbook I mentioned earlier, Orlicky's Material Requirements Planning, Third Edition, is also available here, with a supplemental DVD.
• Orlicky's MRP. This is the official website of the new edition of Orlicky's Material Requirements Planning.

There are several white papers and videos linked at these sites that go into more depth on DDMRP. Training classes are now being rolled out. In addition, the authors will be presenting more on this subject at the APICS International Conference in Pittsburgh, October 23-35. If you are planning to be at this conference you will be wise to register for this session, as it will probably be standing room only.

Related Posts

APICS Returns to Its Roots
PeopleSoft Strengthens Its Manufacturing Offerings by Acquiring Demand Flow
Lean Manufacturing: Not a Complete Solution without Information Technology
Lean Manufacturing Doesn't Really Need Software, But Software Can Help
Lean Thinking is Still More Than Software

Kenandy: A New Cloud ERP Provider Emerges from Stealth Mode

There's news for those of us interested in manufacturing ERP: a new cloud ERP provider is having its coming-out party this week at Dreamforce, the annual user conference of Salesforce.com. Kenandy, which is built entirely on Salesforce.com's platform, provides core manufacturing functionality, such as inventory, shop orders, purchase orders, and material planning. Founded in 2010, Kenandy already has one customer live and a handful of others sold and in implementation.

Early this week, several people forwarded me advance word on Kenandy from a Wall Street journal blog post. Normally, the launch of a new cloud provider would not warrant this kind of attention. But this launch has an interesting twist: the brains behind Kenandy is none other than Sandra Kurtzig. She is the original founder and CEO of ASK Group, the developer of the well-known ManMan ERP system--more or less the SAP of the 1980s. She retired something like 10 years ago, but was convinced to come out for an encore by Marc Benioff, CEO of Salesforce.com and her neighbor on a beach in Hawaii. Kenandy has venture funding from Kleiner Perkins Caufield & Byers, and its managing partner Ray Lane sits on Kenandy's board.

Kenandy's Angle

I scored an interview with Sandra and her CMO Rod Butters yesterday, prior to Sandra's appearance on stage with Marc Benioff this morning at Dreamforce. I had a lot of questions for Sandra, and she was forthcoming with answers.

1. Kenandy is positioning itself for small and midsize manufacturers ($15M - $300M), especially those that source, manufacture, and distribute products through contract manufacturers and channel partners. Sandra noted that ERP vendors with systems designed in the 1970s and 80s (such as ManMan) assumed their customers were vertically integrated. Her perspective is that this orientation has carried forward in the design assumptions of the leading on-premise ERP providers today, which have their roots in systems built during that time period. This is not a good assumption today, as even small and midsize manufacturers are contracting large parts of their operations offshore and have complex distribution relationships with channel partners. Such organizations need an extended ERP system, and Kenandy is being designed with these scenarios in mind.
   
2. Built on Salesforce.com's platform, Kenandy is a full multi-tenant SaaS offering. An organization can run multiple facilities within a single tenant, or it can set up multiple tenants, for its contract manufacturers or business partners, for example, and gain inventory and production visibility up and down its supply chain. (Disclaimer: I have not evaluated Kenandy on any functionality points to confirm these features).
   
3. Kenandy expects very short implementation times. Its first customer, Den-Mat, a maker of dental products, went live in two weeks, converting from a legacy IBM Series i (AS/400) system.
   
4. Kenandy is focusing on manufacturing functionality and depending on other cloud providers to fill out other parts of the enterprise suite. For example, there is integration (of course) with Salesforce.com for CRM, and with FinancialForce.com for financials. In addition, Sandra claims that integration with customer's legacy systems (e.g. Quickbooks) are always an option.
   
5. Development of Kenandy is being led directly by Sandra: in other words, she is not only the founder and CEO. Like many start-up software firms, she is also the brains behind the product and the chief product management executive. She is working with a small group of internal developers and is supplemented by development resources from Persistent Systems in India.

I also took a walk to the Expo floor and got a quick view of Kenandy's system. I also met the "Ken" of Kenandy. (The firm is named after Sandra's two sons, Ken and Andy).

A Market with Lots of Open Space

I am currently working on a research report on cloud-based ERP systems, so I was quite interested in seeing a new competitor emerge in this market. In my view the market is wide open. There are only a handful of pure multi-tenant SaaS ERP providers, and even few that can support the needs of manufacturers. These providers include NetSuite, SAP's Business ByDesign, Workday, Plex, and Rootstock.

Compare this to the dozens or scores of ERP providers that we could choose from in the 1980s and 1990s. Today the market for traditional on-premise ERP systems is dominated by two vendors: SAP and Oracle. Microsoft occupies a strong secondary place, especially in the SMB space. Many of the other players have been acquired by Infor and Oracle, though several good providers, such as IFS, Epicor, QAD, Syspro remain independent.

Nevertheless, the broad industry trend is moving to cloud computing, and manufacturers that want full-suite ERP in the cloud have few choices. Therefore, the market is wide open. As I mentioned to Sandra, it's like the Pilgrims landing at Plymouth Rock. There is a whole continent waiting for anyone so inclined to stake a claim. There's no need to argue about property lines with neighbors. Just go out, pick a few verticals, geographies, and organization sizes, and build out your offering. There is plenty of room to grow.

Other providers are already doing so. Plex was first out of the gate, with a full cloud-based ERP offering dating back to the middle of the last decade, and they continue to gain momentum. SAP's launch of Business ByDesign is also gaining traction, not only in subsidiaries of SAP's traditional large customer base, but in net new SMBs as well. Rootstock, not as well known, has a credible offering for manufacturers (especially project-based) on NetSuite's platform, and it has now migrated its manufacturing ERP offering to Salesforce.com's platform. Moreover, other on-premise vendors, such as Epicor and Infor, have enabled their products to operate in a multi-tenant cloud deployment model.

But there are large swaths of open space. Kenandy is a welcome new player.

Update, 10:02 a.m.: Sandy is on stage now at Dreamforce. She's wearing a button with the letters ERP crossed out. Marc asks, "Your previous firm ASK built on HP's platform, right?" She jokes, "Is HP still in business?" Ray Lane, an HP board member, is standing next to her. Sandy mentions Salesforce.com's investment in Kenandy. Ray, as mentioned in my post above, is also an investor, and now relates the story of Sandy showing up in Ray's office, asking for money. Ray, who like Sandy, is well over the median age at Dreamforce, admonishes the audience, "Don't think our generation is through yet!"

Update, 10:20 a.m.: Dennis Howlett looks at manufacturing cloud ERP developments.

Update, Sep. 6: Dennis Howlett interviews me live about my thoughts on Kenandy. Click on the image below to watch the interview.

Related Posts

Workday pushing high-end SaaS for the enterprise
SAP Innovating with Cloud, Mobile, and In-Memory
Plex Online: pure SaaS for manufacturing
NetSuite a viable alternative for SAP customers?
Workday: evidence of SaaS adoption by large firms

Twenty Years of ERP Lessons Learned

I gave a keynote presentation last week at the Manufacturing ERP Experience conference in Chicago. You can watch the full presentation by clicking on the image to the right.

Because the primary attendees were end-users and prospective buyers of ERP systems, I wanted to share something on current ERP trends and best practices for success.

But this presented a challenge: I've been speaking about ERP for over 20 years. How would a presentation on this subject be different today than one I would have given 20 years ago?

So, during the keynote, I thought of at least three ways in which ERP is different today, and one way in which it is still the same.

ERP as a Platform

Twenty years ago, ERP was viewed, in effect, as the final destination. For example, CRM was not yet popularized (Siebel was founded in 1993). In most companies, business intelligence was limited to report-writing or custom-built data warehouses. Mobility apps and collaboration systems were a long way off in the future. Even email was not well-established in business communications. So, ERP was where most of the action was, especially in the manufacturing sector, where it has its roots.

Although ERP was a hot topic in the early 1990s, today we understand that ERP really doesn't do all things equally well. Even the acronym "Enterprise Resource Planning" (an evolution of "Material Requirements Planning" and "Manufacturing Resource Planning" systems of the 70s and 80s) is a misnomer. ERP is not primarily a planning system, it's a transaction processing system. Its benefits are primarily in standardizing and automating business processes. To perform what-if planning, or to understand trends hidden in the data, or to gain a 360-view of customers, for example, you need to go beyond ERP.

Does that mean ERP is just one of many investments that an organization can choose to make in enterprise systems? Not at all. ERP plays a unique role in the applications portfolio, as the foundation for so many other things that organizations want to do.

Sure, you can go out and implement CRM as a standalone system, but CRM works better when it is integrated with ERP for end-to-end business processes. Some organizations have implemented supply chain management without ERP, but SCM is more powerful when it builds upon ERP as the system of record. Likewise, business intelligence systems, collaboration systems, and mobility apps add more value when they have ERP as their foundation.

Today, ERP is critical as the transaction processing hub of the organization and the system of record for major organizational entities, such customers, suppliers, people, orders, and accounting entries. In many respects, we can think of ERP as the new IT infrastructure, as a standard platform for building out the rest of an organization's enterprise applications portfolio.

Recognition of the Risks of ERP

The second way I think things have changed is in how organizations perceive the risks of ERP. Everyone has read about he horror stories of failed ERP implementations. Names like Hershey, Waste Management, and Nike are well-known examples. Many times the understanding strikes closer to home: most business leaders by now have either experienced for themselves, or heard from their peers, what can go wrong with an ERP implementation.

This wasn't the case 20 years ago. Executives often believed the hype of software vendors who claimed that implementation could be rapid or painless, or that business leaders could go about their jobs while the vendor, or a systems integration partner, did the hard work for them.

Very few executives believe this any more.

General Acceptance of Key Success Factors

Similarly, twenty years ago, executives were quicker to believe that new software could solve their problems, or that systems could be customized to match how the organization did business in the past. ERP projects were often viewed as "computer projects," not business projects.

Today, I find that business leaders have a better understanding of best practices for successful ERP implementation. They realize that ERP means changing now the organization does business. They usually recognize that top management needs to be committed and that it will require participation by all affected functions. They often realize that it is best to pick a system that fits the business, and as much as possible to avoid customizing software code.

But Outcomes Have Not Improved

So, if ERP plays a critical role, and executives understand the risks and best practices, then organizations must be more successful with ERP today then they were 20 years ago, right?

Sadly, I don't think this is the case. According to our 2011 survey, 38% of ERP projects exceed their budgets for total cost of ownership. Furthermore, as I indicated in my keynote, the risks of ERP go beyond cost overruns: ERP is particularly subject to functionality risks (the project was within budget, but the system doesn't satisfy key requirements), adoption risks (the project was within budget, but the organization is not fully using it), and benefit risks (the project was within budget, but the expected benefits are not realized).

So, what is the answer? The answer is that business leaders need to be reminded again and again about these lessons learned, and they need to execute on these best practices. So, while I could have given (and did give) much of this presentation 20 years ago, the lessons are still relevant.

You can watch a video excerpt of my presentation at the top of this post. The complete presentation is also available on Youtube. And, if you'd like a copy of the slides, please email me. My contact information is in the right hand column.

Related Posts

Four problems with ERP
Solving the four problems with ERP

IT Budgets vs. Tech Industry Spending: What's the Difference?

According to our research at Computer Economics, we reported that 2010 IT budgets showed no growth at the median. At the same time, IDC reported the global IT market grew by 8%.

So which is it?

Over the years, I see a lot of confusion between these two metrics, so let's start with some basic definitions.

• IT Budgets: This is the view from within an IT organization, of all IT-related spending.
  
  
• Tech Industry Spending: This is the view of the technology industry and the investor community, of the total market for technology-related products and services.
  

As you can see, these are related but entirely different measures. Unfortunately, many industry observers refer to both of these metrics as "IT spending."

So, What's the Difference?

Even though much tech industry spending comes from corporate IT budgets, tech vendors have a lot of revenue that comes from outside IT budgets. Furthermore, corporate IT budgets contain quite a bit of spending that does not go to tech vendors. Here are the big three differences.

1. Consumer tech spending. Not all tech industry revenues come from corporate IT buyers. For example, Apple just surpassed Exxon as the world's largest corporation, by market cap. How much of Apple's revenues are derived from consumer tech spending vs. business IT spending? Surely, the majority. Microsoft has a much stronger business focus, but still a large percentage of Microsoft's revenues are consumer-related.
   
   
2. Corporate IT spending outside the IT budget. Not all corporate IT spending is in the corporate IT budget. The percentage varies by organization, but typically 20-50% of what could be considered "information technology" spending can take place under departmental budget authority. Some of this is "rogue spending," for example, when a sales group buys a few seats of Salesforce.com, without approval or oversight from the IT department. But a lot of it is by design. For example, in most manufacturing companies, spending on computerized machine tools is entirely within the manufacturing operations budget. Such machinery has an enormous amount of computing power and there is typically an entire group within manufacturing devoted to programming these machines. But the machines themselves and the staff members that program them are typically outside the IT budget.
   
   Similarly, as my friend Vinnie likes to point out, products in nearly every industry today are becoming "smart products," with embedded computing power--not just automobiles, but even washers, driers, and refrigerators have IT capabilities. Do you think the technology spending that goes into designing and building products is under the manufacturer's IT budget? My observation is, almost never. Such spending accrues to the benefit of Intel, Cisco, and other tech vendors, but it is outside the corporate IT budget.
   
   
3. IT budgetary lines that are not tech industry spending. Finally, not everything in the corporate IT budget goes to technology vendors. The biggest item, of course, is personnel costs. Typically 40-50% of the corporate IT budget goes toward salaries of internal support staff, such as programmers, data center personnel, network personnel, and managers. Microsoft, Intel, and Cisco never see that money. So, right off the top, half of the IT budget does not show up in tech vendor revenues.

In addition, there are other corporate IT budget line items, such as facilities, power and utilities, and supplies that are typically not technology-related. Therefore, these show up in IT budget trends, but not in tech vendor market statistics.

When to Use Each Metric

Each of these measures is useful, but for different purposes. If you are a corporate CIO, you are interested in how your organization's IT spending compares against other, peer, organizations. You would like to know how your IT spending and staffing levels and their mix compares against industry standards. Therefore, you are really focused on IT budget metrics. Though they may make interesting reading, reports of tech industry revenues are not your primary focus.

On the other hand, if you are a technology vendor or an investor in the technology sector, you are really interested in how tech industry spending is expanding or contracting. You would like to know about overall tech industry revenues, and you would really like to know specifically about spending forecasts in the market you compete in. You are not interested in the typical corporate IT budget, unless your products or services are highly focused on that market.

What about consultants? If you are a consultant to IT organizations, your interest should be on IT budgetary metrics. Conversely, if you are a consultant to IT product/service providers, you probably want to focus on tech industry spending metrics.

So, when you read reports about IT spending trends, understand the context. Is the report referring to the IT budgets within user organizations, or the revenues of technology vendors? Those are two different things.

Related Links

The IT Spending Recovery and Implications for Enterprise Software
IT Spending and Staffing Benchmarks 2011/2012
Computer Economics IT Spending and Staffing Custom Benchmarking

Microsoft as the Good Guys

I spent a good part of this week at Microsoft's Worldwide Partner Conference (WPC) in Los Angeles, and I came away with this thought: in enterprise IT, Microsoft is turning into one of the "good guys."

When Microsoft ruled the world

First, let's turn back the clock. Around the turn of the last century, Microsoft had a lock on personal computing, especially with its Windows desktop OS and its Office productivity suite. Apple was in a far distant second place. Netscape had a head start with a Web browser but was soon crushed by Microsoft's Internet Explorer. Linux made inroads at the server level but never gained traction on the desktop. Microsoft on the desktop was like IBM in the data center in the 1980s. It was commonly said, whatever market Microsoft chooses to go after, it will soon dominate. The US Department of Justice and European Union pursued Microsoft on antitrust grounds, like the US did with IBM years before. But these actions seemed to do little to slow Microsoft's momentum.

But, what a difference a decade makes. The desktop is rapidly losing ground as the center of personal computing. Smartphones and tablet computer usage are exploding, and Microsoft has a tiny market share on both. Apple still has a small market share for desktops, especially in the enterprise, but it is now the choice for all the "cool kids." Microsoft still has a majority and growing share of the workload in corporate data centers (over half, even in large organizations, per our research at Computer Economics), but it is late to the game in cloud computing, which threatens the very reason-to-be for corporate data centers, long-term. Its search engine, Bing, has some interesting technology, but faces an uphill battle against Google, which dominates the search ad business. Therefore, in many markets, Microsoft is the underdog.

So, it was entirely fitting that the WPC Tuesday keynote this week began with a version of Coldplay's song," whose first line is, "I used to rule the world:

I used to rule the world
Seas would rise when I gave the word
Now in the morning I sleep alone
Sweep the streets I used to own

I used to roll the dice
Feel the fear in my enemies' eyes
Listen as the crowd would sing
"Now the old king is dead, long live the king!"
One minute I held the key
Next the walls were closed on me
And I discovered that my castle stands
Upon pillars of salt, and pillars of sand

There were signs of humility in the keynotes, such as Steve Ballmer remarking that the market share of Windows Phone had gone "from very small to very small." Even in touting success, such as with the roll-out of Windows 7 and Office 2010, there was none of the bluster we too-often see from certain enterprise vendors. Ballmer even had a hard time getting the partner audience to give a good hiss at the mention of a competitor.

So, as I'm listening to keynotes and conducting one-on-one interviews with Microsoft executives and partners, I'm getting the feeling that Microsoft is losing its place as everyone's favorite punching bag. In fact, it has a real opportunity to be the good guys in the enterprise IT marketplace.

I see this in three ways.

1. Offering safe platforms

Microsoft takes a lot of criticism for its proprietary technologies--especially from open source advocates (of which, I am one). I still believe that open source technologies, such as Linux, AJAX, and others, are a great foundation for building enterprise software. But, increasingly, independent software vendors (ISVs) are seeing Microsoft as another safe alternative.

It is not generally known, for example, that SAP--the granddaddy of enterprise software--is using Microsoft Visual Studios as the platform for scripting custom logic in its new Business ByDesign (ByD) cloud-based ERP system. SAP formerly did nearly all development in its proprietary ABAP language as well as in Java. But now, SAP apparently feels that Microsoft's C# is a better choice, at least for ByD. When I asked SAP about this a few months ago, an SAP executive told me, it's because most of the target market for ByD--small business--is already using Microsoft technologies.

This week, at the WPC, I ran into an executive of a Tier II ERP vendor, which competes with Microsoft Dynamics. I was surprised to see him at a Microsoft event. Why was he here, I asked. "Because, we're a Microsoft partner," he replied. "We use .NET, Lync, Sharepoint, and Microsoft's business intelligence capabilities as part of our product strategy. We're also using Azure to build cloud-based mobility apps."

Later in my one-on-one interviews with Microsoft executives, I asked about this. How can you compete with these enterprise software vendors in your Dynamics business, yet turn around and support them with your technology? The answer, in so many words, is that in the big picture, Microsoft will be more successful by being a safe platform provider for other vendors, than it will be by hoarding its technologies only for use by its own applications business.

So, at a time when other enterprise software vendors are questioning their commitment to Java, in light of Oracle's acquisition of Sun, Microsoft is starting to look like one of the good guys.

2. Focusing on cloud-value

Despite Steve Ballmer's talk about being "all in with the cloud," Microsoft's actual progress has been slow. From this perspective, Microsoft is seen as a laggard, falling behind cloud infrastructure providers such as Amazon, as well as SaaS providers, such as Salesforce.com and NetSuite. This has been my view for some time, and I still feel this way.

But from interviews with Dynamics executives, it's clear that there is some deep thinking going on about the cloud. Specifically, what is the value of cloud computing to customers? Is it only in cost-savings through outsourcing the infrastructure to a low-cost platform? Is it with all workloads equally, or with certain workloads? Are there parts of the enterprise suite that customers will more likely want to retain in-house, or with a trusted third party hosting provider, while moving other parts to a shared multi-tenant environment? What scenarios favor multi-tenant as the preferred architecture, due to the relationship between the tenants?

With many enterprise IT vendors today, where you stand on the cloud depends on where you sit. If you are a NetSuite or Salesforce.com, the only valid strategy is to have everything delivered as a pure multi-tenant SaaS offering. If you are a Larry Ellison, SaaS is a myth, or if you are a Harry Debes, the SaaS industry will collapse in two years.

But, with Microsoft there's no such dogmatism. Rather, it is thinking hard about where customers find the most value in cloud computing and is working to prioritize its migration to the cloud to focus on those value propositions. I just wish they would get there faster.

3. Enabling entrepreneurs

The third way in which Microsoft is the good guy is in the opportunity it offers to entrepreneurs. We all know that Microsoft's sells a lot of products to small and mid-size businesses. But Microsoft is also small-business-friendly in its partner channel. Attending the WPC is a real eye-opener: thousands of partners, mostly small businesses, many entrepreneurial, enabled by Microsoft's channel program. During these economic times, when everyone is championing small business as the key to economic prosperity, Microsoft is enabling thousands of entrepreneurs and small businesses worldwide to grow and compete successfully. In fact, IDC recently estimated the total 2010 revenue of the Microsoft partner ecosystem at US $580 billion. Compare that to Microsoft's revenue of approximately $60B, and you can see that every dollar Microsoft makes results in about 8 or 9 dollars of revenue for its partners. That's a big opportunity for Microsoft's 640,000 partners worldwide.

My interviews with three Microsoft partners also gave me insight into how these small businesses are winning in these difficult times. I interviewed Jeff Geisler, owner of Socius, a traditional CPA-type partner, which is growing steadily through the recession by acquiring smaller firms. I also met with Steve Thompson and Jim Sheehan from PowerObjects, a Microsoft CRM partner with strong development capabilities. Finally, I had a sit-down with Paul Tilling and Bob Hadingham at LexisNexis. Paul and Bob's group is an independent software developer in the UK that has taken its software for law firm practice management and is migrating it to Dynamics AX as its underlying platform. These three businesses have different focuses, but each is betting its business on Microsoft's partner channel.

With some other enterprise IT vendors, being a partner is a risky bet, as you sometimes find yourself competing against the vendor's direct sales force. Or, the vendor has a shifting strategy on where it wants to allow its partners to do business. Microsoft, by running 95% of its revenue through the channel, has no such conflict.

A closing thought

The choice of venue--Los Angeles--was entirely suiting to this theme. The city has seen hard times over the past several years. The glow is off the Golden State. The land of opportunity has been slow to recover from the recession. Our state budget is deep in the red and the business climate is going from bad to worse. It's a microcosm of most of the nation.

Microsoft could have chosen San Francisco or Silicon Valley, where it would have been just one more tech conference. Instead, it chose Los Angeles, where it could make a difference. In fact, I'm told, this was the largest business conference ever in Los Angeles, and was estimated to bring $45 million for local businesses.

So, once again, Microsoft is the good guy.

Related Posts

What’s new with Microsoft Dynamics AX 2012
Update on Microsoft Dynamics products and plans