Dieses Beispiel macht klar, wie wichtig es ist, dass der Gesprächspartner ein erfahrener Berater ist, der die Leistungsfähigkeit aktueller ERP-Systeme kennt und der aufgrund seiner Erfahrung entsprechend nachfragt, wenn er dies für erforderlich hält. Eine dritte Anforderung könnte sich in diesem Beispiel noch ergeben, wenn Zu- oder Abschläge in der Finanzbuchhaltung getrennt gebucht werden. Dann müsste man auch dies als funktionale Anforderung aufnehmen.

Erfahrung ist durch nichts zu ersetzen!

Ein weiteres Beispiel soll diese Aussage verdeutlichen. Wenn ich nachfrage, ob man Fremdsprachen für die Kommunikation mit ausländischen Kunden und Lieferanten benötigt, ist die Antwort oft „ja“. Und so kommen wir zu dem Thema, wie man z.B. Mengeneinheiten und Zahlungsbedingungen in Fremdsprachen in einem ERP-System abbildet. Meist kommt die Rückfrage, wo ich an dieser Stelle ein Problem sähe, dies könnten doch alle ERP-Systeme. Die ernüchternde Antwort ist leider „nein“. Man kann nicht einfach davon ausgehen, dass dies alle ERP-Systeme einheitlich gut abbilden. Viele ERP-Systeme haben für Objekte wie Mengeneinheiten und Zahlungsbedingungen einen Sprachkenner und können Fremdsprachen ohne Probleme abbilden. Es gibt aber immer noch ERP-Systeme, die dies nicht im Standard können. Wenn diese Funktionalität fehlt, ist sie auch nicht mal eben schnell in ein ERP-System programmiert, da diese Objekte überall im System verwendet werden. Nehmen wir an, die Zahlungsbedingung mit der Nummer 10 bedeutet 14 Tage 2,5%, 30 Tage netto. Nun muss es möglich sein, für die Zahlungsbedingung mit der Nummer 10 den Text „14 Tage 2,5%, 30 Tage netto“ z.B. unter dem Sprachkenner „GB“ in Englisch bei der Zahlungsbedingung 10 zu hinterlegen.

Wenn ein ERP-System dies nicht kann, erhält man vom Hersteller den Hinweis, eine Zahlungsbedingung mit dem Kenner 11 anzulegen und den Text auf Englisch zu erfassen. Das verstehe ich nicht darunter, wenn ich sage, dass die Wahrheit ins System muss. Die Wahrheit ist, dass die Zahlungsbedingung mit dem Kenner 10 exakt nur einmal existiert, und zwar in verschiedenen Sprachversionen. Diesen Fall kann man auch auf die beschriebenen Zu- und Abschläge anwenden. Bezogen auf Mengeneinheiten bedeutet dies, dass man die Mengeneinheit „Stk.“ nur einmal im System anlegt. Wenn eine Bestellung bei einem englischen Lieferanten ausgelöst wird, muss auf dem Beleg die englische Bezeichnung „Pcs.“ erscheinen. Die Auswirkungen beschränken sich nicht nur auf die Daten im Beleg. Wenn man das ERP-System in der Bediensprache Englisch verwendet, muss auch in den Fenstern des ERP-Systems „Pcs.“ zu sehen sein. Ich habe mal von einem ERP-Hersteller, der dies nicht abbilden konnte, den Vorschlag erhalten, dass man ja im Beleg, also auf dem Ausdruck durch den Formulargenerator „Stk.“ durch „Pcs.“ ersetzen kann. Alternativ wurde mir noch vorgeschlagen, die Mengeneinheit „Stk.“ noch einmal als Mengeneinheit „Pcs.“ anzulegen. Man könnte dann in englischen Vorgängen die Mengeneinheit „Pcs.“ verwenden. Man hat bei diesem Vorschlag allerdings nicht beachtet, dass die Mengeneinheiten einem Artikelstamm fest zugeordnet sind und dieser Vorschlag nicht brauchbar ist. Auf die Folgeprobleme bei Statistiken zu Verbräuchen möchte ich erst gar nicht eingehen. Man darf nicht davon ausgehen, dass diese auf den ersten Blick einfach zu erscheinenden Funktionsanforderungen von jedem ERP-System erfüllt werden und man sie aus diesem Grund nicht abfragen muss.

Die trivial erscheinende Anforderung, Adressen abzubilden ist auch so ein Fall. ERP-Hersteller heben oft hervor, dass sie besonders gut darin sind, internationale Unternehmensprozesse problemlos abzubilden. Wenn ich mir dann die Anlage einer deutschen und einer englischen Adresse zeigen lasse, tritt oft die Ernüchterung ein. Meist besteht in den angebotenen Feldern der Adresse, egal ob man Deutschland oder England als Land ausgewählt hat, kein Unterschied. Obwohl unterschiedliche Daten zu erfassen sind und die Daten auch unterschiedliche Bedeutungen haben. Auf das Thema Datenqualität bin ich an verschiedenen Stellen schon eingegangen, nun sind wir mittendrin. Die Abbildung von Adressen hat etwas mit Datenqualität zu tun und diese sollten vom ERP-System kompromisslos abgebildet werden können. Für Akquise und Vertrieb gibt es keine größere Peinlichkeit als falsch formatierte Adressen oder nicht stimmende landesspezifische Anreden. Selten werden in ERP-Systemen bei der Verwaltung von Ansprechpartner der Namenszusatz und der Titel getrennt. Dies ist für Mailingaktionen aber unbedingt erforderlich. Ein „Dr.“ ist in Deutschland z.B. ein Namenszusatz, ein akademischer Grad nicht. In Österreich legt man bei der Anrede auch auf den akademischen Grad Wert. Wenn man bei Mailings die Anreden landesspezifisch korrekt aus dem ERP-System heraus generieren möchte, müssen Namenszusatz und akademischer Grad in verschiedenen Feldern gepflegt werden. Die Datenqualität fängt bei diesen „einfachen“ Daten schon an, ich kann die Wichtigkeit der Datenqualität nicht oft genug erwähnen.