Several years ago, mid-sized organization implemented a very large custom configuration when they implemented their ERP system. At implementation time, they felt a large number of their customers would take advantage of the change. This was a multi-million dollar custom component. The need for the custom component was driven by the IT organization and was never really understood by the business. Once implemented, they learned only 2% of their customers would be able to use the custom component, yet the custom component negatively impacted 98% of the customers as well as the entire support staff. In addition, each system upgrade would cost the organization over a million dollars to retrofit the custom component.

As this example shows, many times major system upgrades are viewed as a technology project, and organizations miss the opportunity to improve the associated processes and improve business results. Even with the best implementations of major systems, organizations quickly learn that they could have taken better advantage of the system if they would have made some different decisions during the implementation. Projects that were driven as technology implementations usually missed providing many of the break-through transformations of business processes that deliver real business benefits. Often the upgrades are a result of a technical decision to stay current with software versions to ensure the vendor continues to provide support. Upgrading for support reasons provides business benefits to the vendor, but does the organization receive benefits? As the upgrade project begins, questions that should be asked are:

• What was the result of the last implementation/upgrade?  We there open issues or problems with the implementation?  Did the organization achieve the expected business benefits?
• Are there particular processes that are not performing well? Potentially highly manual processes, high error rates, or too slow?
• Were there requested enhancements that are included in the release?
• Many times organizations or people within the organization will have a negative opinion of the software package. Is there a negative opinion? Has anyone done a root cause analysis to determine the cause of the discontent? Many times perceived problems are based on the implementation or business processes, and not based on the software itself. Upgrading the software will not eliminate these issues.  Are there project or business process changes that should be addressed before implementing the upgraded system?

Based on an assessment that asked these questions, the organization listed above decided to remove the custom component as part of their first upgrade.  Some of the benefits they received were:

Last year, Jim Ritchey and I wrote an article for Cutter on the art of selecting enterprise software solutions. Our basic topic was that you need to avoid the tendency to focus too heavily on current features, and instead focus more on product architecture and long-term considerations.  Here is a link to the article.

As part of our work with the CalState system, we recently held two webinars to share information we have gathered on the LMS market. The focus was on the overall LMS market, including proprietary and open source solutions, and the profile of  different state-wide systems. Based on feedback from the webinars, we have decided to make this information publicly available. You can find the webinar archive and presentation material on this page.  Enjoy!

As you can see, we are changing the whole look-and-feel of the Delta Initiative website.  We plan to make the web site a more lively place to find out about Delta Initiative, and to find useful information.  Have a look around and send feedback!