The Candid Voice in Retail Technology: Objective Insights, Pragmatic Advice

ERP Is Dead; Long Live ‘Enterprise Enablement’

						Username: 
Name:  
Membership: Unknown
Status: Unknown
Private: FALSE
					

A lyric from a 1979 Kiss song is looping through my consciousness as I write this: “I sure know something, sure know something “. Well, when it comes to things retail, I know a few things. And two of them are, “words have meaning “, (or perhaps more precisely, “acronyms have meaning “), and the other is that “retailers have long memories “. What triggered this is the term “ERP “, short for “enterprise resource planning “. I cannot say how many times both my RSR partner Paula Rosenblum (another recovering retail CIO) and I have heard a retail executive say, “I considered <name of vendor here>, but decided that I need my job too much. “

The reason this comes up now is because the old memories of difficult, career-ending ERP implementations persist, AND they are no longer relevant — or at least they don’t need to be. At Oracle OpenWorld in San Francisco this week, Senior Vice President and General Manager for Oracle Retail, Mike Webster, spoke about both “point solution pollution ” in retail, and the need for “enterprise enablement of delivery <sales> channels “. But at the same time, the technology executive stressed that his company delivers “best of breed performance from each pillar (the seven components of the Oracle Retail portfolio) “, allowing retail customers to “start where it makes sense for your business “.

In that statement, the retail technologist highlighted the basic messaging challenge that each of the big suite vendors has, whether Oracle, SAP, or anyone else. In the 90’s and into the 2000’s, retailers went to best-of-breed point solutions because (among other reasons) ERP implementations were reputed to be death marches, usually resulting in huge cost overruns and ruined careers — and in a couple of cases the near destruction of the retailer’s business (who will ever forget Ross Stores blaming a system implementation for tanking its year?). So Webster was avoiding the unholy acronym “ERP “. But more than that, his company has done a lot to deliver on the promise that he enunciated. Retailers should be able to start down the path of modernization the way it makes most sense to their business. To be fair, it has to be pointed out that SAP has done exactly the same thing in the last decade, and in no way is today’s solution “your father’s SAP “. Times and technologies have changed.

At RSR, we’ve talked about the inherent problems with a point solution approach to IT application decisions. For starters, such an approach, while better than in-house development from the perspective of taking advantage of best-in-class commercial products, still incurs the cost of integration to the rest of the retailer’s portfolio — and that doesn’t ever go away! Such an approach also condemns the retailer to supporting different technologies (with the necessary differently skilled internal staffs and/or different vendors). And, since point-solution vendors tend to see the world through the lens of their solution’s functionality, the retailer never gets the benefit of an outside enterprise view.

But Webster pointed out that a point-solution portfolio ultimately creates a huge risk for retailers in this time of “anywhere commerce “: the retailer cannot maintain a single view of customer, inventory, and order. We’ve seen the same thing over and over again in our research. For example, a “single view of inventory ” has been rated a top opportunity by retailers throughout several of our studies in the past few years.

Oracle’s Seven Pillars & Functional Alignment

At OpenWorld, Mr. Webster delineated the seven pillars of the Oracle retail suite: Planning & Optimization, Supply Chain, Merchandise Operations, Commerce, Stores, Customer, and Analytics. His point in laying these out is that he expressed a concern that if retailers revert to “point solution ” thinking and focus on merchandise operations and commerce (today’s hot button issues), they will miss the bigger opportunity of “enterprise enablement “. While acknowledging that integration between the pillars has been a challenge ( “there is no lack of opportunities for improvements to the portfolio “), Oracle has the “unique ability to get there ” because of the “disruptive roll of R&D at Oracle. “

According to the Oracle executive, the company has two objectives: end-to-end integration, and functional alignment. It’s that second point which is so different from days past. It could easily be argued that Oracle’s competitors are just as capable of integrating the component parts of their portfolios as the Redwood Shores giant is (as one of my early-career mentors said once, “it’s only code! “). But functional alignment is another issue.

One of the reasons that ERP implementations in the old days failed so often is that retailers felt the compulsion to modify the architectures to bend them to their companies’ peculiar ways of doing business. Although the objective might have been to avoid the organizational change costs of a new system implementation, it was a worst-case scenario in most other ways. For one thing, what retailer, with it’s approximate 1% of revenue spend on total IT could hope to compete with the talent and speed of a software company that might spend 20-30% of its revenue on product development? And even if the internal team possessed incredible talent, they would then have to support the code forever (what a miserable existence!). But worst of all, the retailer missed the opportunity to learn something new. Software companies don’t develop systems in a vacuum — they learn from their early adoption partners, and those learnings are passed on through the solution to the market as a whole.

Oracle’s answer to the functional alignment objective was to develop its “retail reference library “, which contains two key assets: a reference architecture, and a reference model. The reference library was the brainchild of Jerry Rightmer, one of the principles at 360 Commerce (acquired by Oracle in 2006) and a key member of the NRF’s ARTS standards development group (Jerry has since moved on to co-found Starmount Systems). The purpose of the reference architecture is to provide a “deployment guideline to partners and customers “, according to Mike Webster.

The purpose of the reference model is to give retail businesses a starting point for modifying their operations to take the best advantage of the Oracle Suite’s capabilities. This model is an encyclopedia of business processes — and Oracle and its implementation partners urge retailers to deviate as little as possible from the reference models.

A Bold Claim?

It might seem a bold claim to say that a software company knows more about optimizing internal retail operational processes than do retailers who, after all, have spent their entire careers living those processes. But there are two aspects to that: first, many internal operational processes are non-differentiating (to take an obvious example, having a peculiar way of paying invoices doesn’t create strategic differentiation), and secondly, it really depends on the quality of the reference models!

At the Oracle session, I had the fortune to be sitting amongst a group of business process engineering consultants (and Oracle partners), and so I asked one, “do the reference models work? ” His response: “absolutely! They give retailers a place to start, to think about the possibilities. With a blank sheet of paper, they always end up designing what they already have! “

When it comes to choosing the best enterprise enablement platform, the decision comes down to two things: “how well does the solution implement true best-in-class processes? “, and “how convinced are you that the solution vendor in fact has ‘the unique ability’ to offer the best end-to-end solutions? ” Of the two, I would definitely focus on the first, first. As for the 2nd, although it’s too bland an assumption that the available technology solutions basically “work “, it is true that the big providers have spent years and vast amounts of money to modernize their portfolios, and today’s solutions bear little resemblance to their predecessor versions (the technical challenge was and continues to be how well one component truly integrates to other components of the portfolio).

So, is ERP dead? My vote: the term ought to be — because old memories get in the way of a more substantive discussion between those who have solutions and those who need them.

 

 



Newsletter Articles September 24, 2013
Related Research