Given the weakening economy and the stock market’s rocky course during the year’s first weeks, it is not surprising that analysts are predicting tech spending cuts. While tech-budget trimming can be expected, Dan Farber reports that some observers are predicting a less precipitous spending drop than in 2001. He also notes that there are even a few who predict that Enterprise 2.0 service providers will profit from corporate belt tightening.
While it has been a month of gloomy economic news, my outlook has been somewhat buoyed by the number of inquires I’ve received from employers beginning or in the midst of significant HR integration or process re-engineering projects. Perhaps this is anecdotal evidence that more CIOs recognize that cutting investments aimed at making the enterprise more productive is the last thing you want to do in an economic downturn.
Indicative Data: Swiss-Army-Knife-Like Capabilities for HR Integration
More large employers are looking to HR-XML for standards to support the integration of employee data from branch locations to central HR or payroll systems. What does HR-XML have in it’s library to fit the bill? If time worked data is of interest, then HR-XML’s TimeCard is an obvious choice. However, the specification with Swiss-Army-knife-like capabilities for many employer integration needs is HR-XML’s Indicative Data specification. Indicative Data provides a snapshot of employee information. It is used to provision HR, benefits, and payroll systems. It can be used to create or update individual employee records or to handle changes in batch.
While I’ve sung the praises of Indicative Data as the flexible specification for use in synchronizing employee data, most implementers quickly hit a stumbling block — They find something they need is missing. What might be missing? This can be highly variable. It might be company-specific, industry-specific, or data otherwise outside the Indicative Data design scope. Among the items specifically outside the design scope that employers frequently want addressed is payroll setup information. Why did we leave it out? Hopefully it is obvious that binding the HR-XML specification tightly to payroll tax law would not be a good thing. You don’t want to rely on HR-XML community to interpret tax law. Building in this support could be problematical if scoped to a single country and nearly impossible to roll-out internationally. The important thing for implementers to realize is that adding this data is pretty easy.
IRS Form W-4: Example
In the United States, a new employee completes a Form W-4 and provides it to his or her employer so it can withhold the correct amount of federal income tax from the employee’s pay. Employees then file updated W-4’s when their personal or financial situation changes. This type of data is outside the scope of Indicative Data, but can easily be handled within a UserArea as shown in the example below. Take a look at the full example extension schema and example instance. To understand how this works, see my prior post on using the UserArea. Pay particular attention to the name space declarations.
<UserArea>
<ext:USWithholdingDetails>
<ext:TotalAllowancesNumber>4</ext:TotalAllowancesNumber>
<ext:AdditionalWithholdingAmount
currencyID="US">15</ext:AdditionalWithholdingAmount>
<ext:ExemptIndicator>false</ext:ExemptIndicator>
<ext:SignatureDate>2008-01-24</ext:SignatureDate>
<ext:OfficeCode schemeID="Store No">11111</ext:OfficeCode>
</ext:USWithholdingDetails>
</UserArea>
It Gets Better: Indicative 3.0
The above example uses the 2_5 specification. Indicative 3.0 is on its way. A draft is available for review. There is a lot of good thinking in the draft. What I think you’ll find in IndicativeData 3.0 are components and patterns we’ll be using throughout the library in describing employees. For a glimpse of how this might work, take a look at other drafts such as SavingsPlanEnrollment.