Queensland Health Payroll system
A case study on business process management
and application enterprise integration
Raul Manongdo
Macquarie University, Sydney, Australia
[email protected]
Keywords: Business Process Management, Enterprise Application Integration, Payroll,
Queensland Health, Process Modeling
Abstract. In March 2010, the Queensland Health implemented the first stage of a planned
two‐stage implementation of its new rostering and payroll solution. This entailed replacing
the ageing ESP Kronos rostering system and out‐of‐support LATTICE payroll system with
Workbrain and SAP, respectively, as part of an initiative to introduce statewide centralized
shared services to government agencies. The state agency responsible for management was
CorpTech under the state’s treasury department and the prime contractor selected for deliv‐
ery was IBM Australia. [1] [4]
The outcome was described as a spectacular failure in many aspects; delayed delivery by al‐
most two years, at least 300% over‐budget, incorrect payments to 76,000 employees and
performance issues that necessitated significant more investments to fix and stabilize.[1][7]
Numerous reviews from various perspectives on legal, public administration, audit and tech‐
nical were made, engaging subject matter experts and independent bodies. The consensus
reached was the failure can be attributed to an ineffective project governance, unclear busi‐
ness requirements and the few business processes for supporting the project development
cycle were not adhered to and knowingly by‐passed by all parties. [1]
It would had been better if the existing business process were discovered, modeled, opti‐
mized and shared to all stake holders. This would form the basis for the ‘To Be system and a
more clear terms for engagement with stakeholders and external contractors. Business pro‐
cess suite in support of development and implementation could have been introduced to in‐
clude activity monitoring and control.
The risk of failure could had been mitigated by using a a proven and well tested integration
framework; using a partner API between vendor products or better still, adopting an open
web‐based standards in a Service Oriented Architecture.
1 Project Background
In 2002 the then Queensland Government established the “Shared Services
Initiative” the purpose of which was to amalgamate and rationalize government
services across a number of departments and agencies which had had apparently
been applied overseas to the public sector with some success.
The government initiative was intended to produce a
─ Higher standard of corporate service functions
─ Lower cost to government by reducing the acquisition, licensing and IT
workforce cost
By
─ Centralizing IT management and operations
─ Simplifying systems and business processes that can be reused by many
government departments and agencies
─ Adopting a uniform set of business applications and common set of comput‐
er technology platform.
CorpTech under the Queensland Treasury, was to manage this initiative and in
August 2007, engaged IBM Australia as prime contractor for delivery. This is so
as to significantly accelerate the implementation time line giving priority to
legacy systems that will soon have no vendor support, as was the case of the Pay‐
roll system at Queensland Health (QH). [1]
The Queensland government had
─ 15 legacy payroll systems in 13 different government departments from
providers SAP, Aurion, LATTICE, and TSS. [9]
─ QH covered 15 regionals districts. Shared services and the various payroll
district hubs manage the payroll system. [3]
─ LATTICE is used for payroll and ESP Kronos for rostering. This was imple‐
mented between 1996 and 2002. [2]
The LATTICE package was becoming obsolete and support from the vendor
Talent, was to be withdrawn in 2005. The Department’s rostering and payroll
environment is largely paper‐based. Shift changes, movements between posi‐
tions and leave applications are all submitted via line managers using paper
forms.
2 Proposed Payroll System
The State decided upon Workbrain and SAP as the products for the whole‐
of‐government HR and Payroll Solutions. The product mix used was chosen be‐
cause of a proven core payroll solution (SAP) and others considered as best of
breed.
• SAP ‐ SAP HR Payroll will be used for payroll processing and SAP CATS
functionality will be used for non‐rostering agencies. In addition to cap‐
turing attendance data, some of the information processed in SAP Payroll
are fixed allowances, superannuation, deductions, taxation, payroll report‐
ing, payroll processing and separation processing.
• Workbrain – for time related allowances, overtime, penalties and other el‐
ements that will be interfaced into SAP. Its awards engine is to be used to
configure all time related award conditions and business related pay
rules. Pay rules was claimed to be mostly done via configuration and not
customisation.
• Recruit ASP and SABA. [5]
The HR/Payroll solution was to integrate to key existing Queensland Health
enterprise architecture that are mainly in SAP. These are:
─ Financial and Asset Management
─ DSS (Decision Support System)
─ HR Systems
3 Project Governance and Delivery Challenges
3.1 Complexity of pay rules
The Queensland Health’s payroll system was “uniquely complex” [4]
─ 85,000 staff were employed under two different Acts, covered by 12 dif‐
ferent industrial awards and impacted by six different industrial agree‐
ments,
─ 24,000 different combinations of pay created as a result
─ 3,200 employees with concurrent employment arrangements. A
employment arrangement involves an employee having multiple positions
within QH at the same time and different employment conditions / enti‐
tlements for each position.
─ Each fortnight, 1010 payroll staffs were required to perform more than
200,000 manual process on about 92,000 form
─ The solution architect from IBM stated that the number of awards isn’t the
issue; it is the complexity of the pay rules that support a given award.
As a consequence, a significant number of customisations were made to
Workbrain (1,029 customisations) and SAP (1,507 customisations) and with
more than 130 manual workarounds. These in turn introduced significant com‐
plexity into the administration of the payroll system itself that impacted on sys‐
tem performance.
3.2 Short delivery time frame:
The project duration for delivery of the live system was only 8 months. In
contrast, its predecessor system, LATTICE, was rolled out in 6 years done
through stages. [1]
The implementation strategy was for statewide cutover to production in all
QH districts in a single deployment. [5]
4 Stakeholder Management
The project stakeholders were: [3]
─ Queensland Health, as customer, which had the following subgroups.
o QHIC (Queensland Health Implementation of Continuity) project team
with responsibility for managing the project.
o QHEST project team (Queensland Health Enterprise Solutions Transition)
who provided project management, business transition and functional
(HR and Finance) support.
o Payroll Stabilization Project team.
o Shared services provider and district hubs who have responsibility for the
processing of payroll
─ CorpTech, in their role as contract manager and owner of the whole of gov‐
ernment payroll solution
─ IBM, in their role as systems integrator and prime contractor.
─ Unions representing Queensland Health staff.
─ Department of the Premier & Cabinet, Public Works and Treasury
In measuring the value of its IT investments, the Department of Health uses
the balanced score card approach but it was clear that this model was not modi‐
fied to take into account inter‐departmental projects. Kaplan and Norton’s were
recommended as metrics for performance by a researcher.[7]
To ensure proper implementation and mitigate risks, the parties agreed on
the IT industry standard testing phases and engaged an external auditor, KJ Ross
& Associates (KJ Ross), to validate test results. The auditor concluded that test‐
ing was incomplete and test exit criteria had not been met. [1]
─ For systems and integration test that IBM is to deliver, the auditor find a
high number of outstanding Severity 1 and 2 defects; 90 test cases had not
been executed an d test cases could not me mapped to Requirement Tracea‐
bility Matrix (RTM). In addition, IBM failed performance testing.
─ For UAT, QH identified 805 major defects, 14 show stoppers and 1,007 de‐
fects in all.
─ For parallel pay run, none was conducted.
The auditor general in its report concluded that:
“Both parties ignored all the warning signs of a project in serious distress. Ra‐
ther than reset the project or take decisive steps to put it on a stable course,
they altered or lowered the thresholds which had been put in place to protect
against the very thing which eventuated: a system of poor quality which was
not ready to Go Live.” [1]
5 Project Result
Fig. 1. Source: David Klein’s Blog – Anatomy of an IT Disaster, July 2010
The cost, in terms of payments to IBM alone, is over four times ($21 mil‐
lion) more than the contract price ($6.19 million) due to 47 business require‐
ment changes. It took three times longer than originally scheduled. When it went
live it was seriously deficient, causing very many QH staff not to be paid or to be
aid inaccurately. [1]
The business processes designed to deliver the payroll each fortnight are
highly manual. The business processes involved approximately 130 manual sys‐
tem ‘work‐ arounds’, double handling of pay forms, retrospective payments, ad
hoc payments and other associated adjustments. QH estimate that approximately
200,000 manual processes are required to process on average 92,000 forms
within the payroll hubs every fortnight. [4]
Approximately 500 additional payroll staff beyond that required under
the previous payroll system, were required to complete these processes each
fortnight. In contrast with Mater Misericordia Hospital that had a successful pay‐
roll implementation under the same payroll rules complexity, there was only 7
payroll staff. The ratio of payroll staff to employees is 1 to 1000 whilst at QH
Health is 1:100. [1]
To rectify, QH is estimated to cost the state some $1.25 billion between 2010
and 2017. The breakdown given was [4]
• $1.01 billion would be spent on business as usual
• $220.5 million on fixing problems associated with the existing system
• $25.0 million on deciding on a future system.
In detail, the problems identified were: [1][3][4]
Inaccurate payroll payments.
─ System‐generated automatic top‐ups
─ Manual top‐ups resulting in a double payments in a limited number of
─ cases Payment of overtime to employees whilst they are on leave.
Defective or Missing Functionality:
─ WorkBrain does not allow for salary sacrificing of retrospective payments.
─ Workbrain is unable to apportion employee costs to multiple cost centres.
─ Bugs in calculating the enterprise bargaining back pay and superannua‐
tion contributions.
─ Incorrectly calculation of QH’s annual leave liability
Integration between Workbrain and SAP failed
─ Long processing time to send payroll information from SAP to Workbrain
and vice versa. This can be attributed to
“The sheer volume of transactions coming from WorkBrain to SAP is enor‐
mous. Consider if there were 10 records per person per day, each pay would
have approximately (10 records x 85,000 employees x 10 days) 8.5million rec‐
ords! “ [2]
─ Work Brains “Multi View Scheduler”, the agent that manages change in
rosters, crashed several times, casting doubt to the users on persistence of
transactions Workbrain could not diagnose whether or not data had in
been lost that precipitated double entries.
As a consequence, overnight‐processing runs took longer causing process synchroni‐
zation problems.
Data from legacy (LATTICE) to SAP were not migrated completely
─ There were approximately 20,000 forms that were not processed and
their associated transactions were not migrated across to SAP. Approxi‐
mately 5,700 employees required adjustments to their leave balances re‐
lating to leave transactions.
Data Errors
─ SAP used a unique time code identifier to process the files, but files
created at precisely the same second were given the same time code. This
meant only one file with that time code could be processed and the others
were left unprocessed.
6 Discussions and Recommendations
The broad functional areas identified and exposed in this case study that re‐
quired associated business processes are:
─ Project governance and management
─ Business requirements definition
─ Interface dependency
─ Subcontractor management
─ Change control and configuration management
─ Data quality assurance
─ Project development life cycle monitoring
Because of the project challenges as described in the previous section, QH
needed to be agile which required an explicit understanding of the shared responsi‐
bility across business and IT professionals that promoted visibility, collaboration,
consensus building and prototyping. Once a governance model had been agreed on,
a process activity monitoring is needed so that managers can adapt in real‐time.
For the case of QH, the acknowledged short comings below [1] as identified in
various project reviews could had been avoided if an automated BPM product
suite was in use:
─ Accountable Officer responsible for the overall governance and successful
completion of the whole project was clearly identified. There were too many
bodies and many people involved in decision‐making and the governance
structures had changed several times on both QH and IBM.
─ Clearly defined business requirements and adequate documentation and
agreement of business requirements that could had miminimsed the 47
change request that increased the cost, complexity and delays.
─ Scope of the interface of payroll with enterprise system is clarified and
agreed, and not raised when it was too late; raised in February 2009 when
the Go Live date was September 2008.
─ Compilation and storage of documents on business process compliance
from governance bodies that were lacking including documented and ap‐
proved terms of reference.
─ Senior managers and top government officials could had been alerted earlier
pertaining to the following activities:
o Business Activity Document was not being acted.
o Requirement Traceability Matrix was not being accepted.
o The system and test results were not to standards.
Business Process on Process Definition, Discovery and Optimization.
The author believes that identification of business process and the inter‐
action between them is a prerequisite on engaging external vendors and merits
to be a separate and significant government project in itself. IT could have facili‐
tated the BPR through extensive modeling of process and information sharing.
Simplify existing Business Process
The current business practice was acknowledged to introduce data inac‐
curacies and processing complexity.[3]
• The system allowed historical form submission, going back up to six
years in some cases, which required the payroll system to retrospective‐
ly adjust pay and entitlements.
• Timing of pay dates essentially required line managers to estimate like‐
ly hours to be work by staffs for 2 days on any given pay period.
Identify, consolidate and model existing business process
They could have leveraged on past experience and resources from prior suc‐
cessful IT payroll projects in the same area: [1]
─ Department of Housing with Accenture as the provider
─ Mater Misericordia Hospital which was recommended by the Auditor Gen‐
eral
A previous attempt was made to do this but was turned down and senior gov‐
ernment officials chose WorkBrain in the hope of reducing the overall time for
completion of this prerequisite.[5]
Share Application Knowledge.
BPM promotes creation of a community of experts and build knowledge repos‐
itories. Like any legacy systems that had undergone several changes and imple‐
mented in many ways by various payroll hubs, the As‐is System may not be well
known.[3]
─ The application knowledge is held at the various payroll district hubs.
─ Ties were severed due to the centralization of whole‐of‐state payroll system.
─ Project has no visibility outside of those directly involved in the project.
Adopt an Electronic Rostering System
BPM advocates capturing information digitally at the source and links required
to decision‐making. Ernst & Young recommended the use of electronic rosters
for QH. [4] Rosters are the primary input for payroll for use by line managers.
Human intervention is required though for breaches in award conditions that
are best resolved at the time of creation and at the source. The expected benefits
of its adoption are:
─ Increase the accuracy and timeliness of rosters
─ Decrease the time taken to resolve pay‐related enquiries
─ Decrease the average number of roster amendments
─ Reduce the incidence of award breaches.
Use a proven and tested integration framework.
The interface architecture between WorkBrain and SAP is questionable.
“The Integration between the 2 systems is wrong ‐ as WorkBrain rostering is
writing directly to SAP (using flat files to pump data into SAP) rather than us‐
ing the timesheets as the intermediary entry mechanism first. SAP Payroll sys‐
tems are effectively bypassed by using WorkBrain and a bespoke system for
payroll calculation and generation.”[2]
The interface is classified to be a custom API at the data store level. It applies
only to the two integrating applications for this particular case and hence cannot be reused reused for other purposes. The framework is also characterized
as tightly coupled, which is inherently unable to rapidly adept to change.
Proposed application and integration framework
Service Oriented Architecture
The services envisioned are:
─ Analytic engine for determining applicable award conditions and pay
─ rules Entry of scheduled rosters
─ Entry of timesheet and adjustment to rosters to reflect actual hours
─ worked Identification of breaches in award conditions and conflicts with
scheduled rosters
─ Support for a Payroll Portlet
─ Support for integration to existing SAP ERP enterprise systems.
Integration Framework.
An integration platform that can be considered is SAP NetWeaver [8] which
─ Seamlessly integrates to existing enterprise applications from the same
vendor.
─ Claims to adopt open standards and SOA enterprise integration.
─ It is only or internal use by QH and adopting a simpler and less heavy‐
weight framework like RESTful API is preferred.
A Message Oriented Middleware using XML format can be considered.
─ Workbrain predominantly uses XML and Java and there are many middle
tier options available in Java (e.g. RMI , CORBA) and XML is a universal
standard.
─ Payroll applications are normally processed in batches, real time pro‐
cessing is not presumably not significantly needed and asynchronous
message transfer will suffice.
─ The middleware can also mediate for differences in data and interfaces
requirements of participating applications.
For a vendor neutral product, the open source enterprise service bus can be con‐
sidered.
Use of Cloud Services.
As QH and CorpTech are unlikely to possess the expertise for on premise
private cloud computing and have no resources to develop that capacity, an out‐
sourced cloud services has the potential to reduce costs. Integration as a service
hosted on the cloud is recommended.
Self‐service portlet for payroll matters and use of mobile devices
─ The portlet can be used to enter time and attendance and provide payee
feedback loop to detect process dysfunctions.
─ Mobile devices such as tablets and phones can be used to upload time‐
sheets. Actual hours worked can then be entered immediately leading to a
more accurate and timely data.
7 Conclusion
Dr. Mansfield, who has considerable experience and qualifications engaged by
QH for the review of the failed QH Payroll system, summarized his finding by
stating that
“There was plenty of active oversight of the program. However, successful
governance is not just about having processes, but about how governance
processes and tools are used to get the result.” [1]
The ‘As Is’ process was widely acknowledged as complicated and needed to be
discovered, simplified, consolidated and shared to stakeholders to provide as a
foundation. Hence, the ‘To Be’ process is as a consequence not clear and not
shared to stake holders to ensure effective delivery and mitigate risks. The de‐
fined industry standard on quality assurance was knowingly by passed by all
parties, leading to a system that was defective, inefficient and costly to develop,
operate and rectify.
The need for an effective business process on governance is made more
critical due to the short delivery time frame, unclear business requirements and
unclear project governance. Results could had been better achieved if current
processes were identified, optimized and extensibly modeled using of existing
industry Business Process Modeling tools with accompany BPM suite of products
for its development, rollout and operation.
The spectacular failure of this project caused the Queensland government
to abandon in January 2009 its centralized, whole‐of‐government shared ser‐
vices approach. The design and implementation of a new payroll system for
Queensland Health (QH) was the only remnant of the shared services initiative.
[1]
References:
1. Richard Chesterman, Payroll System Commission of Inquiry Report, 31 July 2013
2. David Klein, Anatomy of an IT Disaster ‐ How the IBM/SAP/Workbrain Queensland Health Payroll System
Project Failed, 13 July 2010.http://ddkonline.blogspot.com.au/2010/07/anatomy‐of‐it‐disaster‐how.html
3. KPMG, Queensland Health Payroll Implementation Review Interim Report – Stage 2, 18 May 2010
4. KPMG, Review of the Queensland Health Payroll System 31 May 2012
5. Bond, Darrin, Exhibit‐171‐BOND‐Darrin‐Re‐Comments‐regarding‐the‐use‐of‐Workbrain,
http://www.healthpayrollinquiry.qld.gov.au/__data/assets/pdf_file/0014/203117/Exhibit‐171‐BOND‐Darrin‐
Re‐Comments‐regarding‐the‐use‐of‐Workbrain.pdf
6. Department of Health, Information Sheet ‐ Queensland Health rostering and payroll environment,
http://www.health.qld.gov.au/ohsa/docs/6‐5.pdf
7. Omar M. Ali , IT Governance in Shared Services in Public Sector, University of Southern Queensland,
8. SAP, SAP NetWeaver, April 2014, http://en.wikipedia.org/wiki/SAP_NetWeaver
9. James Hutchison, Computerworld – CorpTech called to account for shared services failing, 7 Juy
2010,http://www.computerworld.com.au/article/352346/corptech_called_account_shared_services_failing