Aufbau einer Payment Factory

Transcrição

02. Oktober 2014
Aufbau einer Payment Factory
Ansätze zur Zentralisierung des Zahlungsverkehrs
28. Alpbacher Finanzsymposium
AUFBAU EINER PAYMENT FACTORY
2
Die Ausgangssituation: Dezentrale Strukturen, hohe Gebühren und Ineffizienzen
Tochtergesellschaften
ERPSystem 1
EBSystem 1
DTAUS/DTAZV
MT101
ERPSystem 2
EBSystem 2
ERPSystem 3
EBSystem 3
XML
EDIFACT
Dezentrale Abwicklung des Zahlungsverkehrs
 Tochtergesellschaften (TG) führen Inlands- und Auslandszahlungsverkehr über eigene
Bankkonten aus.
 TG halten eigene Bankkonten für die wichtigsten Fremdwährungen.
 Cash wird auf zentralen Konten über Cash-Pooling-Strukturen konzentriert.
Schwächen
 Hohe Spesen für AZV-Transaktionen und hohe Margen bei FX-Konvertierungen
 Zahlreiche dezentrale Konten bei diversen Banken
 Komplexe Cash-Pooling-Strukturen
 Organisatorische Schwierigkeiten (ZB-Verwaltung) und potenzielle Sicherheitsrisiken
© Schwabe, Ley & Greiner – www.slg.co.at
02. Oktober 2014..
3
Stichwort „Payment Factory“ – Was ist das eigentlich?


Neben Kostenreduktion durch
automatisierte Prozesse
ermöglicht die PF maximale
Transparenz und Kontrolle über
Zahlungen.
Durch die Implementierung einer
PF werden verschiedene, nichtstandardisierte ElectronicBanking-Systeme durch einen
einheitlichen Kommunikationsweg
zu den Banken ersetzt.
Information für die KontoDisposition
TR-Konten / Kontoinformation
und Abstimmung
Cash-Pooling
Salden operativer ZV-Konten
Bankgebührenstruktur
Intercompany-Funding/
Liquiditätsstatus der TG
HR
TR
ReWe
Zahlungsdatei erstellen

Die Payment Factory (PF) steht
für eine Zentralisierung des
Zahlungsverkehrs in einer
zentralen Einheit, die
Zahlungsdateien von den
angebundenen
Tochtergesellschaften erhält und
diese nach spezifischen Regeln
über Banken abwickelt
Intraday-Auszüge
Bankkonnektivität
Zahlungsaufträge
(vertraulich)
Zahlungsaufträge
man. Zahlungen
Massenzahlungen
aus ERP
Workflow
Prozess
Auswirkung
Treasury-Konten
Payment
Factory
Externe
Kontrahenten
Externe Bank(en)
Operative ZVKonten
Rechnungswesen ̶ intern
Bankkonten (automatische
Buchung im ERP) / IC-Konten
Accounts payable
02. Oktober 2014..
4
Und was bringt‘s? Argumente für die Einführung einer Payment Factory.
Die Einführung einer PF löst aktuelle Herausforderungen und kann durch die Optimierung des
Zahlungsverkehrs sowohl einen qualitativen als auch einen quantitativen Mehrwert schaffen.
LiquiditätsManagement




Zentrale Verwaltung und Transparenz über die externen Cashflows im Konzern
Zentrale Sicht auf die Liquiditätssituation der angeschlossenen Gesellschaften
Möglichkeit der Steuerung des Liquiditätsabflusses
Verbessertes Working-Capital-Management durch Vermeidung von Frühzahlungen
 Transparenz und zentrale Kontrolle im Zahlungsverkehr: Nachvollziehbarkeit der Zahlungen
Compliance
Kosteneffizienz










im Konzern
Standardisierung der Prüfungs- und Freigabeverfahren
Vermeidung „dubioser“ Zahlungen und Transparenz über die Zahlungsempfänger
Zentrale Kontrolle über die Bankverbindungen und damit das Banken-Exposure
Funktionalität von Limiten zur Kontrolle ungewöhnlicher Zahlungsabflüsse aus TG
Einsparung von IT-Kosten durch Reduzierung der Zahlungsverkehrssysteme
Zinseinsparungen durch Zahlwegsteuerung und Optimierung von Zahlungsterminen
Optimierung der Fremdwährungspositionen und Reduzierung des FX-Risikos
Skaleneffekte durch Bündelung von Zahlungen, Verringerung Transaktionsanzahl und -kosten
Reduzierung der Transaktionskosten bei Auslands- und Fremdwährungszahlungen
Automatisierung der Workflows im Zahlungsverkehr, Reduzierung von manuellen
Erfassungsvorgängen
02. Oktober 2014..
5
Konzept Zahlungsverkehr: Wo und über wie viele Konten wird ZV durchgeführt?
Welche Verantwortungen, welche Banken, welche Systeme, welche Formate?
1
2
3
ZV durch die Gesellschaft
und Meldung des
Bedarfes für zentrale
Pool-Disposition
Steuerung und Freigabe
der Zahlungen über eine
zentrale Stelle
Payment-Factory führt
Zahlungen für TG
„on behalf of“ aus
Einbindung von „lokalen
Banken“ in Pool meist nur mit
Valutaverlust möglich
Wenige Zahlungsformate und
eine zentrale Verteilerstelle
(SWIFT, Banken-Provider)
Einheitlicher, zentralisierter
Prozess und zentrale
Kontrolle und Steuerung
Beibehaltung Status-quo
Zentrale Zahlungsfreigabe
Payment-Factory
- Mehrere EB-Systeme
bleiben bestehen (Wartung,
Kosten, etc.)
- Avisierungsprozess muss
gelebt werden
- Systemanpassung erford.
(Bankenkommunikation)
+ Formatvereinheitlichung
+ Sicherheit durch zentrale
Prozessvorgabe
+ Keine lokalen EB-Systeme
- Substanzielle organisatorische Umstellungen
- Payment-Factory Systemunterstützung erforderlich
- Zeithorizont und Zeitbedarf
für Umsetzung
02. Oktober 2014..
6
Zentrale Fragestellungen auf dem Weg zur Payment-Factory
Generelle Anforderungen
 Verrechnungskonten müssen für alle Konzerngesellschaften vorhanden sein
 Abwicklung aller internen Forderungen und Verbindlichkeiten über In-house-Bank
