In Teil 1 dieses Artikels (hier) wurde die Ausgangssituation in vielen Unternehmen dargestellt: die Probleme, die durch den Mangel an koordinierter Vorgehensweise entstehen und jene, die der ECM-Markt durch seine Unübersichtlichkeit verursacht.

Zum Vergrößern auf Bild klicken

Der nachfolgende Teil 2 des Artikels zeigt eine Vorgehensweise zur Erarbeitung einer ECM-Strategie und der Zielarchitektur auf. Diese Vorgehensweise hat sich in zahlreichen ECM-Strategie-Projekten bewährt, auch wenn die individuellen Rahmenbedingungen immer sehr unterschiedlich waren.

Wichtige Ziele einer ECM-Strategie sind:

• Reduzieren der Systemvielfalt für gleichartige Dienste und Funktionen durch Standardisierung von Komponenten (wenn sinnvoll)
• Reduzieren der technischen Komplexität
• Schaffen eines organisatorischen, für Anwender fachlich/funktional sinnvollen und für die IT umsetzbaren Handlungsrahmens für heutige und zukünftige Anforderungen
• Schaffen der organisatorischen Voraussetzungen zur Pflege der ECM-Strategie und umsetzen der Teilprojekte
• Schaffen von Methodenstandards für ECM-Projekte inkl. Ist-Aufnahme & Anwendungsanalyse, Projektqualifikation, Fachkonzeption, Umsetzungs- und Einführungsplanung

Säulen einer ECM-Strategie

Enterprise Content Management (ECM) ist ein sehr unkonkreter Begriff, der für viele ECM-Kernfunktionen steht, die durch unterschiedliche Anbieter und Systemkategorien abgedeckt werden. Reduzieren der Systemvielfalt bedeutet, dass eine Zielarchitektur auf Basis einer minimal notwendigen System- und Komponentenpalette entwickelt wird.
Allerdings wäre es illusorisch anzunehmen, dass es eine einzige Systemlösung gibt, die alle ECM-Kernfunktionen abdeckt. Ein Web Content Management System ist keine geeignete Plattform für Dokumenten Management, und eine Collaboration Plattform taugt nicht zur E-Mail-Archivierung. Wir sind daher davon überzeugt, dass folgende ECM-Kernfunktionen auch in Zukunft von unterschiedlichen Systemplattformen abgedeckt werden:

• DMS/Akte/Archivierung (mit Überschneidungen zu Collaboration)
• Collaboration (mit Überschneidungen zu DMS/Akte/Archivierung)
• Output Management
• Enterprise Search
• Klassische File- und E-Mail-Ablage (die es unseres Erachtens auch in Zukunft – wenn auch hoffentlich reduziert – geben wird)
• In manchen Fällen ist auch die ERP-Umgebung eine eigene ECM-Säule, zum Beispiel bei SAP-Anwendern, die im SAP integrierte Content-Funktionen (z.B. Content Server, DVS, NetWeaver Folders Management, PLM und ILM etc.) nutzen

Ein typisches – hier noch allgemeines – Zielbild ist in der nachfolgenden Abbildung (zum Vergrößern auf Abbildung klicken) dargestellt.

Es kann sehr sinnvoll sein, diese Säulen an bestimmten funktionalen Schnittstellen miteinander zu integrieren, beispielsweise bei der Übergabe von Druckoutput in das Archiv, beim Zugriff via WCM/Portal auf die DMS-Ablage und dergleichen.

Keine homogene Lösung am Markt, die alle ECM-Anforderungen abdeckt

Es gibt Anbieter, die in den vergangenen Jahren eine mehr oder weniger große Zahl an Systemen und Komponenten zugekauft haben und anschließend behaupten, dass mit ihrem Portfolio alle denkbaren ECM-Anforderungen abdeckbar sind. Das ist teilweise sogar zutreffend, allerdings kennen wir keine Gesamtlösung auf Basis einer homogenen Gesamtarchitektur. Manchmal sind sogar die unterschiedlichen Angebote eines Anbieters nicht vereinheitlicht, wenn der Anbieter Lösungen unterschiedlicher Unternehmen akquiriert hat. So besteht immer noch eine manchmal verwirrende Angebotsredundanz selbst bei großen Anbietern, obwohl deren Übernahmen bereits Jahre zurückliegen:

