True Configuration Costs

This topic discusses the cost of configuring your batch processes such as upgrading, further documentation, and support limitations.

Future Ongoing Liability: Upgrades

After you configure the PeopleSoft system, upgrades inevitably become more difficult, with the degree of difficulty directly proportional to the extent of the modifications that you make.

You must retrofit all the configured code to the new PeopleSoft application. We supply you with a new, upgraded system, and you've modified the old one. You're going to have to make a careful analysis of the old and new systems, relying to some extent on the documentation you've (hopefully) produced to go along with the configured code. Additionally, you must decide which modifications to keep (and how to keep them), which to delete, which to record from scratch, and so on.

PeopleSoft maintains our application features from release to release. We may alter the manner in which we provide certain functions. When we do, we deliver the upgraded feature as part of the new system release. When the change requires a new structure for data, we provide you with specific, rigorously tested procedures to change your data or programs to conform to the new release. This, in itself, is a powerful argument against configuration and its associated maintenance costs, because when you make modifications, you may have to re-implement the modifications whenever a new release comes out.

This might be fairly straightforward process: You just add your old modified code into the new system. On the other hand, PeopleSoft may have changed the way we do things from release to release, so you have to look at each modification and technically assess whether it works the way it used to or not. After you make the decision to configure, you have to continue to modify the package each time you implement a new release.

Future Ongoing Liability: Documentation

For every configured feature that you implement, you must produce your own documentation. You have to decide whether to merge the documentation with PeopleSoft's or to keep them separate. And documentation must be maintained. Each time a new release comes out, you have to go through the same process all over again, merging or adapting the documentation as necessary. It's expensive. And this expense will continue. Documentation isn't just a part of your initial configuration project. It's part of your upgrade process with every new release.

Possible Support Limitations

After you modify the system, you face another dilemma: If something in the system doesn't seem to work properly, is the problem due to PeopleSoft or to your configurations? Is the alleged bug in PeopleSoft code or yours?

Can PeopleSoft duplicate the problem you're having? After you've modified the system, PeopleSoft might not be able to do so. It's important to be able to duplicate a given problem, to satisfy yourself that there is indeed a problem, and to know whether you've fixed it.

For PeopleSoft to help you solve the problem, we must be able to duplicate the problem, fix the source code, and rerun the process. This is sometimes very difficult to do, even if you haven't modified the system in any way. We might not be able to do this at all, after you configure the system.

It might be difficult, depending on what you modify, to help you. Such inherent support limitations constitute just one more reason to stay with the core application as much as possible, and if you're going to modify it, to modify only minor aspects.