LEAN

You are currently browsing articles tagged LEAN.

Why we can’t keep up

2009/06/22 in Business-Technology | 7 comments

We’re struggling to keep up. The pace of business seems to be constantly accelerating. Requirements don’t just slip anymore: they can change completely during the delivery of a solution. And the application we spent the last year nudging over the line into production became instant legacy before we’d even finished. We know intuitively that only a fraction of the benefits written into the business case will be realized. What do we need to do to get back on top of this situation?

We used to operate in a world where applications were delivered on time and on budget. One where the final solution provided a demonstrable competitive advantage to the business. Like SABER, and airline reservation system developed for American Airlines by IBM which was so successful that the rest of the industry was forced to deploy similar solutions (which IBM kindly offered to develop) in response. Or Walmart, who used a data warehouse to drive category leading supply chain excellence, which they leveraged to become the largest retailer in the world. Both of these solutions were billion dollar investments in todays money.

The applications we’ve delivered have revolutionized information distribution both within and between organizations. The wave of data warehouse deployments triggered by Walmart’s success formed the backbone for category management. By providing suppliers with a direct feed from the data warehouse—a view of supply chain state all the way from the factory through to the tills—retailers were able to hand responsibility for transport, shelf-stacking, pricing and even store layout for a product category to their suppliers, resulting in a double digit rises in sales figures.

This ability to rapidly see and act on information has accelerated the pulse of business. What used to take years now takes months. New tools such as Web 2.0 and pervasive mobile communications are starting to convert these months into week.

Take the movie industry for example. Back before the rise of the Internet even bad films could expect a fair run at the box-office, given a star billing and strong PR campaign too attract the punters. However, post Internet, SMS and Twitter, the bad reviews have started flying into punters hands moments after the first screening of a film has started, transmitted directly from the first audience. Where the studios could rely a month or of strong returns, now that run might only last hours.

To compensate, the studios are changing how they take films to market; running more intensive PR campaigns for their lesser offerings, clamping down on leaks, and hoping to make enough money to turn a small profit before word of mouth kicks in. Films are launched, distributed and released to DVD (or even iTunes) in weeks rather than months or years, and studios’ funding, operations and the distribution models are being reconfigured to support the accelerated pace of business.

While the pulse of business has accelerated, enterprise technology’s pulse rate seems to have barely moved. The significant gains we’ve made in technology and methodologies has been traded for the ability to build increasingly complex solutions, the latest being ERP (enterprise resource planning) whose installation in a business is often compared to open heart surgery.

The Diverging Pulse Rates of Business and Technology

This disconnect between the pulse rates of business and enterprise technology is the source of our struggle. John Boyd found his way to the crux of the problem with his work on fighter tactics.

John Boyd—also know as “40 second Boyd”—was a rather interesting bloke. He had a standing bet for 40 dollars that he beat any opponent within 40 seconds in a dog fight. Boyd never lost his bet.

The key to Boyd’s unblemished record was a single insight: that success in rapidly changing environment depends on your ability to orient yourself, decide on, and execute a course of action, faster than the environment (or your competition) is changing. He used his understanding of the current environment—the relative positions, speed and performance envelopes of both planes—to quickly orient himself then select and act on a tactic. By repeatedly taking decisive action faster than his opponent can react, John Boyd’s actions were confusing and unpredictable to his opponent.

We often find ourselves on the back foot, reacting to seemingly chaotic business environment. To overcome this we need to increase the pulse of IT so that we’re operating at a higher pace than the business we support. Tools like LEAN software development have provided us with a partial solution, accelerating the pulse of writing software, but if we want to overcome this challenge then we need to find a new approach to managing IT.

Business, however, doesn’t have a single pulse. Pulse rate varies by industry. It also varies within a business. Back office compliance runs at a slow rate, changing over years as reporting and regulation requirements slowly evolve. Process improvement and operational excellence programs evolve business processes over months or quarters to drive cost out of the business. While customer or knowledge worker facing functionality changes rapidly, possibly even weekly, in response to consumer, marketing or workforce demands.