wünschenswert
 Zentraler Zugang für Kontoauszugsinformationen, Weitergabe der Informationen an die
Konzerngesellschaften
 Datentechnische Infrastruktur für das Verarbeiten und Konvertieren von
Zahlungsformaten
Welche Länder?






Rechtliche Situation
Steuerliche
Restriktionen
Länderrisiken
Geschäftsgewohnheiten
Sprachliche Barrieren
Zeitzonen (Cut-off)
Welche Bank(en)?




Länderabdeckung (im
Verbund oder mit
Partnerbanken)
Rahmenvertrag
Landesspezifischer
Vertrag
Anordnung der Konten
Welche Technik?




Formate und
Konvertierung
Systeme (ERP-System,
TMS, E-Banking)
Bankkommunikation
(SWIFT, EBICS, H2H,
etc.)
Compliance Screening
Welche Gesellschaften?





Ressourcen
Knowhow
Bereitschaft
Operatives Geschäft
Risiko
Welche Varianten kommen generell nach einem Kosten-/Nutzenvergleich in Frage?
02. Oktober 2014..
7
Herausforderungen bei der Implementierung einer Payment Factory
Anbindungen und Integration




Anbindung ausländischer TG hinsichtlich
der Anlieferung spezifischer Zahlungsformate
Anbindung ausländischer TG hinsichtlich
rechtlicher, steuerlicher und regulatorischen Vorschriften (OFAC-Liste,
Geldwäschebekämpfung etc.)
Anbindung von TG hinsichtlich
heterogener ERP-Systeme und ReleaseStände

Definition von Leistungsübergabepunkten
und der dazugehörigen Verantwortung

Koordination der Zahlläufe, Integration
von manuellen Zahlungen/Eilzahlungen


Anbindung unterschiedlicher Banken in
verschiedenen Ländern (Formate etc.)
Compliance und regulatorische
Anforderungen
 Sicherheit und Vertraulichkeit der
Zahlungsdaten

Systeme und Prozesse
Kontroll- und Freigabeverfahren zwischen
Konzerneinheiten, Payment Factory und
externen Banken; Definition eines
Limitsystems

Auswahl der internen und externen
Formate für Zahlungen (IDOC, CGI,
SEPA XML, lokale Formate)

Auswahl der Formate für Kontoauszüge
(MT940, CAMT, BAI2, etc.)

Prüfung und Konvertierung von Formaten

