PeopleTools Wish List
- 1 PeopleTools Wish List
- 1.1 PeopleSoft - The Module
- 1.2 Improve Cost of Ownership
- 1.3 Decreasing Test Time
- 1.4 Encouraging Third Party Modules
- 1.5 Other PeopleSoft Enhancements
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.
PeopleSoft has enormous strengths - a mature application that can be tailored to your exact requirements.
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, PeopleSoft can be modified to ensure the smooth running of the business.
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
(PT8.55 update: This has been delivered - custom code can now be applied as Related Actions - keeping them separate and configurable). 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. Private functions and properties would also need to be available to the shadow class. As more PeopleSoft functionality is based on classes, this would reduce the impact of customisations.
4: Keeping Other Objects Separated
Records have a standard subrecord (at the end) to hold custom fields. Pages have a custom "overlay" on top of the Vanilla code - the overlay allows addition, deletion and moving of fields. The vanilla can still be changed but the need to do so is greatly reduced.
Decreasing Test Time
In any major project, testing takes a very significant proportion of the time, effort and budget. Oracle have developed the test framework and are presumably using this internally. If the test cases were released (even if just for core and new functionality) it would have a significant impact - showing ways in which the technology can be used as well as helping test those areas covered.
Releasing any test harnesses for the supplied classes would enable retesting of customisations quickly and easily. This would also develop best practices in the customisation field.
Encouraging Third Party Modules
Oracle (nor any other software provider) cannot, on its own, create all the modules and functionality that is required in every business sector. By actively encouraging a third party market by making customisations cheaper covered above, and by actively creating an apps catalogue of third party extensions to the PeopleSoft product.
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
- Application Designer store who, when and which project when PeopleCode altered. It would save a lot of boilerplate comments. These comments could be seen or hidden.
- Automated commenting of code. With each piece of custom code, developers add a comment stating who and when it was changed and which project it has been added to. Application Designer already knows all this. Why doesn't it keep track of such info, leaving the develop simply to write the code? Also, such automatic comments can be hidden so that the flow of the code can be read, rather than interrupting every couple of lines because an if statement was added.
- Related items in Application Designer projects. Just a simple list (that appears in the left hand pane) of objects that are not changed by the project, but may need to be be referred to.
- Grids to be able to behave more like spreadsheets - able to copy and paste cell blocks to and from other programs such as spreadsheets and other programs with tables