Standardizing Processes Worldwide

September 2015

Lidl is looking to press ahead with standardizing processes worldwide and chose SAP ERP Retail powered by SAP HANA to do the job (PressBox 2, September 2015)

November 2016

Lidl rolls out SAP for Retail powered by SAP HANA with KPS (Retail Times, 9 November 2016)

July 2018

Lidl stops million-dollar SAP project for inventory management (CIO, in German, 18 July 2018)

Lidl cancels SAP introduction after spending 500M Euro and seven years (An Oracle Executive, via Linked-In, 20 July 2018) 

Lidl software disaster another example of Germany’s digital failure (Handelsblatt Global, 30 July 2018)

I don't have any inside information about this project, but I have seen other large programmes fail on because of the challenges of process standardization. When you are spending so much money on the technology, people across the organization may start to think of this as primarily a technology project. Sometimes it is as if the knowledge of how to run the business is no longer grounded in the organization and its culture but (by some form of transference) is located in the software. To be clear, I don't know if this is what happened in this case.

Also to be clear, some organizations have been very successful at process standardization. This is probably more to do with management style and organizational culture than technology choices alone.

Writing in Handelsblatt Global, Florian Kolf and Christof Kerkmann suggest that Lidl's core mentality was "but this is how we always do it". Alexander Posselt refers to Schicksalsgemeinschaften, which can be roughly translated as collective wilful blindness. Kolf and Kerkmann also make a point related to the notion of shearing layers.

Altering existing software is like changing a prefab house, IT experts say — you can put the kitchen cupboards in a different place, but when you start moving the walls, there’s no stability.

But at least with a prefab house, it is reasonably clear what counts as Cupboard and what counts as Wall. Whereas with COTS software, people may have widely different perceptions about which elements are flexible and which elements need to be stable. So the IT experts may imagine it's cheaper to change the business process than the software, while the business imagines it's easier and quicker to change the software than the business process.

What will Lidl do now? Apparently it plans to fall back on its old ERP system, at least in the short term. It's hard to imagine that Lidl is going to be in a hurry to burn that amount of cash on another solution straightaway. (Sorry Oracle!) But the frustrations with the old system are surely going to get greater over time, and Lidl can't afford to spend another seven years tinkering around the edges. So what's the answer? Organic planning perhaps?


Thanks to @EnterprisingA for drawing this story to my attention.

Slideshare: Organic Planning (September 2008), Next Generation Enterprise Architecture (September 2011)

Related Posts: SOA and Holism (January 2009), Differentiation and Integration (May 2010), EA Effectiveness and Process Standardization (August 2012), Agile and Wilful Blindness (April 2015).


Updated 31 August 2018

Two Second Advantage

There are two reasons I like TIBCO's new slogan "The Two-Second Advantage". (I have some reservations as well, but let's start with the good bits.)

advantage means something to business

The first reason is that it actually means something to the business, unlike the widely misunderstood technical term “real-time”. One company that is currently boasting “real-time” performance is SAP, which claims that its in-memory databases will result in analytics that are “really in real-time”. Larry Dignam quotes Hasso Plattner as follows. “In analytics, there’s theoretically no limitation on what you can analyze and at what level of detail. (In-memory databases) mean reports on a daily basis, hourly basis.” [ZDnet] @davidsprott calls this In-memory madness. Even if an hourly or daily report counted as “real-time” (which it doesn't), this kind of technical wizardry doesn't make any sense to the business.

On a Linked-In discussion thread recently, I've seen vendors excusing their misuse of the term "real-time" (to describe software that isn't strictly, or sometimes even remotely, real-time) by claiming that the meaning of technical terms evolve over time. Oh yeah, very convenient. But we shouldn't allow vendors to fudge perfectly good technical terms for their own marketing purposes, any more than we should tolerate car manufacturers self-interestedly redefining the word "friction".

(In The 2 second advantage...the 2 culture disadvantage? Vinnie Mirchandani praises TIBCO executives for being able to talk business, and contrasts them with the IT analysts in the expo hall, with a special dig at Gartner.)

