Aus der Praxis: Anruf des DMS-Projektleiters eines mittelgroßen Unternehmens. Man bittet uns um Hilfe, weil die ständigen Nachforderungen des Anbieters mittlerweile ein Mehrfaches des ursprünglichen Angebotspreises ausmachen, kein Ende abzusehen. Das könne doch nicht sein, man habe doch keine so besonderen Anforderungen: ein bisschen Scannen, MS Office- und Mailintegration, normale Aktenstrukturen. Und dann so was! Klingt bekannt? Klar, die bösen Anbieter!
Bereits während des ersten Telefonates mit dem Anwender wird die Ursache des Problems klar: Der Kunde wusste selbst nicht genau, welche DMS-Funktionalität das System mitbringen soll: „ein DMS halt!“.
Ausgehend von der trügerischen Annahme, dass sich die Systeme nicht sehr voneinander unterscheiden (solchen Unsinn hört und liest man in unserer Branche immer wieder – daher kann man es dem unerfahrenen Anwender nicht vorwerfen, wenn er sich auf solche Aussagen verlässt), hat man zwei Anbieter um ein „Standard-DMS-Angebot“ (O-Ton) gebeten. Auf ca. 10 Seiten wurden die vermeintlich ausreichenden Konfigurationsangaben zusammengefasst und die funktionalen Anforderungen aufgelistet (Anzahl Clients, Anzahl Scandokumente etc.). Die Auswahl fiel auf den scheinbar günstigeren Anbieter, also denjenigen, der den geringeren Preis nannte.
Das Problem liegt hier ursächlich auf Anwenderseite: auf Basis der sehr rudimentären Vorgaben hatte keiner der beiden Anbieter die geringste Chance, ein verlässliches Angebot abzugeben. Beide konnten nur unvollständig Eigen- oder Fremdlizenzen bepreisen. Aber vor allem: Die zur Anpassung notwendigen Dienstleistungen waren nicht einmal grob schätzbar. Man könnte den Anbietern vorhalten, dies dem Kunden nicht klargemacht zu haben. Der Vertrieb wird aber nur rückfragen oder dagegen halten, solange ihm das nicht als versteckter Mangel am eigenen Angebot oder an der eigenen Kompetenz ausgelegt wird. In der Ausprägung mag dieses Beispiel – es hat sich allerdings tatsächlich wie geschildert zugetragen – ein seltener Einzelfall sein. Aber die Tatsache, dass ein Mangel an zur Verfügung gestellten Detailinformationen zu Mehraufwendungen im Projekt führt, ist wohl eher die Regel.
Das Problem fängt bereits bei der vermeintlich einfachen Abfrage der benötigten Software-Lizenzen an. Was dem Anwender als detaillierte Anfrage erscheint („Server und Client-Lizenzen für 100 End User, Scan-Software für 500 Dokumente pro Tag, MS Office Integration, Client-basierte E-Mail-Archivierung, Schnittstelle zu Navision, Aktenverwaltung etc.), ist in dieser Form faktisch nutzlos. Die am Markt angebotenen Systeme unterscheiden sich bei allen derartigen generischen Funktionsbezeichnungen so fundamental voneinander, dass man die relevanten Unterschiede – die dann auch zur Bewertung und zum Ranking der Angebote führen – erst erkennt, wenn man „tiefer gräbt“. Das Beispiel „Aktenverwaltung“ soll dies veranschaulichen, wobei wir zur Vereinfachung die unterschiedlichen Preismodelle für Concurrent User, Named User, Web User bis hin zur Flatrate für „Alles & Jeden“ außer Acht lassen.
Anbieter A versteht unter Aktenverwaltung das, was sein Produkt dazu im Standard hergibt: eine nach dem Dokumentindex „Aktenzeichen“ sortierte Trefferliste. Sieht schick aus, ist einfach zu bedienen und ehrlich gesagt: Wer heute und morgen nichts anderes benötigt, der ist damit gut bedient.
Anbieter B verfügt dagegen über eine sehr ausgefeilte „echte“, aber aufpreispflichtige Aktenverwaltung. „Sortierte Trefferliste“ geht natürlich auch, dafür muss er nicht einmal seine dedizierte Aktenverwaltung anbieten. Aber in der irrigen Annahme, dass der Kunde weiß wovon er redet, bietet er die dedizierte Aktenfunktionalität an: Datenmodellierung für Akten unabhängig vom Datenmodell für Dokumente, was n:m-Beziehungen zwischen Akten und Dokumenten erlaubt, und daher in der Praxis überaus elegante Lösungen ermöglicht. Es gibt ein grafisches Werkzeug, um Aktentemplates zu bauen und das System kennt Aktenversionierung und Aktenhistorie, Rechte auf Register, Indexwerte zu Akten wie z.B. Aktenzeichen, Aktenstatus, Verlinkung Akten und Unterakten, Wiedervorlage, Verwendungsnachweis (in welchen anderen Akten steht das Dokument?) usw.. Es gibt ein API, um leere Akten von außen zu erzeugen und einen Offline-Akten-Client etc. Die volle Breitseite eben, was einem papieraktengeplagten Anwender in Unternehmen und Behörden die Tränen in die Augen treibt, wenn er sieht, was mittlerweile möglich ist. Dennoch verliert Anbieter B das Projekt, weil Anbieter A, der ja die Anforderungen zur Aktenverwaltung vermeintlich auch abdeckt, das wirtschaftlich günstigere Angebot abgegeben hat.
Damit nimmt das Unheil seinen Lauf, weil der Kunde viel zu spät feststellt, dass ihm die sortierte Trefferliste nicht reicht und er eigentlich sehr wohl die erweiterten Aktenfunktionen des Angebots B benötigt. Zudem dachte der Kunde beispielsweise: „das ist doch wohl Standard, eine Akte auf den USB-Stick zu exportieren und mitzunehmen“ („das geht doch schon im File-System und das wollen wir gerade abschaffen“). Oder Dokumente aus MS Office per „Speichern unter“ in ein Aktenregister abzulegen. Oder die Akte per Link in Outlook weiterleiten oder den Akteninhalt drucken zu können, ohne dass die 15 Dokumente in der Akte in vier unterschiedlichen Viewern (Acrobat, Word, Excel und ein TIFF- und JPEG-Viewer) geöffnet werden, um dort individuell über jeweils unterschiedliche Druckdialoge ausgedruckt werden zu müssen.
Der Anwender wusste halt nicht, dass sich die Systeme am Markt fundamental unterscheiden, sowohl in der prinzipiellen Verfügbarkeit von als Basisfunktionen angenommenen Anwendungsfunktionen als auch in Details, die für die tägliche Bedienung wichtig sind. Was hier beispielhaft und immer noch sehr verkürzt für Aktenverwaltungsfunktionen dargestellt wurde, gilt ebenso für andere typische DMS-Anwendungsfunktionen wie Scannen und Indexierung, Mail-Archivierung, MS Office-Integration, Retrieval- und Output Integration mit anderen Systemen, Versionierung dynamischer Dokumente, Freigabe/Genehmigungs- und Postkorb-Workflows, Volltext-Integration, Dokumenten-Viewer, Verwaltungswerkzeuge, Customizing und Programmiermöglichkeiten usw. Auch die Tatsache, dass manche dieser Funktionen nicht vom DMS-Produkthersteller, sondern von einem Partner oder anderen Lieferanten stammen, macht die Sache nicht leichter: Bei Fremdkomponenten entstehen Kostenrisiken und technische Risiken in der dauerhaften – also über die nächsten Releases/Versionen hinweg – notwendigen Betriebsfähigkeit.
Neben den Softwarekomponenten stellen die Dienstleistungen, die notwendig sind, um die Systeme in der individuellen Situation des Kunden aufzusetzen, einen ebenso großen, häufig sogar dominierenden Kostenblock dar. Dies bezieht sich sowohl auf die DMS-Komponenten selbst als auch auf die benötigten Integrationen in Fachanwendungen: Die Erstellung der Barcode-Verknüpfungsszenarien mit der führenden Anwendung, die konkrete Ausgestaltung der Aktensicht für die unterschiedlichen Bereiche, die Implementierung der nächtlichen Übernahme der Indexdatenübernahme aus dem CRM-System, das Training der Dokumentarten und Besonderheit für die automatische Dokumentenklassifikation, das Anpassen der Makros zur MS Office Integration und den verschiedenen Word-Templates. Die Liste dieser Positionen ist in der Regel deutlich länger als die Liste der Softwarekomponenten. Und jede dieser Dienstleistungspositionen sollte bei der Angebotsabfrage mit folgenden Details angefordert werden: „Aufwand zur Feinkonzeption, Implementierung, Test, Abnahme und Dokumentation“. Und wir alle wissen: Dann reden wir bei vielen dieser Positionen über eine Anzahl Personentage, die salopp gesagt durch 5 ohne Rest teilbar ist und das multipliziert mit der Anzahl solcher Anpassungen. Außer natürlich, man hat solche Details vorher beschrieben und findet Systeme am Markt, die diese Funktionen bereits im Produktstandard enthalten, so dass sie lediglich über Customizing-Werkzeuge eingerichtet werden müssen. Da es solche Systeme am Markt gibt, lohnt sich der Aufwand, die Hausaufgaben vorher zu machen. Das ist billiger, als hinterher Funktionslücken durch Individualprogrammierung schließen zu müssen oder, noch schlimmer, das Verfahren aufzuheben und die ganze Systemauswahl nochmal durchzuführen.
Ebenso wichtig für den Projekterfolg ist das Know-how der beteiligten Personen – sowohl auf Anbieter- als auch Anwenderseite. Die Ursachen mancher gescheiterten Projekte liegen nicht im Produkt, sondern im fehlenden Know-how des Projektteams begründet. Kunden sollten sich vom Anbieter darstellen lassen, welche Personen welche Arbeitspakete im Projekt durchführen sollen und sie sollten sich die konkreten Produkt- und Projekterfahrungen der zugeordneten Personen aufzeigen lassen.
Know-how kostet kein Geld, sondern spart Geld, sonst ist es nutzlos. Eine ausreichend detaillierte Anforderungsanalyse, eine schlüssige Lösungskonzeption und damit eine korrespondierende Preisabfrage kosten um Faktoren weniger, als der Mangel dieser Detailinformationen im späteren Projekt kosten würde.