Implikation unterschiedlicher Zeitzonen
bei mehreren In-house-Banken
hinsichtlich der jeweiligen Linien
Effiziente Nutzung des Verwendungszweckfelds (Mitgabe einer Identifikationsnummer zur Kennzeichnung der Auftraggeber-Legaleinheit bei „On-behalf"Zahlungen)
Daten-Management
Verbuchung und interne Verrechnung
Kreditoren-Management bei Bündelung
von Zahlungen mehrerer TG an einen
Empfänger (Avise, Klärung von
Rückfragen)

Einheitliche Stammdaten für
Geschäftspartner

Nachverfolgung von Zahlungsvorgängen;
Bearbeitung von Rückläufern

Vermeidung doppelter Datenhaltung im
ERP-System und der Payment Factory


Verwaltung der Stammdaten der TGs
(Aussteuern interner Zahlungen)
Aufsetzen von Verrechnungskonten und
deren laufende Kontrolle (Vollständigkeit
der Verarbeitung der Zahlungsvorgänge)

Umsetzung der zentralen Datenanforderungen in den lokalen Systemen
Generierung, Versand und Verarbeitung
der internen Kontoauszüge

Definition und Umsetzung von
Buchungsregeln (Verrechnungskonten,
Währungsdifferenzen)

Formate
02. Oktober 2014..
8
Überblick der Payment-Factories: Komplexität steigt mit den Anforderungen
Steigende
Komplexität
Auszahlg.
mehrere
Länder
Auszahlg.
und
Einzahlg.
EU
Auszahlg.
und
Einzahlg.
weltweit
Debitoren-/
KreditorenManagement
weltweit
Auszahlg.
ein Land
Umfang der Payment-Factory
02. Oktober 2014..
9
Variante 1: Abwicklung von IC-Zahlungen und „Transport-only“-Zahlungen
Nutzung der Payment Factory sowohl für die Abwicklung und Steuerung konzerninterner Zahlungen
als auch für externe „Transport-only“-Zahlungen

Beschränkt auf die Abwicklung
von IC-Zahlungen und externe
„Transport-only“-Zahlungen

TG, Zentrale und Treasury
senden Zahlungsdateien zur PF.

Ziel ist, IC-Zahlungen zwischen
TG so effizient und kostengünstig
wie möglich zu verarbeiten.

Alle Zahlungsdateien können
dabei entweder aus den
jeweiligen ERP-Systemen oder
manuell außerhalb des ERP (z. B.
Excel) erzeugt werden.
TG 1
(Inland)
Interne Zahlungen
via Banktransfer
(in Ausnahmen)
TG n
(Inland oder Ausland)
Zahlungsdateien
TradingTradingPlattform
Plattform
PAYMENT
FACTORY
- Filtern
- Routing
- Unterstützung im
Management von
IC-Klärungsfällen
„Transport-only“Zahlungen
Interne Zahlungen
via Clearingkonten
TreasuryTreasuryManagementManagementSystem
System
Zahlungsdateien
In-HouseIn-houseClearingClearingSystem
System
Group Treasury
Begünstigte/r
extern
TG 2
(Ausland)
Buchhaltung

„Transport-only“-Zahlungen sind
Transaktionen, die von den TG
initiiert und von der PF ohne
Änderung der Routing-Regeln
weitergeleitet werden.
Intercompany-Auszug
intern
02. Oktober 2014..
10
Variante 2a: Abwicklung von „On-behalf"-Zahlungen über Konten der PF
Nutzung einer Payment Factory für die Umwandlung von Auslandszahlungen in Inlandszahlungen


TG 1
Zahlung
Zentrales
TreasuryKonto
(Ausland)
Die Zahlung einer Rechnung
durch eine andere TG wird auch
als „payment on behalf“
bezeichnet.
Bankkonten befinden sich im
Eigentum der Payment Factory

Non-resident Accounts in den
jeweiligen Ländern
Zahlungsdateien
PAYMENT
FACTORY
- Filter (intern/extern)
- Konsolidierung pro Land
- Länderspez. Formate
- Vermeidung länderübergreifender Transaktionskosten
- Zahlungen so spät wie
möglich
Zahlung
Zentrales
TreasuryKonto
(Inland)
„On-behalf”Zahlungen
Interne
Zahlungen
Kontoauszüge
extern
TG n
TradingPlattform
TreasuryManagementSystem
Zahlungsdatei
In-HouseClearingSystem
Group Treasury

Begünstigte/r
Resultat: Kosten für grenzüberschreitende Zahlungen
werden auf das Niveau von
lokalen Zahlungen gesenkt.
TG 2
Hauptbuch

Alle Zahlungen der Teilnehmer
werden in der PF gesammelt und
in das lokale Clearing des
jeweiligen Landes überführt.
Begünstigte/r

Nutzung günstigerer IZVGebühren für den AZV
IC-Auszug
intern
02. Oktober 2014..
11
Variante 2b: Lokalisierung von „On-behalf“-Zahlungen
Nutzung einer Payment Factory für die Umwandlung von Auslandszahlungen in Inlandszahlungen


Zahlung
Lokales KG
Bankkonto
- Filter (intern/extern)
- Konsolidierung pro Land
- Länderspez. Formate
- Vermeidung länderübergreifender Transaktionskosten
- Zahlungen so spät wie
möglich
Nutzung vorhandener lokaler
Zahlungsformate und
Bankverbindungen
(Inland)
Interne
Zahlungen
Kontoauszüge
extern
Zentrales
TreasuryKonto
TG n
Zahlungsdateien
PAYMENT
FACTORY
Zahlung
TG 2
TradingPlattform
Zahlungsdatei
In-houseClearingSystem
Group-Treasury
Resultat: Kosten für grenzüberschreitende Zahlungen
werden auf das Niveau von
lokalen Zahlungen gesenkt.
(Ausland)
„Payments on behalf“ mit
mehrstufiger interner Verrechnung
Begünstigte/r

TG 1
Hauptbuch

Für die Zahlungen an
Zahlungsempfänger in den
verschiedenen Ländern werden
lokale Bankkonten von
Konzerngesellschaften in den
jeweiligen Ländern genutzt.
Begünstigte/r

Ebenfalls Nutzung günstigerer
IZV-Gebühren für den AZV
IC-Auszug
intern
02. Oktober 2014..
12
Variante 3: Globale Plattform für den Zahlungsverkehr
Erweiterung der Payment Factory um die Funktionen einer In-house-Bank

Aufgaben der IHB:
̶ Verarbeitung von Zahlungen
̶ Verwaltung interner Verrechn.Konten (IHB-Konten)
̶ Lieferung von Kontoauszügen
Beim Aufbau von IHB und PF ist
eine SWIFT-Anbindung denkbar.
Externe
Zahlungen
SWIFT
Kontoauszüge
Operative
Zahlungen
PAYMENTFACTORY
Interne
Zahlungen
Interne
Verrechnungskonten
(IVK)
TreasuryZahlungen
TradingPlattform
IVK-Buchung
ZENTRALE IN-HOUSE-BANK
Kontoauszüge
TG 1
TG 2
Hauptbuch

Die Kombination von IHB und PF
ermöglicht vollständige Transparenz über alle internen und
externen Zahlungsströme.
Handel
Hauptbuch

Das Treasury nimmt gegenüber
den TG die Rolle einer Bank ein.
Bestätigungen
Operative Zahlungen

Die Integration einer In-houseBank (IHB) ermöglicht die
zentrale Steuerung und Kontrolle
aller finanzwirtschaftlichen
Risiken eines Konzerns.
BANKEN

TG n
TOCHTERGESELLSCHAFTEN
GLOBAL TREASURY PLATFORM
GLOBALE TREASURY-PLATTFORM
02. Oktober 2014..
13
Von Anforderungsanalyse, Business Case, Konzept und Systemauswahl...
1
Analyse der
Anforderungen
2
Erstellung eines
Business Case
3
1
Evaluierung der
Systemplattformen

Eine detaillierte Konzeptphase (Scoping) dient dazu, auf Basis
der Ist-Situation und den Anforderungen an die zukünftigen
Prozesse den gewünschten Projektumfang (einbezogene
Länder, TG, Banken etc.) festzulegen.

Projektteam, Zeitrahmen, Ziele und Meilensteine sowie das
„Wie” der Projektorganisation und -dokumentation werden
ebenfalls in dieser Phase definiert.

Erhebung der Mengengerüste (Konditionen, Volumina, Stückzahlen im Zahlungsverkehr) sowie Informationen zu Systemen,
Formaten und Schnittstellen (u. a. Bankkonnektivität)

Erst auf dieser Basis sind seriöse Aussagen zu Kosten und
Nutzen des Projekts möglich.

In dieser Phase wird die zukünftige Systemlandschaft inkl.
aller nötigen internen Schnittstellen sowie der externen Bankanbindung (SWIFT?) und vor allem das System zur Abbildung
der PF-Funktionen festgelegt.

Falls nötig, findet in dieser Phase auch erst die Auswahl eines
„PF-tauglichen“ Systems statt bzw. werden im Falle einer SAPLösung allenfalls nötige weitere Module definiert und lizenziert.
2
3
02. Oktober 2014..
14
... über die Testphase zum Go-Live

Prozesse und Funktionen rund um die neue PaymentFactory-Landschaft werden auf Detailebene festgelegt und
zwischen Zentrale (PF) und TG auf Ebene des Treasury, des
Rechnungswesens sowie der IT abgestimmt.

So sind u. a. Verantwortlichkeiten und Prozessschritte im
4
Kreditoren- und, falls relevant, im Debitoren-Management zu
regeln, die Systematik der Verbuchung und internen Verrechnung von „on-behalf“-Zahlungen ist festzulegen. Das DatenManagement (ext. und int. Stammdaten) ist zu vereinheitlichen,
Kontroll- und Freigabeverfahren sind zu definieren etc.




7
Die festgelegten Prozesse und Funktionen werden anhand
eines festgelegten Rollout-Plans zunächst mit ausgewählten
TG in einem bestimmten Land oder einer bestimmten Region
als „Pilot-User“ implementiert.
4
Der Rollout-Plan enthält die im Standardfall im Zuge der Implementierung zu setzenden Maßnahmen und ist auf Einzelfallbasis an spezifische lokale Gegebenheiten (Steuer-, Devisenbeschränkungen, Zentralbankmeldewesen etc.) anzupassen.
5
Im Rahmen der Pilotierung gesammelte „Lessons learnt“
können im Zuge des weiteren Rollouts berücksichtigt werden.
Behebung von technischen Fehlern und Prozessschwächen,
die im Laufe der Tests identifiziert wurden
Entlang der im Rollout-Plan definierten Zeitschiene schrittweiser Rollout der Lösung in weitere Länder/Regionen

Beispielhafte Abfolge:
̶

Go-Live
̶
̶
6
Pilotierung
(Land oder Region)

Tests mit den an die Payment Factory angeschlossenen
TG und Banken

6 Testing und Go-Live
Konzeption der
Prozesse
und Funktionen
5
Rollout in weitere
Länder und Regionen
̶
7
̶
̶
̶
1. Interne Zahlungen und/oder Netting über IHB für alle Ges.
2. Externer ZV für Schweizer Gesellschaften (In- und Ausland)
3. Externer ZV für Gesellschaften im SEPA-Raum
4. Externer ZV für alle anderen europäische Gesellschaften
5. Internationaler ZV für Pilotgesellschaft(en) restliche Welt
6. Internationaler ZV für alle verbleibenden Gesellschaften
7. Inländischer ZV für alle verbleibenden Gesellschaften
02. Oktober 2014..
15
Haben Sie Interesse oder weitere Fragen? Ihre Ansprechpartner sind:
Schwabe, Ley & Greiner
Margaretenstraße 70
A-1050 Wien
Tel.: +43-1-585 48 30
Fax: +43-1-585 48 30-15
E-Mail: [email protected]
Internet: www.slg.co.at
Martin Winkler
Partner und Geschäftsführer
[email protected]
Michael Michaelis
Partner
[email protected]
02. Oktober 2014..
Zentralisierung Zahlungsverkehr
ALBA Group
02.10.2014 / Sonja Brei / Leiterin Treasury
Inhaltsverzeichnis
1. Vorstellung ALBA Group
2. Situation bis Ende 2010
3. Zentralisierung und Stand heute
Inhaltsverzeichnis
Die Leistungsbereiche
über 180 Tochter- und Beteiligungsunternehmen
über 8.000 Mitarbeiter
rund 2,6 Mrd. Umsatz
Seite 4
| 02.10. 2014 |
ALBA Group | …
ALBA und INTERSEROH
Zwei starke Marken unter dem Dach der ALBA Group
ALBA – Wir nennen es Rohstoff
INTERSEROH – Ihr starker Umweltdienstleister

Entsorgungsdienstleistungen im kommunalen
und gewerblichen Bereich

Organisation Rücknahmesysteme für
Verpackungen und Produkte

Gewinnung und Vermarktung von
Sekundärrohstoffen


Entwicklung und Betrieb von Recycling- und
Produktionsanlagen
Entwicklung individueller Komplettlösungen
und innovativer Kreislaufsysteme für
Unternehmen

Consulting und Services unabhängig von
Dienstleistern
Seite 5
| 02.10. 2014 |
ALBA Group | …
ALBA Group - Ein führender Umweltdienstleister
Unter den Top 10 weltweit
Die ALBA Group ist ein führendes, vertikal integriertes Umweltdienstleistungsunternehmen in Europa
und deckt alle Stufen der Wertschöpfungskette ab.
Licensing
Collecting
Seite 6
Sorting
| 02.10.2014 |
Recycling
ALBA Group | …
Compounding
Processing
Trading
End User
Umsatzaufteilung 2013 pro Land
Country/Region
Germany
China/Hongkong
Poland
RoE
RoW (incl. Turkey)
Total
Seite 7
| 02.10.2014|
Sales 2013 Share of
(Mio. EUR) Total Sales
1.705
66%
303
12%
140
5%
328
13%
122
5%
2.599
100%
ALBA Group | …
Juristische Einheiten der ALBA Group in D
Seite 8
| 02.10.2014 |
ALBA Group | …
Inhaltsverzeichnis
Kick-Off zentrales Zahlungsverkehrssystem
 Ca. 600 Konten im Unternehmen ALBA/Interseroh mit unterschiedlichsten
„Zahlungsverkahrsbanken“
 Kein zentrales Zahlungsverkehrssystem
 Bis Ende 2010 wurde im Treasury ALBA mit HVB TRXplus gearbeitet, auf IS Seite
mit weiteren Omikron-/Multicashprodukten, Cotel, DreCash…)
 Anbindung an Banken über veraltetes FTAM - Verfahren
 3 Cash Manager im Unternehmen durch Splittung Interseroh / ALBA
 Interseroh: Bereiche SaM und Services mit differenzierter Disposition, Datenlieferung
