Raving, Ranting, and Craving

by Lora Cecere on July 18, 2011 · 0 comments

They call it Base Camp.  I shun boots on this hot day and I do not have the inclination to camp. I want to go anywhere but to a Base Camp. I am tired and cranky.

As the alarm rings, my experience last year hangs heavy in my mind. I struggle to get out of bed at 4:00 AM.   The day is a scorcher. As I travel to the SAP headquarters, I watch the sun come up. I am a late night person, and rarely see a sunrise. I am a bigger fan of sunsets. I question if this will be a waste of my time.

When I arrive, I am crowded into the back of a packed room of analysts with a promise to hear about innovation. I am skeptical. To my pleasant surprise,  I was wrong.  I think that I witnessed two suns rising last week: the one on the east coast from my car window as I traveled to Newtown Square and the promise of a new SAP. While the event failed to deliver for me on many fronts, my mind is reeling with all the possibilities of what SAP could become (especially if SAP can get out of its own way). I feel strongly about this. So, I have broken this blog into my thoughts into three areas: Raving, Ranting and Craving.


Let me start with the positive. 

Content. Wow! My mind, post event, is spinning about the possibilities for SAP. I am full of thoughts of what can happen at the intersection of mobility, analytics and the redefinition of enterprise applications. I feel that SAP is teetering on a tipping point equivalent to the mainframe to client server push or the launch of ecommerce. While I gave SAP tough love last year on last year’s event of not having “enough there there”,  I left this year’s event questioning if SAP truly understands the impact of what their new push means for them, the market, and the potential to help companies address enterprise application problems. Unlike SAP Netweaver or Oracle Fusion, I think that this thinking could redefine enterprise applications.

Last year, I left the event feeling empty and frustrated. This year, I leave feeling full and excited. I went to the event thinking that SAP would become the ERP dinosaur.  I leave the event thinking about the world of possibilities. This is a good thing…. (I reflected hard today on the evolution of the ERP market with Lawson announcing their layoffs with the acquisition by INFOR. Who would have predicted this event five years ago? The technology market is not kind to companies that do not keep up.)

Wisdom. Hidden throughout the standard presentations were a number of gems. My favorites:

  • “When it comes to mobility, we need to think about the design of mobile applications first before we think about the enterprise delivery.” I agree. Effective mobile applications cannot be built from the enterprise out. In fact, enterprise applications need to be built from the outside-in as well.
  • “In-memory computing is analogous to an 8-track music tape powering iTunes.” It is an amusing, but effective analogy. While we can laugh, we should cry. The fact that our sophisticated enterprise application stacks are dependent on a mechanical disc drives is sad irony.
  • “The mistake that many make in talking to us about HANA is that they believe that it is an application migration path. They are better off, if we can start anew.” For clients this is good news and bad news. I write more about this below.
  • “We need to think about commodity management differently. ” I say, AMEN! Bring it on! It cannot come fast enough.  Companies are struggling. Supply chains are in a constrained supply environment. Commodity prices are rising and enterprise applications have no real goo solutions to translate go-to-market strategies to buy-side commodity strategies. Organizations badly need applications that span the organization horizontally. I strongly believe that this shift will outdate conventional Customer Relationship Management (CRM) and Supplier Relationship Management (SRM) applications.

Thanks. We, as analysts, do not often say thanks publicly. My hat is off: the team at SAP did a great job yesterday. I want to start by saying, “thanks!”

As an analyst, it is hard to get good information about SAP. I shun SAP’s Sapphire event and I have found SAP Insider to be less valuable as the years have passed. This creates a dilemma. I struggle with how to get the right level of information easily. I think SAP also struggles with how to effectively communicate to folks like me. So, I want to start by giving kudos to SAP for taking the time and making the effort to host an analyst day for industry thought leaders. It was unique event and shows a commitment to the market that is unequaled by any other technology provider that I cover. I also want to commend the speakers from SAP for side-stepping normal vendor posturing and hubris to be more open, honest and giving in their views. This takes courage. As an analyst, it is tough to sit through eight hours of marketing hype and positioning that does not help to answer client questions. I value honesty, and I have never seen SAP executives more honest, real and giving. It was a gift. Thanks.


Technology disruption is a classic case of “who moved my cheese?”Change in applications happens faster than organizations can absorb upgrades, enhancements and new releases. The political dynamics have pitted the Chief Information Officer against Line of Business leaders that are frustrated. IT costs are high, systems are inflexible, and for many, the latest releases did not deliver against expectations. For many SAP clients, this is the unfortunate reality. Clients are tired. The release of Netweaver, the acquisition of Business Objects, and the increases in maintenance costs have not gone down well, many line of business leaders in organizations that I work with are MAD.  Today, they just don’t want to buy anything that SAP is selling, but this will dissipate if the technology shift warrants the investment. In the “base camp”, there was no reflection of this world reality.  (This is an industry trend.  The sentiment with Oracle users is worse, but reflects the same themes of expense, inflexibility and failed promises.)

