Optimierte Zahlungseingangsverarbeitung in JD Edwards mit Centric BCM

Transkript

1 Optimierte Zahlungseingangsverarbeitung in JD Edwards mit Centric BCM Alexander Klauss Oberhausen Cash Management DTEIN Zahlungsverarbeitung Debitorenzahlungen JDE JD Edwards Bankauszug MT940 Abstract: Mit wachsender Zentralisierung von Finanzprozessen steigen die Anforderungen vor allem an die effektive Kontrolle von Zahlungs- und Finanzströmen stetig an. Eine effiziente Zahlungsverarbeitung ist Grundvoraussetzung für ein effektives Forderungsmanagement. An einem Kundenbeispiel wird aus dem Blickwinkel der Praxis der Einsatz des BCM im Zusammenspiel mit JD Edwards EnterpriseOne dargestellt. Welchen Nutzen zieht der Anwender aus der Tatsache, dass die voll in JD Edwards integrierte Lösung weder Fremdsoftware noch eine zusätzliche Serverinstanz benötigt? Die Benutzer arbeiten in Ihrer gewohnten Oberfläche, alle resultierenden Buchungen in den Bereichen Hauptbuch, Kreditoren und Debitoren werden maschinell und ohne weitere Schnittstelle verarbeitet. Die Erfahrungen des Kunden in den Phasen Installation, Konfiguration, Schulung und Praxisbetrieb mit der Lösung werden anschaulich dargestellt. Welche Auswirkungen hatte die Einführung auf die Abläufe in der Debitorenbuchhaltung, nachdem die Zuordnung von Eingangszahlungen zu den dazugehörigen offenen Posten automatisiert wurde? Wie haben sich die Algorithmen der Zahlungszuordnung in der Praxis bewährt? Diese Fragen werden aus dem Blickwinkel des Anwenders beantwortet.

2 Manuscript: Bankauszugsverarbeitung im Standard von JD Edwards - Getrennte Verarbeitung von Debitorenzahlungen, Kreditorenzahlungen (bzw. Abstimmung DTAUS oder SEPA Zahlung) sowie Hauptbuchbuchungen Diese Lösung ist sinnvoll, wenn nur eine kleinere Anzahl von Kundenzahlungen erfolgt, oder keine Möglichkeiten einer maschinellen Zuordnung bestehen. Auch die Anzahl der zu verarbeitenden Bankkonten sollte nicht zu hoch sein. - Verwendung der manuellen Bankauszugsverarbeitung in JD Edwards Diese Lösung wird generell von den Kunden nicht gut angenommen, da viele manuelle Schritte notwendig sind und es bei Abbruch einer Eingabe teilweise zu Inkonsistenzen kommen kann bzw. einzelne Schritte manuell zurück genommen werden müssen. - Einsatz der im Standard vorgesehenen maschinellen Bankauszugsverarbeitung Diese Lösung erfordert eine Anpassung des Bankauszugs-Import, da im Standard lediglich zwei Ausprägungen des MT940 Formates hochgeladen werden können. Weiterhin ist ohne manuellen Eingriff oder entsprechende kundenindividuelle Programmierung keine automatisierte Zuordnung von Zahlungen und Debitoren OP s möglich. Diese Lösung ist vor allem geeignet, um Kreditoren-Scheckzahlungen abzustimmen und Hauptbuchbuchungen aus dem Bankauszug zu automatisieren. Erweiterung der Möglichkeiten in der Bankauszugsverarbeitung mit BCM - Über 70 unterschiedliche (internationale) MT940 Bankauszugsformate sind bereits integriert und können ohne weitere Anpassung verwendet werden - Eine Vielzahl von Bankkonten kann übersichtlich dargestellt und gesteuert werden - Debitorenzahlungen werden nach definierbaren Regeln entweder auf Basis des MT940 Textes oder eines Kunden-Zahlungsavis maschinell zugeordnet - Kreditorenzahlungen die aus der Bankensoftware direkt erfolgt sind, können maschinell in JD Edwards verarbeitet werden - Alle Aktivitäten können manuell von einer zentralen Funktion gesteuert erfolgen, ohne in verschiedene Bereiche wechseln zu müssen - Bankauszüge sind auch nach deren Verarbeitung elektronisch verfügbar und eine Auditierung der erfolgten Zuordnung ist jederzeit möglich

