| Managing Setup Data | KEVIN RESCHENBERG
02-08-2004 |
Last week we considered some of the types of PeopleSoft objects, how they should be maintained, and how (or even whether) they should be
migrated. While the answers seem fairly easy for most fundamental objects (fields, record definitions, pages and so on), the questions become
more difficult when we are dealing with objects such as queries and trees. I concluded that the best answer may depend on the object type,
your organization's development/support structure, and other factors.
Today we'll think about the other side of the coin: data. I'm referring here to just about anything in your database that is NOT an "object"
as previously described. As before, we have a range of types to consider.
Let's start with the easy ones. Purely transactional data is entered directly in your production environment. Examples would include
normal day-to-day employee personal data changes, self service activities, journal entries, and all of the other detail information normally
processed by the system. The user interface supports this activity, and as long as the system is stable, employees and end users take care
of the data entry and processing without involvement from technical support. No migration or testing of these entries would be needed before
entering them into production. Let's call this type of data "transactional" data.
Of course, before we can reach this normal production operating stage, the system must be configured. A large part of the configuration
involves entering other types of data. Let's call this "setup" data. (There are many different terms for these concepts. Translate my
terminology into your own.)
Setup data itself comes in different flavors. At one end of the spectrum are the very fundamental types of data required to run the system.
The various flags on the INSTALLATION tables, which tell the system which modules are in use, are an example. On the other end of the scale
are items such as departments, locations, and accounts. These might be considered somewhat more "transient" in nature.
So, should the two types of data given in these examples be treated differently? I believe the answer is clearly yes. A proposed change to
a fundamental setup table should be tried and tested in development and/or testing environments and then either migrated or entered again
into production, possibly during a maintenance window. Changes to a department or vendor table, on the other hand, probably would be
made directly in production without any involvement from the developers and without any special testing.
Naturally, there is a "gray area" between these two types of data. Consider benefit plan setups. The addition of a new benefit plan is quite
different from modifying a few option prices. Both of these, however, probably lie somewhere between the fundamental setup data and the
almost-transactional data examples given previously. Where should these changes be implemented first, and how much testing (if any) should be
done? Once again, unfortunately, the answer probably depends on many factors. These include your familiarity with the tables and the processes
they support, the level of risk involved, timing requirements, and the skill and comfort level of your users, among others.
Last week I recommended identifying the various types of objects and setting standards for the development, testing and migration of each.
In the case of setup data, however, there
are a very large number of different types—and even within one type, the best method may change based on timing, scope, and the other
factors just mentioned. You might consider identifying a sort of "czar" for each functional area. You probably already have an obvious candidate.
This person ideally has a mix of both functional and technical knowledge, in addition to good lines of communication with both the end users
and the technical staff. As each situation arises, this person can evaluate the perceived risk and other factors and can determine the best
course of action. Over time, as experience is gained, a set of "customs" will settle in and you will have found the best solution
for maintaining your setup data.
Next week, we'll have one more discussion of setup data, this time as it relates to initial implementations. Then we'll move on to other topics.
|
