Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations E-Book
Grady Brett Beaubouef
31,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Using packaged software for Customer Relationship Management or Enterprise Resource Planning is often seen as a sure-fire way to reduce costs, refocus scarce resources, and increase returns on investment. However, research shows that the majority of packaged or Commercial Off-The-Shelf (COTS) implementations fail to provide this value due to the implementation approach taken.
Authored by Grady Brett Beaubouef, who has over fifteen years of packaged software implementation experience, this book will help you define an effective implementation strategy for your packaged software investment.
The book focuses on Commercial Off-The-Shelf (COTS) implementations, and helps you to successfully implement packaged software. Using a step-by-step approach, it begins with an assessment of the limitations of current implementation methods for packaged software. It then helps you to analyze your requirements and offers 10 must-know principles gleaned from real-world packaged software implementations. These 10 principles cover how to maximize enhancements and minimize customizations, focus on business results, and negotiate for success, and so on. You will learn how to best leverage these principles as part of your implementation. As you progress through the book, you will learn how to put packaged software into action with forethought, planning, and proper execution. Doing so will lead to reductions in implementation costs, customizations, and development time.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 282
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
Grady Brett Beaubouef
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: December 2009
Production Reference: 1091209
Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK.
ISBN 978-1-849680-02-8
www.packtpub.com
Cover Image by Tina Negus (<[email protected]> )
Credits
Author
Grady Brett Beaubouef, PMP
Reviewers
Bob Cutler, PMP
Charles J. Miller, PMP
Chris Papesh
Acquisition Editor
James Lumsden
Development Editor
Amey Kanse
Technical Editor
Ajay Shanker
Indexers
Hemangini Bari
Monica Ajmera
Editorial Team Leader
Akshara Aware
Project Team Leader
Priya Mukherji
Project Coordinator
Leena Purkait
Proofreader
Dirk Manuel
Graphics
Nilesh R. Mohite
Production Coordinator
Adline Swetha Jesuthas
Cover Work
Adline Swetha Jesuthas
About the Author
Grady Brett Beaubouef, PMP is a project manager and solution architect for enterprise packaged software solutions. Brett has over fifteen years of packaged software implementation experience across several implementation roles including Project Manager, Solution Architect, Functional Lead, Technical Lead, Business Analyst, Software Quality Analyst, and Trainer. Brett also worked in a thought leadership role for the #1 business software maker, focusing on implementation methodologies, project assessments, and accelerated implementation services. Brett has a B.S. in Computer Science from LSU and is both a Project Manager Professional (2004) and a Certified Information Systems Auditor (1995).
Acknowledgement
My Customers
I have been blessed to work with many outstanding customers on their packaged software implementations. A special thank you to those of you who made an investment in me to help me better understand your business, and who taught me how to be a better consultant/partner.
My Colleagues
I have had the great fortune to work with many outstanding people who have shared their experience with me, guided me, and supported me during my great adventure in writing this book. A special thanks to Bob Cutler, Charles Miller, and Chris Papesh for their expert insight and feedback. Thank you to Sheila Cepero for helping me find the right publisher.
My Publisher
I would like to say that I am a mature, polished author and it was easy to work with me — but that is not quite true. I would like to say thank you to Packt Publishing for their patience, understanding, and guidance as I took my first dive into publishing. Thank you James, Priya, Leena, Amey, and Ajay for your partnership!
My Family
My greatest achievement! To Lisa, my wife who loves me and is my best friend. To Samantha my daughter — never be afraid to lead with your heart!
My God
To God for giving me the ability, Jesus for giving me the passion and His Spirit for giving me the encouragement to continue with this book in spite of my limitations.
About the Reviewers
Bob Cutler, PMP has over twenty five years of project management experience in both the private and public sectors. He has lectured internationally on project management and is a contributor to the Project Management Body of Knowledge on the topics of time management and cost management. He has successfully managed multi-million dollar Information Technology projects in California for several large public agencies. All of those projects were completed on schedule and within budget.
One of Bob's specialties is project remediation. He has successfully turned around failing projects for multiple clients on two continents. His process involves focusing on the project's goals, instilling trust, and restoring morale. Client satisfaction ratings at the end of those projects have always been excellent.
Bob has been involved with national and global project management offices for two multinational corporations. On those engagements, he was responsible for identifying and/or developing tools and best practices for project managers across the organization. He has also delivered advanced training on scheduling, quality, and risk management, and was a key contributor to the development and modernization of his clients' project management methodologies.
Charles J. Miller, PMP is a Certified Project Management Professional with over ten years experience in managing high-performing teams in the computer manufacturing, software, and telecommunications industries. He has spent most of his career on large-scale Oracle ERP implementations, but has also been a leader of software and web development teams, financial process improvement initiatives, and general technology implementation projects. Charles lives in Denver, CO and currently works as a Professional Services Consultant for a Software-as-a-Service company that provides channel sales solutions to global technology manufacturers.
Chris Papesh serves as CEO of Open Healthcare Analytics, leading the design and implementation of open source data warehousing software for healthcare providers. He has over twenty years of experience in all phases of the design, development, implementation, and project management of computer business systems. Chris has been a leader in the Oracle, PeopleSoft, and Data Warehousing communities. Chris served as Technology Director for PeopleSoft Corporation and Oracle Corporation, and has led national Business Intelligence and Data Warehousing consulting practices. Chris served as an Assistant Vice President for Carnegie Mellon University and Director of Financial Services for the University of California, and has spent more than 10 years as a part-time university instructor.
I wish to thank Brett for his thoughtful analysis and case histories, and stories of real teams in action implementing complex enterprise software.
Preface
Starting back in the 1980s, Commercial Off-The-Shelf (COTS) or packaged software such as Enterprise Resource Planning (ERP) applications were deemed to be the panacea to business pains caused by operational inefficiencies and disjointed applications. This resulted in an exponential growth in the ERP marketplace. To quickly meet this demand, ERP vendors and implementation partners used existing Software Development Lifecycle (SDLC) methodologies like Waterfall as the de facto implementation approach for ERP. This quick-fix decision resulted in an approach that was not effective for packaged software implementations, and that caused several issues. These included:
In my fifteen years of implementation experience, I have been fortunate to play the roles of Information Technology (IT) auditor, functional consultant, technical analyst, programmer, Data Base Administrator (DBA), business analyst, solution architect, and project manager. Through my experiences, I have formed the following observations:
Over the past two decades, the ERP industry has made incremental improvements in the implementation of enterprise business software — specifically, in the areas of implementation tools like industry-specific preconfigurations, online software product setup assistants, and data conversion tools. These improvements provided value from an efficiency perspective, however, there was little accomplished to address how to make ERP implementations more effective at delivering business value.
The strategic value of purchasing ERP — or any — packaged software is to reduce the customer's Total Cost of Ownership (TCO) for their existing business system, as well as allowing the customer to focus on more strategic objectives. The customer would pay some type of maintenance fee to the software vendor, who would then provide support and upgrades. In theory, this approach seems mutually beneficial to all players. However, the reality is that packaged software customers have not been able to experience the lower TCO due to the following:
If you think I'm only speaking of software, then I suspect that you are one of the many people who believe that ERP has been a tremendous disappointment.
Vision of the future
To get to a point where we can get customers to experience the full benefit of their ERP investment, we must EVOLVE our way of thinking on ERP implementations — or any packaged software implementation. The ideal COTS software implementation approach would focus on maximizing the "out of the box" value that packaged software can provide to a customer. The implementation approach would naturally filter out requirements that did not provide quantifiable business value, and keep the focus on the customer's value-added strategic requirements. There would be no need for post-production support provided by implementation partners because the customer would be confident in supporting their business solution. Upgrades are done in weeks instead of months or even years. The project team would have a common language (technology, business, software) that they could speak, in order to collaborate effectively. Validation of business requirements would happen early and often. Organizational change would be manageable because it would be minimized. Business sponsors and end users would see and touch the business solution months before end user testing. Individual project team meetings would generate more decisions and less action items. Implementation costs associated with packaged software would be less than the normal — which is four to six times the cost of the software — because implementation partners would spend more time enabling customers to lead, versus performing staff augmentation. Customers would be left with an actionable roadmap to further leverage packaged software functionality as their business model evolves.
The implementation of packaged software is more than just installing and configuring software: it is the implementation of a business solution. A business solution is far more than just the software. Today, the majority of implementation approaches are guilty of focusing on one of the obvious components (products and technologies), or all of the components separately but not in unison throughout the implementation lifecycle.
Purpose of this book
The main objective of this book is to discuss an approach to implementing COTS software that will maximize the total ownership experience. This book focuses more on the art of effectively applying implementation methods for COTS implementations. As the IT market continues to move to a component-based software development paradigm, using available enterprise-wide software packages and "best-of-breed" applications in the marketplace, I believe this approach will become more relevant.
This book also serves as a challenge to implementation partners and internal Information Technology (IT) organizations that support packaged software implementations. This book will address the change in approach and direction we need to take as we evolve packaged software implementations to the next level, and generate greater business value for our customers. I will discuss different implementation methods and demonstrate how these perceived competing approaches can actually complement one another — it's just a question of identifying the appropriate level, and knowing when to apply these different disciplines. This book will identify the major factors that must be considered when defining the appropriate implementation approach.
I will also spend time in addressing packaged implementation perceptions and myths, in order to better define expectations of a COTS implementation. I firmly believe that business process methodologies like Business Process Management (BPM), Business Process Re-engineering (BPR), Lean, and Business Quality (e.g., Six Sigma) can and should intertwine within a COTS implementation lifecycle.
Out of scope for this book
The purpose of this book is not to rehash ideals and concepts that are present in the general mindshare of customers, implementation partners, and specialists regarding a successful implementation. This book will not define a new implementation methodology — there are plenty of methodologies out there, with their inherent advantages and disadvantages. This book will provide guidance on determining how to appropriately apply methodologies for packaged software implementations.
What this book covers
Chapter 1is an introduction, covering the ten principles for implementing a business solution.
Chapter 2 covers how to ensure that packaged software implementations focus on value-added business results.
Chapter 3 covers how to effectively create alignment with implementation partners by performing a formal knowledge transfer of the existing business solution.
Chapter 4 outlines a key approach that implementation partners can take, in order to ensure long-term success for their customers.
Chapter 5 discusses a best implementation practice for gathering and validating business requirements for packaged software.
Chapter 6 discusses how to select and apply relevant disciplines when supporting the customer's unique implementation.
Chapter 7 discusses a best implementation practice for the initial implementation of the packaged software.
Chapter 8 discusses a software change strategy for COTS software that will minimize potential risks and maximize opportunities for additional software value.
Chapter 9 outlines the negotiation strategy required for implementing COTS software that will maximize the ownership experience.
Chapter 10 defines a new project role that will increase the success of the business solution implementation.
Chapter 11 focuses on effective knowledge generation.
Chapter 12 revisites the principles expanded upon in this book, and discuss how to evolve our strategy for implementing packaged software.
TheAppendix is a summary of challenges.
Who this book is for
This book is aimed at enterprise architects, development leads, project managers, business systems analysts, business systems owners, and anyone who wants to implement packaged software effectively. If you are a customer who is looking to implement packaged software in the future, then this book will provide you with a strategy for maximizing your investment. If you are in an internal IT role and you find that your internal software development methodology doesn't quite work for an "off-the-shelf" business software package then this book will provide you with a perspective on how to adjust your approach. If you are an implementation partner looking to minimize the blood, sweat, and tears shed when implementing packaged software, then this book will provide you with a guide to filtering out obstacles and enabling implementation focus.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
New terms and important words are shown in bold. Words that you see on the screen, for example in menus or dialog boxes, appear in our text like this: "Clicking the Next button moves you to the next screen".
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
The author has used the following terms to identify specific groups:
challenge icon: This icon is used to visibly note a challenge to Customers, Business, IT, and Implementation Partners.
Case Study Icon: This icon is used to visibly note a real world experience with packaged software implementations.
Case Study
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book — what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, and mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books — maybe a mistake in text or code — we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. The Silo Approach is Alive and Well
For the past fifteen years, I have been what you call a "hands-on" student of the packaged software industry — specifically, Enterprise Resource Planning (ERP) software. One of the hard-learned lessons of early packaged software implementations is that we should not take a functional silo approach to implementing an integrated business solution. Enterprise solutions support business processes, and business processes typically span multiple functional areas (silos). Having a functional silo perspective typically results in underestimating integration considerations. ERP, or any packaged software, is only as strong as its integration across the functional areas that support a business process. As an industry, I can see that we are maturing to take a more holistic approach to packaged software implementations. However, there is room to grow.
Consider the following: business software providers are evolving their applications to be more business process centric. There has also been a resurgence in the subject of business process re-engineering and business process management. "Focus on your business processes!" is the advice that you will hear from analysts and implementation partners alike. Too bad that this advice focuses on only one component of a business solution.
Why do we need to change?
Based upon a survey of customers who have implemented ERP solutions, the overwhelming message is that customers are not satisfied with the business results. The following surveys provide statistical data on the rate of failure of ERP implementations:
Robbins-Gioia Survey
Robbins-Gioia, LLC, a provider of management consulting services located in Alexandria, Virginia, conducted a study of the perception by customers of their ERP implementations. The study included 232 survey respondents, spanning multiple industries, including Government, Information Technology (IT), Communications, Financial, Utilities, and Healthcare. A total of 36% of the companies surveyed had, or were in the process of, implementing an ERP system.
Key findings:
Conference Board Survey
This survey interviewed executives at 117 companies that attempted ERP implementations.
Key Findings:
Nearly 90 % of ERP implementations are late or over budget 1 and the ERP implementation success rate is only about 33%. What are the causes for such dismal results? I am firmly convinced that our expectations and approaches to ERP or any Commercial Off The Shelf (COTS) software implementations are the primary drivers. I will spend some time on a few of the key areas that we need to address in order to improve upon the packaged software implementation experience. First and foremost, what I am talking about is the implementation of a business solution.
Business solution defined
Today, the majority of business software vendors say that they provide business solutions. The term "business solution" is one of the key buzz words used to try to uniquely identify a software product offering. And as such, it is being misused and basically getting "watered down" — just like the term "business process".
I believe in the term "business solution"; however, no software can provide you with a "business solution" — only the vehicle to get your organization from point A to B. Before we can implement a business solution, we must first understand what a business solution is. I like to view a business solution as three components:
What is the most important component of a business solution?
Now, here is something interesting to consider: "Do you need all three components to have a solution for your business?" Let me address this in another way, "Do you need software in order to conduct business?" I am persuaded to say that the answer is no. Business was being conducted before the invention of the computer. However, I am quite aware that not having software as a part of your business is not practical in today's competitive marketplace. I do want to demonstrate that software only supports, and therefore can only have a certain level of benefit to, a business. Packaged software does not have the capability to make key business decisions. It is key business decisions that drive business results. Business software can provide information and data to assist people in making business key decisions. Seen in this light, one can conclude that people are the most important component of a business solution. Case in point: I have been on successful business solution implementations in spite of software limitations. I have been on successful implementations in spite of not having all of the business processes clearly defined. However, in my fifteen years of implementation experience I have never been on a successful implementation where the people (i.e., organization) were not ready for the new business solution. People have the greatest impact on the success of a business solution. Is it not interesting to note that the majority of packaged software implementations focus mostly on products and technology.
What is wrong with existing packaged software implementations?
I have listed the components of the business solution in the order of priority and significance. Very often, you will see business solution implementations deal mostly with products and technology during the first three-quarters of the implementation and only at the ending phase of the implementation is there any consideration of the other components of the business solution. Software and technology are important; however, your implementation strategy should not fixate on a single silo. The optimal implementation strategy will focus proportionally on each component of the business solution based upon the impact that each respective area (technology, business process, and people) will have on the implementation's success. To accomplish this change in our implementation strategy, we must first address a couple of popular perceptions in our industry today.
IT does not matter? Think again!
I would like to take the opportunity to note that I do not prescribe to the "IT Doesn't Matter" crowd. It's like saying "I can travel San Francisco to New York without any mechanical means". This is a true statement but how realistic is it in today's competitive landscape? Conversely, the IT community should continue to evolve their support approach where IT supports a business solution — not only software. Software by itself generates no business value. What software can do is enable efficiencies of people in order to produce business results. There is a healthy and optimal balance between the three components of a business solution that is required to generate maximum business value. Each customer and implementation partner must work together to find this balance. One thing is for certain: as part of your implementation, you must focus on all three components in parallel.
Is technology changing Business?
I do not believe that technology is changing business, but rather that technology is finally catching up with leading business practices. For example, back in the early nineties, I read a book on the e-business revolution. The major premise of the book was that technology was transforming existing business models into an e-business model. The book provided an example where inventory stocks could now be checked in retailer stores and inventory orders could be generated to maintain a desired stock level. The book explained that this is an emerging requirement due to new e-business technology.
I have to humbly disagree with this analysis. The above requirement had always been a desire of business. I remember back in the 1950's when my father would make the rounds as a salesman to his retailer customers to see their inventory levels and manually created orders to maintain the retailer's inventory levels. Many businesses did not perform this process because (a) it was manually-intensive work, and (b) it reduced focus on higher-priority business activities. Technology is now providing a cost-effective vehicle to accomplish this business requirement. Everyone has heard the phrase "build it and they will come". This philosophy may have worked out in the era of "green screens" and emerging client/server technologies, but not in today's world. Technology driving the business is like — forgive the cliché — putting the cart before the horse.