3 - Die Verwendung von Standard JD Edwards Tabellen für die eigentlichen Buchungsvorgänge erlauben eine Analyse und Bearbeitung dieser Vorgänge im Standard von JD Edwards ohne Einschränkung Das Kundenprojekt Die folgenden Ausführungen beruhen auf den Aussagen der Projektleitung der BCM Einführung auf Anwenderseite - Prozess vor der Einführung 4,7 FTE waren mit der Verarbeitung von Bankauszügen im Shared Service Center beschäftigt Die Bank Statements wurden in der Regel zunächst ausgedruckt Per Excel Sheet (wegen der besseren Übersicht) oder manueller Suche der Debitoren OP im System wurde eine Zuordnung vorgenommen Bei Kundenrückfragen wurde der Bankauszug manuell durchsucht Partiell wurde ein externes Bankmodul eingesetzt, wo über eine Schnittstelle der Export der Debitoren OP s und der Import der Bankbuchungen nach erfolgter externer Verarbeitung stattgefunden hat. Es hat sich jedoch gezeigt, dass der Einsatz dieser Schnittstelle zu viele Schwachpunkte aufwies, so dass dieser Weg im Konzern nicht konsequent weiter verfolgt wurde. - Auswahlprozess Gesucht wurde eine Cash Application, kein Treasury oder Debitoren Management Modul. Damit wurde BCM genau der richtige Funktionsumfang zugebilligt. Ein weiterer entscheidender Punkt für die Entscheidung BCM zu verwenden, war die Integration in JD Edwards, statt eines Upload und Download per Schnittstelle zu einem externen System. Auch aus Anwendersicht wurde als Vorteil angesehen, dass sich BCM von der Oberfläche und vom Ablauf in JD Edwards nahtlos integriert. - Allgemeine Gründe für die Einführung einer Cash Application Ziel: Effizienz im Bereich Debitoren steigern, also mehr Bank Transaktionen mit weniger Aufwand und Fehlern verarbeiten können. Die Strukturierung von Teilen der Buchhaltung in zentralisierte Shared Service Center erleichterte die Einführung einer solchen Applikation. Europaweit sollte die Verarbeitung von kompletten Bankauszügen maschinell erfolgen. Vor allem im Bereich der Debitorenzahlungen erhoffte man sich eine schnellere und genauere Zuordnung.

4 - Erfahrungen o Technische Installation Die technische Installation war unkompliziert, fand durch das Einspielen eines ASU (Automated Software Update) in den USA statt o Konfiguration/ Einführung Der ursprüngliche Plan sah vor, dass zunächst 3 Firmen einen Probebetrieb aufnehmen sollten Im 2. Schritt sollten dann 5 weitere Firmen folgen Im Verlauf des Projektes wurde aufgrund der guten Testergebnisse entschieden, alle Firmen parallel live zu schalten o Projektverlauf Projektstart: Januar 2010 Produktivstellung: April 2010 Das Projekt wurde parallel zum Jahresabschluss geführt, so dass ca. 6 Wochen nicht am Projekt gearbeitet werden konnte! Externer Beratungsaufwand: 5 Tage o Schulung Interner Aufwand: Wesentlich mehr, wurde jedoch nicht gemessen Es gab (lediglich einige Detailprobleme) keine wesentlichen Störungen im Projekt 1 Tag Schulung geplant Lediglich 3 Stunden realisiert Training on the Job in 6 Wochen Testphase o Praxisbetrieb Seit April 2010 live Gute Effizienzsteigerung Um 6 Uhr sind die Bank Statements im System und alle maschinellen Aktivitäten abgeschlossen Vor der Umstellung waren die Bankauszüge immer mit einem Tag Verzögerung verarbeitet, jetzt ist das System tagesaktuell Lernendes System: Wie bewähren sich die Zuordnungs-Algorithmen? Rate der Zuordnung: 73 75% im Durchschnitt der 29 im System abgebildeten Konten

5 200 Transaktionen pro Tag mit einer Zuordnungsrate von 69 %- 88% beim Konto mit der höchsten Aktivität Auch andere Zahlungen können erfolgreich zugeordnet werden (Kreditoren), bei Sachbuchungen ist die Automatisierung bei 100% Momentan ist die Verarbeitung von Zahlungsavisen noch nicht automatisiert, dies würde die Rate der Zuordnung nochmals wesentlich verbessern o Nächste Schritte Roll out nach Asien Geplant sind ein Training und die (geführte) Verwendung von Echtdaten im Testsystem sozusagen als training on the job Die Automatisierung im Bereich Verarbeitung von Zahlungsavisen soll als rein internes Projekt in Kürze erfolgen