• IBM mit mehreren Lösungen, die den Bereich DMS/Akte/Archiv adressieren.
• Open Text mit einer nicht konsolidierten Vielfalt im Bereich WCM, ebenso bei DMS/Archiv.
• EMC mit Documentum und Legato im Bereich DMS/Archiv

Mit anderen Worten: Die zugekauften Lösungen sind bereits innerhalb EINER ECM-Kernfunktion nicht zu einer einheitlichen Gesamtarchitektur verschmolzen worden. Dabei ist es aus unserer Sicht gerade bei der Kernfunktion DMS/Akte/Archiv unter Berücksichtigung des Marktangebotes nicht mehr notwendig, mehrere unterschiedliche Systeme gleichzeitig einzusetzen. Moderne DMS-Lösungen bringen umfangreiche DMS/Akte/Archiv-Funktionen im Standard mit, die sehr heterogene Anforderungen in unterschiedlichen Bereichen mit unterschiedlichen Prozessen, Mengen und Integrationsanforderungen in einer homogenen Gesamtarchitektur abdecken können. Ähnliches gilt für manche Collaboration-Plattformen: Diese umfassen zahlreiche Funktionen wie Wikis, Blogs, Teamräume, Projekt Management ebenso wie Dokumentenverwaltung, sodass auch hier die Anzahl der einzeln zu beschaffenden Insellösungen deutlich reduziert werden könnte.

Workflow keine eigenständige ECM-Säule

Folgt man diesen Gedanken, kommt man schnell zu der Erkenntnis, dass man nicht alle ECM-Kernfunktionen mit einer einzigen Lösung (Ein-Säulen-Strategie) abdecken kann. Es bestehen aber gute Chancen  eine Mehrsäulen-ECM-Strategie zu entwickeln, die mit wenigen Säulen die unterschiedlichen ECM-Kernfunktionen in einer Zielarchitektur mit einer deutlich reduzierten Anzahl an Systemen definiert.
Jede Säule steht für eine ECM-Kernfunktion und idealerweise wird jede Säule durch eine Systemplattform abgedeckt, die selten (wie im Fall von Open Text) von einem einzigen Hersteller kommen könnte, sondern in der Regel von unterschiedlichen Herstellern kommt.
Funktionen wie Workflow sind nach unserer Ansicht keine eigenständige ECM-Säule, sondern immer Bestandteil einzelner ECM-Säulen. Die Automation des Druckoutputs in einer Output Management Lösung mag vom Anbieter zwar auch als „Workflow“ bezeichnet werden, ist aber etwas ganz anderes als die automatische Änderungsbenachrichtigung in einem Projektraum (Säule: Collaboration), die automatische Dokumentenklassifikation und Vorverarbeitung (Erfassungsworkflow, Teil der DMS/Akte/Archiv-Säule) oder die Automatismen zum frühen Scannen und regelbasierten Weiterleiten in Einzel- oder Gruppenpostkörbe von Antragsdokumenten (ebenfalls Teil der DMS/Akte/Archiv-Säule).

Häufige Diskussion: Collaboration versus DMS. Werkzeugkasten oder Standard-Lösung?