Can we start over? In the area, of supply chain planning, can we just start again and build it on HANA? While it is promising to see some new supply chain applications –Demand Signal Repository and Sales and Operations Planning—released on HANA, the supply chain market hungers for a leader like SAP to change the game and drive dramatic supply chain improvements.   Consider the current state….. In the supply chain world, companies wish that there was more “O” in APO. It was late entrant in an established market. When it came to functionality, it was largely an “inferior me-too” release in a market (Advanced Planning Solutions) that has moved on. Its strength is architectural.

Supply chain management is a market with no good option for a second generation solution. Currently, companies in multi-year roll-outs and infrastructure design are evolving to SAP APO. It is not because it is an ideal release, but because of issues with other alternatives. In many ways, it is winning the ugliest baby beauty contest. Even though it is hard to use, and lacks depth of functionality of best of breed, it is built to last. Today, I have five clients that are migrating from JDA/Manugistics to SAP APO.  It has become the defacto standard.  When SAP knows what to build, they do it well. The journey to APO has been layered by fits and starts in the evolution of the APS market. HANA is a good excuse start again. It is the opportunity to build the second generation supply chain planning application that the market needs and wants, and who is better to write it than SAP?

Doesn’t it take a village?  During the session, there was an elephant in the room. The session yesterday was largely devoid of discussions on partnerships. While sales executives late in the day give SAP an “A” on partnership execution, I give them a D-. The only partnerships that have been successful in the software space are small, industry-specific technology vendors that are sold by SAP sales teams to extend deals. When asked the question, “of who are your successful software partnerships?” They listed ICON, Open Text, Smartops, Vendovo, Vistex…. I smiled. What happened to the Microsoft work on Duet, the Teradata work on enterprise data management, the SAS work on predictive analytics? I wish that SAP knew how to dance better in the ecosystem. Sadly, most SAP partnerships are sales driven. When it comes to tackling the opportunity in front of us, I think that it requires the mobilization of the ecosystem. (My score for Oracle for this would be far worse….)

The greatest issue may be SAP itself.  Within SAP, there are two main drivers: license sales and delivering on the maintenance revenue promise to customers. Both of these drivers run the risk of strangling discontinuous innovation. This tipping point also includes software as a service (SaaS) as the delivery model. It is incongruous with the SAP license delivery model. And, I don’t feel that maintenance customers and the system of industry councils will drive this forward. In the words of Henry Ford, “If I had asked my customers what they wanted, they would have asked for a faster horse.” We are dealing with discontinuous technology here.

What about costs?  Can we ask the line of business user to fund this development? The primary push back on SAP today is the cost of running a SAP architecture. The average client has three ERP instances, and has stomached higher maintenance costs and the purchase of Business Objects. Companies want these costs to go down not up. The discussion last week did not address this.


I live want to know more. I want to talk about how we can redefine applications based on in-memory processing. I am fascinated by what could be at the intersection of mobility, in-memory processing and the redefinition of enterprise applications. I want to move on. Not with my boots at a Boot Camp, but with my running shoes….

What I think that this means for you….

If you are the average supply chain executive that is stunned by the ERP quagmire–escalating costs, inflexibility, and failed expectations– and is struggling with what this means for multi-year roll-outs, these recommendations are written for you:

Don’t get diverted by bright and shiny objects. The market push of mobility platforms, in-memory processing and enterprise application redefinition is compelling. However, don’t get fascinated by bright and shiny objects. The upcoming Demand Signal Repository and Sales and Operations Planning releases planned for the fall on HANA are new and early. As such, it should be treated as should be evaluated as co-development. Instead of jumping with your check book quickly, work in industry councils to guide the development teams. Watch it evolve and shape the future, spend enough to drive the innovation, but it is not ready for swan dive.

The new concepts of SAP may not be a migration.We have a migration mentality. R3 to ECC6.0. APO 3.0 to 7.1. I feel that companies that will get the most value will not tackle this as a  migration discussion. Instead, this is a discussion of what could be. When you have the opportunity to discuss this with SAP, unconstrain your thinking by today’s application definitions, enterprise software limitations, and yesterday’s thinking.

Learn from the past, but be open for the future. Think hard about the areas that do not work well in today’s enterprise applications, but don’t throw away the goodness of what we have learned in the evolution of packaged applications. While the code may not be a migration, the lessons learned are.

All the best to you and your team on this summer afternoon.

Let me know if you have any questions. I am busy finishing up my report on Sales and Operations Planning (S&OP) and have an extensive road trip next week planned with clients.  Look for my tales from the road and may you have safe travels

Crossing the Great Divide

