Your Modification Requirements

After you've gone through these exercises, and everyone on the team has a thorough understanding of PeopleSoft system capabilities, we encourage you to go back to your original list of requirements, whether this is in the form of a request for proposal or something else. Based on your new knowledge of the PeopleSoft system, you may find you can significantly refine your requirements, and that some might actually disappear. This topic provides some key questions to ask when revisiting your requirements.

Where Did We Get This Requirement? Is It Real?

Is it really a company requirement that we do payroll in this particular manner? Do we want to do it that way just because we've always done it that way? And, if so, is that sufficient reason to continue with this practice? Or is there another way that's just as easy, just as good, and doesn't require modification of Payroll for North America?

How Much Have Operational Characteristics of the Existing System Influenced Requirements?

When companies revisit and analyze their payroll requirements, they sometimes discover that particular requirements were actually formulated in response to operational characteristics or restrictions in their current (or old) system. A particular procedure came about that was really a compromise or a work-around. Some payroll department procedures may have no basis in any real payroll requirements; they might just reflect some operational characteristic of the current or old system. If so, this is an argument for re-engineering some of your business procedures and practices and not configuring Payroll for North America.

Whose Standards Should We Use, Ours or PeopleSoft's?

Because of your company's in-house standards and conventions, you might discover a discrepancy between the way you ordinarily do things and the way PeopleSoft has delivered the system.

One reason your company decided to use the PeopleSoft system is the high degree of fit between your requirements and our features. Your selection team determined that Payroll for North America has attributes that your company could use.

A system your company builds in-house will in all likelihood conform to your company's standards; but if you bring in a package, it might be more reasonable to adopt the standards set by the vendor of the package.

Decisions having to do with standards start right at the beginning, when you install Payroll for North America. We require a database to be set up, and the tables all have to be named. A database administrator might say, "Our Company does not name tables this way," and suggest renaming all 8000 and some odd PeopleSoft tables and views. Keep in mind the ramifications of renaming all 8000 tables and just how extensive a change that really is.