- 8 Posts
- 575 Views
My department have allowed the Benefit department to generate their Open Enrollment forms in a testing environment from the start of time but due to limited testing envirnoment because of ongoing projects we no longer have extra testing envirnoment sitting around for the Benefit department to use exclusively for several months. We proposed that the Benefit department do everything in production or share a testing envirnoment with developers. I asked all the developers not to create any new data in the environment. The Benefit department arguement was with developer in the testing environment they are in, the forms will not print correctly. This is not the first time my department have asked the Benefit department to share but the person seems to forgot. Can Open Enrollment form be generate in production? The Benefit staff insisting it will cause issue and that Consultant have told them to do so. I do not believe that is the case and that the department misunderstood what was said. I was wondering how does other company handle open enrollment. Is it done in production or in another envirnoment? If done in another envirnoment wouldn't that cause data issue. How is the data issue handle?
I proposed that the Benefit department share, doing it in production or getting their own server but they do not like that idea. The person got angry when we cannot give them their own system. All I can say is they do crazy stuff.
I would say the benefits department could get a clone and run their reports in a UAT environment over a weekend if they wanted to get it done. Otherwise, they would have to share. Another option could be for them to pay for their own additional hardware and resources for the single node.
Thats the thing. This year we do not have the extra hardware sitting around for the Benefit department to do this. We do not mine if we have the hardware but we have on-going projects which will be complete before Open Enrollment finish. The Benefit department want a seperate environmnet just for printing the Open Enrollment forms and do not want to share with anyone. As far as on-going projects, it have nothing related to benefit.
I am not seeing any issues or concerns that the Benefit department say will happen if they do it in production. I see it as a good thing because the data is accurate and everybody will receive a worm whereas doing in a seperate envirnoment which do not get updated for more than a month is just old. i see the disavantage then the advantage of doing it in production vs on a seperate envirnoment.
If managed appropriately, the OE should not affect other benefit processes. Running BenAdmin to reopen or reset an OE can take time but if the OE availability is set to today, but not effective until let's say July 1, then they can go in and do all of their configuration and setup without causing other problems. The trick is that the Benefit Analyst performing the setup and configuration should be working with a Technical resource to extract all of the configuration data so that it can be easily backed up and moved between environments, and finally to production. We have done it both ways, with a dedicated HRBEN enviornment to get separate setup, and in DEV/TST/UAT to PRD. Last year our resources were severely constrained, so we worked in our DEV for OE config, scripting large data moves and configuration migrations, and would just reapply as DEV was refreshed or as we moved to TST/UAT. We actually use the migration path to test the scripting so that in UAT we are not manually entering anything if possible, then to go live we just run our scripts against PRD, App Designer project and file migrations, and then perform our administration processing.
If you did have a major issue with setup, or a huge change to the way you do business, I could see requiring a separate HRBEN, but it wouldn't need to hang around forever or be assigned to a single user unless you can afford it!
The person setting up Open Enrollment in the Benefit department in the past misunderstood the Consultant and have been requesting a seperate environment for their own use for several months just to print out Open Enrollment forms. Then she would move the configuration over to production later when it is time for Open Enrollment, which is two weeks later. In the past we just let the Benefit department do their things there own way because we have the hardware but with varies project on-going and close to completion, we just do not have the hardware for them to hold for several months. Our other projects will be in production before the Open Enrollment finish. Their arguement of wanting a seperate envirnoment to print out the OE form because by opening the event to print out form it will mess up their benefit process. I want to know how other companies or organizations handle Open Enrollment. Do they do similar practice like us or all things done in production.
I am confused by your question, can you explain a bit more? When you say you usually provide the ability for them to generate their OE forms, do you mean you provide them a separate environment, like HRBEN for example, where they go in, set up OE, set up all of their changes and forms for the year, and test the OE end to end? Or are you saying they do setup in Production and then you copy production to allow them to run their OE finalization?