von juristischen Einheiten an die Disponenten über Excel, mehrstufiges Verfahren
 ALBA: eigene Disposition via Excelsheets
Seite 10
| 02.10.2014 |
ALBA Group | …
Kick-Off zentrales Zahlungsverkehrssystem
 Verschiedenste Tools & dezentrale Unterschriftsberechtigte führten zu FalschDispositionen (fehlende Anmeldung von Zahlungen bzw. Nichtausführung von
angemeldeten Zahlungen)
 Diverse Autorisierungstools im Einsatz bei Schlüsselpersonen (Passwörter, Disketten,
USB-Sticks, Zufallsgeneratoren, „Rubbellose“…)
 Zerklüftete Berechtigungsprofile im Bankprogramm (HVB TRXplus)
 Probleme bei plötzlichem Ausfall der MA
 Inkonsistente Struktur innerhalb der Berechtigungen
 Dezentrale Berechtigungen bei Tochtergesellschaften
 Regelmäßige Performance-Probleme, wodurch die Disposition bereits um 12.00 Uhr
startete
Seite 11
| 02.10.2014 |
ALBA Group | …
Inhaltsverzeichnis
Einführung eines zentralen Tools ATAQ2Bank der Firma Technosis
 Umstellung auf den Übertragungsweg EBICS
 Start der Zentralisierung des Zahlungsverkehrs & Zusammenführung der Kunden ID´s
