-ERP, eine Finanzbuchhaltung für den Public Sector  
Während viele ERP-Systeme für den Private Sector heute bereits eine ordentliche Qualität erreicht haben, was die Gebrauchstauglichkeit und Eignung der Programme in Bezug auf die gestellten Anforderungen (Usability) betrifft, ist das bei den für den Public Sector angebotenen Systemen (Finanzbuchhaltungen und angrenzenden Bereichen) nach wie vor nicht der Fall.  Dies erklärt sich zum einen aufgrund des geringeren potentiellen Kundenkreises und zum anderen aus den erweiterten Anforderungen im Public Sector an das Finanzmanagement und der daraus folgenden wesentlich höheren Komplexität der Aufgabenstellung.
 

Im Unterschied zu "normaler" betriebswirtschaftlicher Software soll eine speziell für den "Public Sector" erstellte Buchhaltung drei Rechnungskreise miteinander vereinen:

In diese 3 Rechnungskreise sollen darüber hinaus möglichst noch die "Nebenrechnungen", wie Inventarisierung und Anlagenbuchhaltung sowie ein Modul für den Zahlungsverkehr und Bestellwesen, Lagerverwaltung sowie eventuell auch Funktionen zur Fakturierung integriert sein. Dies stellt anerkanntermaßen eine nicht ganz triviale Aufgabe dar. Bedingt durch die Komplexität der Materie sind die "Fehlermöglichkeiten" bei der Erstellung einer geeigneten Software entsprechend groß. Wie sich zeigt, werden Fehler vor allem schon in der grundsätzlichen Konzeption (Festlegung des Workflows, Gestaltung der Benutzerschnittstelle, Auswahl der Programmiersprache, Datenbankdesign, etc.) gemacht. Sichtbar wird dies bei vielen bestehenden Lösungen im praktischen Einsatz durch "Unhandhabbarkeit" und durch fehlende oder funktional-logisch unvollständige Verknüpfungen zwischen einzelnen Aufgabenbereichen.

Grundsätzliche Mängel sind im Nachhinein mit vertretbarem Aufwand nicht mehr korrigierbar. Das gesamte Programm erneut zu entwickeln wäre einfacher, als ein bestehendes zu korrigieren.

Verbesserungen sind meist nur in Detailbereichen des Programmes einfach zu realisieren. Eine Fülle von nachträglichen Verbesserungen und Erweiterungen des Programmes führt dann oft zu Brüchen in der Logik des Gesamtsystems, als Folge lässt die Verständlichkeit des Programms auf Dauer zu wünschen übrig, bedingt Unsicherheiten des künftigen Benutzers bei der Programmbedienung. So werden oft die Programmeinführungs- und Schulungszeiten verlängert und erhöht damit die Kosten erhöht. Zur Strategie mancher Softwareanbieter gehört offensichtlich, Programme billig anzubieten und den Umsatz dann durch Supportleistungen zu machen, und von daher ist das Interesse an einer Vereinfachung von Software relativ gering (und dies gilt wohl nicht nur für ERP-Systeme).

Viel Arbeit wird jedoch stets in eine ansprechende "Maskengestaltung" verwendet, die bei Präsentationen zu einem positiven Eindruck beiträgt und von grundsätzlichen Problemen und fehlender Funktionalität ablenkt.

Angemerkt sei hier, daß eine visuell beeindruckende Datenerfassungsmaske mit 100 Eingabefeldern einschließlich Datenhaltung in wenigen Stunden programmiert sein kann, die Gestaltung und Programmierung von logischen Verknüpfungen und eleganten Verfahrensweisen oft Wochen und Monate in Anspruch nehmen, visuell aber oft kaum sichtbar werden und auch nicht umfassend in einer nur wenige Stunden dauernden Präsentation erläutert werden können. Auch in "Kriterienkatalogen", die uns im Rahmen von öffentlichen Ausschreibungen regelmäßig zum Ausfüllen übersandt werden, finden "logische" Inhalte und Prozessbeschreibungen selten einen angemessenen Platz. Anders sieht es aus mit oberflächliche Merkmalen:

Die Schönheit von Datenerfassungsmasken (Anzahl, Beschriftung und Anordnung der Eingabefelder), der Farbgestaltung, Einfügung von Grafiken etc. und andere Kriterien, die im praktischen Programmeinsatz fast keine Rolle spielen, werden gerne abgefragt und bleiben auch nach einer Präsentation oft völlig überbewertet im Bewusstsein der späteren Anwender zurück. Kaum bewertet und oft nicht bemerkt wird, daß Prozesse und Verfahrensschritte in einer Software nicht so einfach, wie man es eigentlich erwarten dürfte, stattfinden, bzw. ablaufen. Eine gewisse "Kompliziertheit" wird oft mangels anderer Erfahrungen als immanenter Teil von Software gesehen und hingenommen.

Um ein Programm zu erstellen, das es einem Anwender ermöglicht, dieses weitgehend ohne Schulung und ohne vorangehendes Studium von Handbüchern zu bedienen, reicht die die Benutzerschnittstelle "Windows" und eine modern gestylte grafische Oberfläche bei weitem nicht aus. Um ein "barrierefreies" intuitiv bedienbares Programm zu erstellen, ist seitens des Programmherstellers neben der genauen Kenntnis der Anforderungen und des Wissens über das individuelle Problemverständnis verschiedener Benutzerkreise (Fachabteilung, Beschaffung, Haushalt, Kasse, Personalabteilung) auch und vor allem Kompetenz in Bezug auf die Umsetzung dieses Wissens in Programmlogik und Datenstrukturen erforderlich. Erfahrung spielt dabei eine wesentliche Rolle.

Diese Voraussetzungen erfüllen wir wie kaum ein anderer und nur deswegen sind wir in der Lage besser als die "Großen" zu sein.

Was wir heute anbieten, ist bereits die vierte von uns programmierte Generation für den Public Sector. Das Ergebnis setzt - wie wir meinen - neue Qualitätsmaßstäbe: Intuitive Programmbedienung ist mit - nach Verständnis der grundlegenden Zusammenhänge und Programmphilosophie - auch im Public Sector machbar. Der Grund dafür liegt wesentlich in der "Null-Toleranzpolitik" des für unsere Softwareentwicklung verantwortlichen Projektleiters gegenüber unverständlich oder kompliziert anmutenden Programmschritten,

Was ein gelernter Systemanalytiker mit mit Interessenschwerpunkt "Benutzeroberfächen und Usability" und umfassendem betriebswirtschaftlichem Know-How und mit langjähriger Programmiererfahrung als Projektleiter bewirken kann, wird in CombiFinanz für den Fachkundigen schnell sichtbar.

Ergebnis ist eine vorbildliche Gestaltung auch der nicht alltäglich oder vorwiegend nur zu Beginn vorkommenden Prozesse und Aufgabenstellungen (Systemkonfiguration, Einrichtung von Stammdaten, Datenübernahme aus Schnittstellen, Erstellung von Jahresabschlüsse, usw.), was gerade auch in der Einführungsphase einen deutlichen Vorteil gegenüber anderen Programmen darstellt.

Die Erfahrung zeigt, daß Softwarehersteller im Public Sector ihr Produkt preisgünstig anbieten und dabei fest mit zusätzlichen Einnahmen aus Schulungs- und Beratungskosten kalkulieren. Möglich wird dies durch die "Undurchdringlichkeit" der Benutzeroberfläche sowie durch eine nicht immer nachvollziehbare Programmlogik, was sich leider immer erst im praktischen Einsatz beim Anwender herausstellt. In vorausgehenden Produktpräsentationen wird dieser sehr wichtige Aspekt nicht sichtbar. Letztlich erweisen sich Mängel in der Usability in der Software als vorteilhaft für den Berater bzw. den Programmhersteller, was natürlich ungern so kommuniziert wird. Die Erfahrung zeigt, daß heute die Einführungskosten die Softwarekosten regelmäßig um bis zu Faktor 10 übersteigen. Uns ist auch ein Fall bekannt, wo eine Finanzbuchhaltung, die vermeintlich günstig mit 20.000 Euro (45.000 mit Einführung) angeboten wurde, mit Einführung schließlich 360.000 Euro kostete. Uns ist dagegen kein Fall bekannt, wo der Berater oder Softwarehersteller für die Mehrkosten haftete. Bisher konnten immer "unvorhergesehene" Gegebenheiten oder individuelle, vorab nicht besprochenen "besondere" Anforderungen für Mehrkosten verantwortlich gemacht werden.  

