Life Technologies, Inc. (B)


In October, 1998, Joe Stokes, CFO of Life Technologies, Inc., reviewed the experience of the management of IT over the previous two years, in preparation for a discussion with his boss, Stark Thompson. Stokes had requested the review, as discussions with Thompson on the subject of IT had consisted primarily of short updates on current topics or urgent issues.

Virtually all the resources and effort by the IT group, which reported to Stokes, had been devoted to the AGILE project. AGILE was LTI’s name for the implementation of the J.D. Edwards suite of ERP software. After a number of delays and potential cost overruns, software implementation for most modules had been accomplished. Stokes’ outline for his review with Thompson, and his thoughts about them, consisted of the following points:

  1. On AGILE implementation, in mid 1997 our plan was to go live with the distribution/order entry module in the U.S. over Thanksgiving holiday in November. In July, 1997, we learned unexpectedly that release 7.2, which we were using, had been found by JDE not to be Y2K compliant. We had to choose between a) implementing that release anyway, given that we had done a lot of customization of it already, and then retrofit a compliant system, or b) delay the implementation until we could adapt the new release (7.3.6) for our needs. We chose the latter course and informed the entire organization worldwide.
  2. In November, our AGILE project manager resigned.

    These events slowed us down considerably. The users were expecting implementation of that module. Even though the Y2K problem was not ours, it was embarrassing. We had a couple of meetings with the JDE vendor, and they agreed to absorb virtually all the costs of the adaptation of the new release to our requirements. Nevertheless, our AGILE project credibility was damaged.

    We appointed a new project mnager from within LTI, and he has coordinated the IT staff, consultants and user involvement very well. The AGILE team has consisted of eight people full time, including two consultants, plus members of the users organizations on a part-time basis as needed.

  3. Manufacturing module went live in Europe, version 7.2, on schedule in November
  4. 1997. We plan to upgrade manufacturing to 7.3.6 this month (October, 1998), with implementation of manufacturing in North America to be in the first quarter of 1999.

    While this helped our credibility, it became evident during implementation that there were major gaps in the use of the new systems. There had not been an MRP system in place before, so the discipline, data, and skills needed to run manufacturing on the new system were not adequately in place. At this time they are using the new system for about 60% of its capabilities to support them.

  5. We upgraded the release 7.2 financial modules, which had been implemented by 1997, to release 7.3.6 in March, 1998, in North America and in July, 1998, in Europe. We expect Asia and New Zealand to upgrade their modules by the end of 1998.
  6. There were not major issues here, as we had modified the JDE core software in release 7.3.6 to fit our needs.

    I was very concerned about the stress on the AGILE team at this point. The senior executive who had been leading the AGILE steering committee resigned from the Company suddenly, leaving our team to take on even more of the responsibility for implementation.

  7. We implemented the distribution/order entry module successfully in North America on August 31, 1998, in a three-day effort.
  8. There was a rumor that a competitor of ours experienced a serious disaster in their implementation of an SAP ERP. This made people nervous, but when ours went in without major problems it seemed to give us all a boost!

    There were minor problems, complaints from some users about the system being different and less user friendly than the previous sustem. These continue, but on investigation it is clear the issues are around user training and resistance to change. For example, on order entry the system is designed to support one-call ordering and to allow the customer to use a credit card. I learned the other day that orders were being held up because our staff were not checking the credit card validity during the initial call. A lot of the problem seems to be the users simply don’t want to change their existing procedures.

  9. We plan to go live in Europe with distribution/order entry in six countries in January, 1999, and the remaining five countries in April.
  10. Several continuing issues and concerns remain:
  1. The need for vendor support in Asia, and in general, the need for coordination of implementation support from vendors on a global basis.
  2. Vendors advertise their products as providing for global integration of processes and across processes, but the office in Japan may not be trained on the latest release when it is implemented by a client of theirs in North America. Even more fundamental, the software in some cases appears not be adapted to take the "double byte" configuration necessary for Japanese characters, and training modules are at times not translated into the local languages.

  3. The capability of all the modules to deal with the Euro conversion. It is unclear what the impact will be, but apparently we will be locked in to making an upgrade in at least our financial modules. This will require a diversion of unplanned resources.
  4. The users still need to adapt their practices to ensure global integration. There is some question as to whether they will do this or not.
  5. Major initiatives other than AGILE have been put on hold. In particular, there is pressure for "e-commerce", and a senior manager from North America sales has taken on an investigation of this.

 

In general, Stokes felt the AGILE project had turned the corner and was headed for success, at least with respect to installing the software and making it available for user use and adaptation. He recalled this had been the top priority in the IT Strategic Plan of two years ago. The AGILE team had rallied in tough times and pulled together to make things happen.

Nevertheless, Stokes knew the pressure had been building to reap the benefits from the new operational software, and that steps needed to be taken soon to address this.

________________________________________________

This case was prepared for use in course 15.568 at the MIT Sloan School and MIS7550 at the Olin School, Babson College. It is not for reproduction or other use except by permission.

Copyright 1997, 1998 Massachusetts Institute of Technology and Babson College. 10/12/98

________________________________________________




Click here to return to Babson Home Page on this site



Home | Syllabus | Faculty | Assignments | Handouts | Extras | E-Mail