Da jede bessere Collaboration-Plattform auch Funktionen zur Verwaltung von Dokumenten kennt (auch IBM Connections kann dank des FileNet CM-Unterbaus Dokumente verwalten, der SharePoint konnte das schon immer und Alfresco kommt historisch aus dem Dokumenten Management-Lager), wird in fast jedem ECM-Strategieprojekt die Frage diskutiert: Benötigen wir für die beiden Säulen DMS/Akte/Archiv und Collaboration überhaupt zwei Systemlösungen oder genügt nicht eine einzige? Wenn die Collaboration-Anforderungen „nur“ darin bestehen, dass verschiedene Mitarbeiter auf gemeinsame Unterlagen zugreifen wollen: Das kann jedes bessere DMS. Wenn es aber um Funktionen wie Wikis, Blogs, Teamräume etc. geht, dann kommen nur noch sehr wenige DMS-Plattformen in Frage, die meistens aber nur die Anforderungen nach sehr rudimentären Collaboration-Funktionen erfüllen können.   Aber wie gut sind die DMS/Akte/Archiv-Funktionen der Collaboration-Lösungen? Hier ist die klare Antwort: Die allermeisten Collaboration-Plattformen wie Yammer (mittlerweile bei Microsoft), Jive, etc. sind kein Ersatz für DMS/Akte/Archiv-Komplettlösungen.
Es gibt aber Lösungen, die mit einer gewissen Berechtigung in beiden Ligen spielen, die bekanntesten sind Microsoft SharePoint und Alfresco. Aber auch bei diesen beiden Plattformen vermissen Anwender viele Funktionen, die ein modernes DMS von Haus aus mitbringt: Aktenmodellierung, transaktionaler und flexibler Ad-hoc-Workflow, hochvolumige Archivierung mit Scan-Szenarien und fertigen Verknüpfungsfunktionen in verbreitete Fachanwendungen wie SAP, Microsoft Dynamics oder andere müssen bei diesen Lösungsansätzen von Dritten hinzugekauft werden. ABER: wenn ein sehr heterogen aufgestelltes Unternehmen aus welchen Gründen auch immer eher einen Werkzeugansatz verfolgt (zum Beispiel, weil man sehr spezifische Anforderungen hat, für die man keine passenden Produkte am Markt findet), dann lassen sich auf Basis dieser beiden Plattformen auch für DMS/Akte/Archiv-Anwendungen entwickeln, weil sie offen und flexibel genug sind und weil der Partnermarkt groß genug ist, um die fehlenden Komponenten zu ergänzen. Für kleine Unternehmen, die mit begrenztem Budget unterschiedliche DMS/Akte/Archiv-Anforderungen mit Standard-Produkten in kurzer Zeit umsetzen wollen, sind diese beiden Plattformen unserer Ansicht nach und vor dem Hintergrund der Erfahrungen aus den letzten Jahren ungeeignet.

ECM-Strategierahmen

Am Anfang der Strategie steht somit eine Konsensfindung:

• Welche ECM-Kernfunktionen sind im Unternehmen relevant und welche sollen als Thema im Strategiepapier in Phase 1 oder später erarbeitet werden?
• Scoping des Strategieprojektes: Es ist kaum möglich, Themen wie Portal, Enterprise Search, Wissensmanagement etc. NICHT als Bestandteil von ECM zu verstehen. Es ist gleichzeitig aber ebenso unmöglich, alle Themenfelder, die mittelbar oder unmittelbar dazugehören mit der gleichen Aufmerksamkeit abzudecken. Hat das Team die Themenfelder abgestimmt, muss daher eine Priorisierung derjenigen Teilprojekte erfolgen, die sich aus der ECM-Strategie ergeben.
• Wie viele ECM-Strategiesäulen möchte man akzeptieren? Hier benötigt das Team Konsens und muss diesen (was geht und was nicht geht) auch in die Bereiche und die IT kommunizieren,. Wunschvorstellungen, die in der Praxis nicht umsetzbar sind, werden spätestens im Umsetzungsprojekt geradegerückt, was deutlich teurer ist als von Beginn an Ziele anzustreben, die mit den am Markt verfügbaren Produkten innerhalb der akzeptablen Rahmenbedingungen („sinnvolle“ Anforderungen, Aufwand, Zeit, Komplexität) auch umsetzbar sind.
• Welche Ausnahmeregeln sind gestattet? Jedes Unternehmen wird Anforderungen haben, die sich nur durch sehr spezifische Lösungen abdecken lassen. Hier muss ein Regelwerk greifen, das nach Pareto dafür sorgt, dass die wesentlichen Anforderungen mit den Standarddiensten und Funktionen erfüllbar sind. Zur Not müssen die Anforderungen moderiert werden. Abweichungen vom Standard müssen die Ausnahme bleiben, sonst hat jeder Bereichsfürst seine Ausnahmelösung, was nicht im Sinne des Gesamtunternehmens ist, weil sich solche Fleckenteppiche an Insellösungen auf Dauer nicht sinnvoll betreiben lassen und die Strategie ad adsurdum führen
• Wer hat die ECM-Richtlinienkompetenz? Wer darf wem was sagen? Die o.g. Aspekte zeigen immer wieder auf, dass das ECM-Team mehr tun muss als Anforderungen und Marktangebot zu vergleichen. Sehr häufig muss das Team Anforderungen aus dem Bereich A stutzen, damit die Anforderungen aus A und B mit der gleichen Lösung erreicht werden kann. Oder es werden neue Arbeitsweisen und Prozessabläufe gestaltet, die Auswirkungen auf die Organisationsstruktur innerhalb der Bereiche und zwischen den Bereichen haben. Es wird für bestimmte Dokumente und Prozesse immer eine federführende Stelle geben, die den Hut aufhat und die wesentlichen Anforderungen definiert. Aber selten sind Dokumente und Prozesse von Beginn bis Ende eines Prozesses nur in einem Bereich relevant. Andere Bereiche sind mittelbar oder unmittelbar involviert und müssen daher eingebunden werden, wenn man sich mit übergreifenden Ordnungssystemen und Prozessen befasst. Daher benötigt man Koordinierungsfunktionen, die im Wissen des Machbaren (welche Systeme und Dienste stehen zur Verfügung? Was geht gut, was ist aufwendig?) moderierend den Gesamtkontext im Blick haben. Das erfordert zwingend eine ECM-Richtlinienkompetenz, sonst verpuffen die Empfehlungen ohne Auswirkung, wenn diese nicht im Sinne der Bereichs- oder Prozessverantwortlichen sind. Eine wesentliche Voraussetzung für den Erfolg einer ECM-Strategie ist daher, dass diese Konsequenzen erkannt und berücksichtigt werden.
• Team-Organisation: Das Thema ECM kann weder von der IT noch von der Orga alleine geschultert werden. Die IT kennt die fachlichen Anforderungen nicht ausreichend und kann daher keine Fachkonzepte für die Prozesse und Bereiche entwickeln. Der Input für die Anwendungslösung muss aus den Prozessbereichen getrieben werden. Häufig ist es die Aufgabe einer Bereichsvertretung diese Funktion wahrzunehmen. Wichtig ist aber, dass die Lösung von der IT auch umgesetzt und dauerhaft betrieben werden kann. Manchmal ist dieser Bereich direkt der IT angegliedert, manchmal ist er im Bereich Orga (der unterschiedlich benannt wird: Business Architects, Prozess Management, etc.) aufgehoben. Wie auch immer der Name lautet und wo auch immer die Berichtslinien laufen: Es ist für das Thema ECM wichtig, dass es eine ECM-Koordinierungsfunktion zwischen der Kundenseite (den nachfragenden Bereichen) und der Angebotsseite (IT) gibt, die bei Bedarf auch andere Stellen (Revision/Recht, Leitungsebene, u.a.) einbindet. Eine solche Koordinierungsfunktion muss nicht zwangsläufig mit der Schaffung neuer Stellen verbunden sein. Häufig ist es ein Team, das aus IT, Orga und Fachbereichsvertretung delegiert wurde.
• Anforderungsmanagement: In einem Unternehmen mit unterschiedlichen Organisationsbereichen (in der Grafik oben symbolisiert durch Abteilungen und Bereiche) wird es sehr unterschiedliche Anforderungen an die ECM-Landschaft geben (symbolisiert durch die Rosettenbilder, die unterschiedliche Sets der ECM-Funktionen darstellen). Ein Beispiel zur Veranschaulichung: Das Rechnungswesen möchte vielleicht nur Eingangsrechnungen mit der ERP-Anwendung verknüpfen und ordnungsgemäß aufbewahren („revisionssicher archivieren“). Die technische Abteilung möchte unterschiedlich strukturierte Projektakten anlegen und in der Lage sein, Papierdokumente und elektronische Unterlagen aus MS Office, Outlook und dem File-System dort abzulegen. Archivierung KANN hier, je nach Dokumentart,  eine Anforderung seinist aber nicht der Projekttreiber. Marketing versteht unter ECM die Marketing-Datenbank und den Internetauftritt und die IT kämpft noch mit Massendrucksachen im IBM 1403 oder AFP-Format, von denen einige in Kundenakten abgelegt werden sollen. Die Liste der denkbaren und legitimen Anforderungen an „ECM“ ließe sich beinahe beliebig fortsetzen. Hier setzt die Säulenstrategie an. Das Team analysiert die Anforderungen, entscheidet, ob die Anforderungen mit einer der vorhandenen ECM-Säulenprodukte abgedeckt werden können und erarbeitet eine Lösungskonzeption in Zusammenarbeit mit den Produktspezialisten (siehe die mit [3] markierten Funktionen im Zielbild der ECM-Säule). Hierbei kommt dem ECM-Team auch eine Vermittlerrolle zwischen Anwendern und IT zu. Die Probleme bei mangelnder Abstimmung fangen schon mit sprachlichen Problemen an. Wenn ein Anwender einen „Projektraum“ oder „Workflow“ oder „Knowledge Management“ fordert, ist noch lange nicht klar, was er damit meint. Gemeint sein könnte:
  • Für „Projektraum“: Eine gemeinsame Teamablage für Dokumente, eine Netzwerk-Meeting-Funktion für Audio- und Video-Übertragung mit Anwendungs-Sharing oder einfach nur eine gemeinsame E-Akte.
  • Für „Workflow“: Die Automation von Redaktionsprozessen komplexer Dokumente, das Scannen von Eingangsdokumenten vor der Sachbearbeitung und Abarbeiten aus Arbeitskörben, die Drucksteuerung umfangreicher Massendruckverfahren, formularbasierte Workflows für Entscheidungsvorlagen, Umlaufdokumente etc.
  • „Knowledge Management“: Diesen Begriff würden wir in jedem Projekt sofort auf die schwarze Liste („Buzzword-Bingo“) setzen. Darunter versteht wirklich jeder etwas komplett anderes. Hier muss man alle Beteiligten zwingen, fachlich-funktional zu erläutern, was denn eigentlich gemeint ist. Die Spannbreite ist dann oft erschreckend: von der Expertensuche im eigenen Haus, Portalanwendungen mit semantischer Suche in unterschiedlichen Beständen, Auswertungsverfahren der ERP-Daten usw.