Aligning technology with business

We can manage each of these pulses separately. Rather than using a single approach to managing technology and treating all business drivers as equals, we can segment the business and select management strategies to match the pulse rate and amplitude of each.

Sales, for example, is often victim of an over zealous CRM (customer relationship management) deployment. In an effort to improve sales performance we’ll decide to role out the latest-greatest CRM solution. The one with the Web 2.0 features and funky cross-sell, up-sell module.

Only of a fraction of the functionality in the new CRM solution is actually new though—the remainder being no different to the existing solution. The need to support 100% of the investment on the benefits provided by a small fraction of the solution’s features dilutes the business case. Soon we find ourselves on the same old roller-coaster ride, with delivery running late,  scope creeping up, the promised benefits becoming more intangible every minute, and we’re struggling to keep up.

There might be an easier way. Take the drugs industry for example. Sales are based on relationships and made via personal calls on doctors. Sales performance is driven by the number of sales calls a representative can manage in a week, and the ability to answer all of a doctor’s questions during a visit (and avoid the need for a follow-up visit to close the sale). It’s not uncommon for tasks unrelated to CRM—simple tasks such as returning to the office to process expenses or find an answer to a question—to consume a disproportionate amount of time. Time that would be better spent closing sales.

One company came up with an interesting approach. To support the sales reps in the field they provided them with the ability to query the team back in the office, answering a clients question without the need to return to head office and then try to get back in their calendar. The solution was to deploy a corporate version of Twitter, connecting the sales rep into the with the call center and all staff using the company portal via a simple text message.

By separating concerns in this way—by managing each appropriately—we can ensure that we are working at a faster pace than the business driver we supporting. By allocating our resources wisely we can set the amplitude of each pulse. Careful management of the cycles will enable us to bring business and technology into alignment.

Tags: , , , , , , , , , , , , , , , , , , ,

What we’re doing today is not what we did yesterday

2009/05/22 in Business-Technology | 1 comment

Telxon

Telxon hand unit

The business of IT has changed radically in the last few years. Take Walmart for example. In the 80s Walmart laid the foundations for its future growth by fielding a supply chain data warehouse. The insight the data warehouse fueled their amazing growth to become the largest retailer in the world. However, our focus has moved on from developing applications. More recently Walmart fielded the Telxon, a barcode scanner with a wireless link to the corporate back-end. This device is the front end of a distributed solution which has let Walmart devolve buying decisions to the team walking the shop floor.

For a long time IT departments have defined themselves by their ability to deliver major applications into the enterprise. CRM, MRP, even ERP; all the three letter acronyms. For a long time this has been the right thing to do. Walmart’s data warehouse, to return to our example, was a large application which was a significant driver in the company’s outlier performance for the next couple of decades.

The world has changed a lot since that data warehouse went operational. First the market for enterprise applications grew into the mature market we see today. If you have a well defined problem—an unsupported business activity—then a range of vendors will line up to provide you with off-the-shelf solutions. Next we saw a range of non-technology options emerge, from business process outsourcing (BPO) and leveraging partnerships, through to emerging software-as-a-service (SaaS) solutions.

What used to be a big problem—fielding a large bespoke (or even off-the-shelf) application—has become a (relatively) small one. Take CRM (customer relationship management) as one example. What was a multi-year project requiring an investment of tens of millions of dollars to deploy a best-of-breed on-premises solution, has become a few million dollar and a matter of months to field SaaS solution. And the SaaS solutions seem to be pulling ahead in the feature-function war; Salesforce.com (one of the early SaaS CRM solutions) is now seen as the market leader (check with your favorite analyst).

Nor has business been standing still while technology has been marching forward. The productivity improvements provided by the last generation of enterprise applications have created the time and space for business stakeholders to solve more difficult problems. That supply chain solution Walmart deployed that was the first of many, automating most (if not all) of the mundane tasks across the supply chain. Business process methodologies such as LEAN (derived from the Toyota Production System) and Six Sigma (from GE) then rolled through the business, ripping all the fat from our supply chains as they went past. The latest focus has been category management: managing groups of product as separate businesses and, in many chases, handing responsibility for managing the category back to the supplier.

