Benefit Plan Mapping

A company's benefits can change during open enrollment, but they can occasionally change before an open enrollment as well.  Different benefit provider, employee and employer costs, or new benefits all together are a few reasons benefits could change before open enrollment.  Workday has the functionality to incorporate some of these changes. One of these functionalities is benefit plan mapping.  With benefit plan mapping you can easily transition a group of employees from the old benefit plan to the new benefit plan.

Benefit plan mapping is usually incorporated if a benefit provider changes before an open enrollment. It can also be used for additional reasons.  Workday does have some rules that are in place for this to work. I have listed them below:

-The old benefit plan should be removed from the new benefit plan year.

-For health care, insurance, and additional benefit plans, the coverage targets between the two plans must be the same. 

-The coverage level for the old insurance plans must meet the eligibility rules for the new plan.

-Dependents in health care and insurance plans must meet the dependent eligibility rules for the new plan.

-The employee contribution type (% or flat amount) in retirement plans must be the same, as well as the minimum and maximum values.

-The currency in the old plan must match the new plan. 

Recently I had a client who changed the benefit provider for their 401k retirement savings benefit plan.  At first you might think just change the benefit provider attached to the original 401k plan. This might seem like the simple solution for this problem, but making this change would adversely affect multiple downstream processes within Workday.  The old benefit plan and the provider could be included in integration, payroll configuration, calculated fields, and more.  

For this client I created a new benefit plan and attached the new retirement savings benefit provider to the plan.  I also created a new enrollment event type that included the 401k plan only.  After I had created the new plan I attached this to the benefit group for the employees that were being mapped to the new 401k benefit plan.  I did this by editing the benefit plan mapping tab within the benefit group and attaching the new plan there.  Once I had done this I edited the enrollment rule that is attached to this benefit group. On the enrollment rule I had to make changes to the start or waive coverage tab and the coverage rules tab to include the enrollment event type that I had created.  On the coverage rule tab I selected no changes allowed for the benefit plan and to default to current coverage or waive. By doing this I ensured that during the benefit plan mapping no other benefit plan could be selected. This also ensures that the coverage amount or percentage from the old benefit plan transfers to the new benefit plan.

After I did everything above the last step was to edit the benefit plan year.  I removed the old retirement savings benefit plan and added the new one to the current plan year.  After all of these items were configured I was ready to run open enrollment.  I ran open enrollment and the employees were enrolled in the new 401k benefit plan and their contribution amounts transferred from their old 401k benefit plan.  

Be sure to first configure and test benefit plan mapping in the sandbox or implementation tenants.  Do not move to production until this has been done first.  Benefit plan mapping is a great tool to quickly transition a group of employees from one benefit plan to another.  Workday does have a few rules in place that can be hard to work around when trying to map employees to new benefit plans. If your new benefit plan can't be used in benefit plan mapping because of the rules that I listed above I would suggest holding off on any benefit plan changes until open enrollment if possible.  

Click on this link to see a thread about benefit plan mapping on the Workday Community.  If you have any questions about benefit plan mapping please feel free to comment below. 

It All Started at a Call Center

Currently I am a Senior Workday Consultant working at Aon Hewitt.  I have really enjoyed working for Aon and their clients the past few months and I plan on staying with Aon for a very long time, but I was not always a Workday Consultant.  At one time I worked in a call center.  I was not excited about working in a call center at the time, but I am grateful that I took the job.

My wife and I were married in 2011, during this time I was still in college and my wife and I lived in a very rundown apartment across the street from the university I attended in Orem, Utah.  I was working towards a degree in business finance and my wife was finishing her degree in graphic design.  We did not have very much money so I had applied for a handful of full time positions.  As you can imagine most jobs that I wanted were looking for a business degree.  After some frustrating job interviews I ended up taking a job in a call center.  (I will refer to this company as company X)

At first working in a call center was a completely new world for me.  There were certain ways you had to answer the calls and scripts that had to be followed.  After a few days I got the hang of things and talking to angry customers no longer bothered me.  I did this for about a year while going to college full time.

While I had worked for company X for about 9 months one of my coworkers showed me the internal job posting site.  Since I was getting a degree in business finance, I wanted to have a job that reflected what I was studying at school.  I started to apply for internal jobs in this area.  This led to some success as I had a few job interviews with managers at company X in the finance department.  I got to know them and I would see them around the office sometimes.  I had been working in the call center for about a year when a position in the payroll department opened up.  One of the managers I had interviewed with before suggested to the payroll manager that I would be a good fit.  I met with the payroll manager and he hired me shortly after.

One of my first assignments in payroll was to implement a new time keeping system call TimeForce. This was a great first project for me.  I learned how to interact with all the department leaders at company X and learn what their requirements were for the time clock.  I learned how to lead discussions and configure the time clock to meet the needs of company X. Everything worked correctly for go live and the hourly employees at company X enjoyed this time clock compared to the old one that was being used.  We could also pull the time clock reports very easily into excel and import them into our payroll system.

After the success of this project I was put in charge of preparing and running company X's payroll on a bi-weekly basis.  There was a lot of manual work because job changes and payroll changes were done on paper forms.  I would then gather together all of these paper forms and manually enter the changes into the payroll system.  At that time company X was using GP Dynamics.  I quickly learned how to run payroll for company X and how to work with all the different departments to ensure that employees were paid correctly and on time.

One day I was invited to a meeting about possibly using a new payroll system called Workday.  I had never heard of Workday but after doing some research of my own I learned that it was a cloud based HCM.  I was intrigued by the idea because I had never though of the benefits of using the cloud for an HCM application.  I was told by my manager at the time that we would be implementing Workday to be the HCM for company X as well as payroll.  I thought this would be good experience for me and I was right.

Company X decided to use a mid sized Workday implementation partner.  This was the first time I had worked with consultants.  We had discovery sessions together and soon after we were working a lot of hours together.  Before I knew it I was working 60+ hour weeks and working late nights getting ready for our go live date.  I mostly worked on data gathering workbooks for payroll data.  Once this data was in Workday I was then doing parallel testing between the data in Workday and our old payroll system.  Before the go live date company X's HR department formed a new HRIS team.  Since company X was implementing Workday they would now need an HRIS team to maintain and update Workday.  After we went live on Workday I was brought over to the newly formed HRIS team because of my work on the implementation team.

I was sent to HCM training in Pleasanton, CA as soon as I joined the team.  I brought my wife and son with me since neither of us had ever been to the Bay area before and we had family who lived there.  I learned a lot from this class and I was able to pick it up easily because of my work during the Workday implementation.  I was impressed by the way Workday ran their trainings and I was able to meet more people that were in the Workday ecosystem.  While on the HRIS team I learned how to support each department with their Workday needs.  I maintained Workday, improved processes and company usability, maintained and improved business processes, advised employees and managers on their individual Workday needs and request, created and maintained Workday reports, maintained security access, provided training to end users, and researched and resolved HCM problems.  I would create test cases for these changes and test in sandbox.  I learned how to record my findings from testing in sandbox in an efficient manner and make these changes in production once my testing was finished.

During my time in HRIS I graduated with my business degree in finance.  At this point in my career I had learned so much and I had developed my skills in Workday.  I had learned how to use Workday the way that company X wanted to use it, but I wanted to learn more about how other companies used Workday as well.  After spending three years with company X I accepted a position as a Workday Principal Consultant.