Benefits – love or hate them, they are one of the primary compensation components for why employees join an organization. Let’s face it, in today’s marketplace, benefits are expensive for employees to purchase and time-consuming for benefit teams to maintain. Having all the cogs of the benefits team well-oiled and churning efficiently shouldn’t just be a wish: it is a must!
I have had the opportunity to work on many benefit projects and have seen Infor’s solutions implemented using various strategies: Lawson S3, GHR Benefits interfacing to S3 Payroll, GHR Benefits with third parties peppered here and there. With any of these configurations, the question always surfaces: how do I maintain enrollments to balance administration time and system resources?
I’m going to focus this discussion on GHR v11 Benefits, simply because it is the future of Infor’s benefit strategy. If you are still using the Infor Lawson S3 Benefits, trust me, I get it; it is tough to rattle what has been working seamlessly for years. However, this post is still for you! If you understand what it takes to maintain GHR Benefits, you will only be setting yourself up for success when it comes time to migrate.
GHR Benefit maintenance can be broken into three phases, which will make up this three-part series on GHR Benefit maintenance:
- Plan changes
- Pre-payroll tasks
In the beginning, there was eligibility. GHR benefit plans sit on top of carefully crafted, skillfully woven benefit groups and custom groups that communicate when and how an employee should be enrolled in a plan.
Judicious planning should go into developing these groups, striking a balance between custom group complexity and system performance. Here are a couple rules of thumb for consideration:
- Do Not Hardcode: We’ve all been there, staring at the screen trying to figure out how we can somehow group a handful of employees together. If you must hardcode, don’t go crazy with it! If you end up with a group of 500 employees hardcoded, benefit jobs that look at eligibility are going to take FOREVER to process. Seriously though, I have come across cases where hardcoding has been taken to such an extreme that benefit jobs timeout and/or have memory problems because of hardcoded values. Are your benefit Async jobs taking an entire day to process? If so, peek at your custom groups--they could be hiding something hideous!
- Keep It Simple (stupid?): When you are creating your benefit plan and corresponding benefit/custom groups, you do not need to plug in a benefit group in every benefit group field on the plan. For example, if all employees that will be enrolled in a plan have the same entry rule logic (i.e., eligible on first of the month following 30 days of employment), you DO NOT need to use a benefit group on the entry rule. The same concept applies to coverage, contribution, and termination rules. This will save you from creating an astronomical amount of benefit groups, leaving you weeping when they start acting up on Friday afternoon.
- Async Check Membership: GHR has two modes to keep benefit groups updated: Saved or Dynamic. Dynamic means that as employees are updated throughout the business day, eligibility groups are being updated alongside those changes. For example, amazing Employee One earned a promotion to King, which comes with benefits fit for a King, making him ineligible for those “other” benefits. Employee One’s new employee status gets magically (dynamically) read by GHR’s custom groups, adding or removing the employee. Async Saved mode means that the refresh group membership job will need to be scheduled or the benefit group will need to be refreshed manually. It seems like a no-brainer to choose dynamic, right? Not necessarily. If you have thousands of employees and complex groups, it may make sense to refresh these groups overnight when system demand is lower.
For more information on the Infor CloudSuite solutions, or to view our webinars, videos, eBooks, whitepapers, and more filled with knowledge to help you succeed, go to our website at: https://www.roihs.com