We attended the NorCalPRUG meeting yesterday to listen to the users and try to understand where we could add value to their day. The meeting was fairly well attended.

I arrived a little late and only caught the tail-end of the Q&A session with the Oracle presenter. I sure did not want to be him yesterday. From the little bit I heard of the session and snipettes I heard during the day, he was not prepared to answer many of the questions presented by the users. While he handled the questions well, the content was not necessarily what the users wanted to hear.

The next presenter was Bob Stambaugh. His presentation on HR in the 21st century brought across the point that HR really needs a paradigm shift. In essence, the current systems are based on the '70s need to capture the data combined with some rudimentary forecasting that presents a linear projection of numerical data based on payroll, benefits, headcount, etc. When combine with the new generation of employees (gamers) and the fact that businesses have regional and departmental dialects, you get a very organic structure that is difficult to shove into the box created by the HR systems of today.

The driver of change needs to be the HR employees themselves. Even if the software can't see these issues, the people can. By 'seeing' patterns in departmental structure and using the existing HR reporting, the employees can make recommendations to management by giving this information and knowledge to the E-team. The E-team can be very receptive to new ideas and suggestions when given the right amount of information and a means to execute them. However, management tends to make quick decisions based on incomplete information. That means if HR personel are going to affect a change, they need to be well informed and fast to react when good ideas appear. HR is in a unique position (and because of SOX requirements may be in a position of extreme responsibility!) . Most data flows through HR and because of that they are able see the whole picture and make recommendations based on what they see. They just need the appropriate tools to make speedy, informed recommendations.

There are also tools outside of the org chart that can help with identifying existing patterns in an organization as well. Social network analyses can show all kinds of interesting relationships and lack thereof in an organization. These tools can identify the support structure for the organization's stars and what effect lay-offs and promotions might have to the organization as a whole. The lack of network links could also indicate problem areas. Since knowledge transfer in an organization can only be pushed not pulled (or conscripted), it pays to have links to all people in an organization to allow for sharing of information.

The conclusion of all of this seems to be that HR systems and employees require a paradigm shift to include more individualized service. And in the near future, HR employees may have much broader responsibilities and the systems of today may not be servicing those needs. Social network analysis should help feed information to organization to make the whole work better than the sum of its departments.

Tomorrow, I'll be writing up my notes from the afternoon sessions I attended.

Labels: Events

This is a topic that deserves several posts, because there are several ways to trick the PeopleSoft application to do what you want. The first posting is a discussion of Database Links.

Database links has allowed many a PeopleSoft customer to get around limitations in release levels, product integration, and a wide variety of other things. Here is a sampling of things that I've been involved with over the years (the earliest example coming from Financials 1.1 in 1993).

1. One of the investment banking firms used database links to capture transactions in DBS Millenium and use PeopleSoft for financial reporting and allocations.
2. Many PeopleSoft customers used database links to allow them to take advantage of features in PeopleTools 8.4x while keeping their application on PeopleTools 8.1x.
3. Yet another PeopleSoft customer used database links to allow them to continue using a depracated 3rd party product with PeopleSoft integration after they completed their upgrade.

Because PeopleTools uses record definitions as a layer between the physical table structures and the application logic, PeopleSoft customers have a lot of flexibility as long as the database link or view matches the dictionary of the database. A motto in the early days of PGS was "if you can't do it, use a database link or a view (views will be discussed at length in a future posting).

Here is how customers used database links to accomplish the previously mentioned tasks.

Using another system's tables in the PeopleSoft application

This is the easiest and most straightforward of the three use cases to solve. You take a look at the record definition in the PeopleSoft database (in this circumstance, it was the ledger table). You use the record name and field names in the record definition and you create a database link that has the same table name and fieldnames in it. You then look at the other system to determine how to source it. Much of the logic is similar to creating a view. You hard-code what you need, and you perform joins and unions to cause the fields to supply the appropriate values. In the Millenium case, they had to do a union 12 times, because each row in the millenium ledger table had an amount column for each period (whereas PeopleSoft has an additional accounting period column and stores all amounts in the same column, but on different rows).

Leveraging PeopleTools 8.4x features in a PeopleTools 8.1x environment

