Einführung eines DMS oder ECM - Teil II


27.08.2008

Teil 2 von 3: informative Entscheidungsgrundlagen schaffen, Anforderungen definieren und Zeitrahmen einhalten

Der Einführung einer DMS/ECM-Lösung sollte immer eine sorgfältige Projektplanung vorangehen. Es ist notwendig, bestimmte Eckpunkte einzuhalten, um nicht zu scheitern. Im ersten Teil dieses Artikels wurde bereits über die Einschätzung und den richtigen Start eines Projektes, über die Rolle von neutralen Unternehmensberatern und die kritische Budget-Frage gesprochen. Auch das Thema der kostenlosen Lösungen auf dem Markt wurde aufgegriffen. Nun geht es darum, welche weiteren Schritte zu einem erfolgreichen Projekt führen:

Wer entscheidet denn über den Kauf? Die Entscheider!

Jemand im Unternehmen wird über die Einführung und vor allem über die Kosten entscheiden müssen. Für die technische Entscheidung ist der IT-Leiter zuständig. Er bestimmt, unter welchen Rahmenbedingungen ein Softwareprodukt eingeführt wird. Außerdem prüft er, welche Sicherheitsanforderungen zu berücksichtigen sind und welche Hardware-Infrastrukturen bestehen. Anbieter stellen für ihre Software-Lösung Anforderungen an Hardware und Software. Diese müssen sie mit den Anforderungen des IT-Leiters abgleichen und gegebenenfalls in ihrem Angebot berücksichtigen. Ebenso hat der IT-Leiter einen Überblick, in welche anderen Unternehmensanwendungen die neue Lösung eingebunden werden sollte.

Der Entscheider für die Finanzen stellt finanzielle Mittel zur Verfügung, z.B. ein Budget, in dessen Rahmen eine Entscheidung gefällt werden darf. Oft scheitern Projekte, weil die Lösungen vom Geschäftsführer oder dem Leiter der Finanzen nicht finanziert werden können oder nicht gewollt sind. Für den Erfolg eines Projektantrags ist es also essentiell, die Anbieterauswahl auf das verfügbare Budget auszurichten oder die Erwartungen und Anforderungen entsprechend zu korrigieren.

Auf Basis der Anforderungen lässt sich grob berechnen, welche Kosten im Unternehmen mit der neuen Lösung gespart werden können. Beispielsweise bieten folgende Kostenfaktoren eine Ausgangsbasis:

  • Kosten für Akten, Papier
  • Kosten für Drucker und deren Wartungsverträge
  • Kosten für Aktenräume
  • Personalkosten für Mitarbeiter, die Akten oder Umlaufmappen im Unternehmen "transportieren"
  • Suchzeiten nach Akten, Dateien und Informationen
  • Zeitaufwand bei Umläufen von Vorgängen im Unternehmen, der durch Bearbeitungs-, Liege- und Transportzeiten entsteht

Hilfreich ist es auch, im Vorfeld zu klären, welcher der Entscheider über das Projekt entscheiden wird und welche Bedingungen er daran knüpft. Oft ist am Ende der Geschäftsführer für die Entscheidung verantwortlich. Werden einer der Entscheider oder gar alle nicht am Projekt beteiligt, besteht eine hohe Gefahr, dass die Einführung der Software-Lösung – egal in welcher Phase – scheitert oder neu aufgerollt werden muss. Das bedeutet verlorene Arbeitszeit.

Es lohnt sich also, alle Entscheider ausfindig zu machen und diese über das Projekt zu informieren. Hier ist Gelegenheit, zu Fragen und zu begründen, warum die Einführung der Software einen Mehrwert für das Unternehmen darstellt.

Was ist überhaupt gewünscht? Anforderungen definieren

Kauft man ein Auto, sind vorher viele Dinge zu klären: Ist das überhaupt nötig? Wofür wird es gebraucht? Wie viele Personen sollen damit fahren? Ausstattung? Farbe?

