Do these lamentations sound familiar? The unfortunate fact is that many companies feel they are held hostage by their information systems: They can be unreliable and overly complex, not suited to the business needs, while consuming vast resources to purchase, implement, and maintain.

Furthermore, business managers are often expected to accept responsibility for systems they don’t understand, can’t manage, don’t trust, and possibly even fear. It would be unacceptable for the production, marketing, sales, or finance departments to operate in this fashion; why should IT be any different?

Fortunately, IT has reached a significant evolutionary milestone, and we now have the opportunity to change this untenable condition. Since the birth of the computer industry change has been revolutionary, with each generation effectively replacing the last, despite expensive attempts to integrate old and new. With an established foundation of standards in hardware, communications, software, and database technologies, change can now be evolutionary. And with the maturity and consolidation of the ERP industry, an enterprise application foundation may be established upon which we can build for the future. We can now strive for the continuous improvement, rather than the continuous replacement, of our enterprise information systems.

In the first ten chapters of this book we have explored how IT may aid in the continuous improvement of a Lean Enterprise. In this final chapter we turn the tables, exploring how continuous improvement, and the lessons learned from decades of Lean Manufacturing evolution, may enhance the performance and longevity of IT. To understand this new approach to managing change we begin with a brief examination of the past; then we’ll explore the future of Lean IT. This chapter is thus organized into four sections:

The Challenges of Traditional IT—explores some of the pitfalls of traditional IT change management practices.
What is Lean IT?—examines the tools of Lean IT, the significance of an enterprise software ecosystem, and lessons learned from Lean Manufacturing.
Guiding Change with Lean IT—explains why information technology is not the solution, merely a tool in the hands of people to improve processes.
Applying Lean IT to the Lean Enterprise—illustrates how Lean IT and the Lean Enterprise may work together for sustained continuous improvement.

Pain, Chaos, and Project Failure
Although they won’t readily admit this, and you won’t see this word appearing in any glossy brochures or fancy websites, IT sales and marketing professionals spend considerable time talking about their customer’s pain. What is it? Why does it happen? What does it cost? Has the pain reached a critical threshold to stimulate a buying decision? If not, what can they do to elevate this perception? Who is the decision-maker that is motivated to relieve this pain? What is it worth to him or her? And most importantly, how can they position their “solution” to eliminate this pain? Astute sales and marketing professionals know that we all live with pain—it’s simply a fact of existence. They understand that people are able to ignore most pain for long periods of time with a variety of clever avoidance techniques. They also know that when pain reaches a critical point, people react quickly and often through emotion. Being at the right place and time with a quick remedy for the pain is often more important than having a legitimate and long-term solution to the problem. In fact, most business problems are solved by changes in policy and process enacted by people—the information technology is simply a tool to facilitate the change.

But because it is human nature to wish for the easy way out, the unfortunate fact is that many reactive information technology “solutions” create new problems as they solve the old ones. In fact, a new solution may introduce more pain than it relieves, or it may shift the pain from one part of the organization to another. In any case, the introduction of a new information technology often creates a new cycle of pain that leads to yet more information technology acquisition.

IT is all about managing change, and change can be unpredictable. The APICS magazine article “Give Change a Chance” observes:

IT projects create value by creating organizational change. The greater the scope and impact of the technology, the more change it creates. ERP touches every area of the company, and many people don’t necessarily perceive a problem in their own area. Why is change—and workers’ natural inclination to resist it—so prevalent in most ERP implementations? It’s the nature of the beast, both the ERP beast and the human one. Bring those two beasts together and you’ve got what could be a volatile, expensive, and time-consuming situation.213 IT projects are indeed volatile, expensive, time-consuming ...and risky. The Standish Group has been conducting surveys on all types of IT projects since 1994. Their research, published in their annual CHAOS report, reveals that in 2001 a staggering 31.1% of projects were cancelled before completion. Further results indicate 52.7% of projects cost 189% or more of their original estimates. The proportion of successful projects completed on time and on budget is only 16.2%. And, even when these projects are completed, many are a mere shadow of their originally specified requirements. Projects completed by the largest American companies reported achieving only 42% of the originally proposed features and functions; and while smaller companies [and smaller projects] do better, there is still a pretty large gap.214 The pain of failed IT projects is felt by large and small enterprises alike, but it is the failures of the largest that have become legends. Many well-publicized ERP and SCM failures have cost large enterprises hundreds of millions of dollars. The widely reported losses include only immediate revenues, project costs, and market valuation, but the damages extend beyond dollar figures to the immeasurable loss of customers, employees, and reputation. Perhaps large enterprises can recover from hits like these, but small and medium-sized companies cannot. In addition to the losses suffered by individual companies, there is a massive economic impact from poor enterprise software quality, according to a The Economist article titled “Managing Complexity”: A 2002 study by America’s National Institute of Standards (NIST), a government research body, found that software errors cost the American economy $59.5 billion annually. Worldwide, it would be safe to multiply this figure by a factor of two. So who is to blame for such systematic incompetence? THE CHALLENGES OF TRADITIONAL IT 357 Cost overruns and delays are common in numerous industries—few large infra-structure projects, for instance, are completed either on time or on budget. But it is peculiar to software that billions of dollars can be spent only for nothing useful to result.215 Large IT projects are dangerous territory, introducing significant business risks and seducing us with high expectations for new technology, while con-founding us with assertions of intangible ROI. The practice of IT is often permeated with a sense of magic and mystery, where businesspeople suddenly find themselves at a loss of confidence. And when large and complex information technology projects meet with the culture and unpredictability of organizations and people, they often fail. The Traditional Approach to Enterprise Software Management Let’s examine the traditional methods of how a company selects, implements, and maintains enterprise software, and later we’ll build on these concepts to show how a company can achieve Lean IT. An enterprise must first match their needs against the capabilities of enterprise software, and it is commonly accepted wisdom that most horizontal* ERP applications should satisfy 80% to 90% of the requirements of any enterprise. Depending on how sophisticated and unusual the operations, they may call for some customization, or the integration of specialized vertical software, to exceed 95% of these requirements. Beyond 95% most find there is a decreasing marginal cost/benefit for a software application investment, and often the gap (the remainder of unfulfilled requirements) is satisfied by a mixture of process redesign, manual work, offline spreadsheets, and disconnected desktop databases. Herein lies a vital question that many fail to ask: Are the unique requirements in the ‘95% and above’ zone (that are not satisfied by an off-the-shelf software application) simply remnants from obsolete legacy systems and outmoded practices, or are they what create distinction and real competitive advantage for the enterprise? The answer to this question may determine whether these practices deserve investment or should be thrown out with the legacy system bathwater. How do we arrive at this measure of 85%, 90%, or 95% fit to our requirements? First, we must identify those requirements; approaches can include extensive investigation by consulting firms using elaborate requirements management software tools and checklists, or internally led initiatives with varying degrees of formality. In any case, let’s assume that we have identified a list of 1000 specific software capabilities needed to run the business, weighted by importance. We’ll discuss the practical implications of managing such a large 358 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS * A ‘horizontal’ application is generalized software designed for most types of businesses, whereas a ‘vertical’ application is designed for a specific industry or purpose. list in a moment, but for now we must develop a plan for the implementation of these capabilities when we install the new system. In our practice we rarely see a company that can implement all of its requirements in a single “big-bang” implementation. Even those that claim to implement in this way choose to leave a few low-priority capabilities on the table to address later—thus even so-called big-bang implementations are phased to some degree. Let’s assume for this example that a company selects an application that satisfies 90% of its requirements (900 out of 1000 from their list)—are they going to realize the full 90% potential of the application after the first phase of implementation? Probably not. Can they get by with fewer than 50% of these capabilities? Again, probably not. So what results is a set of necessary and target zones somewhere between 50% and 90% of their requirements, with the 90% line representing the system potential.216 The necessary zone defines those capabilities the enterprise should have to run the business effectively, and the target zone indicates the nice-to-have capabilities that will boost performance. There is also a danger zone below which the enterprise cannot function; these zones are illustrated in Figure 11-01. Should an enterprise lack the skills or resources to rise above the necessary zone and into the target zone, it may be perpetually trapped by manual workarounds and disintegrated systems that compromise business effectiveness. And if the meager capabilities fall into the danger zone, the application is probably doing more harm than good. Traditionally a project team should select (or develop) a new application that provides a path to the target zone, implementing the application in phases. In the example illustrated in Figure 11-02, this particular enterprise intends to implement phase 1 beginning with 65% of the functional requirements, proceeding to phase 2 implementing another 20%, which results in an 85% fit. Finally they plan to creep over 90% with a combination of incremental refinements to the software and processes, supplemented by spreadsheet and manual workarounds. Following this rigorous methodology, companies may succeed with the implementation, delivering a functional application. According to the Standish THE CHALLENGES OF TRADITIONAL IT 359 100% 80% 60% 40% 20% Danger Zone Target Zone Necessary Zone Fit to Requirements System Potential Figure 11-01. Software Fit Zones Group CHAOS report, however, quite often this story does not have a happy ending. There are many ways a company can be trapped by the complexity of an IT project and become a statistic. For example, a company may struggle with a poor application, or perhaps an adequate application implemented poorly, for years. One day the pain becomes too great and they react, selecting another application that they believe will suit their needs better—hoping for a target of 80–90% fit. But they don’t do a good job identifying their requirements, because they lack the time, the skills, or a vision for the future; they simply define their requirements as an extension of the capabilities of their current application. This company chooses an application that can provide 80% of the requirements they can articulate. Because the company is in crisis, struggling with their current application while trying to keep the business running, they decide to implement 70% of the system potential as quickly as possible. Unfortunately, the project soon begins taking longer and costing more than expected. As they learn of new capabilities they did not consider when defining their initial requirements, they may increase the scope during the project. The time-line and budget slip further. As they continue falling behind they begin to hurry, devoting insufficient attention to training and testing. As a result of this haste, many unanticipated problems arise during go-live. By now the implementation has become a chaotic dash for the finish line, straining to keep the business running while fighting brush fires in every direction. Finally someone throws “the switch” and the new system is live. However, because not all the desired functions work as planned, they end up achieving only 60% of their new system potential. Everyone in the company is exhausted, the project team is disenchanted, and management is frustrated. The project did not go well, and no one is looking forward to phase 2. 360 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS 100% 80% 60% 40% 20% Phase One Phase Two Incremental Improvements Implement and Stabilize High Priority Improvements Continuous Improvement Time Fit to Requirements 90% System Potential Figure 11-02. Phased Implementation Plan No surprise—phase 2 never happens. In addition, the business requirements continue to change, and while the vendor issues updates that improve the application potential, the use of the application is not improved. The effort to upgrade the software is a substantial project in itself, and is thus avoided, so the software upgrades stay on the shelf. Because of the lack of training and proper user documentation, combined with employee turnover, system performance continues to degrade, until one day someone hollers, “This software doesn’t work, we should replace it!” And the cycle begins again. This unfortunate drama is illustrated in Figure 11-03. Whatever the specific causes, ultimately this is a failure of change management. The business processes and the underlying systems are not continuously improved, and the situation follows the natural path of entropy. To manage change in the traditional way, the team must manage the multitude of issues and requirements that arise during an IT project. During the early discovery phases of a project, while the team is conducting interviews, process analyses, mapping sessions, etc., hundreds or even thousands of distinct issues will arise—problems, questions, variables—that lead to specific requirements. Some newly discovered issues will be critical, whereas others will not be. It is important, however, to record all issues and requirements as soon as they are discovered, to prevent them from becoming lost. At some point, this list develops into a prioritized set of issues and requirements that may be used to select software, to direct the phases of its implementation, and to measure the results. Earlier we suggested a hypothetical list of 1000 requirements. In fact, there may be many more, but it is not necessary to manage all of them with equal diligence. Here is a traditional approach that focuses effort on the most important issues: THE CHALLENGES OF TRADITIONAL IT 361 100% 80% 60% 40% 20% Phase One Fit to Requirements Year 5 – 7 Implement and Frustrate Neglect System Failure and Premature Replacement Planned Phase Two Planned Future Phases Year 1 Figure 11-03. Train wreck: the path to premature application replacement • Select a tool to manage the issues and requirements. Although sophisticated software tools are available for this job, a simple spreadsheet or desktop database may suffice for a smaller project. • Prioritize the issues and requirements, and carefully manage the top 10% to 20%: • During the selection of software these key requirements are called critical differentiators, because they distinguish one application’s suitability from another. • During the implementation, as well as ongoing maintenance of the system, these key issues should be prioritized by the impact they will have on the business. Using this approach, the project team may whittle a list of 1000 down to one or two hundred critical issues and requirements; these may be assigned to various subproject teams, where the volume becomes manageable. Because these issues and requirements are managed in a database, they can roll up into a consolidated list that is used to measure overall system performance by percentage of fit to total requirements. The Seven-Year Itch Despite the fact that the traditional change management tools and methods just described have existed for many years, enterprise software applications are replaced with surprising frequency. In particular, it is well known that ERP systems historically have a lifetime of no more than five to seven years. And this frequent replacement cycle of individual applications is only the tip of the iceberg; the fact is that most enterprises maintain several critical enterprise software applications, each with their own challenging implementation and life cycle management issues. Each of these applications must also be integrated and managed collectively to support the smooth flow of processes and value streams. As the statistics suggest, the chances for success in the face of such instability and complexity aren’t encouraging. The enterprise software industry clearly knows about this five to seven year replacement cycle; in fact, it has come to depend on it. Doug Burgum, formerly CEO of Great Plains Software, is now Senior Vice President of Microsoft Business Solutions. In 2002, Red Herring, a Silicon Valley technology magazine, asked Burgum when he expected the ERP market to rebound: He not only skips the ‘poor visibility’ jargon, he names specific years. “This market is going to get a lot stronger in ¢04, ¢05 and ¢06,” says Burgum. Call it the Y2K echo or the seven-year itch. Whatever the name, it’s the cornerstone of Microsoft’s stealthy plan to storm the business applications market. In the late 90’s, companies loaded up on business apps to upgrade systems that couldn’t withstand the year 2000 date change. Since then, sales have nose-dived. But companies typically refresh their application software about every seven years; hence Mr. Burgum’s prediction.217 362 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS Following the Y2K boom and bust, the enterprise software market in general, and ERP suppliers in particular, have seen some hard times. In late 1999 ERP sales suddenly plummeted, like someone turning off a light switch. In the post-Y2K aftermath, the number of viable ERP vendors has dwindled from hundreds to a few dozen. Some of the ERP products simply disappeared, leaving their customers racing to find a replacement. Many more were acquired by ERP software companies bent on acquisition* to capture the ongoing maintenance revenue stream and customer base. These parent companies are consolidating multiple ERP products into a portfolio, hoping to leverage their large customer base and service revenue stream to fund the development of the “next generation” of ERP system. With that said, the likelihood of the emergence of many completely new ERP systems is very unlikely for two reasons: 1) ERP software has become extremely broad and complex, creating a significant barrier to entry, and 2) the ERP growth boom is over, and most publishers are now incrementally improving their systems primarily funded by ongoing maintenance and professional service revenue streams. The top tier ERP vendors are striving to move their complex systems down-market because most of their largest customers have long since purchased ERP systems. After garnering 50% or more of the global ERP market for large enterprises, SAP’s revenue growth has shifted from product sales to professional services. But what about the next seven-year replacement cycle? If anyone has the muscle to introduce a revolutionary new ERP system, wouldn’t it be Microsoft, with their +$3 billion annual R&D budget? Even Microsoft’s Project Green, their initiative to develop a comprehensive new ERP system to replace their assortment of acquired systems to meet this next replacement cycle, was placed on the back burner in 2004. An InfoWorld article, “Microsoft Puts Brakes on Next Business Apps”, states that: Microsoft plans to build completely new business applications on a single code base that will eventually replace its existing offerings. Microsoft originally had planned to ship the first results of Project Green as early as late 2004. Because the first products now won’t be out until 2008 at the earliest, the number of developers assigned to Project Green is being reduced from 200 to 70. “We have made a decision to move resources off Green and back on the core product lines to strengthen those product lines because we realize now that it is going to take much longer,” Burgum told a federal court in testimony in the U.S. Department of Justice’s case to block Oracle’s takeover of PeopleSoft.218 Could it be that even the powerful Microsoft is experiencing difficulty managing the overwhelming complexity of several ERP systems? Then in THE CHALLENGES OF TRADITIONAL IT 363 * These hungry ERP acquisitors include SSA Global, Epicor, Infor Global Solutions, Sage Group PLC, Exact Software, Intuit, Microsoft, and Oracle. March 2005 Microsoft restated their strategy, suggesting that they would maintain the separate product lines for much longer, while investing in their enhancement with the latest developing technologies.219 We may expect Oracle to experience the same challenges as they assimilate PeopleSoft; shortly after the acquisition in early 2005 Oracle announced Project Fusion, the intent within three to four years to combine three massive ERP products (Oracle, PeopleSoft, and JD Edwards) into a unified code base 220 —a seemingly impossible feat. Have we arrived at a critical milestone in the evolution of the enterprise software industry, where managing complexity, and not the mixture of promise and chaos of emerging technology, is our greatest opportunity and nemesis? What does this mean to the company that is planning to purchase a new ERP system? What does it mean to a company striving to improve the one it already has? Is an enterprise destined to continue replacing its core enterprise system every seven years? This crisis of complexity does not just affect ERP systems; it’s a challenge that the entire IT industry must confront. The imperative question that results from all of this pain, chaos, cost, risk, complexity, and failure is this: If a manufacturing enterprise cannot compete in the global market without IT, then how can they make IT manageable? WHAT IS LEAN IT? Lean IT is practical, manageable, agile, and team-based, and it must add value to the enterprise. That sounds easy enough, but don’t expect that achieving it will be. Jim Womack speaks of the natural inertia of human nature working against the idea of Lean IT: I’m not naive about getting the world to embrace Lean information management. We’re not quite yet at the end of thinking that more information is always better and that if we just had all possible information, perfect algorithms, and lightening fast central processors, life would be easy. For example, despite 50 years of evidence that this isn’t true, we are now embarking on a new experiment with RFID in which every item in every process can be tracked individually.221 So how do we compensate for the natural tendencies toward over-complication, over-automation, and rigidity, to realize the benefits of Lean IT? Recall that in Chapter 1 we contrasted the rigidity and long-range planning of traditional IT with the agility of Lean thinking; this is shown again in Figure 11-04. For IT to become Leaner it must: • Manage change incrementally and continuously • Organize and execute with cross-functional teams 364 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS?• Measure performance in a holistic and relevant manner • Encourage the general development and sharing of knowledge • Focus education and improvement initiatives on processes and value streams • Measure success by speed and flexibility, without causing chaos • Be accepted and used properly by the user community • Enable users to be more effective at their value-added activities Lean IT is attainable, but it requires similar effort and resourcefulness as an enterprise striving to transform its traditional manufacturing operations to Lean. The fact that we’re dealing with computers rather than drill presses and assembly lines makes little difference. Michael Hugos, author of Building the Real-Time Enterprise: An Executive Briefing, stresses that: IT can be a big part of what makes a company agile, or it can be a big part of what makes it a clumsy, slow-moving bureaucracy. One of the major determinants of this is the way your company answers the question, “Should we build our systems fast, or should we build them good?” The agile answer is to build them fast and good enough for now. What does “good enough for now” mean? In a fast-paced, competitive world, opportunities arise quickly and then either fade away or evolve into something else. The advantage goes to companies that can develop systems that are ready when the business needs them and don’t cost more than the opportunity is worth. WHAT IS LEAN IT? 365 Attribute Lean Traditional IT Change Management Organic, incremental and continuous Engineered and planned large events Organization Cross-functional teams Central command and control Measures Top-down and bottom-up performance measures linking improvement initiatives to strategic goals Cost containment and uptime Knowledge Management Generalization Specialization Education Process focus Task focus Definition of Success Speed and Flexibility Stability Figure 11-04. The attributes of Lean and traditional IT The best way to do this is to create systems out of combinations of simple building blocks and repeatable processes.222 On our path to Lean Manufacturing we must transform the factory with flexible and standardized processes; similarly, to craft Lean IT we must develop agile and standardized software, development, integration, training, and support tools and methods. More importantly, however, to achieve Lean Manufacturing we must change the way we think—new attitudes accompanied by effective change management and continuous improvement practices are equally vital to the development of Lean IT. First we’ll explore the tools of Lean IT, then in the next section we’ll turn our attention to the essential issues of change management and continuous improvement. The Future of Enterprise Software IT professionals now have the opportunity to do more than just keep their heads above water. This change from revolutionary to evolutionary, from continuous replacement to continuous improvement, offers a real opportunity not just to achieve a system’s potential but, more importantly, to continue improving upon it indefinitely. Gartner, who is known for spotting and naming emerging trends, has coined the term ecosystem for the new industry model of enterprise software, and ecosystem vendor for those large entities around which the supporting players cluster. ComputerWorld notes in the article “Gartner Sees Shift to Bite Size Business Software”: Gartner believes that makers of software [. . .] such as SAP, IBM, Oracle, and Microsoft must carve smaller pieces out of their large packages to make it possible to adapt them more quickly. And they must also make sure that those pieces can also plug into competing products, as companies cherry-pick more specialized programs from different vendors but want to stitch them together seamlessly. This increases the agility of the software because it’s now easier to arrange the process or determine who will actually perform each step in the process. In this way, business process is shifting IT projects from large multi-year marathons to rapid deployment gap applications [incrementally improving capabilities up to and beyond the 90% fit zone]. Instead of continuing to sell comprehensive products, software makers are trying to create what Gartner calls “ecosystems”—realms where they shape the environment and create frameworks and standards within which others operate. Increasingly a [software] company is destined to become part of an ecosystem in order to survive. On the other hand, software buyers need to switch from one large purchasing decision to picking the right product for individual tasks.223 This ecosystem model suggests that enterprise software life cycles will lengthen and there will be fewer new entries into the marketplace for the core 366 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS enterprise systems: particularly ERP, and to a lesser degree CRM, PLM, APS, MES, WMS, and others. Why the distinction between ERP and all the others? As I described in Chapter 6, ERP is the backbone of enterprise software, the core around which all others integrate. The broad scope and complexity of an ERP system, although on one hand desirable, on the other hand is costly to implement. Once an ERP system is well-established, it is dreadful to replace because a mosaic of supporting applications have united around its framework; the entire ecosystem now relies on the survival of its host. With the continuing advance of integration technologies, these host software vendors strive for evolutionary (not revolutionary) advances, so they do not risk losing their existing customer base. In this new model the ERP system now sets the pace of evolution through incremental functional and technical changes—the upgrade paths and future development cycles of the entire ecosystem depend on their plans. Ideally the entire ecosystem will evolve in a smooth fashion, ensuring that the core ERP system will persist, gathering new developments and partners that emerge as markets shift and requirements change. According to Ray Lane, former President of Oracle, speaking before 1100 software industry executives at the illustrious Software 2004 conference in Silicon Valley, “Software innovation on a grand scale is dead.” The chances of revolutionizing the software market today, on the scale of what SAP or Siebel have done, are slim. Consolidation rules. The real change taking place is in software as a service: delivering applications—faster, cheaper, and more nimble—to an enterprise’s Web Services-based architecture, rather than offering packaged software.224 This new ecosystem model means that companies can no longer hope to solve their problems with the replacement of their ERP software every few years. Of course they can try, but with the remaining ERP suppliers improving their products to the point where they are functionally similar, what’s the point? Because the enterprise software market has changed, so must the approach to selection of a partner. Once there were hundreds of ERP vendors competing for business; now there are only a handful of viable candidates. This suggests a thorough consideration of the partner as well as the product. An enterprise should ask: Do we trust these people? Do we buy in to their vision for business and technology advancement? Forget the seven-year replacement cycle, this is a long-term marriage. The software function, look, and feel that evolves ten years from now may be quite different, but we’ll still have the same partner. The bottom line is that an enterprise should expect to use its ERP system for many years to come, so the continuous improvement of the entire enterprise software ecosystem surrounding the ERP core is essential. Recall Michael Hugos’ earlier suggestion in “Agility Is a Frame of Mind”, “The advantage goes to companies that can develop systems that are ready when the business needs them and don’t cost more than the opportunity is worth. The best way to do this is to create systems out of combinations of simple building WHAT IS LEAN IT? 367 blocks and repeatable processes.”225 This is the very essence of what Web Services and Service-Oriented Architectures offer, and how the enterprise software ecosystem may be created. The Role of Web Services and Service-Oriented Architectures In the Lean IT model, although the core components of the ERP system provide the stable structure and transactional framework for the enterprise, changes in requirements may be managed by implementing relatively small and standardized pieces—sometimes called components, objects, building blocks, or granules. This Lean change management approach is similar to an Assemble or Configure to Order production environment. Although there are strong competitive pressures to move quickly in this direction, these are counterbalanced by great industry inertia. Most ERP suppliers have been investing in components and Web Services for some time now, granularizing their systems to some degree. However, many of their organizational structures, consulting methodologies, licensing structures, maintenance policies, pricing, compensation, and revenue recognition models are still managed as a monolithic framework. Then there is the Open Source software movement, where the underlying source code and intellectual property are available to a community of developers and users. Open Source involves a rapid, communal, and democratic development approach with frequent interaction between developers and users. The popular Open Source principle of Free (capital F) software shows the characteristics of a social movement. Free software is accessible via a license that grants users permission, in perpetuity, to copy, modify, study, and distribute the software’s source code. It is a philosophy about the development, distribution, and accessibility of software, namely, the freedom involved to that end—Free does not refer to price.226 Whatever the underlying motivation, economics or social movement, Open Source is a rapidly growing phenomenon that commercial software publishers are being forced to confront and embrace. The article “Demand at the Fount for Open Source” argues that we are seeing early signs of a significant shift in how companies think about software development: [Within the Open Source community] the features of the software may literally be developed by a party other than the one that originally provided the software, and that development may actually be incorporated into the original source of the software itself. This means that if, for example, a company needs something from its Open Source software which is not supported, it can then develop or sponsor development for that functionality in the product. The functionality can further the growth of the product as a whole. Thus the software’s entire user base can benefit and the primary development team of the software may not have to devote as much in the way of resources to creating new functionality on its own. 368 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS Companies sponsor such development because they have the opportunity to get what they need at a lower cost, and via an efficient process. This development process signals a shift in how the software industry does business.227 The Open Source community proudly demonstrates their large-scale commercial viability, pointing to Amazon and Google, whose infrastructures are deeply rooted in Open Source. Erik Keller originally coined the term ERP while at Gartner, and is the author of Technology Paradise Lost. Keller predicts that the Open Source movement will cause a significant and irreversible disruption to the enterprise software industry: It used to be assumed that either you outsource a business process/application, build it yourself, or buy software for it. Open Source changes these assumptions dramatically, as it brings back the potential to build and own an application; or to blend methods by means of a consortium, in-house development, or contracting with offshore providers. Thus the economics of how IT gets deployed is turned on its head and is ready for reevaluation. Buyers of technology now have choice, and with that choice a large amount of bargaining leverage. This is one of the reasons why the software market has yet to recover to historical growth patterns. To cope with Open Source, many sellers of technology will need to switch their investment and revenue strategies from the front end of selling a piece of software to the back end of supporting a process. What a seller may lose in hardware or software license fees, it will need to pick up in long-term support contracts and consulting. These factors and the maturing landscape of Open Source products and initiatives will permit buyers to play software license vendors against Open Source service vendors, forcing margins and long-term pricing downward.228 The Open Source movement is gaining strength, with the major infrastructure players (including IBM, Hewlett Packard, Sun, Oracle, and perhaps even Microsoft) enthusiastically signing up. However, it is unlikely that the main-stream enterprise systems (ERP, CRM, PLM, and others) will be quickly replaced, because these massive applications represent many man-centuries of development. In fact, as ecosystem hosts, many enterprise software publishers are now embracing (or are being forced to embrace) the potential for Open Source component integration. As Gartner pointed out, the customer must select an ecosystem, then form a fluid relationship with its constituencies, adapting to changing requirements. In the future, many of the vital components of an enterprise architecture may be Free. Agile Software Development The use of these new tools, techniques, and relationship models lead to an approach called Agile Software Development. This approach reduces development lead time while improving flexibility, helping to avoid the massive software debacles experienced by large and small enterprises alike. Until now, WHAT IS LEAN IT? 369?complexity has been our biggest constraint to producing timely, flexible software tools. According to The Economist: There are five steps involved in creating a piece of software: enumerating the requirements; designing the program; actually writing the code; testing it; and then deploying it. Traditionally and naturally enough, this was seen as a sequential process. However, John Swainson [formerly in charge of software development for IBM Corporation, and now CEO of Computer Associates, one of the world’s largest software companies] points out that by the time an organization gets around to deploying a piece of software, its requirements have often already changed. This, he says, means that an “iterative” model, in which an organization continually cycles through the five phases, makes more sense than the traditional “waterfall” which puts them in sequence. The main principle of agile programming is that developers must talk to each other often, and that they must talk to the business people setting requirements equally often. Combine this with a short time-scale—ideally agile proponents seek to deliver a working bit of software every few weeks—and you have an accelerated, informal version of the iterative model. This means that no project can go on for years and produce nothing—a fatally flawed project will be caught sooner.229 Figure 11-05 contrasts the traditional waterfall approach to the iterative (spiral) model, where phases are much smaller in scope (measured in days rather than months), using smaller development teams and frequent interaction with the users, to deliver workable solutions faster. Requirements that are 370 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS Design Develop Test Implement Phase One Design Develop Test Implement Phase Two Design Develop Implement Test Phase One Phase Two Phase Three Figure 11-05. The waterfall vs. the spiral not prioritized for the current phase are set aside for a short while, until the next cycle comes along. The iterative development approach favors smaller projects, which means that development teams are not required to forecast requirements far into the future, so the system is able to quickly adapt to change. Furthermore, the teams themselves may be kept smaller and tightly focused. A fundamental challenge for a traditional software-development organization is Brook’s law*: Adding more programmers to a late project makes it later. More generally, Brook’s Law predicts that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. 230 In other words, several small teams work faster and better than one large team. The corollary to Brook’s Law happens to be one of my favorite resource management principles: Nine women cannot make a baby in a month. Agile software development replaces long, arduous phases with rapid and continuous improvement cycles. Requirements forecasting is reduced, lead times for delivery are shortened, waste is eliminated, and quality is improved. By the way, have you noticed that this is the same iterative diagram used to illustrate Dr. Deming’s PDCA cycle? And did I just say “continuous improvement cycles”? It’s beginning to sound like we’re a software factory, producing on an Assemble to Order basis. Work is pulled by real-time customer demand, utilizing concurrent product development methods, small teams, standardizing work, eliminating waste, resulting in reduced lead time, improved quality, and agility. This is the essence of Lean IT. GUIDING CHANGE WITH LEAN IT Technology is NOT the Solution The tools to support IT change management are important; but as we emphasized with Lean Manufacturing in Chapter 3, the tools are necessary but not sufficient. Just as Lean Manufacturing requires a fundamental change in thinking, Lean IT requires effective change management attitudes. Agility begins as a frame of mind. Despite what much sales and marketing literature gushes forth, information technology is just a tool, it is not “the solution.” To deliver value to the customer, Lean IT must aid in the solution of a business problem by developing effective and standardized procedures, thereby enabling continuous improvement. To get to the heart of the business problem, to find the controlling simplicity, the point of greatest leverage, we must identify and eliminate the constraint. According to the Theory of Constraints, we should begin with policy constraints, because they embody the habitual attitudes and behavior of the organization. In the latest installment of TOC novels, Necessary But Not GUIDING CHANGE WITH LEAN IT 371 * Frederick Brooks is author of The Mythical Man-Month. Sufficient co-authors Goldratt, Ptak, and Schragenheim emphasize that in order for IT-induced change to be effective, the policies (rules) of the organization must come first: “. . . now we install some new technology. Let’s assume successful installation occurs; the limitation has been diminished. But what happens if as part of the implementation of this new technology, we neglected to address the rules? What happens if we still operate with the old rules, the rules that assume the existence of the limitation?” “In that case, the rules themselves will impose a limitation,” Lenny says. “Exactly. And then what benefits will we gain from the new technology?” “I don’t know,” Lenny answers. “It depends on the technology and what it does. But I see your point. If we don’t also change the rules, we can be assured that we will not realize the full benefits.” Scott looks at the sky, still pretending to smoke his imaginary pipe. “You see, Watson, technology is a necessary condition, but it’s not sufficient. To get the benefits at the time that we install the new technology, we must also change the rules that recognize the existence of the limitation. Common sense.”231 This may be common sense; most people understand the old phrase garbage in/garbage out. If we invest in automating a broken process, we only speed up the creation of waste, while at the same time cementing the problems into place. But if this is common sense, then why do software implementation teams commit this blunder so often? Even when information technology appears to be focused upon the policies and processes of the organization, this may not lead to an effective or enduring solution. People must drive change. During a presentation titled “Run the Business, Grow the Business, and Improve the Capabilities,” Roger Brooks, President of Oliver Wight North America, illustrated the challenge of sustained change management with the diagram shown in Figure 11-06. 232 Brooks’ message is poignant: • A technology and process improvement solution that does not involve the hearts and minds of people leads to alienation, depersonalization, and turnover; all significant threats to sustained continuous improvement. • A technology and people solution that does not include process improvement simply automates chaos and inefficiency; this is the GIGO (garbage in/garbage out) principle. • A people and process improvement solution that does not include technology may indeed work just fine—information technology is not inevitable. A process should first be simplified before it is automated. But although a Lean Enterprise should initially focus on process improvement and simplification, continuous improvement efforts may eventually 372 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS lead to complexity through increased volume, velocity, and variety. The situation may then call for the skillful application of information technology. This three-way interdependence of people, process, and technology requires coordination, or as I prefer, “orchestration.” Coordination implies centrally planned and controlled behavior, whereas orchestration suggests a leader providing guidance, setting the pace, while encouraging individual creativity and inspiration. Orchestrating Change Through Project, Program, and Portfolio Management How does an enterprise manage change involving people, process, and technology? Through the Project Management Office, which orchestrates the disciplines of strategic planning, program and project management, project portfolio management, and system lifecycle management. The Project Management Office. Many organizations, even large ones, have a localized view of project management. Not only do large projects require dedicated, cross-functional teams, but many medium and large organizations GUIDING CHANGE WITH LEAN IT 373 PROCESS PEOPLE SWEET SPOT Frustration Automated Chaos Alienation Process and Technology without People Alienation and turnover Under-utilized systems People and Technology without Process Automated chaos and confusion Poor customer service People and Process without Technology Frustration and inefficiency High cost of operation TECHNOLOGY Figure 11-06. The three pillars of change may have dozens of projects running simultaneously (IT and other types) competing for scarce capital and human resources. Without central planning and management, these resource battles starve some projects while feeding others, the inevitable result is a number of failed (or at best underserved) projects. This suggests the need for not only central allocation and management of resources but a decision-making process to establish priorities. Any projects that do not justify sufficient resource commitments should be cancelled or delayed. How do we determine these priorities? They must be aligned with strategic goals and objectives. In their study on enterprise software project failures, the Boston Consulting Group found that initiatives based on a clear strategic vision had positive outcomes 53% of the time vs. only 22% for projects lacking such vision. The study concludes that smaller, more focused projects have better chances of success than broader ones, and companies should focus on “smaller, high-value chunks” of their business, where big returns can be gained from modest IT investments.233 The instrument required for such clear prioritization is called the Project Management Office (PMO), which performs both Program and Project Management activities, defined by the Project Management Institute: Project Management—is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. The work typically involves competing demands for scope, time, cost, risk, and quality; stakeholders with differing needs and expectations; and identified requirements. Operations and projects differ primarily in that operations are ongoing and repetitive whereas projects are temporary and unique. The project life cycle serves to define the beginning and the end of a project. Program Management—a program is a group of projects managed in a coordinated way to obtain benefits not available from managing them individually.234 Program management involves a collection of projects that are interrelated; they compete for shared resources while working toward shared goals. Programs and projects may involve a variety of participants and stakeholders from within and outside the boundaries of the enterprise, including providers of products and services, customers, suppliers, funding sources, regulatory agencies, and so on. Programs include multiple projects, and each project may include multiple phases and subprojects. The competition for resources can be intense, and the management of all of these interrelated parts requires great skill and proper tools. Just like managing the allocation of resources on a manufacturing shop floor, periodically the need will arise to make trade-off decisions among projects due to time or resource constraints. How are these prioritization and trade-off decisions made? Within a single project this may be within the scope of the project manager. Within a program consisting of multiple related projects, this may be within the scope of the program manager. But what happens when an enterprise has many unrelated programs across various departments 374 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS and locations, all competing for the shared pool of capital and human resources? Project Portfolio Management. The Project Management Institute defines Project Portfolio Management (PPM) as “the selection and support of projects or program investments. These investments in projects and programs are guided by the organization’s strategic plan and available resources.”235 The Chief Financial Officer of an enterprise is often ultimately responsible for the oversight of all projects, and the portfolio of IT projects is accountable to this authority. From a corporate governance perspective the CFO is particularly attentive to controls upon cost and risk. The Business Finance magazine article “Project Portfolio Management Goes Mainstream” describes the value of PPM from this point of view: Few of the challenges CFOs face are as complex and demanding as managing a portfolio of enterprise projects. Dropping dollars into one initiative affects all of the others. Shifting time and resources among ongoing projects directly impacts risks and returns. A typical medium to large organization has dozens, even hundreds, of projects under way at any given time, and finance executives are increasingly hard-pressed to establish priorities and ensure that initiatives stay aligned with corporate goals. Just because a project is important doesn’t mean we have resources to do it. In this era of tight budgets and limited resources, a haphazard approach to project management is no longer workable. Companies are looking for a better way to analyze the risks, costs, and returns that their enterprise initiatives generate. Many organizations are turning to software that enables them to manage a broad range of efforts holistically: Project Portfolio Management tools.236 As you might expect, PPM has much in common with investment or product portfolio management. Although PPM software applications are diverse, most provide a combination of project management, content management, collaboration, portals, reporting, and analysis tools that are fine-tuned to PPM tasks. Many offer sophisticated and expensive tools that may be appropriate only for larger enterprises with dedicated PMO resources. However, many small and medium-sized companies also have the need for such capabilities, because they have similar functional requirements and project management complexities as their larger counterparts, but with fewer resources to manage them. The Industry Week magazine article titled “Made for Midsize” stresses this important point: “It’s a major misconception that smaller companies have less complex technology needs,” observes Rod Johnson, a vice president at AMR Research. “While larger companies can afford to pursue innovation around technology, smaller firms typically have to pick their spots and make sure that they’re investing in solutions that will provide a significant payback. They face some tough decisions.”237 GUIDING CHANGE WITH LEAN IT 375 If they are resourceful, a small or medium-sized company may practice the disciplines of Project Portfolio and Program Management without sophisticated software tools. In fact, earlier in this book we explored an array of knowledge management tools that may be useful. Furthermore, Project Portfolio and Program Management principles share the same organizational framework as enterprise performance management described in the previous chapter, emphasizing the hierarchical linkages between business strategy and ground-level initiatives illustrated in Figure 11-07. More important than the software tools is the necessity for every enterprise, large or small, to develop competency in portfolio, program, and project management. The modern enterprise exists in a dynamic environment; operational excellence (the performance of ongoing and repetitive activities) has become a basic requirement for viability. However the ability to plan, execute, and control a variety of interrelated projects with a wide variety of stakeholders, and according to a clear strategic direction, may distinguish top competitors from the also-rans. From shop floor kaizens, to internal IT projects, vital constraint-breaking kaikaku initiatives, and elaborate global supply chain programs, the enterprise must juggle numerous projects, utilizing scarce resources to best advantage. 376 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS Project Management Office (PMO) Project Portfolio Management Finance Constraints Human Resource Constraints Business Strategy Executive Management Program Management Project Management System Lifecycle Management comprised of many distinct projects over the system lifetime Design or Select System Based on Requirements Validate and Test Implement and Integrate Define Requirements , Value and Measurements Support, Maintain, and Continuously Improve Repeat Figure 11-07. PMO linkages from overall strategy to individual project management But there’s more to the PMO than just balancing the project portfolio, programs, and projects of the enterprise. The EAI Journal article “A Guide to ERP Success” suggests that there are five vital roles that the PMO and its staff may contribute to institutionalize effective change management practices: • Project Management Solution Architect—The PMO assumes a leadership function in defining the combination of processes, technologies, and standards required to meet strategic and tactical project management needs. • Process Champion—The PMO develops, implements, and continuously improves project management processes based on organizational feedback, management requirements, and industry best practices. Implicit in this role is the need to provide value to project and senior management stakeholders. • Mentor and Coach—The PMO assumes an active role in promoting knowledge, understanding processes, and achieving buy-in from stakeholders. The focus is on promoting an understanding of relevant PMO processes but may extend to an understanding of general project management knowledge that’s relevant to the stakeholder. This role also includes developing and implementing project management training. • Facilitator—This role includes working directly with project teams and conducting project workshops designed to gain consensus on key parameters such as scope, resource requirements, plans, and schedule dependencies. • Knowledge Broker—In this role, the PMO ensures that all project-critical management data and information necessary for process implementation and decision-making are available to all stakeholders. This includes the analysis and reporting of project metrics, including performance and risk metrics and quantitative and qualitative analyses, including variance analysis, critical path analysis, and trend analysis.238 System Life Cycle Management Finally we arrive at ground level, where systems are selected, developed, implemented, and continuously improved in the five basic stages described in Figure 11-07: 1. Define Requirements, Priorities, and Measurements During this stage, a company should form cross-functional teams, map current-state processes, and identify desired future states and the gaps between current and future states. The team should identify linkages to the strategic plan and then establish a value for each gap, to prioritize their closure. Finally, the team should define particular software requirements GUIDING CHANGE WITH LEAN IT 377?to address each gap, remembering that a balance of people, process, and technology is required at this point. Now here’s the kicker—if continuous improvement efforts are already underway, shouldn’t this current/future state gap analysis, strategic linkage, and prioritization process already exist? An enterprise shouldn’t perform these analyses only when they’re shopping for software; this should be an ongoing process. 2. Design or Select a System Based on Prioritized Requirements Although this stage may include the development of software, our focus in this narrative is on the selection of a commercially available software product. The team should be armed with a prioritized set of requirements based on their desired future state. A team selecting software without a clear definition of its needs, and without predefined criteria and methods for evaluating, weighting, and selecting the right software based on those requirements, is just conducting a fashion show. Either the cheapest or the best ooking software, presented by the most persuasive sales team, that happens to say the right things at the right times, is likely to win. Or, if the selection team is imbalanced, with too much emphasis on a particular function or department, then an imbalanced selection may result. A cross-functional team ensures the development of a balanced set of criteria through the future state definition process, linking priorities to strategic goals and objectives, ensuring that the selected application provides the best overall fit. As Rother and Shook point out in Learning to See, without a guiding future state, improvement efforts are just wasteful. 3. Validate and Test Software has now been selected (or designed) based on a preliminary definition of key future state requirements. But before the final system design is determined, the team should undertake several rounds of prototyping to validate key assumptions and design decisions. This testing process should be iterative and repeated in multiple rapid cycles and include tight interaction between the design team and the user community. In addition to system design, testing also validates training effectiveness, user proficiency, data accuracy, documentation, and system performance, before a go-live decision is made. 4. Implement and Integrate Skillful planning, project management, and a committed team are essential to a successful implementation; otherwise delivery of a successful project is pure luck. 5. Support, Maintain, and Continuously Improve As we have already established, it is critical that selection, implementation, and maintenance decisions be made with the entire ecosystem in mind. Once a system is in place, changes made within the entire collective of systems and processes (the ecosystem), including rapid and fine-grained adaptation to changing business practices, software upgrades, 378 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS customizations, and integrations, must be carefully orchestrated in conjunction with cross-functional training and continuous improvement initiatives. Period. This process describes the initial selection and implementation of a new system; however, the very same approach applies to the ongoing improvement of any system in a rapid cycle as shown in Figure 11-08. APPLYING LEAN IT TO THE LEAN ENTERPRISE Focusing Change To realize their full potential, Lean Enterprise and Lean IT initiatives together must encompass the entire organization, guided by effective strategy, focusing on specific initiatives. According to Goldratt, Ptak, and Schragenheim, “Software adds value only to the extent that it overcomes limitations.” So what are your limitations? What are your Strengths, Weaknesses, Opportunities, and Threats? Where are your constraints? How do you improve throughput? How do you satisfy your current customers and grow your market? How do you nurture and leverage the collective knowledge of the enterprise? The answers to these questions must focus the initiatives of the Lean Enterprise, supported by Lean IT. Leaders must develop a strategy, identify the constraints that limit the achievement of that strategy, and focus the energy of the entire enterprise on breaking those constraints to achieve breakthrough improvement. Does this focus on constraints mean that an enterprise should disregard the abundance of incremental improvements that naturally arise from team-based continuous APPLYING LEAN IT TO THE LEAN ENTERPRISE 379 Define Requirements, Value, and Measurements Design or Select System Implement and Integrate Validate and Test Figure 11-08. The life cycle of a system improvement activities? Of course not. If something is broken, fix it. If something has fallen on the floor, pick it up. Individuals and cross-functional teams should be empowered to make incremental improvements whenever they find them. But should these random incremental kaizen improvements be the focus? No. The often-cited Lean ideal of the “pursuit of perfection in everything” may sound virtuous, and is a worthy aspiration for tactical improvement teams, but it’s not practical from a strategic perspective. To be effective we must focus on priorities. We began this chapter by exploring traditional tools and techniques for managing IT change. This included guiding the selection and maintenance of enterprise software by identifying gaps between the current and future states, managing hundreds (or even thousands) of distinct requirements, and measuring overall system performance by percentage of fit to those requirements. This conservative methodology of rigorously prioritizing and managing a portfolio of countless programs, projects, issues, requirements, and gaps may lead to reasonably effective information systems, but many aspects of this process are wasteful. Furthermore, this approach is not assured of creating a system that will propel a Lean Enterprise to the next level of performance. This is because the burden of managing the many small details may bog the change process down, restricting the team’s focus, leading to incremental but not breakthrough change. In this chapter we also explored the benefits of modern enterprise software tools, which may deliver increased agility through granular component architectures and a rapid spiral PDCA process. Although this approach is likely to succeed in creating more flexible information systems, it may not deliver breakthrough business performance; good tools do not guarantee good results. Forget guiding the business forward by managing thousands of detailed issues and requirements—which are the few critical issues that drive Lean Enterprise success? Where is the business going, and what are the system capabilities required to get there? Whichever enterprise software application best satisfies these critical requirements will probably perform satisfactorily on the hundreds or thousands of others. That is not to say the selection/development team shouldn’t keep this list of the top 20% requirements in mind, because failure to satisfy any one of these may create a new constraint. And an internal application development and support organization should track all of the issues and requirements in a database, because that is how they manage their activities and support the end users. But from a system life cycle management perspective, even if there are non-critical shortcomings with the chosen system, with the flexibility of Web Services and rapid deployment methodologies, creating a strong ecosystem foundation upon which to grow and adapt is more important than focusing on the many insignificant details. So how do you determine the critical issues that prevent you from achieving breakthrough performance? Suppose that an enterprise forms a functional team comprised of nine leaders representing engineering, marketing, sales, 380 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS purchasing, production, quality, distribution, service, and finance; these are the nine functional areas illustrated in the matrix organization (Fig. 10-13). Each functional team leader then forms cross-functional process teams to focus on the elements of the value streams for which they are responsible. For example, the production functional team leader may form process teams for scheduling, capacity management, setup time reduction, and other vital production processes. Remember that this is a cross-functional (matrix) approach, so engineering and quality members must be involved on the setup reduction process team, because their actions impact setup time reduction effectiveness. In this example, suppose that the nine functional teams are each responsible for ten process teams; these process teams are responsible for the results of their processes within the overall value stream. Functional team leaders communicate strategic goals and objectives downwards to the process teams, and ideas and initiatives percolate upwards. Through catchball, each process team develops a list of (for example) five improvement initiatives that support enterprise objectives; 450 separate kaizen initiatives are now under way (9 functional teams ¥10 process teams ¥5 initiatives), each with its own targets, activities, and measurements. The results of these initiatives roll up to the functional team leaders who direct and encourage the teams. The aggregate results of these initiatives at the functional team level then roll up to the executive level as a handful of KPIs. Although 450 separate process team improvement initiatives are guided by the top-down communication of strategic goals and objectives, how many of these initiatives are truly strategic? How many directly address a critical constraint? Most likely, just a few. And who decides which initiatives are strategic, directing the focus of enterprise-wide resources to break critical constraints? Are the nine functional teams or the ninety process teams responsible? Can they determine whether any of their improvement initiatives address a critical constraint? Possibly not, because they do not have a perspective on the overall portfolio of projects. Only executive management has the necessary top down perspective to determine where the critical constraints exist; thus strategic constraint elimination efforts should be coordinated through the Project Management Office. Does this mean that the process team improvement initiatives are unimportant? Absolutely not. From the bottom up, continuous improvement should pursue perfection in every process. Each employee should feel a sense of ownership, responsibility, and empowerment for making incremental improvements each and every day. But from a top-down perspective most relatively minor initiatives do not merit specific visibility. How is the fabric of top-down and bottom-up objectives and initiatives to be woven? The answer lies in a blending of Hoshin Planning mechanics and the Project Management Office leadership, enabled by a fabric of IT tools such as alerts, portals, and scorecards, orchestrating enterprise-wide kaikaku and kaizen initiatives. APPLYING LEAN IT TO THE LEAN ENTERPRISE 381 Hoshin Planning concentrates enterprise resources on breakthrough change, by focusing a few strategic kaikaku initiatives that break constraints. The Hoshin Catchball process reaches down and across the organization to the individual kaizen teams, focusing resources on the critical enterprise constraints. And when a strategic improvement initiative requires software support, this process also guides the management of strategic requirements for software selection, implementation, and life cycle management. And finally, the PMO may also be responsible for orchestrating the KPIs that direct the numerous team-based, continuous improvement initiatives within the enterprise. With responsibilities for guiding both breakthrough and incremental change of processes, and supporting enterprise software requirements, perhaps the Project Management Office deserves to be renamed the Office of Breakthrough Change and Continuous Improvement. Sustaining Continuous Improvement with Lean IT The underlying message of this book is this: Continuous improvement and IT are complementary disciplines. Leveraging IT tools and methods to enhance Lean Enterprise performance, and using continuous improvement techniques to enhance Lean IT performance, are two sides of the same coin. Both aspects must focus on constraints to limit complexity and optimize results. As the enterprise change management process charts a direction for focused process improvement, to the extent that IT can enable these improvements, systems should be planned, tested, and implemented quickly and decisively. Once the systems are in place, they should be measured and continuously improved during their entire life cycle. As processes are improved and the need for transactions and controls diminishes, the systems may be simplified and perhaps eliminated. This symbiotic relationship among people, processes, and information technology requires a new way of thinking about enterprise information systems. In the traditional IT paradigm, a system became a monument that embedded itself deeply within the minds and processes of the organization, often requiring a meltdown to bring about change. By contrast, Lean IT is proactive and agile. This contrast between the old and the new is shown in Figure 11-09. For breakthrough results and lasting change, the Lean Enterprise and Lean IT must work hand in hand. Throughout this book we have explored a variety of PDCA cycles for both Lean improvement and IT implementation and life-cycle management. Are these really separate cycles? Consider these two statements: “Continuous improvement is a cyclical process” and, “The flow of materials and the flow of information are two sides of the same coin. ”The continuous improvement of the Lean Enterprise and the continuous improvement of Lean IT are two aspects of the same cycle. Not two, but one integrated cycle is required. Figure 11-10 illustrates such an integrated cycle, where each step contains an aspect of process and information. 382 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS People, Process, and Technology merge in this one great cycle: 1. Develop Strategy and Identify Constraints—Executive management should evaluate value streams at a strategic level. Measure value creation through Lean operational improvement, innovation, and customer service. Identify the sources of competitive advantage. Develop a clear marketing and production strategy, positioning the overall mix along the product/process diagonal. Identify constraints that limit the achievement of the strategy, pursue constraint elimination initiatives aggressively, and monitor them carefully. 2. Manage Goals, Objectives, Measures, and Project Portfolio—Articulate the strategy, then develop measurable goals and objectives to support it. The PMO should manage the portfolio of projects and improvement initiatives carefully and continuously, focusing scarce resources on the elimination of constraints. Targets and measures should be communicated from the top down, encouraging cross-functional teams to generate ideas and initiatives for their achievement from the bottom up. Teams should own their KPIs. APPLYING LEAN IT TO THE LEAN ENTERPRISE 383 Attribute Traditional IT Lean IT Organization Centralized Centrally Managed Team-Based Functionally Driven Initiatives Focus Tactical Technology-Driven Solutions Prioritize Local Optima Strategic Business-Driven Solutions Value Stream Constraints Change Management Rigidly Planned and Long Term Dynamic Primary Success Drivers Stability and Cost Containment Value Creation Knowledge Management Functional Silos Fluid Education Specialized Cross-Functional Speed Long Term Rapid Cycles Agility Discourage Change Encourage Rapid Adaptation User Involvement Periodic or Episodic Continuous Phasing Waterfall Spiral Figure 11-09. Attributes of traditional and Lean IT 3. Team Development and Education—Invest in the development of cross-functional teams throughout the enterprise; include an IT representative on each team. Provide the teams with ongoing education and coaching in continuous improvement techniques. Guide the teams with vision and strategy, and encourage them to develop their own initiatives and measures. Focus teams on creating value and eliminating constraints; remove obstacles from their path, and discourage inappropriate management interventions. 4. Map the Current State—Map the existing value streams, processes, and sub-processes so that cross-functional teams have a clear and holistic understanding of all activities and interrelationships within the enterprise. This mapping should include the complementary flow of materials and information. Manage these maps and supporting documents as vital enterprise knowledge. 5. Map the Future State—Develop a vision for the future state that is consistent with strategic goals and objectives. Do not bog down in the details; focus on simplicity and economy. Carefully map and analyze the constraints, and verify that they are legitimate and not merely symptoms of underlying problems. Ask “why” often. 6. Prioritize Changes—Perform a simultaneous gap analysis of business processes and their supporting information systems, identifying the incremental changes required to achieve the future state. The PMO 384 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS 1. Develop Strategy and Identify Constraints 2. Manage Goals, Objectives, Measures, & Project Portfolio STRATEGY TACTICS IMPLEMENT 3. Team Development and Education 4. Map the Current State 5. Map the Future State 6. Prioritize Changes Establish Value 7. Plan, Phase, and Manage Projects and Initiatives 8. Measure Projects& Initiatives Regularly Quantify Milestones 9. Communicate 10. Test, Test, and Test 11. Execute and Measure Evaluate Success 12. Standardize REPEAT Figure 11-10. Sustaining continuous improvement with Lean IT should focus the majority of effort on eliminating strategic constraints, while the improvement teams discover and execute tactical improvements along the way. Simplify processes first, then determine where IT may be applied to enhance performance. Identify how data should be captured, according to how it adds value. Remember that although spreadsheets and other quick technology fixes may be used sparingly, information should flow as smoothly as production; information disintegration causes waste. 7. Plan, Phase, and Manage Projects and Initiatives—Using a rigorous project management methodology, develop a plan for each project and initiative. Think PDCA. Strive to reduce project cycle times and improve agility through tightly controlled scope, regular interaction between users and designers, the use of small and standardized components, and a rapid deployment spiral. Deliver quick wins to build confidence. 8. Measure Projects and Initiatives Regularly—Establish measures that link strategy to action. Develop clear relationships between cause and effect, establishing appropriate result and process measures across the entire enterprise. Make sure these measures are balanced, reflecting finance, operational effectiveness, customer satisfaction, and innovation. 9. Communicate—Communicate the project plans and progress reports widely, ensuring that everyone in the company understands the purpose of each initiative, how it may impact them currently and in the future, and how the project supports strategic goals and objectives. 10. Test, Test, and Test—Design and test new processes and systems rigorously. Verify design and structure, user proficiency, data accuracy, user documentation, and system performance. The team should make a clear go/no-go decision to proceed beyond testing to implementation. 11. Execute and Measure—Execute the new processes and supporting systems, and measure the results. Use the monthly Sales and Operations Planning process to regulate all aspects of planning, execution, and control, and to perform a reality check against executive expectations and strategy. 12. Standardize—Now it’s time to act, the “A” in PDCA. As the changes to processes and systems prove effective, institutionalize them through standardization, best practice documentation, and frequent education, training, and cross-training. Standardization does not mean rigidity; it is a pillar of continuous improvement—processes must be reliable so they can be consistently measured and quickly improved. After each improvement cycle, celebrate your accomplishments, and praise judicious experimentation and risk-taking. Determine whether a constraint has been broken. If it has not, then what must be done next? If it has, then identify the next constraint, and start again. APPLYING LEAN IT TO THE LEAN ENTERPRISE 385?There’s always a next constraint. Repeat the cycle and keep the momentum going! Although it takes great effort to get this cycle rolling, it takes much less effort to keep it moving. Keep improvement cycles small in scope and short in cycle time—the protracted waterfall change management approach must be replaced by a swift spiral. Just like Lean Manufacturing, Lean IT replaces long lead times and work order-based production with a level schedule and standardized components. This approach provides the flexibility to shift resources and alter the project scope in near-real-time according to changes in demand. Changing system design quickly is not scope creep, nor should it create instability—short project cycle times allow for rapid changes, just like a short takt time allows for a flexible product mix. Using this approach, Lean IT delivers agility and stability at the same time. This holistic approach continuously improves teams, value streams, and information systems, aligning company strategy through the design of future-state processes, with an unwavering focus on constraint elimination and value creation. Lean IT creates competitive advantage by accelerating and amplifying the continuous improvement of people and processes. Lean IT, as well as IT in support of Lean initiatives, requires the effective change management of people, processes, and technology, in that order. 386 LEAN IT: APPLYING CONTINUOUS IMPROVEMENT TO INFORMATION SYSTEMS

---

ABOUT THE BOOK

LEAN ENTERPRISE SYSTEMS effectively demonstrates how the techniques derived from Lean Manufacturing, combined with the thoughtful application of information technology, can help all enterprises improve business performance and add significant value for their customers. The author also demonstrates how the basic concepts of Lean Manufacturing can be applied to create agile and responsive Lean IT.

STEVE BELL is President and cofounder of Steady Improvement, Inc., a management consulting firm dedicated to improving business effectiveness through the alignment of people, processes, and information technology. He is a Certified Fellow in Production and Inventory Management (CFPIM) by the Association for Operations Management (APICS).

NWLEAN is currently running an online 'book study' of this text. To obtain information on how to join this study, visit http://groups.yahoo.com/group/NWLEANstudy/.

Click here for a SNEAK PEAK at next months article...