Inhouse ECM-Beratung

Was man also benötigt ist eine Anforderungsqualifizierung, die die Probleme, Anforderungen und Wünsche der Anwender aufnimmt und qualifiziert, mit den vorhandenen ECM-Werkzeugen mappt und daraus eine umsetzbare Lösungskonzeption erarbeitet. Das ECM-Team ist dann in der Rolle eines internen ECM-Beraters mit unterschiedlichen Aufgaben:

• Erarbeitung eines systematischen Vorgehensmodells mit Werkzeugen zur Analyse, Lösungskonzeption (auf Basis der ECM-Unternehmensstandards), Implementierung, Test, Abnahme und Einführungsbegleitung.
• Moderation unrealistischer Anforderungen. Diese müssen nicht unbedingt von Anwenderseite kommen. Manchmal hat auch die Führungsebene Ansprüche an die Architektur oder Funktionalität, die sich mit den heute verfügbaren Systemen schlichtweg nicht umsetzen lassen. Hier gehört durch Know-how gut unterfüttertes „Standing“ dazu, so manche „Vision“ auf Führungsebene wieder geradezurücken (Beispiele: „wir wollen nicht ablegen, wir wollen nur finden und wollen daher nur noch Volltextsuche, so wie Google“ oder, auch gut „Wir machen alles mit dem SharePoint“).
• Mit „Moderation“ ist auch Qualifizierung gemeint! Nicht jeder Wunsch lässt sich betriebswirtschaftlich sinnvoll umsetzen. Einer unserer Kunde hat den schönen Begriff der „Leitplanken“ verwendet, innerhalb derer sich das Projekt bewegen muss. Leitplanken können personelle, zeitliche und andere betriebswirtschaftliche Ressourcen sein, aber auch IT-architektonische Rahmenbedingungen. Ein Unternehmen, dessen IT sich mit bestimmten Architekturen und Komponenten gut auskennt, bevorzugt zu Recht Lösungen, die sich innerhalb dieser Architekturen dauerhaft betreiben lassen. Die auf Papierform beste Lösung ist manchmal nicht die beste Lösung für das Gesamtunternehmen.
• Erarbeitung ECM-Roadmap mit Migrationspfad. ECM-Projekte sind fast immer eine Abfolge mehrerer Einzelprojekte, weil Prozesse und Bereiche häufig individuelle Anforderungen an die Integration mit anderen Anwendungen und an die Ausgestaltung der Prozesse und Ordnungssysteme haben. Daher umfasst ein ECM-Projektplan häufig eine Reihe priorisierter Einzelprojekte und die Einzelprojekt-spezifische Ressourcenplanung. Alt-Anwendungen, die nicht mehr in die Strategie passen, müssen natürlich nicht sofort oder vielleicht sogar nie migriert werden, wenn sie die Anforderungen erfüllen und der Betrieb keine besonderen Nachteile zeigt. Das sollte aber nicht zufällig, sondern durch einen systematischen Bewertungsprozess erfolgen.
• Erarbeitung zentrales Dienste- und Funktionsangebot. Dazu gehören manchmal nicht nur die Anwendungsfunktionen (Aktenmodell, Vorgangsmodell für Dokumentenprozesse von der Erfassung bis zur Bearbeitung in Dokumenten-Workflows) sondern auch klassische Dienstleistungsangebote wie Scanning, Archivauslagerung etc.
• Einbettung in die regulatorischen Leitplanken: Häufige und parallele Teilaufgaben sind die Erarbeitung von Verfahrensdokumentation, Schriftgutordnung oder Arbeitsanweisungen zum sachgerechten und regelkonformen Umgang mit geschäftsrelevanten Unterlagen und den neuen Werkzeugen. Diese Tätigkeit wird häufig von Bereichen wie Compliance/Revision entweder beauftragt oder verantwortet, sollte aber immer mindestens in Abstimmung mit dem ECM-Koordinierungsteam erfolgen.

