Workforce Planning isn’t very Groovy. Most workforce planning applications come out of the box with the ability to add and edit To Be Hired (TBH) members by using either dynamic member creation or generic TBH members. This works very well if the TBH members you are adding are all for the same Cost Center / Department / Job Code.
What the users figure out very soon after implementation is that the TBH members they need to add are seldomly in the same Cost Center / Department / Job Code. This causes the admins to go through a sorting exercise to get each TBH by Cost Center / Department and so on. This is a very time-consuming effort, especially if the TBH form they are using runs a Business Rule (calculation) on save. Then they must run the Business Rule multiple times to get every combination of TBHs they need entered. Definitely not Groovy.
This time-consuming exercise led several clients to ask me to build them a “Mass Add” from a single form which allows them to select the Cost Center, Department, Job Code and other dimensions on the form using a Smart List (PBCS’s term for in form dropdown selections). Admins and Users can then input all the TBHs they need into a single form and only submit and calculate once. Let’s see how Groovy can help.
Groovy Steps
Before Groovy was introduced to Enterprise edition of PBCS (now Oracle Cloud EPM Enterprise), this was not possible, but now workforce planning can be groovy.
- Specify the dimensionality for which the TBH should be added (Entity, Location, Cost Center, Project, Job Code…) using Smart Lists that are created in Oracle Cloud EPM based on these dimensions.
- Add account data for the TBH as well as the number of TBHs for the row and a description for the TBH. Using a combination of Smart Lists, Text and Numeric accounts, we can add all required accounts to the columns of the single form.
- With Groovy, we validate each of the Smart Lists and flag any of the rows that have missing dimension data or have invalid dimension combinations. If any validation errors are found, we generate an error message to display to the user so that they will know what row and validation issue to resolve and then cancel the save so that the invalid data is not sent to Oracle Cloud EPM. This validation method can be extended to the account input columns as well.
- If we are working in an existing application that has been tested and deployed, we don’t want to modify the current Business Rules. Unless of course you want to redo the UAT process (I am sure someone out there would enjoy this, but I haven’t met them yet). Utilizing the capabilities of Groovy again, we can call the original Business Rule for each Row and pass it the data from that row. So, once the validation iteration is complete and we determine that there are no validation issues, we can do the iteration again passing each row separately to the original TBH Business Rules.
- To ensure that we don’t send the same TBHs multiple times, if both iterations are successful (Validation and Calculate), we simply clear the form and the temporary data from PBCS that stored the form values.
- In addition to TBH, this methodology can be used to do mass edits, terminations, and transfers on a single form.
If using the out of the box TBH functionality has you feeling down, make the switch to this functionality. I think it is safe to say you will be feeling groovy in no time! Want to get creative? Ask us about this functionality and how it can also be extended to applications outside of workforce planning.