Wurde in einem Unternehmen erkannt, dass bestehende Probleme mit einem Software-Produkt lösbar sind, muss zunächst geklärt werden, welche Anforderungen zu erfüllen sind. Häufig ist es so, dass die Einführung eines Software-Produktes aufgrund des dringenden Bedarfs in einer Abteilung gestartet wird. Damit sind aber viele Projekte bereits im Vorfeld zum Scheitern verurteilt, weil andere Abteilungen erst in späteren Phasen in die Projekte involviert werden. Damit ändern sich aber sofort die Anforderungen an die Software und auch alle anderen Rahmenbedingungen.

Es ist daher notwendig, die Anforderungen aller Abteilungen zu sammeln, zusammen mit dem Feedback der Mitarbeiter. Diese Anforderungen sind die Grundlage, nach der die Software-Produkte auszusuchen sind. Bei der Einholung eines Angebots sollten die Anforderungen so detailliert wie möglich beschrieben werden. Je gröber die Anforderungen beschrieben sind, desto mehr Anbieter werden sie mit "Ja" beantworten, aber nicht wirklich die gesuchte Lösung bieten.

Sinnvoll ist es, die Anforderungen in verschiedene Kategorien aufzuteilen:

  • Muss-Anforderungen
  • "Wäre schön"-Anforderungen (Nice To Have’s)
  • Eigenprodukt oder Partnerprodukt (je mehr Partnerprodukte, desto höher die Kosten für den Implementationsaufwand, höhere Kompatibilitätsprobleme, Medienbrüche, etc.)
  • Kosten für die Anpassung der Muss-Anforderung (Es sind nicht immer alle Funktionen im Standardumfang eines Produktes inbegriffen. Daher müssen Anbieter diese Funktionen individuell implementieren. Besonders hier ist eine möglichst genaue Beschreibung der Anforderungen notwendig. Je mehr Anforderungen individuell erfüllt werden müssen, um so teurer wird die Lösung)
  • Realisierungszeitraum der Anforderung (Sofort, später, in X Jahren) – damit erhalten Anbieter die Möglichkeit, Anforderungen ohne Aufpreis in das Standardprodukt zu implementieren

Im Anforderungskatalog sollten sich alle Anforderungen an Funktionen sowie an die Hard- und Softwareumgebung (das klärt in der Regel der IT-Leiter) und die Implementierungsbeschreibungen in andere Lösungen befinden.

Schnittstellen sind besonders zu behandeln. Oft wird in Anforderungen beispielsweise "eine SAP Schnittstelle" angefragt. Jeder kommerzielle oder Open Source Anbieter kann irgendetwas in SAP anbinden. Für eine eventuelle Kostenfrage ist es notwendig, möglichst genau zu beschreiben, was von der Schnittstelle erwartet wird. So ist ein einfacher Import aus einer externen Anwendung ganz anders zu bewerten, als eine tiefe Integration in ein ECMS/DMS System, inklusive Interaktion. Je genauer die Anforderungen für die Schnittstelle beschrieben sind, um so exakter kann der Anbieter einen Vorschlag und ggf. eine Kostenvorstellung aufführen. Gerade Schnittstellen in branchenspezifischen Fachanwendungen sind genau zu erläutern.

Wichtig ist: Jeder Anbieter erfüllt die Anforderungen auf seine eigene Art. Daher verzichtet man am besten auf eine Beschreibung von Dialogführungen. Besser beschreibt man genau, was das Ergebnis der Funktion sein soll, damit die Anbieter ihren Weg zum Ziel mit ihrer Software beschreiben können. Wird ein exakter Dialogweg vorgeschrieben, so erfolgt in der Regel eine kostenpflichtige Individualprogrammierung.

Niemals darf man glauben, dass ein Produkt eine bestimmte Anforderung "sowieso" erfüllen kann. Es sollten ALLE Anforderungen – egal wie banal diese sind – in einen Anforderungskatalog mit aufgenommen werden. Dort sind auch die Mengen der unterschiedlichen Daten anzugeben. Viele Applikationen können eine bestimmte Menge an Daten nicht mehr zeitnah verwalten, beispielsweise wegen einer fehlenden Skalierung auf mehrere Server. Für den Anbieter ist es wichtig zu wissen, welche Datenmengen ihn erwarten. Dann kann er eine Skalierung in seinem Angebot entsprechend berücksichtigen, oder sich aufgrund der großen Datenmengen aus der Angebotsphase zurückziehen. Es wird außerdem oft genug vorkommen, dass während des Projekts neue Anforderungen hervortreten. Diese sollten allen einbezogenen Anbietern stets mitgeteilt werden.

