Practical-3

CASE STUDY : ERP problems at Stanford.

Stanford University wanted to get rid of its 20-year old mainframe software and advance to the latest financial and human resources modules of ERP systems from Oracle and PeopleSoft. However, the process turned out to be extremely difficult. Stanford spent more than seven years transferring its financial systems onto the Oracle financial modules. The project was supposed to be finished in 1999, but it experienced severe delays. These delays were caused in part by the huge amount of customization required by the software. In 2000, Stanford finally got part of the Oracle financial modules running. At that point the university set the remaining projects aside. It then started another project, installing PeopleSoft to manage student records and human resources systems. The PeopleSoft projects were delivered on time. However, faculty and students found the applications quite disruptive. For example, the modules interfered with Stanfords ability to issue correct paychecks and assign student housing. Finally, in 2002 the Faculty senate called for independent oversight of Stanfords IT department. One cause of these problems was that the Oracle and PeopleSoft applications were designed to be used by public companies not decentralized educational institutions. For example, the ERP software had a single ship-to address in the purchasing module. This arrangement works well for a company like IBM that is organized around a central receiving unit. However, it is not functional for a massive research university like Stanford where packages are delivered directly to numerous offices and labs. Unfortunately, ERP vendors can be slow to recognize the pain their software can cause customers. For example, PeopleSoft was sued by the state of Ohio after a botched installation at Cleveland State University. Stanford finally decided to change itself rather than change the software. So far, however, each project in different enough so that it is hard to establish best practices. The university must cope with version upgrade gridlock In other words, changing the version of the PeopleSoft package requires changing the version of the Oracle package, and vice versa. Stanford hopes that Oracles purchase of PeopleSoft might help in this area by promoting compatible software.

Ques & Ans:

1. Should Stanford simply have started fresh, rather than spending seven years trying to install oracle financial modules? - Stanford should have tried to transfer the financial units which were of relevance for that point of time, rather than try to do it for all its 20 years stuff. It could have done that slowly at a later stage - Apart from above, if they had done it freshly it would have been better (at least they should have done it after they saw the delay in the transfers and at the later part it could helped them to overcome the pain of delays and budget overruns that accompany complex enterprise resource planning(ERP)systems. 2. Should Stanford have investigated other universities with EPR system before beginning its implementation? - Yes, it should have checked with other universities then it would have known the problems they had and which may help them to decide whether to start fresh system or not - Also they should have looked into other available software providers than only these two (Oracle and PeopleSoft ) which might helped them to reduce pain of delays and budget overruns that accompany complex enterprise resource planning (ERP) systems. 3. Should Stanford have had to pay for the difficulties in implementing the oracle and peopleSoft system? Should oracle and peoplesoft have borne part of the costs? - The delay has been caused in part by Oracle itself, which helped Stanford customize the software so heavilychanging Oracle Financials to accommodate the way Stanford, so Stanford need to redistributes overhead costs across its grants. - Equal part should be paid for both Oracle and Peoplesoft because for instance- together they broke continuity with future versions of the software, rendering portions of what they put in place unusable