by Lora Cecere on August 31, 2010 · 0 comments


It was a hot Atlanta day. The temperature in the cab was sweltering.  It was the kind of day that makes you feel like a grease spot on the pavement. As I bustled through the air-conditioned lobby, past reception and not catching my breath until I sat down in the deep leather chairs in the Chief Financial Officer’s conference room, I tried to compose myself.  However, the question that I was asked did not have an easy answer. I was in the HOT seat.

Bob, the CFO, opened the meeting with the statement, “Our SAP implementation was expensive. I know we need it, but I am trying to get a Return on the Investment (ROI).  I think that I can improve the ROI by using retail Point of Sale (POS) data to improve forecasting and replenishment.  How are others using POS data?”

I swallowed hard.  This question does not have an easy answer.  Most companies are struggling to answer the same question.  The company had built a repository for demand data and wanted to plug it into SAP APO, but I knew that it was not as easy as that.  I replied, “You cannot get there from here.  The data in the repository used by the account teams cannot just be plugged into APO for three reasons:  scalability, granularity, and usability. And, I started to tell him a story.”

The Story:  We Have Puzzle Pieces That Do Not Fit Together

The good news is that the sharing of retail data by retailers is increasing and the data is cleaner and more granular than it has ever been before.  For most consumer goods manufacturers, 40-60% of the channel is available as daily data received on a weekly basis.

The bad news is that POS technologies are over-hyped and confusing. In the fourth quarter of 2009, there were 72 instances of downstream data repositories sold in the North American market.  Often at more than one per company, and sometimes more than one technology sold into the same account team.  It is not unusual to have 4-6 different technologies to manage POS in the technology ecosystem of a branded manufacturer.

The market for downstream data repository vendors is very competitive and over-crowded.  To improve market positioning, several technology providers have added forecasting to their offering.  These companies have very little understanding of the differences between account level and corporate level forecasting.  At a minimum, it varies by focus (short term versus long term), the data model, and the depth of statistical forecasting.  (Account level forecasting is short-term (0-8 weeks) and corporate forecasting is longer term forecast.  On average the longer term corporate forecasting process uses demand data to project the period of 0-78 weeks).

Likewise, more than 80% of the market has an Advanced Planning System (APS) for corporate forecasting.  Most companies implement APS to model ship from data—either shipments or orders—on a monthly or a weekly basis.  Traditional APS technologies also use rules-based consumption to split the forecast into daily targets—usually termed “buckets” to drive replenishment. The problem is that rules-based replenishment is never right.  And, POS data requires a ship-to or a market-driven forecasting data model (outside in).

The data in the account team is used for weekly forecasting and replenishment.  It is isolated, seldom integrated and used for ad hoc analysis.  Very few companies have figured out how to plan globally at a corporate level to act with greater insight at a sales account team level.  Similarly, the data needs to flow bi-directionally to enable demand sensing by the account team to spotlight opportunities for improving sales through pull-based replenishment, minimizing costs through demand orchestration, and reducing channel and company inventories.  Today, 98% of companies do not have a synchronized demand signal and it is not as easy as just plugging POS data into APO. It takes more than that.  To use the POS data and drive maximum value, you have to cross the Great Divide.

The Answer:  It is Like Crossing the Great Divide

Demand data is the river that runs through the corporation that gives it life.  There are many—not just one stream—of demand data to harness.

The great divide is a name given to a mountainous region that forms a hydrological divide separating watersheds.  For example, the continental divide in the United States separates the watersheds that drain into the Pacific Ocean from those river systems that drain into the Atlantic Ocean.

In a similar vein, forecasting is the great divide between go-to-market and supply-side processes.  It is a rocky process— each company defining it a bit differently—and few companies being entirely happy with what they have.  In this time of demand volatility, where demand error is the largest risk to the corporation, it is often contentious.  To be successful with POS data integration, you need two hierarchies:  a demand and a supply hierarchy.  Most companies only have one:  a supply hierarchy. Therefore, they cannot cross the great divide, and they have no place to put POS data for modeling.

Good forecasting processes start with the end in mind.  Each of the functions have a different goal.

Let’s take a look at history.  As you read this synopsis, it is clear that the goal has changed, the data input choices have improved and the processes are being redefined to move from a supply-focused forecast to a demand-driven process.  It is a shift from an inside-out (supply side modeling based on shipments and orders) to an outside-in forecasting process (demand side modeling based on downstream data) to focus on market drivers.

Forecasting Supply

In the 1990s—the go, go years of supply chain management—new forecasting systems answered two questions for supply:

What should manufacturing make?

What should we stock in the warehouse to improve customer service?

These optimization engines used orders and shipments to generate a forecast for the future based on history.