Which brings us back to the Telxon. If we’ve all been on the same journey—fielding a complete set of applications, optimizing our business processes, and deploying the latest, best practice, management techniques—then how do we differentiate? Walmart realized that, all things being equal, it was their ability to respond to supply chain exceptions that would provide them with an edge. As a retailer, this means responding to stock-outs on the shop floor. The only way to do this in a timely manner is to empower the people walking the floor to make a procurement decision when they see fit. Walmart’s solution was the Telxon.

The Telxon is an interesting device as it reveals an astonishing amounts of information: the quantity that should be on the shelf, the availability from the nearest warehouse, the retail price, and even the markup. It also empowers the employee to place an order for anything from a pallet to a truck-load.

Writer

Writer Charles Platt during his stint as a Wal-Mart employee in Flagstaff, Ariz.

As one journalist found:

We received an inspirational talk on this subject, from an employee who reacted after the store test-marketed tents that could protect cars for people who didn’t have enough garage space. They sold out quickly, and several customers came in asking for more. Clearly this was a singular, exceptional case of word-of-mouth, so he ordered literally a truckload of tent-garages, “Which I shouldn’t have done really without asking someone,” he said with a shrug, “because I hadn’t been working at the store for long.” But the item was a huge success. His VPI was the biggest in store history—and that kind of thing doesn’t go unnoticed in Arkansas.

Charles Platt, Fly on the Wall (7th Feb 2009), New Your Post

Clearly the IT world has moved on since that first data warehouse went live in Arkansas. Enterprise applications have been transformed from generators of competitive advantage into efficient sources of commodity functionality. Technology’s ability to create value should be focused on how we effectively support knowledge workers and the differentiation they create. These solutions only have a passing resemblance to the application monoliths of the past. They’re distributed, rather than centralized, pulling information from a range of sources, including partner and public sources. They’re increasingly real time, in the Twitter sense of the term, pulling current transactional data in as needed rather than working from historical data and relying on overnight ETLs. They’re heterogeneous, integrating a range of technologies as well as changes in business processes and employee workplace agreements, all brought together for delivery of the final solution. And, most importantly, they’re not standalone n-tier applications like we built in the past.

But while the IT world has moved on, it seems that many of our IT departments haven’t. Our heritage as application factories has us focused on managing applications, rather than technology, actively preventing us from creating this new generation of solutions. This behavior is ingrained in our organizations, with a large number of architects through project managers to senior management measuring their worth by the size of the project (in terms of CAPEX and OPEX required, or head count) that they are involved in, with the counter productive behavior that this creates.

In a world where solutions are shrinking and becoming more heterogeneous (even to the extent of becoming increasingly cross discipline) our inability to change ourselves is the biggest thing holding us back

Tags: , , , , , , , , , , , , , , , , ,

Applications let us differentiate, not!

2009/02/15 in Business-Technology, IT Strategy, Mailing List | No comments

Being involved in enterprise IT, we tend to think that the applications we build, install and maintain will provide a competitive advantage to the companies we work for.

Take Walmart, for example. During the early 80s, Walmart invested heavily in creating a data warehouse to help it analyze its end-to-end supply chain. The data was used to statically optimize Walmart’s supply chain, creating the most efficient, lowest cost supply chain in the world at the time. Half the savings were passed on to Walmart’s customers, half whet directly to the bottom line, and the rest is history. The IT asset, the data warehouse, enabled Walmart to differentiate, while the investment and time required to develop the data warehouse created a barrier to competition. Unfortunately this approach doesn’t work anymore.

Fast forward to the recent past. The market for enterprise applications has grown tremendously since Walmart first brought that data warehouse online. Today, applications providing solutions to most business problems are available from a range of vendors, and at a fraction of the cost required for the first bespoke solutions that blazed the enterprise application trail. Walmart even replaced that original bespoke supply chain data warehouse, which had become something of an expensive albatross, with an off-the-rack solution. How is it possible for enterprise applications to provide a competitive advantage if we’re all buying from the same vendors?

