John wiley sons e business and erp rapid implementation and project planning fly

TE AM FL Y Cover Team-Fly® Page i E-BUSINESS AND ERP Page ii This page intentionally left blank Page iii E-BUSINESS AND ERP RAPID IMPLEMENTATION AND PROJECT PLANNING MURRELL G SHIELDS Page iv Copyright © 2001 by John Wiley & Sons, Inc All rights reserved No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per -copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744 Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012, (212) 850-6011, fax (212) 850-6008, E-Mail: PERMREQ@WILEY.COM This publication is designed to provide accurate and authoritative information in regard to the subject matter covered It is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services If legal advice or other expert assistance is required, the services of a competent professional person should be sought This title is also available in print as ISBN 0-471-40677-5 (cloth : alk paper) For more information about Wiley products, visit our web site at www.Wiley.com Page v To my son, Robert, as he begins his own career in systems development Page vi This page intentionally left blank Page vii PREFACE Organizations are going to have to change the way they implement packaged applications systems The old ways have never been successful and are incapable of supporting the needs of a rapidly changing business economy The e-business phenomenon has only accelerated the rate of these changes and created more severe consequences from failing to implement solutions in a timely manner Organizations that want to be successful in the future are going to have to develop a core competency in rapid implementation of packaged business applications to solve existing business problems and take advantage of new opportunities in Internet time Organizations have been implementing computerized applications to support their business processes for over 30 years During the early years, most of these systems were custom developed: each organization designed, programmed, tested, and implemented financial, human resource, and operational systems to meet unique (or at least believed to be so) organizational requirements Most of these systems were developed by the organization's in-house information systems (IS) department— with or without the help of consultants During the last 20 years, a whole industry has developed around the construction and marketing of standard application packages: software that a vendor develops and sells to a wide variety of organizations With standard software, organizations not have to create their own systems; they can purchase and tailor the standard systems to meet their own needs, often in much less time than it would take to develop these applications from scratch Several of the packaged software vendors have grown into large, global organizations The majority of the projects that have implemented these applications over the last 30 years have been failures They have taken much longer than planned, have cost many times more than originally estimated, and have not produced the business results that were expected Many of these projects were aborted after years of effort and millions of dollars of cost The primary reasons for these failures are well documented and widely known However, organizations continue to make the same mistakes— and get the same results This history of failures has created a bad image for business system implementation projects Page viii In the past, many of these system failures were masked from the view of organization's customers and suppliers Most of the applications that were implemented were back-office systems that did basic transaction processing These projects were usually done to reduce transactional costs and mainly affected processing within the four walls of an organization As such, they did not directly touch an organization's customers and suppliers Often managers and employees did not rely on information in these systems to make decisions and provide accurate information to business partners A number of substitute processes and redundant data sources were used instead Because of significant changes in the last five years in the functional richness and variety of the applications offered by the software vendors and the use of several new technologies in their development (e.g., Internet protocols and standards, web servers, wireless communication, handheld devices, graphical user interfaces, various middleware products), the potential business returns from implementing these new applications have skyrocketed The new applications can enable significant changes in the way organizations perform business processes, share information with customers and suppliers, and change business models and relationships Organizations are scurrying to take advantage of these new products and capabilities The software vendors and consulting organizations are all transforming themselves into e-business product and service providers New applications and uses of technology are surfacing every month These new applications go beyond the traditional applications available in the Enterprise Resource Planning (ERP) suite of modules (e.g., financials, distribution, human resources, and manufacturing) and extend to customer relationship management (CRM), supply chain management (SCM), eprocurement, data warehouses, and a multitude of new e-business enabling products (e.g., e-retailing, e-mail management, and electronic marketplaces, exchanges, auctions) Organizations are not willing to wait the normal one to three years it has taken to implement major systems in the past To meet rapidly changing business needs, organizations need to find ways to implement most or parts of these new applications in a matter of months, not years This is where rapid implementation comes in As with most things, there is good news and bad news here The bad news is that projects that used to take years to complete now have to be done in a matter of weeks and months Not only that, but they have to be done successfully the first time Solving critical business problems quickly and taking advantage of opportunities resulting from the e-economy makes implementation speed and time to market critical success factors In this environment, in many situations there is not time to fail and make a second attempt The market will pass you by A second issue is the fact that most of the problems that plagued traditional implementations still apply to rapid projects So, in addition to figuring out how to implementations faster, the teams and their managers have to figure out how to avoid the problems that have caused these projects to fail for the last 30 years Finally, the solutions that have to be implemented rapidly, avoiding traditional Page ix sources of failure, have to be better than those implemented in the past In today's rapidly changing business environment the solutions that are developed must be flexible and scale well Business situations are continuously changing Mergers, acquisitions, changes in supply chain composition, increasingly demanding customers, globalization, the Internet, and a number of other major trends mean that any process design implemented today will probably be obsolete in a year or two Therefore, these designs (and the software that supports them) must meet current requirements and be able to be adapted to a number of possible scenarios in the future Fortunately, there is good news to offset the bad With the right implementation approach, vendor package, accelerator tools, and management principles, it is possible to implement these products in a third or less of the time that these projects have taken in the past And this can be done in a way that better manages the risks associated with these products This is not idle speculation There have been hundreds of projects that have already proven the validity of this statement But it does take a different approach and the availability of a particular toolset to make all this happen That is what this book is about: •Chapter presents a case for making rapid implementations the preferred method for approaching these projects •Chapter describes the activities that are necessary to perform a rapid implementation •Chapter covers three different approaches for selecting application packages that can be implemented rapidly •Chapter deals with the challenges of managing these projects •Chapter discusses methods to address the people issues that have often been the primary source of failure in the past •Chapter describes what needs to be done to ensure that these projects are business driven and deliver the business results that were used in justifying the project in the first place •Chapter covers issues around supporting the IT aspects of these projects •Chapter deals with tools, called accelerators, that must be present to support a rapid implementation approach •Chapter covers trends and changes in the business and the packaged software industry that will impact implementations in the future •Chapter 10 gives guidance on what factors should be present before an organization is ready to have a successful rapid-implementation project This book is based on my 20-plus years of experience implementing custom -developed and standard package systems in various roles: project manager, process Page 258 second project delivers the B benefits after six months and the third project the C benefits after nine months And the final project delivers the last benefits at the end of the year By the time the traditional project would go live, the rapid-implementing organization would have already been receiving many of the benefits for six to nine months Besides phasing in benefits earlier, it is much easier to manage smaller projects than larger ones The project team that produces the A benefits will be much smaller than a team that has to produce all the benefits The smaller team will have less communication and integration challenges and will be easier to manage OTHER ADVANTAGES There are a number of other advantages resulting from a rapid implementation approach These include easier change management, increased staffing with top performers, and higher visibility with management Most people understand that the users are very important to the success of any of these implementation efforts If the users cannot understand and support the new system and its associated processes, it is not very likely that the desired changes will stick If the changes not stick, the organization will not receive the desired benefits It is easier to absorb change in smaller chunks The project that produces benefits A, B, C, and D will have changes in a number of areas occurring simultaneously The smaller projects will allow the organization to get used to some of the changes before the next wave of change takes place Some people say that it is better to make all the changes at one time and get it over with once and for all But that approach tends to overwhelm the organization and its employees and is a much higherrisk approach People must realize that the level of business stability experienced during the last 20 or 30 years is gone forever Things will have to continuously change in the future In spite of this, organizations still need to be sensitive to the fact that they should what they can to ensure that changes occur at a rate that managers and employees can absorb Another benefit from the rapid approach is that it is easier to get people assigned to shorter projects than longer ones A department may be willing to give up a star performer for a two- or three-month project but not for a one- or two-year project On longer projects these people are often permanently gone from their departments Replacements are found for the positions the team members used to have Therefore, at the end of the project, project team members are often assigned to new positions These positions may not even be in the departments the people came from On shorter projects, the departments may be able to come up with temporary measures to make up for the loss of the person without hiring a permanent replacement Page 259 Department managers often are more receptive to this idea of giving up key employees to the team if the system being implemented will have a major impact on their departments and people Having people who are good representatives of their areas on these projects is important So giving up these employees is more palatable if it is just for a short period of time and allows a department to have someone represent its interests on the team Finally, it is easier to keep the attention and support of top management on shorter projects If managers go a long time before seeing benefits from their investments, they tend to lose interest in the projects This is natural, given the large number of things on the typical manager's plate On shorter projects that create quick benefits for the organization or solve an immediate problem, it is easier to generate some enthusiasm and involvement from top managers TRADE-OFFS Obviously, there are trade-offs associated with taking a rapid implementation approach Many of these trade-offs are a byproduct of having a large number of smaller projects Others result from some of the basic assumptions dictated by this approach Although managing a small project is easier than managing a very large project, there are significant management challenges associated with coordinating the work on a number of separate small projects In many cases, each of the projects is focused on achieving a subset of the benefits of a larger business case, and someone needs to manage the achievement of the total set of benefits across a series of projects In addition, methods need to be established to achieve continuity and knowledge transfer across the projects implementing various components of the same vendor's products Lessons learned and information important to rapid implementation of a vendor's product should be captured and shared among the teams There are several approaches to minimizing these coordination and continuity problems One of the approaches is to create a program manager position to coordinate the planning and execution of a number of related projects The program manager can sit on the steering committee of all the projects to ensure that the work is coordinated This involvement allows the program manager to minimize the amount of redundant work among projects and identify gaps not addressed in the various project plans The program manager can also periodically meet with the managers of the various projects to understand the status and issues for each project and provide information to integrate the activities of the various projects Another approach for handling these coordination issues is to use the same project manager— and perhaps some of the same core team members— on a related series of projects Use of resources in this manner will help coordinate activities on subsequent projects since there will be people on later project teams who understand why certain decisions were made in prior projects This approach also allows the organization to Page 260 substitute its own people for some of the resources that were provided by the vendor or consulting organizations on earlier projects A second trade-off with a strategy that uses several smaller projects to achieve the organization's goals is that it requires the teams to create of a number of temporary interfaces between systems Each time a new vendor's module is implemented there is usually a requirement to create an interface with other legacy or standard software modules If all the modules of a vendor's suite are implemented at one time, many of the intermodule interfaces will already be available from the vendor In that situation the main interfaces that will be needed are between the packaged software and legacy systems For example, if the project team is implementing the financial, distribution, and human resource modules from one vendor in a single project, the interfaces between these modules are already designed into the vendor's technical architecture However, if the first project implements only the financial module, the team will have to create custom interfaces to the existing legacy distribution and HR modules These interfaces take time to develop and test They will also be thrown away as the organization implements the other package modules in future projects AM FL Y So, there is some inefficiency associated with getting parts of a system up quickly rather than doing all the parts at one time Temporary interfaces will have to be developed Even if manual interfaces are used in the short term as an alternative to custom-developing throwaway interfaces, there will be additional work for the users to maintain these interfaces Obviously, this overhead must be considered against the advantages of getting benefits sooner and having a higher possibility of success with the shorter, limited-scope projects TE A number of assumptions were inherent in using a rapid implementation approach These can limit some of the activities and results that can come from these projects Therefore, they should be balanced against the advantages of this approach before deciding whether a rapid approach is best for a specific situation One of the principles of rapid implementation is that the project team will not modify the vendor's source code In effect, the organization is outsourcing to the package vendor the ongoing development and maintenance of business applications Modifying the vendor's source code will often invalidate the vendor's support agreement and pass responsibility for maintenance of the applications back to the organization Developing custom modifications also takes a lot of time The activities needed to define requirements and design, code, and test the changes may significantly extend the timetable for the project In many situations an organization will be able to live with the functions provided by the vendor After all, configuration options provide a lot of flexibility in how the software will work to meet the organization's needs However, there are some situations where this constraint must be lifted There are some industries that have unique requirements that are not met at this time by the major application packages There are also situations where modifying Team-Fly® Page 261 the vendor's code allows the organization to execute innovative practices that provide true competitive advantages Other situations exist in which the vendor's code and data structures must be changed in order to provide interfaces that take advantage of unique, value-adding capabilities in custom-developed legacy systems and best-of-breed applications from other vendors Not all code development has to modify the vendor's source code and therefore invalidate the vendor's support agreements A corollary condition for rapid implementation is that there will not be a great deal of custom development even outside the boundaries of the vendor's code It is possible to invest in custom development for bolt-on functionality This code uses the vendor's standard application program interfaces (APIs), and therefore does not change the vendor's source code But again, this approach mitigates many of the benefits of a rapid implementation approach Modifying vendor code or creating bolt-on functionality takes a lot of time and effort and introduces additional risks associated with any custom-development activity Therefore, it should be discouraged when using a rapid implementation strategy However, if this is the only way to provide functionality not supported by the package, whether because of unique industry requirements or to implement newly redesigned processes as a result of reengineering efforts, then it may have to be considered The best way to handle this situation may be to initiate a separate project, with its own team, to develop this new functionality Obviously, there needs to be close coordination between this team and the team rapidly implementing the vendor's product PRECONDITIONS It should be obvious by this point that not all organizations, or projects, will be good candidates for a rapid implementation approach The following is a checklist of the 10 enablers required to make these projects successful: A strong business imperative to solve a problem or take advantage of a unique opportunity in a short period of time A business case that clearly defines the benefits to be achieved from the project and is used to guide project plans and decisions The desire to try a different approach to implementing business applications in order to overcome some of the things that have made these projects unsuccessful in the past This approach leaves the detailed scope of the project flexible and time boxes the rapid implementation project It also supports a general philosophy that the organization will change its processes to those supported by the software package and that there will be no modifications to the vendor source code Page 262 The willingness of top management to support the project team (e.g., remove organizational barriers) and stay close to these initiatives so that the organization can develop a core competency in doing these projects faster and accelerating the benefits stream The selection of a standard package that generally fits the needs of the organization and has been designed to have flexibility so that it can be changed frequently to meet continuous changes in business requirements The selection of a software vendor and systems integrator who have a rapid implementation methodology and tools (e.g., preconfigured versions, configuration aids, procedure and training templates, sample project deliverables) available to accelerate the implementation of the selected package The organizations should also have specialists that can be brought in to quickly handle the most complex and difficult parts of these projects An outstanding project manager from the functional side of the organization and an excellent management coach from the vendor or systems integrator Technical support capabilities to get a development environment available before kickoff, complete the technical support project activities in a timely and professional manner, and support the ongoing production environment and other technical support requirements An experienced cross-functional core team from the organization that works full time on the project and are empowered to make significant decisions as representatives of their functional and technical groups The team should be staffed with people who have gone through these projects before and are specialists in particular business processes or package modules 10 Heavy involvement from end users throughout the project, especially in the iterative development and testing activities There are no hard and fast rules on how many of these conditions should be met before an organization is ready to use a rapid implementation approach However, if two or three of these conditions are missing, using this approach will be a much riskier proposition Even in these cases, the organization will be better off in the long run if it starts some of these projects as pilots and works through overcoming these limitations Doing so will position the organization to better meet the continuously changing challenges that all organizations will face in the future FINAL THOUGHTS Most organizations have not had a lot of experience doing rapid implementation projects There is a lot of interest in this area in organizations trying to figure out better Page 263 ways for increasing returns on their technology investments and more rapidly responding to business problems and opportunities In addition, software vendors and consulting organizations are making significant strides in developing tools and software capabilities to make this approach to implementation less difficult The project accelerators and support capabilities that are being developed should make these projects easier to perform This is an area that should see increased activity in most organizations over the next two or three years However, there are many success factors for these projects that have to come from within the organization implementing systems using this approach Many of these changes have to with organizational culture and people issues Top management has not historically had adequate involvement in these projects, perhaps because they have not had strategic implications in the past Staffing these projects with the best candidates in the organization and empowering these people to make significant decisions is not something that has been common practice The business cases for these projects have been deficient and not effectively used during the projects There has not been enough involvement and participation by the key users who can help make the final designs better and more palatable to the organization These cultural and organizational issues will have to be overcome for these projects to be successful The key premise of this book is that things have to change The traditional approach to implementing standard business applications with big teams and long projects has not been successful and will not meet the needs of a rapidly changing business environment This approach also does not fit well with how the new e-business applications should be implemented using iterative development and hosted processing Organizations need to learn how to a lot of smaller, targeted projects in order to keep up with the demands of the e-economy This book has not provided all the answers for how an organization can take advantage of this new, better approach for implementing application systems in response to continuously changing business requirements The special challenges and capabilities for doing these projects will continue to evolve The specifics will also vary with the particular package that is being implemented or the process being improved However, the overall philosophy, principles, approach, and prerequisites for successfully completing rapid implementation projects will endure If your understanding of the issues involved with a rapid implementation approach and the keys to its success is a little clearer at this point— and piloting such an approach seems like something that most organizations should be at least considering— then this book has accomplished its purpose Together, we can figure out how to these projects better in the future— for the benefit of all our organizations The journey should be challenging and rewarding— what more could we ask? Page 264 This page intentionally left blank Page 265 INDEX Accelerated SAP (ASAP), 205, 217 accelerators, 42, 201 activity diagrams, 163 advanced applications, 14 application programming interfaces (API), 69, 226 application service provider (ASP), 11, 25, 56, 70 application suites, Ariba, 7, 15, 211, 233 Baan, 7, 164, 208 backfill plans, 129 benefits, 2, 156, 168 best-of-breed, 5, 7, 232 best practices, bolt-on, 65 BroadVision, 7, 233 business applications, business case, 37, 94, 165 celebration, 63 change, 142 change management, 51, 143 change mangement plan, 145 client-server, 246 code modification, 5, 13 Commerce One, communication, 53, 104, 135, 145 computer-based training (CBT), 212, 221 concurrent activities, 30 conference room pilot, 80, 87 configuration, 47, 208, 222 consultants, 29, 89, 248 consulting advisor, 36, 132 cross-functional teams, 26 contingency plans, 43 continuous improvement, 175 core implementation team, 126 core selection team, 89 custom development, customer relationship management (CRM), 14 database management system, 12, 192 data conversion, 30, 56, 61, 120 data warehouse, 17 deliverables, 38, 112, 204 Deloitte & Touche, 164 design book, 209, 223 detailed requirements selection, 74 distribution modules, 13 distribution requirements planning (DRP), 13 documentation, 53 due diligence, 86 e-business, e-businesses, electronic data interchange (EDI), 9, 215, 240 electronic funds transfer (EFT), enterprise application integration (EAI), 9, 70, 194, 240 e-procurement, 15 e-retail, 15 ERP, 6, 9, 12 estimate-to-complete, 102 Page 266 executive sponsor, 88, 133 expected results, 50 eXtended Enterprise System (XES), 11 eXtensible Markup Language (XML), 9, 70, 241 external consultants, extranets, 171 fast selections, 90 financial applications, 3, 12 flexibility, 69, 172 Gartner Group, 8, 83 general package characteristics, 68 go-live, 62 help desk, 61 hosted solution, 186, 213, 215 human resource applications, 13 Hyperion, 17 i2, 7, 15 IBM, 12 implementation, 20 individual accountability, 98 industry-specific modules, 16, 68 industry-specific process models, 162 installation, 18 instances, 186, 188 integrated suites, 67, 232 integration, 156 integration issues, 135 interfaces, 6, 225 involvement, 145 IS department, 3, 61, 90, 180, 194 issues management, 43, 118 iterative development, 46 IT support, 37, 54, 116, 178, 182, 191 J D Edwards, 7, 14, 47, 67, 82, 211, 217, 234 job design, 146 just-in-time training, 28, 210 key requirements selections, 77 key users, 137 kid-in-the-candy-store effect, 104 knowledge mangement, 121 knowledge management systems, 16 Lawson, 7, 82, 234 leadership team, 131 lessons learned, 62 Linux, 11 load-bearing walls, 28, 47, 209 managing expectations, 145 manufacturing applications, 13 Manugistics, 15 Meta, 83 methodology, 202 Microsoft, 12, 225 Microsoft Project, 99 networks, 11 non-value-adding steps, 172 NT, 11 online help, 222 online vendor support, 218 operational processes, 207 Oracle, 7, 8, 12, 14, 22, 67, 82, 113, 225, 234 order-entry, 13 organization, 130 organizational specialists, 141 outsourcing, 13, 171, 185, 198, 235 package administrator, 138, 193 package analysts, 136 package-enabled process redesign, 150, 166 package selection, 28 package specialists, 141 Pareto's 80/20 rule, 27, 108, 109 patches, 190 paving the cow paths, 153 payroll applications, PeopleSoft, 7, 82, 234 performance metrics, 157 personnel problems, 118, 123 point solution, 67 portals, 16 preconfigured software, 27, 51, 71, 208 preintegrated packages, 70 process analysis and design, 44, 157, 174 process analysts, 135 process lead, 134 process models, 30, 150, 159, 205 Page 267 QAD, 7, 82, 164, 210 quality, 102 quick decisions, 24, 115 TE rapid, 20 rapid implementation roadmap, 35 reengineering, 151 reference checking, 86 referential integrity, 225 relationships, 171 remote processing, 16 reports, 120 request for information (RFI), 74 request for proposal (RFP), 75 resistance, 117 risk management, 38, 43, 114 RossettaNet, 242 AM FL Y process owners, 133, 176 process redesign goals, 167 program manager, 259 programmers, 138, 193 project charter, 37, 96 project clock, 26 project kickoff meeting, 39 project manager, 31, 89, 93, 131 project phases, 33 project repository, 121 project status, 42 project workplan, 38, 42, 97 proof-of-concept selection, 79 sample deliverables, 42, 114 sand box, 24, 186 SAP, 5, 7, 14, 22, 24, 47, 79, 82, 113, 164, 209, 211, 217, 224, 234, 247 scope management, 26, 43, 46, 64, 103, 111 security, 61, 191, 252 selection approaches, 73 selection team, 88 Team-Fly® self-service, 172 sense of urgency, 107 short list, 83 Siebel, 7, 79, 211, 233 simplicity, 168 simulations, 170 software bugs, 116, 134, 218 specialists, 101, 117, 139, 185 speed, 2, 170 standard software, 2, status reports, 100 steering committee, 89, 102, 133 supply chain management (SCM), 14 support processes, 206 team training, 41, 210 technical lead, 138 technical specialists, 141 technical support team, 137 technology infrastructure, 11 testing, 45, 48, 59 time boxing, 26, 63, 107 train-the-trainer strategy, 54 transport process, 190, 192 UNIX, 11 user procedures, 216 user training, 54, 60, 146, 220 vendor criteria, 71 vendor IT investments, 183 vendor process models, 161 vendor representative, 133 virtual private networks (VPN), 171 vision, 155 war room, 37 wireless, 242 work breakdown structure, 34, 203 XES, see eXtended Enterprise System XML, see eXtensible Markup Language Y2K, ... address the people issues that have often been the primary source of failure in the past •Chapter describes what needs to be done to ensure that these projects are business driven and deliver the... developers, the need to handle Y2K issues, and the push of globalization and competition The three years before the end of the century were great years for ERP vendors Most of the top ERP vendors... supporting the needs of a rapidly changing business economy The e- business phenomenon has only accelerated the rate of these changes and created more severe consequences from failing to implement solutions