ECM ist zu 51% ein Orga-Thema

Eine ECM-Lösung ist ein exzellentes Werkzeug mit all seinen funktionalen Möglichkeiten, Dokumenten- und Content-Probleme zu lindern oder gar abzustellen. Aber die Ursachen liegen nicht immer im Mangel an Software oder Technologie. Das ursächliche Problem ist häufig der Mangel an (akzeptablen) Regelungen oder der Unwille der Bereiche, ihre individuell gewachsenen Lösungen und Anforderungen den Unternehmensinteressen unterzuordnen. Dafür mag es gute Gründe (zentrale Lösungen sind untauglich, zu komplex, Verrechnungspreise zu hoch, kommen nicht rechtzeitig, etc.) oder schlechte Gründe geben (Phänomen der „Fürstentümer“, die zentrale Lösung ist vermeintlich nicht geeignet). Eine ECM-Lösung ist letztlich nur ein Werkzeug zur Umsetzung fachlicher, funktionaler und vor allem auch organisatorischer Vereinbarungen. In einem ECM-Projekt sind Prozesse und Ordnungssysteme zu implementieren, die nicht nur die Optimierung einzelner Bereiche im Blick haben. Es ist daher wichtig zu verstehen, dass bei bereichsübergreifenden Prozessen geklärt werden muss, wer die Vorgaben für Attribute und Ordnungsstrukturen macht und wer bei dieser Strukturierung eingebunden werden muss. Wir sprechen hier häufig vom federführenden Bereich (zum Beispiel dem Bereich Einkauf bei Beschaffungsakten) und den involvierten Bereichen, die später auf Teile der Einkaufsakte wie zum Beispiel Rechnungen zugreifen wollen. Aber bereits das Einräumen der Leserechte anderer Bereiche auf Dokumente fällt manchen schwer. Natürlich stehen die fachlichen Anforderungen im Vordergrund, aber nicht isoliert, sondern im Gesamtkontext abgewogen.
Wie auch immer man das sehen mag: Es ist sicherlich klar, dass ein ECM-Projekt diese organisatorischen Aspekte zwingend berücksichtigen muss. Lässt man aber eine reine IT- oder reine bereichsorientierte Vorgehensweise zu, entsteht automatisch ein Fleckenteppich an Lösungen, der auch von einem größeren Unternehmen auf Dauer nicht wirtschaftlich betrieben werden kann. Das notwendige Know-how aus den Bereichen ECM-Funktionalität, Ordnungssysteme, Integration, regulatorische Anforderungen etc. muss an vielen Stellen erst aufgebaut werden, aber es ist aus unserer Sicht unverzichtbar, um diese koordinierende Aufgabe im Unternehmen wahrzunehmen. Was in der Praxis nicht funktioniert, ist das unkoordinierte Erstellen einer Lösungskonzeption ohne Prüfung, ob der Markt das Spezifizierte auch hergibt und ob die IT dieses auch leisten (herstellen und betreiben) kann.  Ebenso führ das teure Basteln mit vorhandenen und daher vertrauten Systemen und Werkzeugen zu Problemen, wenn Funktionen umgesetzt werden sollen, für die diese Systeme gar nicht gemacht wurden.

