Batch Process Configuration
This topic lists prerequisites and discusses:
Batch process configuration considerations.
True configuration costs.
Payroll for North America system capabilities.
The vanilla PeopleSoft system.
Your modification requirements.
List of required modifications.
Proposed modifications review with PeopleSoft.
Contact with other customers.
Configuration is not to be performed lightly. Before you start to think about adding, deleting, or modifying code, ensure that everyone in the organization understands what configuration entails. Your goal should be to modify the system as little as possible, and preferably not at all.
Remember that companies decide to acquire a software package such as Payroll for North America because it is a package. It's a coherent and self-contained system, already designed and delivered. It runs, it works, it satisfies the demands made upon it, and it does this best—and with the least problem and expense—when you work with the package as it exists.
Before you make a list of required modifications to Payroll for North America, perform the following prerequisite activities:
Understand what configuration may cost—and this includes hidden maintenance expenses that might not be immediately obvious.
Understand Payroll for North America system capabilities and design from a functional point of view. For what tasks are you trying to use it?
Use the vanilla Payroll for North America system extensively; both with the PeopleSoft-supplied Demonstration data and with your own realistic test data.
Revisit your configuration requirements thoroughly.
Produce a list of your required modifications.
Review your proposed modifications with PeopleSoft.
Contact other PeopleSoft customers to discuss configuration issues you may have in common.
Before you modify Payroll for North America batch processes, make a thorough analysis of the business requirements that you're trying to address through configuration and seriously consider the possibility of addressing those requirements through re-engineering the payroll department procedures rather than through changing PeopleSoft COBOL source code. It is almost always more cost-effective to reduce the list of required changes to an absolute minimum. When you configure batch processes, you incur a variety of ongoing maintenance expenses and possible conflicts as the effects of the changes move through the system.
An important configuration consideration is how the system processes the various dates in Payroll for North America: effective dates, begin and end dates, dates on the job record, dates on the General Deduction table, and dates on the Pay Calendar table.
Note: In providing information on this topic, we assume that you have a basic understanding of PeopleSoft online processing flow, PeopleTools, relational databases, and COBOL programming.
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.
To configure Payroll for North America you must have a rigorous understanding of the system. How is the system put together? What is its component tables, programs, and pages? What is its system architecture and what is it really designed to do? And, of equal importance: How is your organization using it or planning to use it?
This topic provides some tips for training the appropriate people in your organization with Payroll for North America.
Combine Functional and Technical Personnel into One Team
When you're learning about Payroll for North America, the functional and technical personnel should be in close communication with each other, to the point of becoming a single team. Your functional people know how your business runs; your technical people know how your current system is put together. And between the two groups, they can act as an effective team.
Ensure That Team Receives Training
Make sure that the whole team receives training in the PeopleSoft system, as a team, everybody together.
Run PeopleSoft Vanilla Payrolls at Your Site
Before rushing to configure, or even to formulate a list of configuration requirements, PeopleSoft recommends that you install the standard Payroll for North America demonstration software without changes. Have your team start using the demonstration companies, employees, pay groups, pay calendars, deductions, and so on; have everyone read Payroll for North America Business Processes; run Payroll for North America. In this way, everyone becomes familiar with such critical concepts as what paysheets are and what the Create Paysheet COBOL SQL process (PSPPYBLD) is; what the Pay Calculation COBOL SQL process (PSPPYRUN) does, and what checks are in Payroll for North America; what the Pay Confirmation COBOL SQL process (PSPCNFRM) does, what balances are, and so on.
Everyone in the team should be familiar with how Payroll for North America works, because the next step is to try to duplicate your company's payroll with the vanilla Payroll for North America system.
Build Real Earnings/Benefit/Deduction Table Entries
Start configuring your Earnings table, Benefits tables, and Deduction table by creating entries tailored exactly to support your company's payroll operations. As you do this, you will, of necessity, start making some real decisions on how to define the actual earnings, deductions, and benefits that you need, according to the PeopleSoft vanilla style.
Set Up Realistic Test Cases
Set up some realistic employee test data; then use all parts of the system. Hire employees through the normal PeopleSoft HCM paths; set them up with realistic earnings, general deductions, and benefits; enable them to be paid; then go ahead and pay them.
Keep the Demonstration System Available
Be sure to keep the original Payroll for North America demonstration system data available, so that as you're going through and modifying earnings, deductions, employees, and other data, you can always refer back to some of our test cases to see how they were set up. Many of the demonstration employees are paid, for example, with fairly complex benefit setups. And if you purge all the PeopleSoft demonstration data, you won't know how they were originally set up. By keeping the demonstration system available, you always have a reference point as you continue to build tables for your own company's real-life needs.
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.
Now that you've assessed the costs of configuration, acquired a deep understanding of Payroll for North America system capabilities, used the vanilla system extensively both with the DEMO data and your own test cases and thoroughly examined your requirements—you are in a position to come up with a list of required modifications. What remains should consist of changes you absolutely have to make to the Payroll for North America system to make it acceptable for production.
After you've come up with such a list, separate it into two parts:
Changes that can be addressed through business re-engineering.
Changes that require configuration of the PeopleSoft system.
Examine your list very carefully with the goal of having an absolute minimum of changes that require configuration.
After compiling your list of modifications, work with your PeopleSoft Account Executive on these proposed changes.
Remember that there might be another way, short of rewriting code, to do what you want to do. It's always useful to reconsider the functional and technical issues, with the help of an experienced expert in the system. Often, they can suggest another way of achieving the functionality that you want, ideally, through the standard system.
And it may be that PeopleSoft is already planning and designing, for a future release, a feature similar or identical to what you have in mind. Particularly if your requirement doesn't represent something unique to your company's individual way of doing things, but is rather a genuine functional requirement typical of many payroll departments, we might have other customers who have requested we add such a feature to our standard system.
PeopleSoft may have already designed the feature that you need. If this is the case, you can work with PeopleSoft, through your Account Executive, so that we can jointly get that feature into your system.
It's always to your advantage to remain in close contact with PeopleSoft on configuration issues. For example, even if you do all the work on designing and implementing a modification, if PeopleSoft subsequently takes it over and makes it part of our standard application, then you'll be free from the ongoing maintenance liability.
Your company probably has payroll requirements that overlap to a considerable extent with those of other PeopleSoft customers. Another PeopleSoft customer may have requested the same modification that you are contemplating; they might have gone ahead and designed the feature on their own. This might occur even if you think the requirement is absolutely pure or unique to your circumstances.
Other customers might have similar requirements and built it into their systems. By trading design ideas back and forth with other customers, you might be able to come up with a great solution more effectively and efficiently than either of you could on your own.
Use My Oracle Support to Communicate
My Oracle Support, Oracle's web-based communications service consisting of updates and fixes, discussions and SIGs, and news and information about PeopleSoft applications and development plans, is an ideal tool for communicating with other customers about configuration issues.