Late in the 1990’s processes for internal collaboration were added—to align sales, marketing, finance, manufacturing and supply chain—around a common plan.  There was an assumption that the parties could give unbiased, accurate input, and that this could form the horizontal bridge across functions.  This assumption proved to be false.  To improve forecasting, bias and error accountability in consensus forecasting was adding in the period of 2005-2010.

Forecasting Demand

In the period of 2000-2010, short-term forecasting (weekly/daily forecasting for 1-8 weeks out in duration) in the sales account teams became a retailer expectation.  As a result, account teams started forecasting using point of sale data for Vendor Managed Inventory (VMI) programs to answer the question, “What will the retailer sell?”  As these account teams proliferated (the average consumer products team has 22 accounts teams just in North America), and point of sale data grew exponentially, companies started asking themselves the questions of:

How can I connect these account team forecasts to corporate demand planning?   How can I best use the growing availability of point of sale data to improve the corporate forecast?

This data is usually isolated in the account teams.

The Conundrum

Traditional APS architectures do not support the direct connection of corporate forecasting and account team forecasting.  Likewise, the direct usage point of sale data in corporate forecasting can be problematic.  There is no over-arching demand management architecture for companies to plan globally and execute at the account team level.  To make this happen, seven things need to happen:

  1.  Change hierarchies. Corporate forecasting must be re-implemented to model ship-to relationships based on market drivers. The hierarchy needs to have account level granularity to ensure modeling flexibility.
  2.  Assess Technology fit. The fit of the optimization engine to model downstream data must be accessed to determine optimization engine best fit and scalability.  This is often a re-implementation.
  3. Build Process Governance.  A governance model needs to be established between account teams and the corporate planners.  Often the account teams own the bottoms-up forecast for the account for the short-term forecast and input these numbers into the corporate plan. Another alternative is to bring short term forecasting into the model as an indicator. Indicators are based on forecasting on multiple demand streams.  Alerts are then triggered by comparing indicators.
  4. Eliminate Rules-based forecast consumption.  Move to daily statistical forecasting to determine a pull-based signal.  The greatest return on the usage of downstream data has happened making this move.
  5. Infuse Discipline into Consensus Forecasting.  Insert bias and error accountability into consensus forecasting.
  6. Persistence and Data ownership.  The demand forecasting process needs a persistence layer and a data owner. As POS moves from weekly data sharing weekly to daily data sharing daily, data volume grows exponentially, this requirement grows in importance.
  7. Demand translation and Demand Orchestration:  To translate demand data across the watersheds of the Great Divide, focus on the definition of demand translation and demand orchestration processes.  Demand translation is the process of translating a ship- to or market-driven hierarchy to a supply hierarchy.  This requires a deep knowledge of mix, supply capabilities and shipment types/characteristics.       Demand orchestration is the process of pushing the demand forecast back from the supply-side to the demand-side hierarchy to analyze and maximize opportunity. These what-if analysis to evaluate the impact of demand shaping – sales incentives, marketing programs, new product launch, promotions, price management, and inventory obsolescence programs—on the corporate opportunity.

So, now you know the answer that I gave the CFO on his bulletin board on that hot Atlanta day.  My hierarchies were not drawn as pretty, and the board was full of scribbles.  It was a deep discussion, but at the end, he thanked me.

So, net/net, POS data sharing is a great opportunity, but it takes more than just pumping POS data through traditional forecasting systems.  As you work on this definition, it is important to keep in mind:

  1. One number forecasting is a hoax.  Do not hire ANY consulting that tries to convince you to strive for this as an end goal.  Instead, focus on a common plan understanding that the data must be synchronized based on demand translation and demand orchestration.
  2. Demand translation needs to be based on the operating strategy.  Get clear. Spend to time to develop the right strategy for your company to bring corporate financial forecasting, corporate market-driven and supply forecasting together.  If your strategy is to be demand driven, the market-driven forecast modeling drives the plan.  The output of this forecast is an input into the corporate financial forecast, but the market-driven forecast is never constrained by the financial forecast. The supply forecast is populated from the market-driven forecast based on demand translation of from the ship- to to the ship- from model.
  3. Make sure there is discipline.  Many companies make the mistake in the formulation of the market-driven forecast of believing that they can just ask sales what they are going to sell.  WRONG.   This is a sales-driven, not a market-driven approach.  The sales organization, by definition, is COIN operated.  They are paid on bonus and commission, and their forecast is inherently biased.  In developing the market-driven forecast, focus on market drivers.  Spend time to get it right.

The good news is that the CFO let me finish the entire story.  He liked the analogy of the Continental Divide.  The demand hierarchies are like mountain ranges with different watersheds.  Demand translation is the path between them.

What do you think? Any stories of demand excellence that you want to share?  What would you have told the CFO?

<Please excuse the length of this post.  This is a complex concept asked frequently, and I thought that it deserved a detailed answer.>