I have been a PeopleSoft consultant for about five years and currently
work Help Desk at a school system that did not have a succesful
implementation. There is not one all-encompassing reason for the
number of failures. Many of these reasons cross any ERP system, but
there are specific reasons for different ERP systems.
For PeopleSoft, the following are reasons I've seen an implementation
fail:
1. Education and Government versions of the software (before 8.0) are
not as actively supported by PeopleSoft as commercial and federal
versions.
Case in point, while documenting Inventory and Billing for E & G, our
PeopleSoft rep told us that 'I don't imagine anyone will buy the
software, much less the EUT kit for it'. My current institution
purchased Inventory for E&G, and frankly, it didn't work out of the
box, by PeopleSoft's own admission.
2. Implementations are managed by consultants without PeopleSoft
experience.
KMD some years ago decided that they were going to branch out from
their demonstrated SAP expertise and get into PeopleSoft
implementation. All of their PeopleSoft projects went south because
experience in SAP does not equal experience with PeopleSoft. They are
not basically the same, they are very different system that address
similar problems, but as I said, they are quite different.
3. Customers implementing with an Oracle database backend can
self-destruct. This isn't because Oracle is a bad database platform,
it's quite good. However, because of it's functionality, a DBA will
try to customize PeopleSoft through the database backend, instead of
through PeopleSoft's toolset. PeopleSoft is not designed for the
database to have triggers, stored procedures, or anything else at the
database level except tables and data. All data manipulation is
designed to be handled through peoplecode, SQRs, Application Engine,
or COBOL. I mention Oracle, but this can happen with other database
platforms as well. It seems from my experience, though, that this
happens quite a bit with Oracle.
3B. There is a command in PeopleCode called sqlexec that allows any
valid db platform specific sql statement to be executed. PeopleSoft
tries to be flexible by allowing this feature, but it can sometimes
backfire if this is relied on as a workaround to attending PeopleCode
class.
4. The implementation consultants know PeopleSoft on a functional
level, but not a technical one. This happens a lot and it happened at
my present institution. A customer looks to the implementation
consultants to fix problems, but the consultant only knows functional,
not technical. This can also be the most infuriating.
5. High turnover at PeopleSoft. Lots of people have left and that
creates an expertise gap that is hard to bridge.
6. Customer Support is lousy. They are making efforts, but the truth
is, they are not good at this.
7. The customizability of PeopleSoft. This is a blessing and a curse.
If something is customized a great deal, it is difficult to maintain
as patches and fixes become available. This is why PeopleSoft
recommends that any major modifications be made as a custom module (or
bolt-on) instead of a major modification to an existing module.
8. The number of patches and fixes that are published almost daily for
some of their products. The rate of patches for anyone still using 7.5
is astounding. Even 8 and above users get deluged with the number of
patches required. The good news is that it is becoming easier to put
in patches (assuming point 7 doesn't mess you up), but there are still
quite a few.)
9. Implementing PeopleSoft means that there will have to be personnel
hired specifically to care for the system. It is a full-time job for
several people to manage the PeopleSoft system(s) after
implementation.
10. Student Administration is just not good software.
Hope that helps. |
