After breaking new ground in implementing its ERP system, the Department of Foreign Affairs and Trade is embarking on a journey from leading edge to bleeding edge.
"To advance the interests of Australia and Australians internationally." This, says the Department of Foreign Affairs and Trade (DFAT), is why it exists - and with Australia's profile on the world stage both more prominent and perilous these days, responsibilities do not come much weightier than this.
No wonder, then, that DFAT chose to build a robust IT system for what is perhaps the federal government's most important global backbone - DFAT's financial management system, which links more than 90 missions worldwide, facilitates global banking for 41 federal agencies and handles approximately $2 million across 4000 daily transactions.
But as if to prove IT never stands still, after breaking new ground in implementing its ERP, DFAT is facing likely changes in reporting and estimating requirements that may soon force it to consider whether to move to its third SAP upgrade. It is a decision that may force it to make a new journey of its own - right to the bleeding edge.
DFAT's journey to ERP began in late 1998 when the department faced the need to build a new financial management system to meet the new reporting and accountability requirements of the upcoming first federal accrual budget. Y2K compliance also demanded an upgrade, not only to the financial system, but to the HR administration systems in the major missions of London and Washington. On top of that, DFAT was set to inherit global banking responsibilities for 41 federal agencies, and would need the functionality to provide electronic receipt and payment facilities at numerous local and overseas locations.
These new requirements demanded a $3.9 million SAP implementation of a new financial management information system (FMIS) and the rollout of SAP HR to two major posts. A single finance database run out of Canberra replaced 90 disparate regional databases. The system runs 24x7 across 93 sites worldwide, trading in approximately 80 currencies and allowing close to 1000 users a day real-time access to data.
The FMIS went live on July 1, 1999, built in SAP version 4.0B, with four initial modules: financial accounting, financial controlling, investment management and project systems. A travel component of the SAP HR module was also implemented.
But DFAT has been working to improve the system ever since. It built a number of interfaces between the SAP system and existing systems accessed by Australian users, including one between the FMIS and the Australian operation's PeopleSoft HR system. Australian users also access a front end DFAT believes is the first of its kind in Australia: a Lotus Notes workflow system, implemented to allow users to input purchasing, travel and selected accounting documents into the FMIS. It also built a remote-function call interface on to the DFAT e-mail system, to enable interaction between DFAT and the 41 agencies it would be acting as global banker for.
But ERP systems, like threats to global security, just keep growing, so DFAT added numbers of system enhancements in the following months, including a profit centre accounting module. SAP HR was implemented in London and Washington, for payment and administration of staff, by the end of 1999, and the whole system was upgraded to the more user-friendly SAP 4.6C last year.
Successfully meeting Commonwealth demands for accrual budgeting would simply not have been possible without the FMIS, says Anne Hazell, CFO of DFAT. Under accrual budgeting, financial statements need to reflect the full cost of services (including depreciation), by detailing all financial obligations incurred each year, such as superannuation liabilities, rather than just cash costs. These new demands required a system that could produce the kind of data necessary for monthly accrual financial statements - something that under the old system would never have happened. "It enabled us to do much better auditing - for example, we can monitor and follow up bank reconciliations from here [Canberra]," she says.
The more rigorous recording of revenues, expenses and liabilities across 93 far-flung missions could only be done effectively by getting a real-time perspective on the department's financial status across all locations, Hazell says. "The real-time factor is one of the big benefits for us, because we now have the ability to educate long-distance," she says. "Posts used to manage their budgets on spreadsheets. Now they manage them in real time so we can see what they're planning; there's far less querying from us."
Reporting is also faster, says Hazell. Under the old system, with disparate databases and with missions using their own spreadsheets for budgeting, financial statements were not produced until the end of September. "Under the new system we have audit clearance on August 15 and the reports are signed off before the end of the month."
As well as budget management, processes have also been considerably streamlined, particularly in Washington and London under the new HR module. "Most of the processes in London and Washington we replaced with the SAP system were manual ones, or produced on a spreadsheet, so it's streamlined the time taken for actual processing," Hazell says.
And more efficient business processes and budget management have vastly improved data accuracy, she adds. "We now have a lot of faith in what the system produces in the way of numbers, whereas prior to that it would be fair to say there was limited faith in the financial figures."
With a centralised database, technical administration is also now more streamlined, explains director of management information systems Steve Candotti. "We basically needed system administration in every post [mission] before - we've now been able to centralise admin and reduce technical problems at posts as well," he says.
Breaking Ground
After the project budget was signed off, the FMIS was rolled out in just nine months, in what Hazell describes as a "big bang" approach, forced by the impending accrual budgeting deadline.
A standard Commonwealth tendering process was applied to the project, where selected vendors, including SAP, PeopleSoft, Oracle and Sun Microsystems, were presented as tender options under the Commonwealth shared systems suite. The eventual selection of SAP was central to the success of this large-scale implementation because it had the functionality for global operations and could handle a large stream of transactions, says Hazell. After selecting SAP, however, the FMIS project team deviated from standard government tendering procedures.
Vendors on the shared systems panel normally worked around a government template of Commonwealth technical specifications. But for this project the FMIS team did not rigorously stick to the template, preferring to build specifications around the unique requirements of a global financial management system.
Hazell says that while the FMIS project team did not hesitate to use those template specifications that were relevant, she was keen to avoid the restrictions of a template designed primarily for domestic agencies. "Most of the time the government template didn't suit us because of the global component we needed," she says, adding that the template tended to lack a lot of foreign exchange functionality and included Australian specifications around local HR definitions such as long service leave.
The SAP system needed to cover broader needs. "There were a lot of issues with SAP HR, and many agencies [who developed systems under the government template] had to do total manual leave record calculations to keep the auditors happy." The FMIS also required a specialised interface with the Reserve Bank, which went beyond the standard template.
In fact, Hazell says this approach was one of the keys to the implementation's success, compared to other federal agencies, with many other agencies historically tending to "slavishly follow the template".
After the FMIS was implemented in Australia, it was rolled out to all but six posts by the end of 2000, and all posts have now had the system for 18 months. Staff were given a week-long training package covering basic processes like invoice creation, payments, banking arrangements, reconciling and receipting. User training was followed up with a series of regional management conferences, and a user help desk is run out of Canberra, with a 24-hour turnaround time. To back up centralised support, there is an informal user network of "regional expertise", says Hazell - regional champions of the system who are able to support other users. "We rely on them a lot for backup training and support in a region not in our time zone."
Technical development was handled concurrently by an in-house team and an SAP implementation partner, which was an SME called Britestar. "In those days, we tended to steer away from the Big Five [implementation partners]," says Hazell. "I have a reputation in the Commonwealth for being a bit tight with what I like to pay contractors, and so we went with a smaller company that was locally-based." DFAT stuck to this approach for last year's upgrade, using the SMEs BTEC Solutions and Sandfield Systems. But Hazell stresses that she always intended to develop and retain technical expertise within DFAT. "We have not gone down the Commonwealth line of outsourcing the whole kit and caboodle," she says.
There were no major change management problems associated with the upgrade, which was completed on budget and on time. Executive officer of DFAT management information systems Andrew Brice says that the diversity of international staff created an occasional language barrier over some system concepts. However, because users did not need to learn many new business process changes to begin to use the system, he says most of the staff was "reasonably confident".
In fact, Hazell says there was no coordinated business process re-engineering done up-front, mainly because diverse locations and finance practices meant that business processes differed widely, and the system was tailored to suit local banking circumstances. Instead, she says, DFAT reaped business process improvements from the new system via a "continual process of improving and streamlining our business processes as we looked at what the system could do progressively".
"A lot of those processes began to happen once people could see the system and start to work with it. Our staff got fairly intensive training - and as they realised what the system could do they made their own process changes."
The education opportunities facilitated by the new system led to the inevitable re-engineering of business processes. Data was progressively "cleaned up" once the new system was in place, as it went through the process of being input into a uniform, standardised database. An education process of ensuring data was input and used correctly accompanied this, which meant business processes improved over time, in the months after the implementation, Hazell explains. "We've continually done that rather than take a big bang approach to processes at the beginning, which doesn't drive continual change management."
But immediate benefits were apparent, nevertheless. "We moved from an old-fashioned mainframe to a Windows environment, which immediately sped up processing and changed the nature of doing business."
This approach to business processes re-engineering, along with the robustness and capacity of the SAP system, were key to the implementation's success, says Hazell.
Certain project management methods also played a part, particularly in terms of how the change management process was driven. The project was made a visible, top priority in DFAT, being run out of the CFO's office, rather than the IT department. Top-down support of the system led to better user acceptance and long-term change management, says Hazell. "It wasn't a matter of ticking off the new system and saying: 'Right, done that, forget it', says Hazell. "A big system means big change, which takes time for user acceptance - and running it out of the CFO's office meant we've continued driving that change process after implementation."
The rollout was partially driven by a steering committee encompassing divisional and IT personnel, as well as representatives from the agencies which would be using the system for global banking. The committee was involved in the tendering process, and also made decisions about timelines, budgets, module functionality, interfaces and general system specifications. At a more technical level, the project team liaised directly with module users and gained their buy-in using the 'catch' methodology, under which system user buy-in was 'caught' via presentations at four progressive points in the development of the modules.
The initial implementation of the SAP FMIS cost $3.1 million, with annual ongoings set at $980,000, while the SAP HR implementation cost $750,000, with ongoing costs of $450,000. Considering comparable implementations in other agencies have come to $10 million, Hazell believes this was a reasonable figure. "When you think about the size of it, the installation was not all that expensive," she says, adding that few hidden costs or hitches meant budget requirements were met.
One lesson that could be drawn from the installation, however, was that of bandwidth demands, which was not sufficient in some countries, and needed to be upgraded. This delayed implementation in about six posts by a few months. "We planned the rollout around when we could get additional bandwidth, but in some countries the local infrastructure was simply not there," says Hazell. The project team worked around this by rolling out a cut-down version of SAP with basic functionality to such posts, and upgrading them when the bandwidth allowed for it.
"That problem ended up costing us initially a little more than what we thought, but over time, as bandwidth gets cheaper and technology better, it stabilised quite nicely," Hazell says.
While Brice says there were no major technical problems relating to the implementation, there were a few issues in terms of configuring the system to work with local banking arrangements. "We had a basic process of setting up the system [in each post], which was developed in Australia," he says, explaining that differing regional banking arrangements often required the system be tweaked to processes unique to the region.
Hazell says she also would have ideally preferred a longer rollout period. "We did some remarkable things in a nine-month time frame, but I suspect 12 to 18 months would have been a far more sensible time frame in terms of workload and pressure on staff." She recommends that in the absence of a "drop-dead deadline" like that of accrual budgeting, project managers "leave enough time to scope it and plan it and leave enough time for the proper testing of things you may not expect to happen".
Upgrading the Upgrade
Now DFAT's SAP implement ation has come full circle, with foreshadowed still newer reporting requirements likely to force even more changes.
Reflecting the ever-evolving nature of IT, the department is now considering a third upgrade, largely to be dictated by likely changes in Commonwealth reporting and estimating requirements for banking due in the coming weeks. No decision has yet been made. "The government changes aren't confirmed yet - so we're not committed to an upgrade yet because we would only do that when there was a definite business need," Hazell says.
If the upgrade goes ahead, DFAT's technical team is considering an SAP business warehousing module, which will allow upgrades in business intelligence to enable the better forecasting that changes to government banking requirements may demand. "If we go down that path we may look at upgrading to the next version, which is SAP Enterprise [4.7]," Candotti says. SAP's provision of support on the current version, which extends until around 2005, will also be a deciding factor in when and how to upgrade.
Unfortunately, SAP 4.7 is still in development, and there is an element of caution about being, most likely, the first organisation in Australia to upgrade to it. "I'll be quite honest - I'd like to see someone else put in Enterprise first. Ideally that would be someone in the public sector, because private sector implementations don't always translate easily across," says Hazell.
"Leading edge can be bleeding edge - I suppose that is a bit of a public sector focus, but it can save you anxiety and grief along the way."
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.