Hello Russ,
Let me start by saying that what will follow is only my personal opinion based on the few elements shared.
If you require a more in-depth analysis based on your full context, feel free to reach out to us and we will put you in contact with our Professional Services team.
To me, it sounds like this new HR system constitutes another source, so another publisher.
With its own specificities and rules.
So I would handle it as such and load its data through a new publisher.
However, what I'm not understanding is why you would need to delete the data associated to the old HR system (maybe for security/regulatory purpose?).
Because if not, and if you want to keep a trace of the data from the old HR system, then you can leave it as is in your MDM.
The only thing to keep in mind, will be to adjust your rules (matching and survivorship specifically, to deprioritize this old publisher and to include the new one) and replay matching for all involved publishers.
Thanks for the quick response Alexia.
While it's true we could simply treat the new HR system as just another source, I'm not sure that would be the best option. On the face of it, I'm not sure that it makes sense to treat a system replacement the same as an additional system.
In terms of the effort involved, it would likely be much simpler to re-use the current HR publisher ID, since (for the most part) all we would need to do is start publishing from the new system using the old ID. The downside is that the old publisher ID wouldn't match the new system. Also, I've been informed that we will only be bringing current employees into the new HR system, so we will need to keep the old master data, and as a result it would be unclear whether the old HR system or the new one published the master records (though I suppose we could add our own 'publisher' attribute to get around that).
If, on the other hand, we create a new publisher, there are many other implications (some which may not have been immediately obvious as I did not mention that we have an associated basic entity which stores affiliation data for staff - basically each row has an employee ID and affiliation type of 'staff' or 'retired').
Hello Russ,
It seems indeed that the solution will be heavily dependent on your context and all its specificities.
Do you want me to transform this topic in a ticket, this way I'll be able to transfer it to our Professional Services team who will be much more equipped to dig on this implementation topic?
That would be great! I initially tried opening a ticket, but I was redirected here since it was a 'how to' request.
Thanks again!
Russ
We presently have our HR system feeding Semarchy, but will be replacing our HR system, and are struggling to determine whether we should be adding the new HR system as a new publisher ID and clearing the master data from the old one, or if we should simply re-use our existing publisher ID. If we go with the first option, it seems we would lose all of our historical data and manual matches, and we would have to find/replace all sorts of references to the original publisher ID (in survivorship rules, integrations etc.). If we go with the second option, the Publisher ID would conform to the name of the old system, and it would not be particularly obvious which system actually published the data.
Any thoughts?