PeopleTools Wish List

=PeopleTools Wish List=

==PeopleSoft - The Module==

Why isn't PeopleSoft a Fusion/Oracle HCM Cloud module? Surely it makes sense to adapt PeopleTools to the Fusion setting. Yes there would definitely be technical challenges, but surely none so great that Oracle could not overcome?


This would decrease the perceived risk of adopting Fusion for PeopleSoft customers and therefore increase the take up of Fusion, making it a strong powerful product with key differentiators from the competition. In turn, PeopleSoft customers have a reduced resistance to other Fusion modules such as Taleo/Recruit.

==Improve Cost of Ownership==

PeopleSoft's key strength is that the application is easy to customise and enhance. Translation: PeopleSoft can support your business processes, now and in the future. In areas where processes and procedures need to adapt to best practices, legal requirements and the business changes happening in that sector.

One criticism that this amazing feature gets is the cost of an upgrade. Oracle have made in roads into reducing this with the PUM image releases. Now it is trivial to download and review the latest PeopleSoft code base.

Decreasing the cost of keeping current means decreasing the impact of customisations. There is a body of development standards and techniques created by partners and customers to try to make customisations easy to spot and separate from the PeopleSoft vanilla code. Many of my ideas here are to embed these good practices into PeopleTools and almost make them mandatory.

===1: Naming conventions===
Virtually every site I have been to utilises a naming convention of prefixes or suffixes to denote custom code. Often this is a 1-3 letter code (usually derived from the company name) followed by an underscore. Each customer has picked a different prefix and a mildly different way to get around the "awkward cases" where a prefix would cause an issue with functionality.

If Oracle named a recommended range of prefixes that they do not use in the PeopleSoft apps and never will this would be a good starting point. This fact could be then used to advantage with compares, audits etc.

===2: Holding a Copy of Vanilla within the Database===

Vanilla PeopleSoft code held separately from any customisations. The vanilla code would remain untouched and custom code would be held separately, so an upgrade could confidently switch the old vanilla code with the new code, leaving the customisations in place. If all three (old vanilla, new vanilla and customisations) exist in the database at once, compares could be much faster and so less costly than at present.

Additionally, reverting to vanilla code would be very easy (if custom code could be switched on or off).

How could this be achieved? Add a key field to each PeopleTools table stating the release of that code. PeopleSoft releases would always have a set label format, allowing PeopleSoft to ensure the latest code is always in use. Customisations would be given a label that would override the vanilla code. There would also be a status field that allows custom code to be switched off.

This scheme could require a lot of changes to the PeopleTools code, so another option would be to hold the versions in copy tables of vanilla, and for Application Designer (and the PIA where applicable) maintains the copying to the resultant PeopleTools tables.

===3: Reducing Clashes Between Vanilla and Custom Code===

Finding and reapplying each customisation within PeopleCode is another significant chunk of the upgrade time.
Although it would not prevent all possible clashes, if there was a custom event after (or before or both) each vanilla event, many clashes in the code could be avoided, saving a lot of time.

Also, if each vanilla class could have a shadow custom class that could extend it without changing its name, this also would allow enormous flexibility without the upgrade penalty.

==Other PeopleSoft Enhancements==

Here is a list of fairly minor enhancements I would like to see in [[PeopleTools]] :

* Prompts have an Edit button that leads to the set up of the prompt
Where there is a prompt on a page, if the user has access to the set up page, they can access the setup of that item by pressing an edit button on the search prompt dialog.

Behind the scenes: in Application Designer on a record prompt, there is a new pair of fields to enter the Menu, Market and Component (or content reference) of the setup component for that item.

* Process Monitor - fewer clicks to get files, tools to find long running processes, currently running processes