Tatsache ist: Programme erfordern einen um so größeren Schulungs- und Wartungsaufwand, je schlechter sie sind. Solange diese Erkenntnis bei den Auftraggebern des Public Sectors nicht überwiegt, macht es bei den Programmhersteller wirtschaftlich keinen Sinn, in die Qualität der Programme zu investieren. Das Gegenteil ist der Fall: Qualität führt zu Einnahmeverlusten beim Programmhersteller.

Auch mangels sinnvoll erscheinender Alternativen wurden im Public Sector in der Vergangenheit regelmäßig solche Produkte zu Einsatz gebracht.

Auch Consultants müssen durch "Qualitätssoftware" zunächst einmal Einnahmeverluste hinnehmen. Der Aufgabenbereich eines Consultants bei einer guten Software wird kleiner.  Er liegt jedenfalls nicht mehr beim "Customizing" der Software.  Die Hilfestellung dabei, das "Maximum aus einer unpassenden oder schlechten Software herauszukitzeln" (was oft auch als Customizing verkauft wird), ist nicht mehr nötig (sehen Sie hier an einem  Beispiel, wie einfach man "customized"). Der Aufgabenfokus eines Consultants könnte dafür aber mehr auf betriebswirtschaftlicher Beratung liegen, wo im Public Sector manchmal Defizite erkennbar sind.

  Welche Software Consultants oft empfehlen, ist bekannt. Die Gründe, die sie dafür anführen, werden auch durch die immer gleich lautende Begründung und durch häufige Wiederholung nicht wahrer. Wahr aber ist, daß viele Empfehlungen in der Tendenz von einem gewissen Eigennutz geprägt sind. Wahr ist auch, daß es kaum eine größere Consultingfirma gibt, die ihren Angestellten bei Softwarefragen überhaupt einen Spielraum läßt und daher das Ergebnis von vorne herein feststeht. Dafür muß man ein gewisses Verständnis aufbringen: Man kann nicht erwarten, daß sich eine Firma durch Reduktion der Komplexität einer Software oder durch Empfehlung eines besonders geeigneten Produktes die Geschäftsgrundlage teilweise selbst entzieht.
 

Wohl aus diesem Grunde gibt es Consultants, die nicht zu den besten Freunden von Qualitätssoftware gehören.

Anwender von haben nur mit wenigen Schwierigkeiten zu kämpfen:

Ein gutes Programm lässt sich einfach installieren, einfach konfigurieren, einfach customizen. Für die gesamte Installation, Einführung und Schulung von reichen wenige Tage, während andere Anbieter von Programmen mit vergleichbarem Leistungsumfang oft mehrere Wochen allein für das Customizing veranschlagen (Es ist wirklich wahr: es gibt Anbieter, die brüsten sich sogar damit, die Einführung einer ERP-Software für den Public Sector in wenigen Monaten geschafft zu haben). Wir sehen keinen sachlichen Grund, warum dies Monate dauern könnte. Sobald das Konzept klar ist, ist die Einführung von innerhalb weniger Wochen, wenn nicht Tagen erledigt. Auf Ebene unserer Software gibt es keine Gesichtspunkte, die eine andauernde Beratung erforderlich machen würden.

Im Bereich der Prozessgestaltung ist erfahrungsgemäß Beratungsbedarf, was im Vorfeld einer Softwareauswahl zunächst unabhängig von einer "Zielsoftware" erfolgen sollte. Genau dies ist oft nicht der Fall. Prozesse und Beratung werden oft schon im Rahmen des Softwareauswahlverfahrens auf die Möglichkeiten der Zielsoftware und nicht auf die eigentlichen Anforderungen abgestimmt. Die "Auswertung" der darauf aufbauenden und den Softwareherstellern zugeleiteten Fragebögen im Rahmen einer "Nutzwertanalyse" ergibt so immer das angestrebte Zielergebnis. Auch wenn solche Nutzwertanalysen teilweise schon auf grotesk verzerrten Voraussetzungen aufbauten, wurde das von den durch das Ergebnis schließlich Betroffenen nur selten bemerkt. Und wenn dies doch einmal der Fall war, wurde oft - auch mangels Vertrauen in die eigene Kompetenz - nicht nachdrücklich genug auf Korrektur gedrängt.

