There are many PeopleSoft HCM clients using the Base Benefits module to track enrollments and drive payroll deductions while Automated Benefits sits on the shelf as a “Phase 2 – that never happened” project. While it is true that you can use eBenefits without implementing the Automated Benefits module, that access is limited to viewing rather than enrolling in benefit plans.
In these days of tight budgets and under-fulfilled promises of cost savings from that big ERP implementation a few years back, many organizations still find it hard to justify another systems project. The true benefits of modern day ERP systems are only partially found in the base functionality. Having all that integrated data won’t do you much good unless you use some of the advanced features like self-service. One of the biggest returns comes from automating Benefits Enrollment, particularly at Open Enrollment time.
Printing forms, mailing packets, collecting forms, manually checking eligibility and doing data entry is a slow and expensive process and prone to errors, which result in more work after the enrollment period.
Today’s Benefits Administration Module
Early versions of Benefits Administration had its issues – I know from hard experience. I first tried adding the Benefits Administration module to an existing installation back in version 5*. The program that determined eligibility and created open enrollment forms ran for three days and
would still be running today had we not cancelled it. We then touched base with other organizations that had tried the module and realized that it had many shortcomings so we had to customize it.
Today, I am happy to report that Ben Admin works almost too well – meaning your current base benefits data had better pass the rules or some employees will have their benefit enrollments terminated as soon as you switch over. The tools are very powerful and the configuration is complex but if you set it up correctly your benefits users will never have to make a decision with regard to eligibility or qualifying events again. That means, employees can elect their own benefits and you can stick to the more important work.
*If you are trying to calculate the year by version numbers, it was 1995. Version numbers came out more often back then so every other year was a new release - unlike today where full versions occur in a closer proximity to dog-years.
Planning Your Project
The first step is to create a plan – and because open enrollment period gives you the biggest payback and is the easiest event to configure, that is the perfect place to start. Take your enrollment period start date (when employees have to be able to log on and do elections) and work
backwards. Depending on the size of your organization, complexity of your plan structures and rules and the consideration of how well your current enrollment data will pass those rules – implementing automated benefits can run as short as three months and as long as a year. Most organizations will fall somewhere in between.
Resources
Functional Lead: Your lead person should be familiar with benefits eligibility and event rules as well as have an understanding of the HCM data. This person does not need to be a technical resource but should have no fear of setting up configuration tables.
Subject Matter Experts: Knowledge should include expertise in each benefit area and organizational policies. You may want legal specialists who can review wording on the enrollment pages so that they conform to your policies and provide clear and legally correct information to the employee.
Technical Lead: Person available to the project on a part-time basis who can research problems, apply fixes from the vendor if needed and migrate your configuration to production when ready. There is a small possibility you may need some programming to populate user-defined fields or alter enrollment pages but that should be minimal.
Functional Consultant: Expert in configuration and testing of Automated Benefits who has done multiple implementations (doing production support does not count) and has done at least one on the current release or the release just prior (in the event a new release is just out).
Not a shameless plug for consulting services: While many organizations feel that they could manage implementing Automated Benefits without help, it will take most people months to get a full understanding of the complexity and nuances of eligibility and event rules and many trial and error configurations to know which design works best. Think of it as going for surgery. Doing it yourself is possible but the stakes are high. If
you do go to a doctor for that surgery, would you want one who has done the procedure many times or someone who just got out of school? Look for experience.
If you do some of the analysis ahead of time you can save the consulting help for the more difficult design and configuration steps. Some of the tools shown below will help you get started.
Analysis Phase
I typically do the analysis part on a white board with a group of benefit experts in the room and convert to worksheets for documentation. Try not to do the program design on the fly – it’s best to gather information first, put it into spreadsheets and come up with the best design afterwards.
The analysis that follows will tell you if your HR data is structured in such a way as to allow eligibility rules to identify who is eligible for which plan options. You may need to change that configuration as part of this process, which can have an impact on other functional areas.
Plans and Eligibility
First, build a matrix with all of your plans listed in rows.
Add columns across containing all of the fields that can be used for benefits eligibility (there are 28 data elements so the example below only lists a few). You most likely will not need all of them. I typically use 3 or 4 core fields.
Then fill in the field values that make an employee eligible for each plan.
Sample Eligibility Matrix: Note: very simplified
Events and Event Rules
Once you have your plan eligibility done, move on to events. Those are the triggers that allow employees to make new elections because of job or personal changes.
Take all qualifying events and build your matrix with a specific event in each row. The delivered events do not usually cover all requirements (they are designed to be a sample not the end-all) so you may have to add events (found under the same menu as event rules).
Then add columns for each benefit plan type, even those that will not be impacted by the event, as we want to make sure to set those to ignore that event.
Once you have the matrix, start filling in the allowable actions in each benefit plan type when that event occurs. Be very specific as to which dependent types can enroll or change within that event. Example: Birth of a Child may allow you to add the ‘Child’ dependent type to coverage but not ‘Spouse’.
Sample Event Matrix: (under the plans list what changes are allowed for that event)
Your matrices will be much larger – more events, more plan types and more detailed information. I sometimes turn the plan type columns into four or five sub-columns and add each dependent type. See below:
This will make for a wide spreadsheet but a good tool for configuring event rules.
If you complete both of these matrices before you touch the actual configuration, it will make the design phase much easier and save a lot of trial-and-error.
Design Phase
The goal of design is to come up with the simplest configuration that still allows the system to automate the rules. This is not as easy as it sounds. A simple design means you will have to burn some brain cells (not covered by benefits by the way) and rework the configuration multiple times. This is why it is best done on spreadsheets first then configured in the setup tables.
The ideal design is ONE Benefit Program. When you had only base benefits you probably used Benefit Programs to manage eligibility because
it was all you had.
During the design phase, you will also want to create a prototype in a separate test database so that you can better see and understand the workings of automated benefits.
Development Phase
Development often means conversion and customizations. For this project, it is mostly configuration and unit testing.
The order of configuration/development should be as follows:
Benefit Plans and Attributes – If you have any changes or new ones, get them defined first.
Rate Tables and Formula tables – As with benefit plans, use this step only if there are changes.
Eligibility Rules – Because eligibility rules are applied at the plan/option level you may have many more of these than Event rules – however, they can be shared.
Event Rule (note: Singular) – Because they are tied to a plan type, you might be tempted to create event rules for every plan type (can also be shared but less often than eligibility rules). Event rules are not only complex but tricky to understand (and People Books do not do an adequate job of explaining consequences of each option choice). You will find that you have to adjust and tinker with Event rules quite a bit. Once you have one working very well, clone it to create the others.
Program Structure – This is where you tie all of the setup tables together. In this case, you will be continually adjusting the program structure as you validate the event rules (and add new rules). Start out with the first event rule for all plan types. As you test event rules and create (clone) additional rules, update the program structure.
Text Catalog – Do not modify self-service pages. The text catalog (if you know how to find the right message numbers) makes it easy (well – easier than customizations) to change text on the employee self-service pages. The text can even be tied to different benefit options and change with employee elections.
Reports – New technology brings with it the need for new reports to help manage processing. The system comes with some very good reports but you may need additional reports or queries to let benefits administrators know of potential problems such as open events that were for some reason not finalized. You will likely find what you need during testing if you have not done a proper fit/gap and prototype session up front.
Customizations – While the system works very well and core processing should need no customizations (if you are good at configuration), there may be a custom program or two that you will need. One example: For one organization, we wrote a program to close events that had no election options by the employee. Some events triggered a change in certain benefits such as sick plans but those were auto-enrolled (no employee selection) – but unless someone opened that event, it was never flagged for finalization. The program we added (ran nightly) identified those
events and turned on the Finalize flag.
Testing Phase
Testing is the single most important part of this process. During a new implementation, we (CedarCrestone) usually have users identify every
possible scenario they can come across for employee types, multiple jobs and benefit configurations.
Since you already have your employees in the system, use them for testing but be sure to find those problem cases that I am sure you know about from maintaining them today. One project I did for a company that owned a movie studio (who shall remain nameless) used Clint Eastwood as one of their test cases because he had so many jobs (director, actor, producer, advisor, etc.). Another employer had one person with 12 children (how they found time to work, I don’t know) and was always included in their test cases. You probably know who your problem cases and exceptions to the rules are. Exceptions can be grandfathered into eligibility if you want.
Training and Change Management
While testing is the most important part of implementation to get your system functioning properly, failing to properly inform and provide training to employees could be disastrous.
Many organizations run what is sometimes called a “Benefits Fair” prior to open enrollment. That is usually a good time to add another booth to demonstrate use of the automated enrollment feature. This is just one method and should not be the only one. Pamphlets and presentations work well too.
The best tool for the employee is on-line help. There are several options, such as the UPK product, that allow you to build on-line training and demonstration videos. These allow the user to do their own just-in-time training.
Deployment Phase
Baseball legend Yogi Berra used to say; “It’s not over till it’s over”. Just because you have turned automated benefits on and employees are on-line enrolling, it does not mean your work is done. The first deployment (most likely open enrollment) will need monitoring and sometimes even some adjustments (hopefully not).
Now you have the choice of turning on the other events such as Hire, Promotion, Termination and the “Family Status Change” events, including spouse loss of coverage, birth, marriage, address changes, etc. I have had some institutions specify over 40 different event types, which actually reached a limit within the program that runs Automated Event Processing (an internal table that never expected that many event rules – requires
a simple COBOL change that is well documented by Oracle but that they never actually patched themselves – you may have to do that one).
Some organizations use automated benefits for open enrollment alone, others use the other events but have a benefits user actually perform the data entry, and still others open all events to the employee to both trigger and make elections. Version 9.2 has more self-service options than
previous versions so timing implementation of automated benefits with your next upgrade may be a good strategy.
Final word
I have implemented just about every module in the PeopleSoft HCM suite over the years, and Automated Benefits is always the most fun project
I get to do as a consultant. It is challenging but doable. Think of it as a big puzzle that once put together does a great job of saving time and money for your organization. Have fun with it.