Business Process (BP) Functionality
Business Processes have been described as 'the heart of Workday'. If you don't have the BPs built properly, you cannot function. A BP in WD is the set of tasks that need to occur as a part of an HR process. It is here that you establish and associate all the nitty gritty details such as approval chains, notifications, escalations, , validation, help text on the step, security of who is seeing what step, etc.
Examples of business processes include: Hire, Propose Compensation, Create Position and Termination. Workday delivers all the basic ones, and you just need to make the business decisions of how your process should work, defining the approvers, etc.
From a user perspective, they are easy screens to use--point and click, similar to using Excel. Anyone can set up a BP...however, it requires some skill and businss understanding to set up the BPs in the most efficient manner.
Considerations when setting up a BP
- Think about the future state process. It seems that many companies are implementing WD in the US first, and then other countries later. When setting up processes, you need to give it some thought as to: Will you have 1 big global Hire process or duplicate the Hire process per organization/country/region, etc? Otherwise, if you are not sure of your design, you will potentially need to change your BPs in a Production system when other countries come on board. Of course, if you duplicate processes and apply country specific rules, this will cause one result with troubleshooting and maintenance. If you build everything into one big one, it's a different result as far as troubleshooting/maintenance efforts. Both solutions will require work--it just depends on how big your company is, how different or standard the processes are, etc.
- Standardise where possible. This one goes without saying, as WD is built on the premise that your HR processes are standarized. However, when we started to do some analysis of local processes, we found quite a bit of variation, as well as local needs. For example, we had a lot of 'post-hire' activities, such as generating a parking permit in one facility vs. confirming that a safety training occurred in a plant with previous issues. We made a decision that any 'localized' activities that did not involve system tracking would not be embedded into the business process.
- How many approvals do you need? We debated this one quite a bit, as we had defined some processes with a 'Manager +1 approval' level, but then one part of the business wanted to add 'Manager +2'. It would have impacted our process design and cause some if/then work in our processes.
Tips for designing your Workday Business Processes
- Build the process flow on paper first, rather than in the system. Sometimes, it's helpful to see the process in action, in the system. However, if your HR colleagues cannot agree in the first instance to a proposed process flow, then it's of little use trying to automate that uncertainty.
- Gather the requirements before you start to build them. For example, knowing the user groups who can initiate the transaction, where help text is needed, etc. I would suggest to use something basic such as Word, and to fill in the details before beginning any build activities.
Overall thoughts
It's helpful functionality, and will allow for a lot more automation than we are able to generate out of our PeopleSoft system today. In addition, depending on how detailed you go with them--they will make for a nice user experience, especially for our managers, who will suddenly get a lot more visibility to data. Not sure how much the managers will appreciate suddenly being initiators of HR processes though!
As well, for those of us who are worried about automating outselves out of a job(!) WD's BP's actually create more work, as someone needs to maintain or design new ones, as well to monitor the queue, for processes that have failed or are somehow stuck. :)
No comments:
Post a Comment