One argument is that differentiation rests in how we use enterprise applications, rather than in the applications themselves. Think of the manufacturing industries (to use a popular analogy at the moment). If two companies have access to identical factories, then they can still make different, and differentiated, products. Now think of enterprise applications as business process factories. Instead of turning out products, we use these factories to turn out business processes. These digital process factories are very flexible. Even if we all start with the same basic functionality, if I’m smarter at configuring the factory, then I’ll get ahead over time and create a competitive advantage.

This analogy is so general that it’s hard to disagree with. Yes, enterprise applications are (mostly) commodities so any differentiation they might provide now rests in how you use them. However, this is not a simple question of configuration and customization. The problem is a bit more nuanced than that.

Many companies make the mistake that customizing (code changes etc) their unique business processes into an application will provide them with a competitive advantage. Unfortunately the economics of the enterprise software market mean that they are more likely to have created an albatross for their enterprise, than provided a competitive advantage.

Applications are typically parameterized bespoke solutions. (Many of the early enterprise applications were bespoke COBOL solutions where some of the static information—from company name through shop floor configuration—has been pushed into databases as configuration parameters. ) The more configuration parameters provided by the vendor, the more you can bend the application to a shape that suits you.

Each of these configuration parameters requires and investment of time and effort to develop and maintain. They complicate the solution, pushing up its maintenance cost. This leads vendors to try and minimize the number of configuration points they provide to a set of points that will meet most, but not all customers’ needs. In practical terms, it is not possible to configure an application to let you differentiate in a meaningful way. The configuration space is simply too small.

Some companies resort to customizing the application—changing its code—to get their “IP” in. While this might give you a solution reflecting how your business runs today, every customization takes you further from a packaged solution (low cost, easy to maintain, relatively straight forward to upgrade …) and closer to a bespoke solution (high cost, expensive to maintain, difficult or impossible to upgrade). I’ve worked with a number of companies where an application is so heavily customized that it is impossible to deploy vendor patches and/or upgrades. The application that was supposed to help them differentiate had become an expensive burden.

Any advantage to be wrung from enterprise IT now comes from the gaps between applications, not from the applications themselves. Take supply chain for example. Most large businesses have deployed planning and supply chain management solutions, and have been on either the LEAN or Six Sigma journey. Configuring your planning solution slightly differently to your competitors is not going to provide much of an edge, as we’re all using the same algorithms, data models and planning drivers to operate our planning process.

Most of the potential for differentiation now lies with the messier parts of the process, such as exception management (the people who deal with stock-outs and lost or delayed shipments). If I can bring together a work environment that makes my exception managers more productive than yours—responding more rapidly and accurately to exceptions—then I’ve created a competitive advantage as my supply chain is now more agile than yours. If I can capture what it is that my exception managers do, their non-linear and creative problem solving process, automate it, and use this to create time and space for my exception managers to continuously improve how supply chain disruptions are handled, then I’ve created a sustainable competitive advantage. (This is why Enterprise 2.0 is so exciting, since a lot of this IP in this space is tacit information or collaboration.)

Simply configuring an application with today’s best practice—how your company currently does stuff—doesn’t cut it. You need to understand the synergies between your business and the technologies available, and find ways to exploit these synergies. The trick is to understand the 5% that really makes your company different, and then reconfiguring both the business and technology to amplify this advantage while commoditizing the other 95%. Rolls-Royce (appears to be) a great example of getting this right. Starting life as an manufacturer of aircraft engines, Rolls Royce has leveraged its deep understanding of how aircraft engines work (from design through operation and maintenance), reifying this knowledge in a business and IT estate that can provide clients with a service to keep their aircraft moving.

Tags: , , , , , , , , , , ,

Newer entries »

© 2010-2012 Peter Evans-Greenwood All Rights Reserved