Lufthansa’s Flight to Payments Quality
by Carlos Scheeren, Project Head Payment Factory, Group Finance, Deutsche Lufthansa AG
At the start of 2014, Lufthansa Group embarked on an ambitious project to achieve visibility and control over group liquidity across its 540 global entities, and centralise, harmonise and standardise payment processing. In this article, Carlos Scheeren, project manager of the project, describes some of the background, progress and achievements so far.
The Lufthansa group has around 1,500 bank accounts, nearly 50% of which are held with our primary cash management banks, Citi and Deutsche Bank. Before embarking on our payment factory project, we used banks’ electronic banking systems, CitiDirect and db-direct respectively for payment approval and execution, both at a headquarters level and across the group. Given the nature of our business, we also need to work with local banks, so we have around 800 accounts which, until this project, have been held with more than 100 banks across 107 countries. We used numerous local electronic banking solutions with which to communicate with these banks. Given the different levels of functionality, diversity of formats and varying opportunities for process automation, the use of multiple systems resulted in fragmented processes for retrieving bank statements, approving and executing payments, user administration etc.
As well as fragmented processes from a banking perspective, we also recognised that our internal processes were often heterogeneous and manual. Although we use SAP, we have different instances and releases across the group, while smaller business units often have other ERPs in place. Consequently, with diverse internal systems, electronic banking systems, processes and file formats, we did not have a consistent view of data and therefore lacked visibility of group liquidity.
Most business units conducted payments locally, but we had a central payment processing hub that supported nearly 30 group companies, all of which used SAP. Our headquarters executed payments in EUR, GBP and USD on behalf of these companies from Deutsche Lufthansa AG accounts and debited intercompany accounts accordingly. However, although this centralised approach to payment processing had proved successful, we recognised that the solution was not scalable to meet the needs of the wider group.
Addressing the challenge
In 2011, we put together a multi-disciplinary team including payments, cash management and information management (SAP support) to conduct a preliminary study into the feasibility and cost benefit of a payment factory. We were aware that payment factories were becoming more popular, and from events such as Schwabe, Ley & Greiner’s Finanzsymposium, and visits to other DAX companies, we could see the advantages. As a result of this evaluation, it became clear that our banking structure, namely having only a limited number of primary cash management banks, would be a distinct advantage. We put together the business case, and by the end of 2012, our senior management board had authorised us to issue a request for proposal (RFP) and embark on a formal process to select a provider.
Evaluation and decision
We had already issued a request for information (RFI) in late 2012 as part of our business case definition, to which we had received nine responses. We analysed these responses systematically and as a result, shortlisted three providers, two of which responded to our RFP. During the third quarter of 2013, we conducted evaluation workshops with both companies to understand their solutions, refine the scope of services and clarify the costings. On the basis of this evaluation, we selected Hanse Orga as our payment factory system provider, and completed negotiations by the end of 2013.
There was a variety of reasons for selecting Hanse Orga. One of them was the company’s performance during the workshops, as well as the commitment of the designated project manager to whom we had already been introduced. The software was highly flexible, and had a rule-based mechanism to map different incoming file formats into a meta format, from which the outgoing XML ISO 20022 (CGI) format is created. This was important as we were using iDOC, XML and a variety of local formats. We are using three modules of the solution at this stage: payment management; treasury management (in-house banking and limits) and some features of the cash & liquidity management module.