"Rapid Implementation Methodology"

If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"CDC Supply Chain software solutions are specifically architected for multi-enterprise, multi-channel, multi-language, and multi-currency order environments. We support end-to-end processes for distribution companies, from customer collaboration and eCommerce to global inventory management and supply-chain execution, all united by our Collaborative Services Framework for process integration and user interaction. "
Source: CDC Software

Resources Related to Rapid Implementation Methodology:

• Product Software Implementation Method (Wikipedia)

Rapid Implementation Methodology

Contents

• Introduction
• Executive Summary
• Cost drivers - and how to manage them
• Modifications of the standard software
• Integration
• Fixed price
• Technology
• Roll out
• Project Organization
• About the author
• Used acronyms

Introduction

This white paper is especially intended for readers interested in supply chain standard software implementations. It is however generically written, so worthwhile reading for anyone with interest in standard software implementation issues.

It is a sad but well known fact that too many software implementation projects are running out of time and money. Substantially! We expect that in reality it is even worse, due to hidden statistics.

The white paper is suggesting that it is quite possible to stick to plans and budgets, provided that you do the right things and avoid the traps. It elaborates on the key critical areas with advice based on more than 25 years of profound experience from software implementations, especially in the WMS/supply chain domain.

The expression "software vendor", or "vendor" only, have been used throughout the document for representing the software manufacturer, software reseller, implementation consultants and system integrators.

Executive Summary

There are some crucial activities with striking effects on cost in a software implementation project. This white paper suggests spending extra energy on the following parts of a software implementation project, in order to minimize cost and risk:

• Avoid software modifications by implementing the business processes of the software into your organization
• If the standard software has to be modified, make the modification part of standard
• Take integration seriously and test thoroughly
• Strive for getting fixed price quotes
• Look for modern technology
• Avoid Big Bang - rather, roll out in small steps
• Staff the project with people you "cannot do without"

The following sections will explain the rationale and the importance of these statements in more detail.

Cost drivers - and how to manage them

No doubt, there are just a few areas where things can go really wrong. But there is no escape, you ought to recognize the perils and deal with them undaunted. A general word of advice is to keep things simple - a large software implementation project is complicated already as it is.

Modifications of the standard software

Once you have decided to purchase and implement a new software solution, it is not likely that you want to maintain all the business processes as they were before. It would not make much sense. Yet, that is exactly what people tend to do. Unwillingness to change is a normal human behavior.

Fighting against change is not a good option when implementing enterprise software. Instead, use the software's built in business processes as the basis for organizational changes. The assumption is that a best-of-breed software solution comprises the sum of all the software vendor's customers' intellectual property, so it is likely to enrich your business opportunities rather than constraining them.

You may find instances when the software does not support what you think is a key feature for you. Please think it over again. Ask your vendor. Is there a workaround? If not, you have two options: 1) Order a software modification, or 2) negotiate an adoption of your key workflow into the standard software.

Modifications of the standard software should be avoided to the full extent of what is reasonable. If modifications pile up, you have either chosen the wrong software or slackened the reins too much. Or, your business is quite unique, unfortunately.

Extensively modified standard code is the single most significant cost driver in a software implementation project, for these reasons:

• The cost up front, you have to pay for the extra development
• Additional maintenance cost, around 25% of the initial cost of the modification is typical, and this is an annual cost
• There is much less critical mass of knowledge about the modification - a likely scenario might be that the guy ordering/using it and the software engineer creating it both resigned, and nobody else knows that much about it...
• Additional cost is induced every time you upgrade, including the risk of disturbing quality of the standard software while migrating the mod to a newer standard version

However, there are very few implementations of enterprise software that runs plain vanilla. So, when a mod must be, make sure it is justified, well documented and built in a componentized way, thus enabling easy upgrading and minimizing interference with the standard software. Ideally, make sure that the software vendor adopts your business processes in its standard software.

There are two software domains deserving special attention when it comes to modifications; integration, which is further elaborated on in a separate section of this white paper, and reporting. With "reporting", we simply mean paper reports.

The need for changing report layout of a standard software is common, and in many cases well justified. That is because (paper) reports are documents that you send to your customers and other trading partners, they may have legal importance and must be designed in certain ways for various conformance.

So, it is recommended to choose a solution that supports report design done by the customer itself rather than by the implementer of the software.

Integration

Someone described integration as the piece of software that "everybody needs but nobody wants to pay for". Gartner Group have stated that "35% of all IT spending is for application integration". A similar statement from Meta Group reads "60% of the implementation cost of an ERP package is spent on integration".

One may argue the numbers, but what is true is the need for integration. Very few, if any, enterprise software solution would work independently from surrounding software. A lot can be said about integration and it can take many shapes or forms: Critical/non-critical, synchronous/asynchronous, bespoke/standards based, point-to-point/service bus, EDI/API/web services etc. The integration subject is too extensive and ambiguous for allowing a deep dive here. But there are implementation steps in general that should be watched carefully:

• Choose a solution that is flexible, has documented open interfaces and supports modern technologies
• Open interfaces for initial data loading is an additional advantage
• If you have an EAI backbone in place, use it; otherwise, use point-to-point
• Keep it simple and make sure you can't lose data
• API or web services technologies are easier to control and manage compared to flat files
• Hierarchical message structures are more complicated to implement compared to flat, fine-granular structures
• Use resources with the right skill-set - integration is usually mission critical and cannot be taken lightly

Fixed price

Always look for fixed prices. The upsides are cost control and positive incentives for your vendor. It also gives an opportunity for comparing quotes from other vendors. The drawback is that you may get dubious quality unless you play the game right: Specify tangible deliverables in work orders, scrutinize specs carefully and test delivered software carefully.

Some areas, typically integration and data loading, would cause reluctance from the software vendor when you ask for fixed prices. It is understandable, because not all involved components are known to the vendor. Your approach would be to purchase a pre-study, on a time and material basis. It is appropriate to ask for a fixed price when the pre-study is done.

Technology

The importance of technology is often overrated. However, you do not want to buy a standard software package that is built on obsolete technology that is, or will be, cumbersome to support in the long term.

Please consider the checklist below. Questions answered with 'No' are negative indicators:

• Is the solution based on .Net or java?
• Does the solution run on Windows server?
• Does the solution run on Unix/Linux server?
• Does the solution run on any of Oracle, SQL Server or DB2 databases?
• Does the solution support web services based integration?

Roll out

Much can be said about rolling out software. This white paper simply states that priority 1 focus should be on mitigating risk when rolling out the software.

Recommendations:

• Invest in thorough testing — the cost is negligible compared to the cost of a major disaster
• Roll out in small steps, facility by facility and/or function by function
• Avoid Big Bang; if not possible, conduct scrupulous testing
• Create a contingency plan

Project Organization

A mirrored project organization is suggested. The customer would essentially appoint a project manager with a project team, and so would the vendor. The two projects should have clear responsibilities, with no or minimal overlap. Both project managers report to, depending on e.g. project size, either of a main project manager or individually to a mutual steering committee.

The steering committee should comprise members from both the customer and the vendor; typically be the project principal(s), the account manager, financially responsible people and other stakeholders.

It is crucial that the steering committee is autonomously capable of decision making.

Additionally, a perfect project organization would engage the people that "you cannot run your operation without...". It adds not only deep business knowledge, but also user acceptance.

About the author

Mats J. Nordgren is Director of Product Management at CDC Software and has been in the supply chain software industry for more than 25 years in implementation, development and product strategy.

Used acronyms

• API — Application Programming Interface
• EAI — Enterprise Application Integration
• EDI — Electronic Data Interchange
• WMS — Warehouse Management System