ERP Associates, Inc.

Here is an opportunity for you and your company to provide input into the future Fusion application.

Oracle has developed a new SQR called CUSTINFO -- the Customer Intelligence SQR. According to the International Oracle User Council,

Oracle would like your help so they can better understand their customer's customizations and setups as we design and build their Fusion application suite.

You can find the CUSTINFO SQR on Customer Connection under Support > User Groups. If you choose to run it, it will

extract key meta data and table counts from your environment. The resulting flat file, which does not contain any sensitive customer data, can be sent back to Oracle.

The CUSTINFO documentation claims

This info will be consolidated with responses from other Enterprise customers and used by our strategy and development organizations to better understand common areas our customers have customized, their setups and the typical features our customers are using.

I don't know about you, but I was kind of curious as to what was being extracted. Here's what I found:

The program only looks at the metadata. It doesn't look for customized SQR's, COBOL's, Crystals, etc, although it would identify custom batch objects by looking for custom process definitions.

First, the script prompts you to enter your company and contact information.

Then it gathers information around your Database Platform, Tools Release, Application Release, number of rows in each PeopleTools table,

Then it begins to answer the following questions:

• How many rows are in each application table? This lists each table name and the row count


• What are the batch processing times for the last quarter? Includes process name, process type, and average run time in minutes


• How many user ID's are set up in PSOPRDEFN?


• How many users have logged on in the last seven days?


• How many users have logged on in the last year?


• How many users have access to each component? This lists each component by name and provides a count of how many users can access it.


• How many roles are defined?


• How many permission lists are defined?


• What is the base language?


• What are the other languages are loaded?


• Is this a Unicode database?


• Which records and fields have been added or changed? This lists each custom and customized record and fields by name.


• Which labels have been added or changed?


• Which components have been added or changed?


• Which pages have been added or changed?


• Which page.fields have been added or changed?


• Which PeopleCode programs have been added or changed?


• Which AE programs have been added or changed?


• What PS Queries have been added or changed? This lists all new or modified queries by name.


• How many channels are defined?


• How many total Component Interfaces are defined?


• What Component Interfaces have been added or changed?


• How many total app messages are defined?


• What app messages have been added or changed?


• Which navigation CREFs have been added or changed?


• Which trees have been added or changed?


• Which workflow activities have been added or changed?


• What Record Groups have been added or changed?


• How many Business Units are associated with each Record Group/Set Id combination?


• What trees are defined, do they use Dynamic Ranges, and how many nodes and leaves do they have?


• How many trees are defined (including non effective rows)?


• How many tree structures are defined?

On the surface I don't see anything in this file that I would consider overly sensitive. At the same time, I'm not crazy about Oracle tagging this data with specific client information.

Query names might not be something you want to share with Oracle -- you never know when your HR manager might create a query called "LAYOFF_LIST_2006" or your IT manager might create "ELIM_ORA_SUPPORT_JUSTIFICATION". But on second thought a little creative query naming might not necessarily be a bad thing during maintenance renewal time...

If I was a hacker, the information about roles, permission lists, and user counts could be interesting but without actual user/role names I don't think it would help much.

So should you run this thing or not? The bottom line is that I think all PeopleSoft customers should take an active part in defining Fusion. Run the extract, participate in your users group, e-mail your account manager. Do whatever it takes so that Oracle knows about the PeopleSoft functionality your business depends on.