bei den Banken
 Anpassung und Einführung einer einheitlichen Berechtigungsstruktur bei den Banken
 Behebung der Performance-Probleme, sodass die Disposition auf 14.00 Uhr verlegt
werden konnte
 Vereinfachte Anmeldung und Verschlüsselung der Zahlungen innerhalb des Systems
ohne Donkeys, Key-Cards, Sticks, usw.
Seite 13
| 02.10.2014 |
ALBA Group
Kontenlandschaft bei ALBA (incl. Kassen)
Reduzierung der Konten auf Hauptbanken
Anzahl Konten
700
600
500
400
300
200
100
0
2009
2010
Seite 14
| 02.10.2014 |
2011
ALBA Group
2012
2013
2014
ZV / Disposition / Unterschriften
 Steuerung und Beobachtung der Konten und deren Limite + Inanspruchnahmen
 148 Konten / 81 Gesellschaften (Volumens-/Umsatzanteil 91,6%) sind über 4
automatisierte Cashpools (Commerzbank, Deutsche Bank, SEB und Unicredit) zum
Header ALBA Group plc & Co. KG (Dispositionskonten) gepoolt.
 Zahlungsverkehr wird zentral durch Treasury für diese Gesellschaften freigegeben und
automatisch disponiert (zu Spitzenzahltagen werden rd. 500 Zahldateien durch
Treasury versendet).
 Lediglich zwei externe Unterschriften sind dafür bei den Banken hinterlegt, jegliche
Freigabenregelung erfolgt im TMS (Umsetzung von Betragsbeschränkungen,
Unterschriftskombinationen, Vertretungsregelungen, Rollenverteilungen)
Seite 15
| 02.10..2014 |
ALBA Group
ZV / Disposition / Unterschriften
Zahlungen über TMS
Zahlungen außerhalb TMS
> 90 % der Ausgangszahlungen
<10 %
Überweisungen und Lastschriften werden
grundsätzlich automatisch (Schnittstelle SAP)
erfasst.
Großteil über zentrale Zweitsysteme
(z.B. db-direct, pekao biznes etc.)
Zweite Freigabe erfolgt durch Treasury
Zum Teil Freigabe durch Treasury
Administration von elektronischen
Bankunterschriften liegt im Treasury
Bankkonten werden in das TMS eingelesen, auch
wenn die Zahlungsdateien außerhalb TMS
ausgeführt werden.
Steuerung durch Limitierung (Zahlung nur aus
Guthaben) und Treasuryseitige
Liquiditätsversorgung (mittels Übertrag).
Umstellung auf TMS (ausgewählte Konten
werden aktuell abgelöst), ständige Überprüfung
 Ausgangszahlungen können nur mit elektronischer Unterschrift ausgeführt werden