This one is a little more labor intensive, because you are essentially taking the tables in a PeopleTools 8.1x application and mapping them to a PeopleTools 8.4x system. Customers who do this are usually looking for reporting features added in 8.4x, such as run to window, improved process scheduler and report manager, and query enhancements.

If you are focusing on reporting, you do not have to worry about getting anything more than the record definitions mapped so that the reporting tools know how to select data out when doing reports. Again the process of doing the mapping is almost the same as in the previous section (but there are many more tables that you have to look at).

If you are doing this near the time you are doing an upgrade, the data conversion scripts can give you a cue as to how to do this mapping.

Continuing to run an old tools release after doing an application upgrade

You may need to do this if you are in the following situation:

1. PeopleTools has depracated a piece of technology that you want to continue to use (such as message agent).
2. You are not ready to upgrade a 3rd party product that is depracated in a new tools release (such as using Crystal Info instead of Crystal Enterprise... this is the one I was involved with most recently).

Again the process is essentially the same as the second example. You create the database links into the 8.1x environment, mapping from the 8.4x environment that is capturing the data.

Again, If you are doing this near the time you are doing an upgrade, the data conversion scripts can give you a cue as to how to do this mapping.

Labels: Database

I've had lots of conversations with both consultants and PeopleSoft clients about recommended approaches for meeting business needs. The primary question at hand is: should customers invest in modifying the delivered product to meet business needs or wait for something else.

There are two things that drive this decision:

1. The impact of modifying the software to future product releases. In other words, will the change make taking future maintenance or upgrades too expensive?
2. How long customers will stay on their existing PeopleSoft system. In other words, does it make sense to invest in the PeopleSoft system when they will be moving to something else eventually?

Rick Beers of Corning provided insight into this when he presented to the PeopleTools development team 3 years ago. According to Rick, project sponsors have already had to justify the ROI of implementing PeopleSoft and upgrading PeopleSoft based on improvements in productivity and controls. This means that even performing an upgrade will have limited support because of the cost and the fact that executives feel that they have already solved their ERP problems. This means that the bar is set extremely high for replacing a PeopleSoft system with another system (whether it be SAP or Oracle).

Therefore, a much more effective strategy is to look at the features that are needed in the PeopleSoft application and focus on addressing them. The current environment makes this approach much more feasable than in the past.

1. There is little risk that modifying the PeopleSoft application will create future upgrade risks. Products will not change dramatically with future maintenance, and Oracle will most likely want to protect its maintenance revenue stream from PeopleSoft customers and not force upgrades.
2. The impact to making specific changes to the applications are much smaller than taking a full upgrade or switching to a completely new infrastructure (which is what moving to Fusion will likely be, or what moving to SAP will likely be).
3. PeopleSoft delivers the source code for its products, unlike other ERP applications. This means that customers can make incremental changes to product behavior without writing a lot of code.

In essence, I believe that PeopleSoft customers should plan their investment in software like many people plan their investment in a house. If you need to add a home network to your house, you don't buy a new house, you hire a contractor to do the wiring (or do it yourself). Until it gets too expensive to meet your needs with your current home, you fix the problems one at a time because a house is a very expensive asset.

Labels: PeopleCode, PeopleSoft

Earlier this week, I helped a customer who wanted to use PeopleSoft nVision to do ledger-based reporting in EPM. Because their ledger and business unit structure was the same between their PeopleSoft Financials application and EPM, this was pretty easy.

The secret is the view NVS_LEDGER_VW, which nVision uses to find all the info it needs to access a ledger. The customer updated their Ascential maps to load the tables that were used in this view, and nVision magically worked.

There are some caveats to this approach, however.

1. The ledger definitions in Financials did not have to be modified to work in EPM. THis is important, because the pages used to maintain ledgers have not been implemented in EPM. Therefore, if you make changes to the tables or chartfields used, you will need to either modify the view or make changes directly to the tables.
2. The setid and business unit mappings are set up properly in nVision (and match the business units in the ledger definition). Again, one approach may be to modify the tables under the view or view itself, if you cannot use the same setids and business units in your finanical system.

Another approach is to do Query-based nVision reports (which is how the delivered EPM nVision reports access data). However, Query-based nVision reports do not know how to use timespans (which is pretty important).

Labels: nVision