Wenn eine anforderungsgerechte Gestaltung der Prozesse unterbleibt, ergeben sich zwangsweise unnötige Schwierigkeiten bei der Einführung einer Software, die weiteren Beraterbedarf nach sich ziehen. Nicht zuletzt bedeutet es auch Mehraufwand bei der täglichen Arbeit und dies über den gesamtem Softwarelebenszyklus.

Auch wir behaupten "anforderungsgerechte" Prozesse in implementiert zu haben und natürlich unterstützt "unsere" Idealprozesse auf besondere Art und Weise. Auch wir werben für unsere Idealprozesse, dennoch besteht auch der Freiraum, Prozesse auch anderes zu gestalten, als unsere Software das explizit begünstigt. In den meisten Fällen konnten anders gestaltete Prozesse auch in in unsere Software abgebildet werden, ohne daß eine größere Neuprogrammierung notwendig wurde. Im Unterschied zu andere Software treten mit unserer Software auch keine "unvorhergesehen" Schwierigkeiten nach der Installation auf. 

Unserer Überzeugung nach profitiert die Volkswirtschaft als ganzes davon, wenn Qualitätssoftware eingesetzt wird, denn freiwerdende Mittel und Ressourcen können an anderer Stelle dann produktiv eingesetzt werden.

 

   

Aus Sicht der TCO (Total Cost of Ownership) dagegen ist eine ausgezeichnet Benutzerschnittstelle und eine durchgängige Programmlogik mehr als eine Kann-Anforderung, sondern ein unbedingtes Muß. Dies gilt um so mehr, je komplexer die Aufgabenstellung ist und gilt daher im Bereich "Public Sector-Finanzbuchhaltung" in besonderem Maße.

Das Programm , das wir anbieten, ist erneut besser, als alle unsere Vorläufer-Produkte, mit der sich bereits Einrichtungen mit einem Haushaltsvolumen von bis zu 80 Mio. Euro und 1200 Mitarbeitern erfolgreich verwaltet haben. Unser Produkt weist nicht nur in Bezug auf die Usability, sondern auch in Bezug auf die TCO deutlich bessere Kennzahlen als das auf, was die Konkurrenz (S.., D.., M.. usw.) anbot und auch heute noch anbieten. Fragen Sie nach:

Eine mit Software ausgestattete Einrichtungen des Public Sectors mit 12 mit ausgestatteten Arbeitsplätzen in der Verwaltung entrichtete im Zeitraum von 1992-2002 (also 11 Jahren) nicht einmal 100.000 Euro an Softwarewartungs- und Beratungskosten (das entspricht ca. 63 Euro pro Monat und Arbeitsplatz) und hatte in dem gesamten Zeitraum Null Tage Systemausfallzeit. Diese Einrichtung war daneben im Stande mit diesen 12 Mitarbeitern einen Aufgabenumfang zu bewältigen, wofür vergleichbare Einrichtungen (mit anderer Software) den doppelten bis dreifachen Personalbestand einsetzen. Zu erwähnen ist auch, daß diese Einrichtung während der gesamten Zeit regelmäßig von verschiedenen Wirtschaftsprüfungsgesellschaften geprüft wurde und es nie grundsätzliche Beanstandungen gab, weder in Bezug auf die Verwaltung noch in Bezug auf unsere dort alle Bereiche (außer Lohn und Gehalt) abdeckende Software. Dies spricht eigentlich schon für sich.

 

Zusammenfassung:

Es gibt eine Fülle von Details, die berücksichtigt werden müssen, um ein ERP-Programm für das Finanzmanagement im praktischen Einsatz gut handhabbar zu machen. Sich um diese Details zu kümmern, kommt für viele Anbieter angesichts des hohen Aufwandes und des anschließenden "Wenigerverdienstes" nicht in Frage. 

Im Unterschied zu dieser Strategie haben wir Interesse daran, Sie nach dem Erwerb unserer Programme eigenständig und von uns unabhängig zu machen.

Wir versprechen Ihnen, daß Sie von unserem Programm folgendes erwarten dürfen: