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:
Unnecessary requirements being captured (i.e., requirements gathered based upon limitations of existing systems).
Requirements validation happening late in the implementation cycle.
Highly-customized solutions that left customers with the same or even more challenges.
Unrealized business results and benefits because the implementation focused only on the software.
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:
Customers are more concerned with implementing successful business solutions, not just installing software products and technologies.
Leading implementation methodologies are not focused on all of the components of a business solution. These components must work in unison in order to generate business value.
Every business solution implementation is a "point-in-time" solution.
Flexibility in a business solution starts with a flexible implementation approach.
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:
Initial implementations are taking longer and cost more than originally planned.
Software upgrades are more costly because implementation approaches focus on turn-key, point-in-time business systems, and not on putting the customer in the best position to leverage future COTS software upgrades.
Customers were never given the complete holistic approach needed to optimize their new enterprise business solution.
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.
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.
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.
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.
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.
The Appendix is a summary of challenges.
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.
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".
The author has used the following terms to identify specific groups:
Customer: This is used to holistically identify the organization that purchased the software. This would include all Business and Information Technology (IT) organizations.
Business: The specific business organization that is the direct user and benefactor of a business solution. This includes the business owner(s), business analyst(s), business systems analyst(s), and users.
IT: The customer's internal IT organization. This includes functional analysts, technical analysts, developers, and IT strategists.
Implementation Partner: The external Project Services Organization that will provide implementation services to the customer.
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
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.
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.
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 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.
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.