Unfortunately, TIBCO is not content with the "two second advantage" slogan, and we find TIBCO CEO Vivek Ranadivé over-egging the pudding by introducing some additional notions including Enterprise 3.0. Transcript of HCL keynote by TIBCO CEO Vivek Ranadive (April 2010). For @neilwd "Enterprise 3.0 ... is the sound of a company trying too hard" (TIBCO, Enterprise 3.0 and the two-second advantage, May 2010. See also Tibco’s Hits and Misses (Ovum, May 2010).

advantage is relative

The second reason I like the phrase "Two Second Advantage" is that it focuses our attention on the business advantage - not of raw speed but of getting there first. If you are a speculator who judges that some asset is overvalued or undervalued, the way to make money from this judgement is to buy or sell and then wait for other speculators to arrive at the same judgement. Being just ahead of the pack is actually more profitable than being a long way ahead, because you don't have to wait so long.

And although simple decisions can be taken quickly, complex decisions need time for understanding. (See my presentation on Mastering Time.)With complex decision-making, it's about spending just enough time to process just enough information to make a good enough judgement.

Ranadivé also talks about two trends - the increasing volume of data and the diminishing half-life. (In physics, the concept of "half-life" suggests a long tail of residual value - just as a radioactive sample will always remain somewhat radioactive, so the value of data never reaches zero.)

But as @neilwd points out, these trends don't necessarily refer to the same kinds of data, especially if we measure data volumes in terms of physical storage, since these volumes are dominated by email attachments and rich media. Maybe we need to find a way of measuring data volumes in terms of information content ("a difference that makes a difference"): as the cost of data transmission and storage continues to get smaller, it is not the number of megabytes but the number of separate items (giving managers the experience of being overloaded with information) that really matters.

Even if we limit ourselves to traditional data, the relationship between data volumes and response speed is not as simple as all that. Let's look at a specific example.

If a retail store gives a hand-held scanning device to the customer and/or places electronic tags on all the goods, it can collect a much higher volume of data about the customer's behaviour - not merely the items that the customer takes to the check-out but also the items that the customer returns to the shelf. As technology becomes cheaper, this enables a huge increase in the volume and granularity of the available data, collected while the customer is still shopping, and therefore the retailer actually has more time to use the data before the customer leaves the store.

For example, you might infer from the customer's browsing behaviour that she is looking for her favourite brand of pasta sauce. The shelf is empty, but there's a new box just being unloaded from a truck at the back of the store. Find a way of getting a jar to the customer before she reaches the checkout, and there's your two second advantage.

Semi-structured processes 2

@jonerp (Jon Reed) kindly sends me a link to an article on the SAP community network website, Value Scenarios and the BPM continuum, discussing the requirement for semi-structured processes. 

 

The author of the article, one Dan Woods of Evolved Media, places "processes automated and supported by BPM" at the "loosely-structured" point of the continuum, but he also talks about "more advanced and structured process design using BPMN and other such techniques"; I don't fully understand his taxonomy of processes, but he certainly seems to understand the need to support semi-structured processes as well as the fully structured processes described by Ann Rosenberg. 

Dan's starting point is the SAP book written by Ann Rosenberg and others, but his own analysis goes a lot further. He picks up on a reference to the Geoffrey Moore core/context distinction (which CBDI Forum members will be familiar with - see link below), and takes this distinction to its logical conclusion. 

Dan also makes clear his opinion that SAP doesn't currently support this continuum. "SAP's integrated story about BPM, SOA, and Value Scenarios will have to be extended to include more unstructured collaboration." Dan is not an official spokesman for SAP, although it's worth noting that his opinion article is published on an SAP website.

 

---

 

CBDI Forum, SOA Fundamentals (2009) - key extract from page 222

Richard Veryard, Towards the Agile Business Process (CBDI Journal July/August 2007) 

Related posts: Activity-Based Computing (March 2006), Semi-Structured Processes (April 2009)

Semi-structured processes

A lot of the focus in the BPM world is on highly repeatable, controlled processes. These processes follow a strict management lifecycle.

1. analysed and designed by process experts on behalf of process owners,
2. implemented by process engineers using sophisticated BPM tools and workflow engines
3. performed by armies of obedient employees or compliant customers
4. monitored and calibrated by statisticians using sophisticated analytical tools

This is essentially the BPM lifecycle presented by Ann Rosenberg of SAP at the London TOGAF conference today.

In this lifecycle, we can achieve process agility and innovation through rapid redesign and recalibration. If the design and control phases can be make more efficient and effective (for example by being supported by tools), then the set-up costs are reduced, and this improves the economics of scope as well as the economics of scale.

At the other extreme, there may be some processes in an enterprise that are completely adhoc, with no repeatable structure. For example, a decision to merge with a competitor may involve a number of highly complex steps (investigation, evaluation, due diligence and so on) but without any systematic process structure.

Is there something in between these two extremes? Well there certainly should be. In my previous post on Activity-Based Computing, I mentioned four important examples.

• Sales. The sales team produces a detailed proposal in response to a complex request from a customer or prospect.

• Customer Complaints. Each complaint follows a different path, which depends on the nature and content of the complaint.

• Problem solving.

• Medical intervention.

All of these processes are semi-structured. The people doing these jobs are given some degrees of freedom to customize the process to their own understanding of the requirements of a particular customer or patient or situation. However, they are still accountable and their performance is measured; and therefore there must be some underlying process structure.

Who is doing the process management? All the participants in the process are participating in the management of the process, and should have access to all the management tools (not just BPM but also BAM and Business Intelligence). Then the job of the process architect is not to lay down the process but to create a collaborative process space in which everyone can be productive and appropriately innovative, with the right balance of variation and standardization, freedom and control.

So the big question for the process architect is not optimizing one process, or even optimizing lots of different processes, but managing the process continuum. In this way, the process architect becomes the enterprise architect.

Update: see Semi-structured processes 2

Timeless Way 2

Excellent report from James Governor (Redmonk) on SAP's view of Timeless Software, and I am very glad to see Stewart Brand's work getting wider exposure. See also Nick Hortovanyi.

But I am puzzled at SAP's use of the word "timeless". This was apparently introduced by SAP CTO Vishal Sikka (via Mark Finnern) Vishal explains it further in the comments to James's blog.

"I have indeed coined the phrase timeless software to refer to our strategy of continuously evolving our software ... [and allowing for] constant and furious change across all layers of the technology stack."

What is timeless here is not the software itself but the process of continuous evolution. I have previously used the term "timeless software" to mean something closer to the original work of Christopher Alexander on the Timeless Way of Building. (See posts by Dion Hinchcliffe and myself from March 2006 )

Note also this quote from Barry Boehm's magisterial View of 20th and 21st Century Software Engineering (pdf) (via Andrew Newman)

The theory underlying software process models needs to evolve from purely reductionist “modern” world views (universal, general, timeless, written) to a synthesis of these and situational “postmodern” world views (particular, local, timely, oral)

In other words, Boehm is contrasting the timeless and the situated, and calling for a synthesis of both. I think the Brand notion of shearing layers (or pace layering as he is now calling it) allows us to get the best of both worlds - BOTH timeless AND situated. The "timeless" has a very slow pace of change, while the "situated" is much more dynamic. See my post on Lightweight Enterprise.

This is certainly consistent with material that has been coming out of SAP for many years about the stratification of business. See my review of Shai Agassi's talk on Achieving Enterprise Agility from 2004. At that time, Shai was talking about some really interesting ideas in this area that I wasn't hearing from any of the other major vendors. It is good to see that SAP is still pushing some of these ideas.

---

Footnote

As my regular readers will know, I've been talking about Brand's book for many years, and I note the emergence of the term pace layering for Brand's principle that stratification should be based on the differential rate of change. See Long Now Blog. I previously referred to this principle as "shearing layers", but this refers to what happens when this principle is not followed.

ERP Platforms

In my previous post Does ERP matter? I discussed the business requirements for enterprise resource planning - a management style involving tight command-and-control coupling between different enterprise functions (sales & marketing, distribution, manufacturing, purchasing).

However, this is not the question addressed in Shai Agassi's original post Does ERP matter? His primary concern (as it has been for much of his time at SAP) is the impact of SOA on ERP. He avers (I think rightly) that enterprise software cannot be assembled from JBOWS (just a bunch of web services), largely because of concerns about semantic consistency and compliance.

In the past, major vendors persuaded their customers that the way to achieve semantic consistency and compliance was to purchase the entire application suite from a single supplier. While at SAP, Agassi has championed the creation of a radical SOA-based alternative to this strategy. If you build the rules into the ERP platform (e.g. Netweaver), then your chosen vendor (e.g. SAP) can maintain hegemony and control over a heterogeneous but properly architected collection of enterprise services.

Including of course the multiple inconsistent implementations of SAP software that global mergers sometimes throw up.

So what matters now, according to Agassi, is not the ERP but the ERP platform. If you are going to implement enterprise software, then use a platform that is specifically designed to support enterprise software, rather than a general-purpose software platform.

There are various other terms for this platform, including the bland (Business Process Platform or BPP) and the downright ugly (Applistructure). For recent commentary, see Sam Lowe, Michael "Mitch" Hatscher (via Matej) and Phil Windley (via John Gøtze).

Moving the platform upwards is a powerful architectural strategy, as I've argued before. But these strategies, while enabled and encouraged by SOA, remain challenging both technically and conceptually. It will be interesting to see whether this strategy goes on the back burner once Agassi is out of SAP.

Does ERP matter?

Having announced his departure from SAP (apparently quitting the software industry to work on alternative energy and transport) Shai Agassi continues to blog about enterprise software on the SAP Network as well as his personal website The LongTailPipe. His latest post: Does ERP matter?

People in the software industry often use labels like ERP (enterprise resource planning) and CRM (customer relationship management) to refer to computer systems or application packages, such as those purveyed by SAP and its competitors. So most people will probably read Agassi's post as a discussion of the ongoing relevance and value of these packages.

But these packages are merely a software solution to a particular class of management problem. So we might first ask: does enterprise resource planning matter?

This is not such a stupid question as it might seem. Like MRP and MRPii before it, ERP represents a certain management style. Invoicing is integrated with inventory control and logistics not just because data management likes to have all the data in one place, not just because it makes the transaction processing more efficient and effective, but because this integration enables a set of higher-level management capabilities, including planning and coordination. ERP is therefore not just a transaction processing system, it is a command and control system.

In the early days of MRPii, I can remember considerable resistance to the notions of planning and coordination that MRPii entailed, from factory managers who were accustomed to planning next week's production of widgets quite oblivious of the fact that the warehouse was already full-to-overflowing with widgets.

And it is possible to imagine a fictional enterprise in a totally service-oriented world that doesn't need resource planning - because it doesn't possess any resources. Everything it ever needs is invoked from somewhere else in the network, on a just-in-time basis. You would still need systems to handle logistics and invoicing and all the rest, but you wouldn't need ERP.

Enterprise resource planning represents a kind of management coupling between different management functions - sales and marketing, distribution, manufacturing, purchasing. In the past, there were many enterprises where the coupling between these functions was loose and incompetent. There are many enterprises today where the coupling between these functions is now tight and efficient - and some of the credit for this improvement may go to SAP and its competitors.

Clearly we don't want to go back to a loose and incompetent style of management. But is there a real alternative to enterprise resource planning, one that is loosely coupled (as befits a service-oriented world) but still efficient and effective? I think that's the fundamental question as to whether ERP matters.

But this is not the question Agassi is addressing. I'll come back to his argument in another post.

---

See also Ian Thomas Does ERP Suck?

Business Unbundling

One of the key concepts of the component-based business or service-based business is that you can change the nature of the coupling or coordination between enterprise units. So we are seeing significant quantities of demerger, unbundling, outsourcing and so on.

Much of this unbundling is being pushed by regulators, especially in utilities (including telecom). See my previous note on Local Loop Unbundling. Think also of the structural changes that various regulators have threatened Microsoft with.

These are often formulated in terms of unbundling services, products or platforms. But they have obvious implications for organizational structure as well. (At one time it looked possible that Microsoft might be split into separate organizations, just as Standard Oil and ATT were previously broken up. And many years before that, IBM was also threatened.)

But the regulatory agenda should not make us think there is always a going to be a conflict of interest here. (Someone in a large telecom company once told me that the unbundling forced upon the company by the regulator had actually turned out to be beneficial for the company as well, because it had increased internal management visibility and innovation.) So sometimes unbundling is the right thing all round.

SAP has been making moves to support unbundling, and the SAP Roadmap includes guidance for unbundling (ECRM Guide, Feb 2005). There is also some standard IT support for inter-company collaboration and data exchange (SAP Press Release, Feb 2005).

John Hagel III and John Seely Brown have been writing about these issues for ages. John Hagel and Marc Singer had an article in Harvard Business Review called Unbundling in the Corporation (1999) (abstract only, purchase reprint). Hagel has been promoting a standard demerger pattern, which splits the enterprise into three standard chunks: infrastructure management, customer relationship or product innovation and commercialization. (This pattern has evolved in his writing, and his terminology has shifted somewhat.) In a recent blog posting (March 2005), he interprets recent developments at 7-Eleven as a successful implementation of this idea.

Hagel points out that these three activities operate with a different business logic on different timescales. Referring to Disney, HP and Morgan (April 2005), he comments: "Product innovation businesses and customer relationship businesses have completely different economics, skill set requirements and cultures. These are incompatible business types that cannot co-exist successfully within a single corporation. By trying to straddle both, these companies found that they could not be excellent in either."

Hagel has identified some of the relevant factors for determining the best way of unbundling the business - but this is not the whole story.

There are two contrasting approaches for unbundling. The approach favoured by Hagel assumes we can establish broad patterns and practices of demerger and subsequent collaboration. This has some advantages - among other things, it suggests that there will be multiple organizations offering broadly similar interfaces, yielding commercial flexibility. But we have some doubts about the generality of this approach. The alternative is to carry out specific analysis for each particular situation. More effort, but sometimes justified.

dotBiz

I have just come across an interesting talk by Shai Agassi of SAP, entitled Achieving Enterprise Agility.

Slides (pdf) from Accelerating Change 2004. Voicetrack (various formats, 18mB audio, 38 minutes) courtesy of IT Conversations.

The first 10 minutes or so provides some business background, including airline examples. Then he starts talking about composition, which I think is the most significant part of his talk. He has a vision of what he calls dotBiz (roughly equivalent to the Service-Based Business), for which he makes massive estimates of market size from around 2008 onwards. (After about 25 minutes he starts to rush through the rest of his material. It's probably not worth listening beyond this point.)

From the slides, you might get the impression of a ho-hum nothing-special software product architecture. But his talk implies something much more radical: a stratification of business.

At the top of the stack are niche companies with small solution-oriented microprocesses. This are assembled from "composites" - he refers to a "conveyor belt" of partly-assembled (orchestrated?) subprocesses. Below this are tens of thousands of business objects exposed as web services. These then sit on top of a layered enterprise platform, presumably supporting supply-side composition.

Agassi then characterizes the historical position of the big four, roughly as follows:

• IBM outsourcing non-core process - "on-demand" understood primarily in terms of variable volume of standardized process
• Microsoft preferred for local non-scaleable solutions, but not taken seriously for enterprise solutions - "start here but don't know whether it can scale"
• Oracle specializing in supporting big one-off differentiated process - "stuff you want to build on your own"
• SAP specializing in non-differentiated non-core process - "best practices that always run"

In other words, each represents a different mix of differentiation, integration and scale. Agassi's characterization provides a possible explanation of the current strategy of the big four: all trying to converge onto the same central ground, using SOA to get the best of all three worlds: differentiation, integration and scale. However, in this presentation, he doesn't get to the most interesting question: how business stratification helps this agenda.