Alle Beiträge mit dem Tag "Goldene Regeln"
23. Januar 2008
Goldene Regel #23: Ergebnisse kontrollierbar machen
Das Enterprise Content Management mehr als Software ist und das Konzept der wichtigste Teil der gesamten Arbeiten ist, sollte bei jedem Projektverantwortlichen bekannt sein. Aber auch ein gutes Konzept bringt noch keinen Erfolg, wenn in dem Konzept nicht Kriterien definiert sind, was das Projekt eigentlich erfolgreich macht.
Dabei ist es nicht nur im Interesse des Unternehmens, es ist auch im größten Interesse aller Projektteilnehmer, wenn klar und deutlich schon früh im Projekt kommuniziert und später eindeutig formuliert wird, was die entscheidenden Faktoren für den Projekterfolg sind – und wie man diesen messen will.
Zwar ist es nicht einfach, messbare Kriterien für den Projekterfolg zu finden und nie werden einzelne Kritierien den Gesamterfolg oder -misserfolg abbilden – aber ohne irgendwelche Kriterien gerät das ganze Projekt ins wanken. Denn woran will man eigentlich fest machen, dass sich das Projekt gut entwickelt? Mit was soll ein weiterer Ausbau argumentiert werden? Nur auf subjektiven Argumenten? Dies führt nicht zum Ziel und sorgt nur für Unzufriedenheit. Je deutlichere Kriterien es gibt, desto deutlicher lässt sich der Erfolg messen.
Und was spricht dagegen, beispielsweise die Dauer, die Mitarbeiter pro Tag im System arbeiten als Bewertungskriterium zu wählen? Am besten in Verbindung mit der Anzahl von Supportanfragen. Aber es gibt noch viele weitere, oft höchst individuelle, Punkte, die gut berücksichtigt werden können und sollten.
24. Januar 2007
Goldene Regel #22: Funktionalität ist gut, Sympathie und Know-how sind besser.
Die Auswahl einer passenden Softwarelösung muss auf nachvollziehbaren Fakten basieren und gut dokumentiert durchgeführt werden. Dies ist die Grundlage für eine erfolgreiche Softwareauswahl – jedoch nicht immer für ein erfolgreiches Projekt.
Neben den reinen Funktionalitäten des auszuwählenden Softwareprodukts, sind auch andere, nicht so klar zu analysierende und subjektive Kriterien ein wichtiger Bestandteil einer erfolgreichen Produktauswahl.
Zwar ist es wichtig, dass die ausgewählte Software die Anforderungen erfüllt – genauso wichtig sind jedoch auch z.B. die Qualität der Kundenbetreuung, die Flexibilität des Unternehmens, die generell Verfügbarkeit und das individuelle Know-how der Integration- oder Implementationspartner sowie letztendlich auch die individuelle Sympathie und das Vertrauen zum Unternehmen und seinen Mitarbeitern.
Hierbei lassen sich teilweise genau keine objektiven Kriterien anbringen und ein Berater tut sich schwer, hier objektive Aussagen zu treffen – eine Auswahlberatung ohne (möglichst objektiv formulierte) Einschätzung der “Projekttauglichkeit” des ausgewählten Anbieters und seiner Partner muss aber elementarer Bestandteil einer seriösen Produktauswahl sein.
Wichtig: Die “harten Kritierien” können die “weichen Kriterien” nicht überstimmen. Wenn die erfolgreiche Zusammenarbeit mit einem Unternehmen fragwürdig ist, sind die Fähigkeiten der Software irrelevant.
13. Dezember 2006
Goldene Regel #21: Ein WCMS darf keine Designeinschränkungen bieten
Agenturen sind kreativ – und werden genau dafür bezahlt. Um erfolgreich zu sein, müssen sich Webseiten abheben – in Punkte Design, Usability und Bedienkonzept (auch wenn die beiden letzten Punkte oft nicht leicht miteinander vereinbar sind). In Agenturen werden keine Techniker beschäftigt, sondern “Kreative”, die eine ganz andere Sicht auf die Dinge haben und haben sollen.
Ein Internetprojekt – aber auch Projekte im Bereich Intranet, Extranet etc. – lebt nur sekundär von Integration oder Funktionalität, die dem Benutzer angeboten wird, sondern primär von Design und Inhalt – wobei vorallem Letzteres durch Einsatz eines Web Content Management Systems möglichst gut zu verwalten sein soll.
Eine Grundlage von Web Content Management ist daher die Trennung von Design, Inhalt und Funktionalität. Für ein Internetprojekt ist es daher förderlich bis tödlich, wenn aufgrund von technischen Limitationen des WCMS ein Design nicht umgesetzt werden kann. Nicht nur, dass das Design verändert werden muss – die Probleme liegen meist tiefer. Wenn ein Design nicht umsetzbar ist, sind auch andere elemenatere Ansprüche an eine moderne Website (“sauberer” Quellcode, Barrierefreiheit, Suchmaschinenoptimierung, generelle Website Usability) meist nicht erfüllbar – womit der Einsatz des Systems ausscheidet.
Ausnahmen von dieser Regel gibt es keine: Was als HTML/XHTML/CSS realisierbar ist, muss auch mit dem WCMS realisierbar sein – sonst funktioniert die Trennung von Design und Inhalt nicht und weitere Probleme werden alsbald folgen.
28. November 2006
Goldene Regel #20: Sprachverwirrungen vermeiden
“Daher heißt ihr Name Babel, weil der HERR daselbst verwirrt hat aller Länder Sprache und sie von dort zerstreut hat in alle Länder.” (Genesis 11,9)
Die Sprachverwirrung in der IT-Branche ist keine “babylonische Sprachverwirrung”. Im Gegensatz zur biblischen Sprachverwirrung, ausgelöst durch Gott als Folge des Turmbaus zu Babel, sind die vielen “Zungen” in den in der IT-Branche gesprochen wird, selbst – und oft mit Grund – gewählt.
Verschiedene Personengruppen benutzen einen besonderen Wortschatz, um sich in ihrem Fachgebiet optimal miteinander auszutauschen. Hierbei werden nicht nur Fachworte verwendet, sondern es finden auch Umdeutungen von Worten statt. Eine Nebenwirkung ist, dass die Kommunikation mit Personen aus einer anderen Fachrichtung mit einem anderen Wortschatz schwierig ist und es zu Verständigungsproblemen und Missverständnissen kommt.
So wird in einem ECM-Projekt von konzeptioneller Seite der Begriff “Workflow” verwendet, um die Abbildungen von Arbeitsabläufen der Benutzer und Interaktion mit Content/Dokumenten und anderen Benutzern zu beschreiben. Ein einfaches Beispiel ist ein Freigabeverfahren, wo Content bevor er für andere Benutzer verfügbar ist, zunächst von einer anderen Stelle genehmigt werden muss.
In der Systemtechnik wird der Begriff jedoch oft anders verwendet. Hier kann ein Workflow der automatisierte Ablauf eines IT-Prozesses, beispielsweise eines Backups oder eines Datenaustausches sein. (Man könnte dazu auch “Batch-Job” sagen, würde damit aber den komplexen Abläufen in einer modernen IT-Applikation nur bedingt gerecht.)
Unbedingt wichtig ist daher die klare und griffige Definition von Begriffen individuell in jedem Projekt. So kann mit allen Beteiligten auf einem gemeinsamen Wortschatz gesprochen werden und es wird niemand ausgegrenzt oder herabgesetzt, weil er Begriffe in seiner täglichen Arbeit anders definiert.
7. November 2006
Goldene Regel #19: Über den Erfolg eines Projekts entscheidet nicht die Technik
Die derzeit grundsätzlich eingesetzten Technologien hinter Enterprise Content Management sind mittlerweile erprobt und sehr praxistauglich. Nur selten stehen dem Erfolg eines Projektes wirklich handfeste technische Probleme im Wege. Hauptgründe für Probleme bei der Einführung sind die fehlende Akzeptanz bei den Benutzern und die fehlerhafte Berücksichtigung bestehender Prozesse und Abläufe.
Genau deshalb muss ein DMS-Projekt nicht zwingend in der IT-Abteilung aufgehangen sein. Die IT spielt natürlich eine wichtige Rolle, insbesondere für den Betrieb der Lösung. Die eigentliche Arbeit bei der Einführung liegt aber in den Fachabteilungen! Hier müssen Dokumente strukturiert, Abläufe analysiert und Prozesse definiert werden.
Außerdem muss dafür gesorgt werden, dass die tatsächlichen Anwender den Mehrwert der Lösung erkennen. Was aus technischer Sicht oder unter dem Aspekt der Prozessoptimierung sinnvoll erscheint, kann schnell zur großen Gegenwehr unter den Anwendern führen. Diese ist meist nicht aktiv – allein die passive Gegenwehr durch Nichtbenutzung der neuen Lösung läßt ein Projekt scheitern.
Anwender, Planer, IT-Abteilung, Fachabteilung, Geschäftsführung und evtl. externe Verantwortliche gehören daher so früh wie möglich gemeinsam an einen Tisch gesetzt. Jeder muss aus seinen Erfahrungen beitragen dürfen und im Rahmen seiner Fähigkeiten und Kenntnisse Berücksichtigung finden.
17. Oktober 2006
Goldene Regel #18: Kommerzielle Software ist nicht besser!
Auch wenn Open Source Software immer nur als “Alternative” zu kommerzieller Softwaregesehen wird und dann Argumente für Open Source aufgelistet werden, sind kommerzielle Produkte nicht per se “besser” und “erste Wahl”. Vielmehr sollten bei einer Produktauswahl jegliche Lizenzen als gleichwertig betrachtet und mit den individuellen Anforderungen des Projekts verglichen werden.
Der wirkliche Unterschied zwischen kommerzieller und Open Source Software liegt nicht im jeweiligen Lizenzmodell oder dem Preis der Software, sondern im generellen Geschäftsmodell der Software. Diese Geschäftsmodelle müssen bei der Auswahl der passenden Lösung berücksichtigt werden, da nur durch die Durchleuchtung des Geschäftsmodells klar wird, wie sich dieses auf das Projekte auswirkt und welche Funktionalitäten und Services zu welchem Preis zur Verfügung stehen. Denn auch für die professionelle Nutzung von Open Source Produkten können Kosten anfallen! Um beispielsweise bestimmte Service Levels oder Support zu erhalten, sind Wartungsverträge genauso üblich, wie bei kommerzieller Software.
Im Umkehrschluss heißt dies jedoch auch, dass es prinzipiell keine “ideologischen” Argumente für oder gegen kommerzielle bzw. Open Source Software gibt, sondern immer die Anforderungen im Einzelfall entscheiden müssen, welche Lösung zu welchem Projekt passt.
Wer kommerzielle Software kauft, weil er denkt, dass damit das Projekt kein Mißerfolg werden kann, der denkt genauso falsch, wie derjenige, der Open Source Software einsetzt, weil er damit auf jeden Fall günstiger fährt.
17. Oktober 2006
Goldene Regel #17: Open Source Software ist nicht schlechter
Auch für den kommerziellen Einsatz eignet sich Open Source Software hervorragend. Nicht ohne Grund haben es – insbesondere im Web Content Management Umfeld – die Anbieter von kommerzieller Software immer schwerer, ihre Produkte an die Frau zu bringen. Im Open Source Umfeld finden sich besonders Produkte mit einer breiten potenziellen Kundenbasis, denn es entwickelt sich meist die Software richtig gut, die von möglichst vielen nachgefragt wird. Entsprechend bietet sich für Standardanforderungen meist eine interessante Alternative im Open Source Bereich.
Wichtig: Open Source Software ist nicht per se günstiger als kommerzielle Software. Erst bei einer tiefer gehenden Analyse kann festgestellt werden, ob ein Open Source Produkt die geforderten Funktionalitäten nicht nur genauso gut wie kommerzielle Produkte, sondern auch zu einem vergleichbaren oder günstigeren Preis bietet. Erst wenn man hier auch die Anpassungsaufwände hineinrechnet, kann eine seriöse Aussage getroffen werden.
Zusätzlich eignet sich Open Source Software für besonders innovative Unternehmen, die für ihre Anforderungen sowieso keine Lösung auf dem Markt finden. Hier kann Open Source eine gute Basis für die eigene Weiterentwicklung bieten. Aber Achtung: Meistens müssen auch die Weiterentwicklungen unter die gleiche Open Source Lizenz gestellt werden, unter der auch das Basisprodukt stand.
16. Oktober 2006
Vorschau ECM-Report 2/2006
Bald gibt es einen neuen CMMAG – ECM-Report. Die geplanten Themen:
- Digitaler Posteingang
- BPEL
- Goldene Regeln für DMS- und ECM-Projekte
- Roundtable “Konsolidierung in der ECM-Branche” mit mittleren DMS/ECM-Anbietern
Das Cover ist schon fertig:
Im November kostenlos als PDF-Ausgabe auf www.cmmag.de verfügbar.
28. September 2006
Goldene Regel #16: Werden Sie Fan der “neuen Einfachheit”!
Für IT-Architekten ist Enterprise Content Management eine Spielwiese, auf der Lösungen beliebiger Komplexitätsstufe umgesetzt werden können. Sämtliche Abläufe eines Unternehmens können kombiniert mit sämtlichen Informationen, Inhalten und Dokumenten weltweit individualisiert und beliebig miteinander verknüpft zur Verfügung gestellt werden.
Nur allein: Wer möchte mit so einer Lösung arbeiten? Die “Eierlegende Wollmilchsau” ist einfach zu kompliziert zu halten.
Denn so schön die Technik auch ist, am Ende steht der Benutzer, dem die Lösung bei der effektiven Bewältigung seines Arbeitsalltags helfen soll. Immer komplexer werdende Oberflächen, um immer mehr Funktionalität abzubilden, sind hier kein geeignetes Instrument.
Werden Sie deshalb Fan der “neuen Einfachheit” und machen Sie Ihre Benutzern zu Ihren Fans: Eine Aufgabe in jedem etwas komplexeren ECM-Projekt muss auch sein, sich mit den Arbeitsweisen der Benutzer auseinanderzusetzen und – wenn irgendwie möglich – vereinfachte und auf bestimmte Arbeitsprozesse zugeschnittene Oberflächen zu entwickeln.
So braucht z.B. in einem Projekt eine große Gruppe Sachbearbeiter in 99% der Fälle nur die Funktion zur Suche nach Dokumenten anhand einer Kundennummer und zum Durchblättern der Akte (vorwärts – zurück). Hier kann durch einen einfachen, spezialisierten Client eine enorme Einsparung erzielt werden. Gleichzeitig werden viele Vorurteile der Anwender abgebaut, weil man ihnen wirklich helfen will.
Beispiele hierfür gibt es zu genüge. Überall finden sich große Anwendergruppen, die nur einen Bruchteil der Funktionen brauchen und sich dafür durch umfassende Menüs hangeln müssen. Besondere Clients – Fatclients, wie auch Webclients – sind, bei maßvollem Einsatz, ein optimales Instrument, um das komplexe Thema ECM für den Anwender benutzbar zu machen.
27. September 2006
Goldene Regel #15: Softwareanbieter sollen Software anbieten
Die Realisierung von Projekten im ECM-Umfeld findet über qualifizierte und oft spezialisierte Partner der Softwareanbieter statt. Diese sind “vor Ort”, installieren die Software, programmieren Anpassungen, bieten softwarespezifische Beratung und sind meist auch der “lange Arm des Vertriebs”. Nur über diesen Weg ist es Softwareanbietern möglich, den Markt flächendeckend zu bedienen, ohne sehr stark in eine flächendeckende Infrastruktur investieren zu müssen. Zudem ist die Skalierung von Arbeitskraft hierdurch erheblich vereinfacht, da schnell neue Partner gewonnen und qualifiziert werden können bzw. diese sich auch anderweitig auslasten können, wenn einmal keine Projekte des Softwareanbieters anstehen.
Das Problem: Diese Partner realisieren durch die Serviceleistungen rund um die Produkte einen nennenswerten Umsatz. Je nach Projekt und Kunde entsprechen die Umsätze im Bereich “Services” den Lizenzkosten oder übersteigen sie. Besonders in großen Projekten fälle schnell eine zwei bis dreistellige Zahl von Personentagen an.
Hier entstehen Begehrlichkeiten und Anbieter kommen immer wieder in die Versuchung Kunden “direkt zu betreuen”. In sehr begrenztem Maße ist das sinnvoll – in einer Art “Competence-Center-Ansatz”. Oft ist es jedoch nur die Ausrede für den Anfang vom Ende. Wenn die Umsätze mit der Software – warum auch immer – schwächeln, werden Projekte beim Endkunden direkt durchgeführt. Oft geschieht dies recht dreist an den Partnern vorbei und im schlimmsten Fall werden Projekte aus der laufenden Betreuung von Partnern mit fadenscheinigen Argumenten abgezogen. Besonders Neukunden aber werden dann gerne direkt bedient und an die Partner nurnoch “Brotkrumen” verteilt.
Das Resultat aus einer verstärkten Beteiligung des Softwareanbieters ist die nachlassende Beteiligung der Partner, für die der Vertrieb und der Einsatz des Produktes ob der neuen und oft recht umfassenden Konkurrenz völlig uninteressant wird. Im Gegenzug kann der Softwareanbieter nurnoch wenig Arbeitskraft in die Weiterentwicklung des Produktes investieren.
Endgültig läuft eine solche Strategie auf die Einstellung des Geschäftsbetriebs des Softwareanbieters im Zeithorizont von hinaus – Beispiele gibt es zu genüge.