Fazit: nicht Mangel an ECM-Technologie, sondern Mangel an Einsicht

Die Erarbeitung einer ECM-Strategie erfordert immer das Zusammenarbeiten verschiedener Bereiche: Mindestens IT und Orga sowie die Leitungsebene, weil Bereichsinteressen mit den übergeordneten Zielen der Gesamtsicht eines Unternehmens kollidieren können. Die häufigste Frage in vielen Projekten ist: wer soll das wahrnehmen? Es gab halt bisher (nach unserer Wahrnehmung) in den allermeisten Unternehmen keine ECM-Koordinierungsstelle und daher fehlt eine natürlich Zuordnung. Das Schaffen neuer Stellen und der Aufbau auf der grünen Wiese ist unbeliebt (aus Kostengründen) und meistens nicht praktikabel. Ein häufiger Weg ist der Aufbau eines virtuellen ECM-Teams, die in ursprünglichen Berichtslinien verbleiben (also in IT, Orga, Recht/Revision etc.) aber eine bereichsübergreifende ECM-Richtlinienkompetenz innehaben. Das funktioniert aber nur, wenn die Leitungsebene dies auch so beauftragt und die Bereichsverantwortlichen dieses gemeinsame Vorgehen auch mittragen, indem das Team also mit den notwendigen Richtlinienkompetenzen ausstattet wird. Dazu gehören auch Entscheidungskompetenzen. Wenn die Einsicht der versteckten Kosten, Arbeitsprobleme und Risiken nicht da ist, wird es auch keine Änderung der bisherigen Vorgehensweise geben und die Mitarbeiter werden weiterhin mangels besserer Optionen die File- und E-Mail-Systeme zumüllen, es wird eine wachsende Zahl an ECM-Lösungen geben und am Ende wird niemand mehr wissen, wo denn was abgelegt ist, auch wenn das letzte Stück Papier gescannt ist. Und dann passiert, was ein Mitarbeiter in einem Interview als „seine“ Lösung genannt hat: Er druckt sich alles aus was er in „seiner“ Akte haben möchte, weil das die derzeit verlässlichste Ablage im Unternehmen sei. Die Ursache ist nicht der Mangel an Technologie sondern der Mangel an Einsicht, wie man mit ECM-Technologie umgehen muss.