Nothing succeeds like other people's success if you can learn from their experiences, that is.
Integration projects can take many different forms. ZDNet Australia's ongoing series presents three more real-life case studies, this time involving the integration of mobile and back-office systems, project management and accounting, and linking internal systems with an industry hub.
Pauls Parmalat
Pauls Parmalat is best known as one of Australia's largest dairy products manufacturers, but it is also a Coca-Cola franchisee in the Northern Territory. The company wanted to equip its Coca-Cola sales representatives with handheld computers to automate their operations, and selected Hewlett-Packard Pocket PCs and O4's Mobile Sales system.
According to chief information officer Rod Walden, each rep was losing one or two hours productive working time every day because they had to "race back to the office by 4pm" to lodge the orders they had taken so the goods could be delivered the next day.
That deadline also meant data entry staff had their peak load between 4 and 7pm. "That wasn't working very well for us" says Walden, and errors were occurring due to the rush.
The O4 software incorporates call plans, customer relationship management, orders, call cards, planograms (shelf layouts), and light merchandising, but Pauls required integration with its SAP system for order processing in order to overcome the afternoon rush.
Although the reps were equipped with mobile phones, communication was also an issue so Pauls wanted to link the Pocket PCs with Exchange for e-mail and calendaring.
"Given the nature of mobile applications, they're always extensions of existing systems," says Ashley Bloch, managing director of O4. "Our approach is to keep it simple and cost effective."
In almost all of O4's projects, this means using text or CSV (comma separated values) files for moving data between systems. The external interfaces provided by enterprise software such as SAP, J.D. Edwards, and PeopleSoft handle these simple formats and can export data according to a schedule or on demand. Text files are common and available--"our clients seem to like that."
Mapping the information between the centralised system and the devices in the field is handled by the O4 Application Workbench, which runs on a server that bridges the two layers. In Pauls' case, this involves downloading customer and product information from SAP to the Pocket PCs, and uploading all orders, call cards, and changed customer information captured by the sales reps back into SAP.
The biggest challenge presented by the project was setting up the rules to determine which changes entered by the reps could be fed directly into the master records without human review, Walden says.
Although the original plan was that reps would use their mobile phones to link back to the central system, the slow 9600bps communication and difficulties in maintaining the infrared link between phone and Pocket PC means they all prefer to borrow fixed lines from friendly customers and dial in to a 1800 number using a conventional modem. About 90 percent of updates are performed via fixed lines, either at the reps' homes or at customers' premises. Walden says CDMA 1x would be useful for Pauls' application, but there is no sign of that service in the Northern Territory.
"Having information coming in every hour or once a day is enough for [our clients]... real time can mean an hour later," says Bloch. "It's just being practical and real-world." O4's approach is to update data no more frequently than necessary, and to only as much integration as is really needed. This provides a cost-effective result for clients, he says. "We don't get caught up in the love of some fancy technology," he explains. This also means it is quite easy to swap out the back-end system if it becomes necessary. "Stay away from fancy middleware stuff if you don't need it," Bloch advises. His discussions with potential clients often start in terms of technologies such as XML and Web Services, "but often you don't need those fancy things." It's not that he has anything against such technologies; it's just a case of horses for courses, and if a job requires instant data synchronisation and tight integration, other methods may be more appropriate.
Application Workbench implements standardised processes and procedures to convert the data between the formats used by each application, maintains audit trails, and provides exception handling so that the sales reps can keep working even if the SAP system is temporarily unavailable.
"We hardly ever integrate with just one system--it's usually Excel and something else," says Bloch. "We have some smart server technologies to facilitate that."
"The rate of change in mobile systems is much greater than in back-end systems," such as the need to accommodate new sales initiatives. Consequently, you need interchange methods that don't require programming changes at the back end to cope. O4's approach of putting a server between the back end and handhelds means that all changes can be made in one place and then pushed out to the mobile devices. Also, the server does all the work of translating the data, so all that's left is to transfer it to and from the Pocket PCs and the backend system.
Pauls chose O4's software because it did not want an approach that relied on custom coding, as that would make it difficult to deploy in other areas of the company's operations.
O4 performed the initial configuration and provided skills transfer to Pauls' staff so minor changes could be carried out in-house, though Walden says he would look to O4 to implement support for significantly different roles.
The project cost less than $80,000 with a payback period of less than 1.2 years, says Walden. In addition removing most of the data entry problems, the reps only need to visit the office once or twice a week yet are better informed about matters such as stockouts and special offers.
"There has been keen interest from other merchandising areas of the company," says Walden. The NT soft drinks operation was selected as a small pilot, and the company is now defining the requirements in other business areas for "significant rollouts this year".
"It's been a well-accepted solution."
Kinetica
Kinetica is an IT infrastructure company based in Sydney with branches in Brisbane, Canberra, and Melbourne.
Due to expansion, Kinetica needed to replace its existing accounting software and it selected the Greentree system from the New Zealand company of the same name, to be supplied by Star Accounting Solutions.
"They were looking for a best of breed project system... so we supplied a specialised system called Star Projects," says Richard Downing, director of Star Accounting Solutions, an accounting solutions specialist and a value added reseller for Epicor, Best, and Star System Solutions. The latter company is the creator of Star Projects, and was spun off from Star Accounting Systems about five years ago.
Downing points out that his company takes a far more active approach that most IT integrators. It is the largest CPA company in Australia, even though it does no tax or audit work. Where an IT-centric company might ask its clients what they want to do and then work out how to do it, Star Accounting Solutions tends to be more prescriptive, advising clients what they should do and then implementing its own recommendation.
Mark Gray, financial controller at Kinetica explains that "a lot of the work we do is consulting services," so his company needs to charge out its consultants and engineers. Kinetica needed new accounting software as well as a project accounting program, but "[I knew] it would be great if I could do [the invoicing] once," he says. Star Accounting Solutions' proposal "sounded like exactly what I was looking for."
Downing explains that the two packages had to be integrated at three levels.
Firstly, there was a technological integration. Not only were the two packages from different vendors, but the underlying architecture was very different: Star Projects uses a conventional SQL database, while Greentree uses the Jade object database.
Greentree is Web services enabled, so it was relatively easy to drive it from Star Projects. The reverse isn't the case, but Star Project's SQL database is accessible from Greentree via ODBC. "The Web service is a more elegant method, the preferred method," says Downing.
"In the late '90s, there was massive integration between legacy systems and SQL. Now, we're looking at integrating current (ie, SQL) systems with emerging systems."
Secondly, the accounting approach differed between the packages, with Greentree performing real-time updates as data is entered or modified, and Star Projects using a batch posting protocol. Overcoming this mismatch was the difficult part of the project, Downing says.
To understand the problem, consider the transfer of an invoice from Star Projects to Greentree. The invoice comes into existence when the batch update is performed, so it must be transferred to Greentree at that time. When it arrives in the accounting system, all updates that would occur with the manual entry of a new invoice must be triggered to ensure consistency. Fortunately, Greentree has a "new invoice" object that could be used. This means there is no isk of inconsistency (because the same routine is used however an invoice is created) and the integration will survive any updates to the Greentree software without needing further customisation.
So far, so good--but what happens if an invoice is changed in Greentree? That's normally acceptable providing the accounting period is still open, but the use of batch posting in Star Projects means that once an invoice has been posted it cannot be changed. The solution was to identify such objects in Greentree as "external" and customise the software so that external objects cannot be altered.
The other complication concerned data entered in Greentree and then passed to Star Projects. For example, invoices for travel costs associated with projects are entered in Greentree and then fed back to Star Projects. As described above, once data is posted in Star Projects it cannot be modified. A simple solution would be to wait to the end of the accounting period before transferring the data, but Kinetica needed weekly updates. Fortunately, Greentree also has a batch option, so invoices can be held in the system until the end of the week before the batch is closed. Code to transfer the invoices to Star Projects was added to Greentree's batch close object.
From the user's perspective, handling project expenses this way "saves us a hell of a lot of time," says Gray.
The situation is further complicated because invoices from some overseas suppliers arrive after Kinetica has invoiced its own customer. Incorporating these costs is very time consuming, according to Gray, so Star Accounting Solutions added a procedure to track the cost of sales in Greentree so it was obvious when costs have not been included.
Finally, there was the business-level integration. "Business mapping is just a matter of legwork," says Downing. For example, moving an invoice from one system to another may mean relating the "customer code" field in one package to the "debtor code" field in the other. Difficulties can arise when the corresponding fields are of different lengths or if they are different data types (eg, numeric vs alphanumeric). Kinetica was spared either problem, but when they do occur they can be overcome by restructuring the data in one package, or by adding a field to the more restrictive database.
Sometimes, important data may exist in one program but not the other. For example, Star Projects records the "responsible manager" and Kinetica needed that information to be carried across into Greentree. Adding a field to Greentree was an obvious solution, but the drawback was that it also required the creation of custom reports.
Although Kinetica's own staff could have performed the integration project, the opportunity cost of diverting them from clients' work was greater than Star Accounting Solutions' bill, and "it's easier for us to outsource it," says Gray.
The work took about a month of effort spread over a four-month period. The accounting system was installed first, then the project accounting, and finally the integration. "We crunched it through pretty quickly," says Gray, "I didn't want to run parallel systems for a great length of time."
Recent changes to Kinetica's system include the use of Star Projects' Web interface allowing data entry such as time sheets via a Web browser, and the use of Crystal Reports for generating Web-accessible reports. This means people can get the reports they need even if they don't have direct access to Greentree or Star Projects.
AUSMAQ
AUSMAQ, a subsidiary of National Australia Bank*, acts as an intermediary between the manufacturers of managed investment funds and buyers such as wraps, master trusts, custodians, and margin lenders. It consolidates orders from those clients and then places a single order with each manufacturer, maintaining its own sub-registry to track each client's holdings since each manufacturer regards AUSMAQ as the owner of the securities.
To speed this process, AUSMAQ created MAINhub, an implementation of the IFSA (Investment and Financial Services Association) MFundEC (Managed Fund Electronic Commerce) programme. The objective of MFundEC is to reduce the costs of the Australian managed funds industry by applying electronic commerce. Some 50 fund managers and over 100 buyers perform approximately 9000 wholesale transactions per day.
Geoff Purcell, chair of the MFundEC committee, explains that the original goal was to standardise and automate the information flows between players in the managed funds industry. According to Purcell, overseas experience suggested this could result in substantial cost reductions, as Australian transaction costs were "two orders of magnitude greater" than those for US users of the Fund/SERV system (an equivalent of the system MFundEC was proposing).
An important feature of the design effort was the care that was taken to include the information that would be needed in each transaction by every class of participant. As well as the XML-based definitions, the standards also specify whether (and if so, how) messages are to be acknowledged.
By the end of 2002, MFundEC had defined standards for over half of the transaction types identified. Since the committee had started by tackling the "high-cost, high-volume information flows," what remained were the less costly, lower volume transactions. Consequently, its posture changed to being "happy to develop further standards as and when the industry demands them" and instead focusing on promoting the take-up of the defined standards, says Purcell.
The committee's original plan was to invite expressions of interest from companies with the ability to implement the standards, but the response from the industry was that it would be better to allow for competing implementations and let the market--not the committeedecide which prevails. The Australian Stock Exchange and InvestmentLink are also developing MFundEC compliant systems, Purcell says. "MFundEC has been careful to remain agnostic" about the providers and the technology they use, he explains.
"Certain standards have been developed in the industry," says Byron Cox, head of operations at AUSMAQ, "and AUSMAQ is standards driven."
"IFSA is also working on a standard for the distribution of unit prices," adds Chris Donohoe, general manager--business development and operations. "As soon as it is standardised, AUSMAQ will implement it."
MAINhub allows businesses such as E*Trade and HSBC to transmit orders electronically to AUSMAQ, but as Cox explains, "at the back end, market practice was to fax orders to manufacturers."
The task facing AUSMAQ was to integrate MAINhub with its own back-end system, which is based on a Progress database. Since Microsoft's BizTalk had been successfully used to link MAINhub with its clients, the same technology was used for the internal integration.
Carl Hill, general manager--IT, explains that another BizTalk server was used to interface MAINhub with AUSMAQ's back-end IDPS (investor directed portfolio service) provider. "BizTalk gives us stability and reliability," he says. Another advantage is that if any message format changes occur, it is easier to alter the BizTalk layer rather than the applications themselves to accommodate those changes. Since all the messages are in XML, translating between one format and another is relatively simple.
AUSMAQ was the first IDPS platform to provide straight-through processing without manual intervention.
The adaptor between the two systems was developed with assistance from Microsoft Consulting, and Microsoft subsequently released BizTalk Accelerator for MFundEC to simplify the task of connecting clients' systems with MAINhub. However, it is not necessary to use BizTalk to integrate with MAINhub.
Dave McNaughton, solutions marketing manager at Microsoft, explains that an organisation seeking to connect its systems to MAINhub or another MFundEC-compliant hub face two challenges. The first is the diversity and complexity of the internal systems that must be integrated to permit straight-through processing. The organisation may already have an integration strategy, or they may be in the market for middleware.
Secondly, drawing an analogy with a phone service, they need to find the cheapest way of getting "a handset with dial tone to the hub." This is where the combination of BizTalk Server and the accelerator comes in. Together, these components take care of the communication with the hub, and will pass XML messages to and from whatever integration software is used internally.
However, the same copy of BizTalk Server can be used as the basis for integration with those other applications, regardless of the platform they run on, says McNaughton. "You've bought one [server] to be the gateway, you don't need another for integration," he explains. Over 300 adaptors and toolkits are available to simplify integration with various applications and technologies.
Organisations with modest transaction loads can use BizTalk Server Partner Edition, which costs around $2000 and has the same hardware requirements as Windows Server. The accelerator is free, and Microsoft will keep it up to date with any changes to the MFundEC or MAINhub specifications at no charge. At the other extreme, BizTalk Server Enterprise Edition costs around $50,000 and requires SQL Server ($8000) and suitable hardware. "The reality is that the cost is in the internal integration," says McNaughton.
Microsoft has used a similar strategy to simplify integration with other external standards, such as SWIFTNet (used by banks and financial institutions to exchange messages) and RosettaNet (used by high-tech companies such as Nokia and Dell to integrate their supply chains).
Accenture--AUSMAQ's integration partnerintends to use BizTalk and the accelerator in integration projects for its clients, he adds.
The MFundEC standards can also be used for internal integration, Purcell explains. For example, an organisation may need to exchange information between its portfolio administration and investment accounting systems. MFundEC means the same set of interfaces can be used for internal and external integration.
According to Purcell, MFundEC is a good example of the "network effect" in that its value increases with the number of users. Until all players are using it, organisations will still need to retain the traditional and more expensive communication channels. If everyone uses it, they will get 100 percent of the benefits, he says, but "we're just in the early stages of that take-up."
Stephen Withers holds shares in National Australia Bank.
Subscribe now to Australian Technology & Business magazine.
15%
7%
