About 5 years ago, Qualcomm in San Diego was presenting at various meetings nad user groups to show off the employee self service module they had built in-house. At the time, it made sense – self service UI’s were still maturing, functionality was not well deployed, and interactivity and workflow were immature.
5 years later, Qualcomm is still one of the few who hold most of their HR development in-house. While I refuse to condemn this practice, it truly doesn’t make much sense to me, and I’ll have to admit that Qualcomm’s HR department seems to be doing something right: “MySource has been a factor in earning the company a spot on Fortune magazine’s list of the “100 Best Companies to Work For” eight years in a row, Morlock says.” ((Frauenheim, Ed, July 17, 2006. “Homegrown HR Technology.” Workforce Management Magazine.))
The fact is that in the 90’s and early parts of this decade, the entry costs to getting a good ERP system were significant, and I could see where creating the software yourself could be attractive. However, as technology has advanced, I can’t see an organization re-tooling an application from the ground up every time there’s a new leap in technological innovation and capability.
A newer approach to this problem is the use of a “rules engine,” which is a layer of software that allows business managers to change a policy once and have it automatically update all the necessary parts of the system. “I wish we would have had a rules engine in the very beginning,” Hemry says. ((Ibid))
A similar example would be XML and web services where re-tooling the entire application to be compliant with the newer web standards would be incredibly time consuming and costly. While it may have been cost effective for the first years, not being able to spread out upgrade costs over many hundreds of clients would absolutely explode any TCO you originally anticipated.
The plusses of an in-house built system is that you can be responsive to your business needs and specifically target functionality and design to the way your organization operates. This is assuming however, that you have an army of programmers at your beck and call.
By making virtually all its HR tech in house, Qualcomm is taking an ever-more lonely path. Just 10 percent of the Fortune 500 choose to build a significant amount of their workforce management software these days, down from 25 percent five years ago and 70 percent 10 years ago, Knowledge Infusion’s Averbook estimates. ((Ibid))
5 responses to “Building your own HRMS”
I don’t think they’re *that* crazy. We should chat 😉
T O S
I would be a bit wary stating that an HRMS system built in house helped them achieve the 100 Best Companies to Work For. That particular survey focuses very little if any on in-house HRMS and their effects on employee satisfaction.
My experience is that the success of internal projects is inversely proportional to their scale. Average-to-good IT departments can often build very nice single-task-oriented tools, but they rarely succeed at turning good tools into good systems. When they do, it is often because of one or two heroic IT guys. Rarely is there a systematic and ongoing commitment to maintaining the project, because it’s not cost-effective. So the cost savings are the same as one would see from buying the software but not the maintenance, etc.
That being sad, there is also a factor in here depending on how well-evolved the commercial products are. In the early stages of a segment’s life, the COTS offerings often bring so many compromises that there is a real opportunity for some companies to build something in-house that is simply much more effective. Whether this is worthwhile depends on how long one thinks it will take the vendors to catch up.
in house users have the advantage of only ordering what they want, baked one way, the way they want it. vendors, to whichever degree decided by each, carry features for a wider population of buyers, which greatly increases the complexity of development, support, training, etc. furthermore, much software company revenue goes back out for sales, marketing, admin, and scale items not needed to simply support a library of software code within an organization.
if organizations have strong competencies in software development (full cycle- design, code, test, doc, deploy, maintain, replace) they can often easily succeed without a package for a given functional grouping.
however, since most firms are middling to poor at software (even many software firms…) the package holds value. the likely winner is having competencies that allow you to exploit packaged software, producing a wider range of choices and more ways to succeed on projects dealing with functional groupings for a set of users.
We have found that when an organization is asked to put a new technology on their network that it takes a long time to get it through the process. IT is concerned about security and integrity issues. The business user of the system needs the system up and running immediately.
For absences and tardiness we have an automated call in and notification and management system called ATS™. http://www.qquest.com/ATS/tabid/62/Default.aspx
We have a version of ATS™ which is hosted by us and an enterprise version of ATS™ which is on the customer server.
We can generally get a customer up and running on our hosted web based system with in days. The customer ability to proceed is all that hinders getting ATS™ up and running.
The enterprise version which is hosted by the customer takes months to get it up and running because of the internal checks and balances; the involvement of more people; the learning curve to get all of thee people on the same page and the greater difficulty to schedule meeting with this larger group of people.