Trying to integrate two businesses after a merger can be a lengthy, complicated procedure, not least because of the need to combine two or more computer systems and make sure there is a single set of clean and current data. So what do IT directors do when there are four businesses using 113,000 desktop PCs, 2,600 application servers, 2,500 databases and 1,500 applications to merge? Add to that 60,000 e-mail accounts, 290 server locations and 18 regional datacentres and it is clear that DHL, which faced exactly that scenario, had a substantial integration challenge.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
During the past three years, Deutsche Post, the German postal network, has acquired the global express carrier DHL, European express company Securicor and international freight forwarding and transport specialist Danzas. Because DHL is the strongest of the three brands, Securicor, Danzas and many Deutsche Post activities have been amalgamated under the DHL name. But this also meant merging the companies' IT systems.
"The challenge was to merge a lot of the platforms and systems already being used in the various businesses," says Paul Coubrough, program manager for DHL. James Harvey, technical services director responsible for change in IT at DHL, says, "It meant developing an IT strategy based on the business strategy. It has been a mammoth project that was even given a name, 'Star', to help people identify with it."
DHL's systems and applications had to include the order and sales processing, customer databases, finance and human resources systems common to every company. However, processes such as warehouse management, vehicle load planning and route scheduling, aircraft management, communication with airlines, road hauliers and other service providers used by DHL also had to be considered.
The company uses track-and-trace systems to enable external clients and its own customer service staff to pinpoint the location of any consignment anywhere in the world at any time, which had to be integrated with other customer-facing applications.
These applications include Pakstation, which enables home consumers to have their goods delivered to a Pin-controlled box, which is accessed with a computerised swipecard, rather than to their home. Another service, Tas, enables businesses to access DHL's expertise to calculate duty and tax for any import and compare duty and tax requirements of different countries, enabling the customer to decide whether to import into, for example, the US or Canada, or an EU or non-EU country.
The strategy for merging existing systems and choosing one operational system to cover all company activities using all modes of transport was based on three main premises:
- A three-step approach to planning change
- A "kernel" concept of centralised functions with the ability to localise constant with open communication, including user buy-in to the systems
- Continuous monitoring and measurement of progress.
The approach was intended to establish strong enough groundwork to support the development of a homogenised, company-wide implementation.
"We needed to first define the system requirements in terms of operational need, rather than pick a solution looking for a home," says Coubrough. "This meant defining common processes and creating a glossary. Having a common language is vitally important to provide a way of communicating and to help align the system across all our businesses."
If, for example, one business, or even one part of a business, defined "order" as the customer's requirement for DHL to collect and deliver a package, but another part of the business defined it as DHL's request to a road haulier or airline for carriage of the package, it could cause confusion. An airwaybill could be the document provided by an airline which DHL uses, or DHL's own internal document or the document referring to a load on DHL's own aircraft.
Once all the business requirements were determined, the company used Finmatica, a program from a company of the same name which develops transport, logistics and supply chain management software targeted at third party logistics companies.
"Anything we chose also had to be scalable in both directions, so that it would grow with the global company, but could be scaled down for an individual business requirement or particular operation," says Harvey.
Core functionality of Finmatica includes order entry, goods pick-up, terminal handling, linehaul (long distance transport), delivery and financials. Individual countries are allowed to use best-of-breed products for any function if preferred, providing it integrates properly into Finmatica.
Although the ultimate goal, says Harvey, was "a single, global infrastructure encompassing hardware, software, telecoms, IP data, voice and video, local input was the key to success. Communicating our IT strategy was important. The strategy had to remain dynamic and change with the circumstances."
Coubrough says, "We involved as much of the business as possible from the beginning when we defined processes and terminology. Whatever we decided would set out how our employees communicate, so they had to have a say. Local input was also necessary to cope with different ways of working or legislative requirements. Of our systems, 80% were centralised and 20% were left for local adaptation. This also ensured local teams could fit new products into their systems easily."
Each of the four businesses had its own change programme and integration was included in the targets. "Integration was made a line of responsibility," says Coubrough. "The business had to be kept informed throughout. Feedback was also valuable to the IT staff as it helped us understand why the businesses needed to make changes and to ensure the timing of the IT implementation would fit in with the overall business plan.
"Implementation was done country by country. We tried to make sure that the new system was seen as something each country wanted to have, that the staff understood the value of it and were not being forced into having it imposed upon them. This meant some countries had to wait, but it worked."
DHL felt it was important to review the business data and understand where it came from, how it was generated and in what context. "We could get a view of data from a datawarehouse, but that did not give us the context," says Coubrough. "We devised a single way of capturing data that could provide any user with that understanding of where it came from and why."
Measuring and monitoring all decisions, pilots and implementations played an essential role in creating a robust system. "We established bodies to monitor the performance in different areas," Harvey says. "This included application road maps, service development and information security. Each group had representatives from the business and user groups."
Pilot projects included "stress tests" where users were asked to look an application, test it and verify the results. "We measured - and are still measuring - the applications and we update the results every month," says Harvey.
Measurements are colour-coded: red for "not good", green for "fine" and amber for "okay, but needs work". We measure both fact and perception, which includes measuring service level agreements between the internal and external service providers and users.
"Governance bodies were established at an early stage to measure performance. Each business can contact any of DHL's three global IS centres. When outsourcing any function, we leverage the lowest cost service provider for each area, as long as we can guarantee 99.99% availability," Harvey says.
Capability maturity measurements (CMMs), were introduced three years ago, before DHL merged. They measure the maturity of software, ensuring that it is reputable, reliable and bug-free. DHL's Malaysian centre reached level five, the highest CMM level, and another centre at Scottsdale, Arizona, reached level three. The third centre is about to be moved from London to Prague. The idea is being extended to measure the whole business and the goal is to reach level three this year.
Annual targets were set for implementation and measurement. Application road maps were based on a plan agreed by the IT department and the business to reach target applications with monitoring by the governance bodies. A migration plan was also drawn up to show how the organisation was to be integrated and applications migrated. A priority was to show a single face to the customer. "We needed one website and one e-mail address for each employee - one face to the customer," Harvey says.
Visibility of costs constituted another requirement. "The IT cost of each activity, such as order processing, was identified and separated so it could be charged to the relevant business unit," says Harvey. "There is now one IT finance group throughout DHL, with IT costs and targets expressed in business terms. IT must have the budget to accept the costs and the ability to charge back to business units facilitates that."
DHL started its system integration at the beginning of last year and by the time it is finished at the end of next year, it should have reached its goal of having one system, one homogenised architecture, one hardware platform, a common set of applications and a harmonised way of capturing, accessing and manipulating data.
Most importantly, through a single customer interface, every customer, wherever in the world they happen to be, should be able to communicate with DHL in the same way: the same customer service system, the same track and trace, the same ways of processing orders, producing documentation and organising collections and delivery. And no one should have any doubt about which company they are dealing with.