Seite 16
| 02.10..2014 |
ALBA Group
Seite 17
| 14. Mai 2014 | ALBA Group | …
EGGER PAYMENT FACTORY
Umsetzung einer europäischen Payment Factory
Lösung bei der EGGER Holzwerkstoffe Gruppe
Gerald Jobst, Leiter Gruppen-Treasury
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
1
AGENDA
 Die EGGER Holzwerkstoffe Gruppe im Kurzüberblick
 Implementieren wir eine Payment Factory






Die Ausgangssituation, Definitionen
Projektabgrenzung, das Konzept
Die Umsetzung des Projekts: Projektphasen, Einblicke
Optimierungschancen, Erfolgen
Projektverlauf, Projektstatus
Herausforderungen und Lessons Learned
2
DIE EGGER GRUPPE
KURZÜBERBLICK
Ein Familienunternehmen besonderer Prägung
 Ein führender Holzwerkstoffhersteller in Europa
 Stammsitz in St. Johann in Tirol, Österreich
 17 Werke in 7 Länder
 Über 7.200 Mitarbeiter
 Umsatz 2013/14: EUR 2.219 Mio.
 Kapitalmarktorientierung
 Zentrales Gruppen-Treasury (aktuell 4 Mitarbeiter)
3
DIE EGGER GRUPPE
GESCHÄFTSBEREICHE - FOKUS B2B BUSINESS
4
DIE EGGER GRUPPE
VISION
5
6
CASH MANAGEMENT BEI EGGER
STATUS QUO SOMMER 2011 – SEPA DEADLINE „FIXIERT“
ZV Formate AT
OpCo
SAP
ZV Formate DE
Electronic
Banking A
Bank A
Electronic
Banking B
Bank B
(Cashpool)
ZV Formate DE
OpCo
SAP
ZV Formate UK
ZV Formate DE
OpCo
SAP
1 einheitliches SAP
(selber Release-Stand:
SAP ECC 6.0 EHP 6)
2 Instanzen: FI und HR
Electronic
Banking B
Electronic
Banking C
Bank C
Electronic
Banking B
ZV Formate RO
ZV Formate FR
Electronic
Banking D
Bank D
Electronic
Banking E
Bank E
7
PAYMENT (UND COLLECTION) FACTORY
DEFINITION UND VERSTÄNDNIS
Shared Service Center: Zentralisierung Headcounts
- Zentrale Abwicklungseinheit
- Beibehaltung lokaler Bankbeziehungen
- Keine Änderung der Kommunikationskanäle oder Zahlungsformate
Zentralisierung über einheitliche IT-Lösung
- Anbindung von Banken über ein einheitliches System (Bankenlösung?)
- Gruppengesellschaften zahlen in eigenem Namen
- Freigabe von Zahlungen: zentral oder dezentral
Payments on behalf
- In-house Bank Konzept
- Abwicklung von Zahlungen über zentrales Konto („Payments on behalf“)
- Intercompany-Verrechnung zur Verbuchung von Eingängen/Ausgängen
Principal / Agent Modell
- Zentrale Gruppengesellschaft fungiert als einziger externer Kontrahent (Principal)
- Zahlungen und Inkasso nur noch zentral durch Principal („Ein-Konto-Modell“)
- Gruppengesellschaften als Agents
Grafik: frei nach UBS, Treasurer Summit Wolfsberg 2013
Projektabgrenzung
 Fachliche/sachliche Rechnungs-/Zahlungs-Genehmigung weiterhin lokal
 Erstellung Datenträger für Zahlung weiterhin lokal
8
ZIELSTRUKTUR
ZV Formate AT
OpCo
SAP
ZV Formate DE
Electronic
Banking A
Electronic
Banking B
ISO20022 XML
OpCo
SAP
ZV Formate DE
ISO20022 XML
E
B
I
C
S
Bank B
(Cashpool)
Electronic
Banking B
Electronic
Banking
Electronic
ZV Formate UK
Bank A
Banking C
Bank C
ISO20022 XML
ZV Formate DE
OpCo
SAP
1 einheitliches SAP
(selber Release-Stand:
SAP ECC 6.0 EHP 6)
2 Instanzen: FI und HR
Electronic
Banking B
ZV Formate RO
ZV Formate FR
Electronic
Banking D
Bank D
Electronic
Banking E
Bank E
9
PROJEKTPHASEN
1. Phase:
Ausgehende EUR Zahlungsverkehr für AT, DE, FR, UK, RO (bzw. auch FX-Zahlungen)
a) Massenzahlungsverkehr operativ (Lieferanten, Steuern)
b) Mitarbeiterzahlungen und HR-verwandte Zahlungen
c) Manuelle Zahlungen
Zahlungen Gruppen-Treasury (alle Währungen)
2. Phase:
Inlandszahlungsverkehr in nationaler Währung
a) UK (in GBP)
b) RO (in RON)
jeweils schrittweise Umstellung wie in Phase 1
3. Phase:
Inlandszahlungsverkehr, Auslandszahlungsverkehr in RU und TR
(soweit rechtlich und technisch umsetzbar)
10
DAS PROJEKT IM ZEITVERLAUF
Gemeinsames Kick-off Meeting mit Vertretern aller beteiligten Banken
Weitere Ausrollung Format auf
andere Ländern, alle Banken
Kick-off Meeting mit Reval – Scoping Projektumfang
Vertragliches Setup / Abstimmung Dokumentation
Umstellung HR Zahlungsverkehr
Formatabstimmung mit allen beteiligten Banken
Entscheidung für ISO20022 XML v3
Versand RFP an 7 Banken
Rückmeldung/Angebote Banken
Auswertung/Short-List
Formatentwicklung Banken und EGGER (SAP, Reval)
Präsentation Banken
Entscheidung EGGER
Pre-Sounding
Bilaterale Gespräche
Ausarbeitung RFP
Umstellung manueller
Zahlungsverkehr
Start Projektphase II
(RON, GBP)
Intensive Formattests
Go-Live ISO20022 XML v3
Sommer /
Nov 11 – März /
Juni 12
Juni 12 – März 13
Herbst 2011
Jän 12
April 12
März 13
ab April 2013
11
UMSETZUNG
SINGLE SOLUTION – TOTAL VISIBILITY (AND CONTROL)
Anforderungen von EGGER:




Ablöse von verschiedensten Electronic Banking (Insel-)Lösungen
Verarbeitung und Erzeugung von (abgestimmten) bankenspezifischen XML-Format:
für SEPA und NON-SEPA (pain.001.001.03)
EGGER Autorisierungskonzept muss darstellbar sein
Vertrauliche Verarbeitung von Mitarbeiterzahlungen muss gewährleistet sein
Umsetzung in Reval erfüllte alle Anforderungen und ermöglichte



Erhöhung der Transparenz: alle ausgehenden Zahlungen über ein zentrales System
Reval als Cashmanagement-Tool bereits im Einsatz – intensivierte Nutzung
Prozessautomatisierungsgrad erhöht





automatische Dispo
halbautomatische Verarbeitung von Zahlungen
einheitliches Format, einheitliche Anbindung aller EGGER Kernbanken
Verschlüsselte Verarbeitung HR-Zahlungen
Direkte Erzeugung von Zahlungen aus Treasury-Modulen
12
DIE EGGER PAYMENT FACTORY
UMSETZUNGSKONZEPT FRÜHJAHR 2012 – LIVE SEIT HERBST 2013
Payment Factory
„CGI“ XML ISO 20022
EGGER Kernbanken
1. und 2. Unterschrift durch das Gruppen Treasury & ReWe AT
Import der XML‐Datei Treasury- &
Einzelzahlungen
EBICS
(Version 13.1) pain.002
SAP: Erstellung der CGI XML ISO20022 ‐Dateien auf Basis der Zahlungsvorschläge
EGGER Holding
Companies
DE
Companies UK
Companies RO
Companies FR
MT940 /
MT942
Konverter EGGER Kernbank
Dateikonvertierung
für lokales Clearing
(zB BACS, CHAPS, ROI, ROA)
EUR:
EBA, TARGET2
Clearing
‐
Lieferanten‐
zahlungen
‐
Gehalts‐ und Lohnzahlungen
‐
Mietzahlungen
RON:
ROI/ROA
‐
Steuern & Sozial‐
versicherungen
GBP:
BACS + CHAPS Clearing
‐
Treasury ‐
zahlungen
FX:
zB DTAZV
Lokales Treasury & Massenzahlungsverkehr
13
UMSETZUNG MIT ISO20022 UND EBICS
ISO20022 / SEPA XML / CGI bringt (auch neue) Anforderungen mit sich




Lokale, landesspezifische Dialekte bleiben teilweise erhalten
Bankenspezifische Anforderungen müssen erfüllt werden
Dateigröße von XML im Vergleich zu txt-Zahlungsdatei
Umsetzung von NON-EUR und Eilzahlungen
EBICS ist in der EGGER-Bankenstruktur der optimale Kommunikationskanal




Beste gemeinsame Nenner
Hohe Verfügbarkeit
Schnelle und unkomplizierte Anbindung in Europa
Kostengünstig
14
UMSETZUNG
BEISPIEL SAP ZAHLUNGEN (FI) DURCHSCHLEUSEN
SAP Standard
Zahllauf (F110)
Download SAP
Zahlungsdatenträger
XML pain.001.001.03
(pain.008.001.02)
Info an Gruppen
Treasury, Versand
Zahlungsbegleitliste
Freigabe der Zahlung
gemäß EGGER
Berechtigungskonzept
Kontrolle der importierten
Zahlungsdatei – kein
Ändern/Nachbearbeiten
Import von SAP
Zahlungsdatenträger
durch Gruppen Treasury
in Reval
Automatische Disposition
Zahlungen auf Konten im
Cashmanagement
Versand der
Zahlungsdateien über
EBICS an Banken
Abruf von Protokollen,
untertägigen Auszügen
(PTK, pain.002, MT942)
15
UMSETZUNG
BEISPIEL ZAHLUNGEN AUS DEVISENHANDEL
Anfrage und
Abschluss FX
Geschäft über 360T
durch
EGGER Front Office
Import von
360T Trade Ticket
in Reval
Kontrolle und Freigabe
des 360T Trades
in Reval durch
EGGER Middle Office
Erstellung , Versand
von Misys Matching
Datei an
Misys CMS Deal
Confirmation Plattform
Kontrolle der erstellten
Zahlung
(kein Ändern möglich)
EGGER Back Office
Erstellung Zahlung
automatisch in Reval
direkt aus Trade
(über
Standardzahlwege)
Automatische
Bestätigung und
Disposition des
Trades in Reval
Import von Misys
Matching Datei in
Reval
nach erfolgreichem
Matching
Freigabe der Zahlung
gemäß EGGER
Berechtigungskonzept
Versand der
Zahlungsdateien über
EBICS an Banken
Abruf von Protokollen,
untertägigen
Auszügen
(PTK, pain.002,
MT942)
16
IMPLEMENTIERUNG EINER PAYMENT FACTORY
OPTIMIERUNGSCHANCEN UND -ERFOLGE