Kommerzielle Anbieter unterscheiden zwischen verschiedenen Abrechnungsmodellen. Zwei seien hier als Beispiel genannt:

  • Named User – hierbei werden alle Benutzer gezählt, die mit der Lösung arbeiten. Oft auch als "Arbeitsplatz-Lizenz" bezeichnet
  • Concurrent User – bei diesem Modell wird die Anzahl der gleichzeitig angemeldeten oder arbeitenden Benutzer gezählt. Dieses Modell ist in der Regel kostengünstiger. Für diese Zahl sollten ca. 75% der "Named User" Anzahl kalkuliert werden, da Mitarbeiter oft unterwegs, im Urlaub oder krank sind

Bei hohen Benutzerzahlen sind Open Source (oder Closed Source)-Anbieter interessant, da hier die Kosten für Benutzerlizenzen oft entfallen und die Einsparungen in eine Anpassung der Anwendung an die individuellen Erfordernisse des Kunden investiert werden können.

Die Benutzerzahlen sind die Minimum-Basis für ein späteres Angebot.

Termine, Termine, Termine! Die Meilensteine!

Die meisten Projekte scheitern an einer fehlenden Zeiteinschätzung. Sie "plätschern" vor sich hin, da das Tagesgeschäft die Software-Einführung überlagert und damit zeitlich aushebelt. Außerdem sollten alle Projektbeteiligten durch die Entscheider auch ausreichend Zeit erhalten, das Projekt durchzuführen. Spätestens bei der Evaluierung der Software oder bei einem Prototypen drohen diese Projekte mangels Zeit zu scheitern.

Um das zu vermeiden, sollten Projektleiter zusammen mit den Entscheidern für die folgenden Eckpunkte einen Termin festlegen, bis zu dem

  • alle Abteilungen und Entscheider gefunden und informiert sind
  • die Anforderungen der Abteilungen, Entscheider und Benutzer(!) aufgelistet werden
  • potenzielle Anbieter auf Web-Seiten, Messen oder mit Hilfe von Beratungsunternehmen ausgesucht werden
  • die Anbieter den Anforderungskatalog bearbeiten und beantworten sollten
  • eine finale Auswahl von drei Anbietern stattfindet
  • eine Prototypphase (bei größeren Projekten) laufen soll
  • die Kaufentscheidung erfolgt
  • die Software-Lösung eingeführt wird
  • die erreichten Anforderungen nach der Software-Einführung überprüft werden

Die so gesetzten zeitlichen Limits sollten nicht zu schnell aufeinander folgen, sondern realistisch geplant werden. Dabei immer an eventuelle Urlaubszeiten der Entscheider denken!

Hat man all die bisherigen Hinweise berücksichtigt, ist man dem Endziel "erfolgreiche Projektdurchführung" schon ein ganzes Stück näher gerückt. Im nächsten und letzten Teil des Artikels (erscheint am 8. September) gibt es weitere nützliche Tipps zur rechtlichen Absicherung, zur Präsentation vor Ort und zum Thema Vorabschulungen sowie Prototypen. Außerdem wird eine einfache Projekt-Checkliste bereitgestellt, anhand derer Unternehmen prüfen können, ob sie die Kriterien und Voraussetzungen für ein erfolgreiches Projekt mitbringen.


Kommentare

Bitte beachten Sie unsere Informationen zum Datenschutz.

blog comments powered by Disqus

Weitere Artikel zum Thema

alle Artikel zum Thema

Autor

  • Jens Büscher

    amagno

Jens Büscher ist Geschäftsführer des DMS Systems amagno. Bis 2010 führte er das ECM Unternehmen DocuPortal. Bis 2003 war Jens Büscher als Product Manager verantwortlich für das WCM System der RedDot Solutions AG (heute OpenText).




Unsere Experten


alle Experten

Premium Lösungen

Marktübersicht

Premium Services

Dienstleisterübersicht