Thales750,
The question you asked is actually the core of at least one fairly well-known business - PeopleSoft. They have a data layout and optional modules for business management including payroll, benefits, taxes, insurance... the problem comes about when you wanted to do something that wasn't part of their "standard" offering. Then you have to pay through the nose to fix things that conform to YOUR business model.
In answer to your direct question, you must do a lot of research on just how closely this "commercial off-the-shelf" (COTS) project matches what you actually do, and how much of your business model are you willing to change to begin using the COTS product. The closer the match, the more likely it is that you can make it work. But when there is a big divergence between your model and the model used by the COTS product, that way lies pain, monetary disaster, and (if it is a big enough "fail" - a touch of ignominy.
This business-model/COTS-model mismatch once led to a billion-dollar screw-up. You can look up DIMHRS as the case study. I watched it happen.
In brief, the U.S. Congress tried to achieve a savings by converting all services to use a single personnel management system, Defense Integrated Military Human Resource System, which would have been powered by PeopleSoft. The problem was that the major military branches each had their own systems and were not willing to change the way their internal business models worked. (Yes, the military thought of themselves as having a business model.) That discord on business models meant that they couldn't reach common ground and the project fell apart over the squabbling of how to manage military personnel.
It started with PeopleSoft coming in to look over each major branch's HR system. The PeopleSoft "modules" were oriented to the commercial HR world, but the military world has radically different ways of doing personnel business. (Not the least of which is that if you try to quit during wartime, it is called "desertion" and they shoot you.) But even in peacetime, there were RADICAL differences between military and civilian HR.
For the Navy Reserve, PeopleSoft identified over 3500 such differences. EVERY MAJOR MODULE of PeopleSoft had to be modified. But worse, every module had to be modified DIFFERENTLY for all of the services. (We didn't have the Space Force yet, so only five services, and the Coast Guard used something similar to the Navy's system - though not identical.) Eventually, the evaluation was made that the Navy would only be able to use 19% of the code extant in the PeopleSoft modules. The next competitor was an ORACLE package because ORACLE hadn't yet bought out PeopleSoft. They were an 18% match. The contract was awarded to PeopleSoft on a 1% difference in usable code.
The problems that abounded included such things as the database engines getting swamped because PeopleSoft did EVERYTHING by Triggers - so the database servers went "compute bound" trying to resolve the stack of triggers that applied to each record. The best hardware we could get could only manage a 36-hour run-time on the daily processing cycle, and there were no shortcuts available such as skipping a step, because with the military, you do things in the right order or they don't get done. (It's a military oversight sort of thing.) Eventually it became clear that DIMHRS was not viable and Congress pulled the plug.
Here are some articles on the subject:
Shrinking Department of Defense budgets have resulted in a greater focus on IT project expenses. The Defense Integrated Military Human Resource System (DIM...
ischool.uw.edu
After spending $1 billion and 12 years of effort, Defense officials have pulled the plug on a hapless plan to bring the four military branches under a single payroll and personnel records system.
www.stripes.com
One year after the Pentagon canceled an $850 million payroll system that never became operational, the last of the contractors who worked at the project's New Orleans home base are
www.nola.com