Reduktion von Schwachstellen in der Zahlungsverkehrsabwicklung: korrekte und
zeitgerechte Freigabe, Betrugsprävention, Erfüllung regulatorischer Anforderungen,
Fremdwährungsmanagement, Datengenauigkeit, Formatierung, Abgleich Zahlungen

Prozessstandardisierung (auch der Annex-Prozesse)

Erhöhung des Straight-Through-Processing Grades

Liquiditätsmanagement: Erhöhung Transparenz, Planbarkeit und Kontrollmöglichkeit

Unterstützung von Wachstumszielen: schnellere Integration von Akquisitionen,
rasche Anpassung an neue Märkte (Kanäle, Formate, etc.)

Kontrahentenrisikomanagement: Verkürzung der Reaktionszeit
Und natürlich...
Kosteneinsparungen durch Reduktion von Ineffizienzen (optimale Wahl Zahlweg,
Instrumente), Beseitigung von Redundanzen (Bankkonten, IT-Landschaft) und
Erreichen von Skaleneffekten (personelle Ressourcen, Volumen)
17
IMPLEMENTIERUNG EINER PAYMENT FACTORY
KRITISCHE BETRACHTUNG

Die (Ziel-)Struktur determiniert die Wahl des Payment Factory Modells

Gesellschaftsstruktur: bestimmend oder bestimmbar?

Berücksichtigung rechtlicher/steuerlicher Rahmenbedingungen (zB „Payment on
behalf“ rechtlich möglich? In-House Bank: Bankkonto notwendig?)

Einfluss der betroffenen Stakeholder (lokale Geschäftsführung, Regulatoren,...)

Commitment der Geschäftsführung unerlässlich

Zentralisierung bedingt Verantwortungsübernahme

Zahlungsverkehrsprojekte sind (auch) IT-Projekte – Ressourcen?

Eingesetzte Instrumente: Berücksichtigung lokaler Gewohnheiten und „Bedürfnisse“

Format: all-in-one Format (zB CGI ISO20022 XML) oder lokale Formate

IT-Landschaft: multiple ERP-Systeme (oder Releasestände), ZV-System(e)

Konnektivität: lokale Standards (zB EBICS), proprietär (H2H), global (SWIFT)?

Banken: lokale Banken vs. globale Banken – Erreichbarkeit vs. Individualität
18
LEASONS LEARNED
Softwareanbieter, Banken







Gemeinsame Kick-off Meetings mit allen Beteiligten (IT, Banken, Reval etc.)
Verschiedene XML-Dialekte / Versionen auf einen Nenner bringen – Unterschiede zeitgerecht
erkennen / kommunizieren
Klaren Zeitplan einfordern und Test-Schritte genau definieren
Berücksichtigung unterschiedliche Technik-Stände  (kleine) Abweichungen zwischen
Banken bzw. bei Softwareanbietern führen zu großen Auswirkungen in Projekt
Technische Möglichkeiten bzgl. aktuellem Release-Stand abklären (Updates notwendig?)
Pflichtenheft (inkl. Projektmanagement) für gemeinsames Verständnis
Konsequenzen bei Abweichungen/Projektverzug
Intern





Klares Projektmanagement; Detailplanung jedoch schwierig
Parallelbetrieb in Übergangsphase / Contingency Lösungen
Genügend Zeit für Tests einplanen (Ressourcen Banken, Softwareanbieter begrenzt!)
Committent der Geschäftsleitung/Vorstand - Frühzeitige Informationspolitik an alle Stakeholder
Optimierung vor- und nachgelagerte Prozesse (Kontoauszüge, AWV-Meldungen,
Freigabeprozess manuelle Zahlungen, Nutzung TMS / ERP) in Projekt aufnehmen
19
RESÜMEE
 Lange Projektdauer


Wie alles begann…
Aufbau Know-how ISO20022 XML und SEPA notwendig
Komplexer Prozess, verschiedenste Stakeholder
 Entwicklungen während Projektverlauf


Extern: Entwicklungen Systemlandschaft Banken
Intern: Entwicklungen SAP, TMS (Reval)
 Umsetzungsform angepasst an EGGER Strukturen
Das ideale Nachfolgeprojekt zu SEPA
 Nutzen des internen und externen Know-hows
 Prozess- und Systemstandardisierung
 Transparenz
http://www.iso20022.org/
20
Vielen Dank für Ihre Aufmerksamkeit
Gerald Jobst
Leiter Treasury Gruppe
Fritz Egger GmbH & Co. OG
Telefon: + 43 50 600 10229
E-mail: [email protected]
21

Aufbau einer Payment Factory

Transcrição

Documentos relacionados

Installation instructions for wall paneling with laminate flooring

Hotel info

Online-Abos Ganz einfach statt höllisch komplex

Paul Egger - ritterkreuztraeger.info

Industrial IT

Die TRAKTOR Factory Sounds fehlen

Globales Payment Alles mit einer Integration

Reservierungen - stellplatz

Swiss Lanna Society Chiang Mai Anmeldung als Mitglied

Mobile Payment