Open-Source-Lösungen in der Praxis

Transkript

1 Dieser Artikel wurde am in der Online-Ausgabe der COMPUTERWOCHE veröffentlicht: ITSM-Projekte mit OTRS realisieren Open-Source-Lösungen in der Praxis Von Rico Barth* Vorhaben im Bereich IT-Service-Management (ITSM) sind in der Regel zeit- und kostenaufwendig. Open-Source-Lösungen wie OTRS und das Einhalten von ein paar Regeln helfen dabei, Geldbeutel und Nervenkostüm zu schonen. Die fünf Bände der IT Infrastructure Library (ITIL) mögen ein dröges Werk sein, das sich nicht viele Zeitgenossen mit Vergnügen vornehmen. Gleichwohl trifft die Umsetzung dieser Empfehlungen für eine effektive IT in Form des IT Service Managements (ITSM) auf großes Interesse. Zunächst begonnen von großen Unternehmen verfolgen heute mittelgroße und sogar kleine Organisationen entsprechende Projekte. Egal wie weitreichend, anspruchsvoll und finanziell aufwändig diese Vorhaben sind, lassen sich in der Praxis immer wieder die gleichen Erfahrungen sammeln und Probleme erkennen. Zunächst unterscheiden sie sich nicht elementar von anderen IT-Projekten. Dem Kick-off folgen die Phasen der Analyse, der Tool-Auswahl, der Umsetzung, der Einführung und des Betriebs. In dieser Reihenfolge sollen hier Grundregeln für die Vorgehensweise und die Vermeidung von Schwierigkeiten vorgestellt werden. Hier stehen Services für innerbetriebliche IT-Prozesse im Vordergrund. Die Erfahrungen lassen sich aber genau so übertragen auf Situationen, in denen es um Services für außerbetriebliche Kunden geht. Die Phase der Analyse Der erste Schritt besteht darin, die angestrebten Serviceprozesse festzulegen und gegen die Realität zu spiegeln. In vielen Fällen bestehen nur recht vage Vorstellungen davon, was mit ITSM umgesetzt werden sollte. Basierend auf dem, was die IT bisher gemacht hat, besteht jedoch häufig der Wunsch es irgendwie besser zu machen. Leider sind diese gelebten Prozesse in zahlreichen Fällen überhaupt nicht oder nur rudimentär dokumentiert. Darum sollten anfangs keine komplexen Ablaufbeschreibungen erstellt werden, meist reicht eine Stichpunktliste, maximal ein einfaches Flussdiagramm aus, um die Sachlage zu beschreiben.. Ferner gilt es, die fachlichen und die technischen Projektteilnehmer festzulegen. Das sind zum einen die Projektverantwortlichen, die dafür den Kopf hinhalten müssen, und zum anderen jene, denen die Umsetzung und der spätere Betrieb des Systems obliegt. Diese Personen sollten im Verlauf des Projekts nicht wechseln. Denn die Folge sind nicht nur Mehraufwendungen für die Einarbeitung. Viel schlimmer ist, dass dadurch leicht das Projektziel fließend wird. Auch wenn man derlei gern als dynamisch ummäntelt, gefährdet es jedes ITSM-Projekt, wenn das Pflichtenheft durch ständig neue Anforderungen ad absurdum geführt wird. Schließlich ist ein Zeit- und ein Anforderungsplan vonnöten. Ersterer gerät leicht zu ambitioniert. Der zweite muss neben den fachlich-technischen Anforderungen alle im Projekt Involvierten benennen. Und dazu gehören nicht nur die IT, sondern auch die Fachabteilungen und externe Firmen, zum Beispiel Lieferanten und Software-Maintainer, deren Produkte in das ITSM-Projekt tangieren. Diese Anforderungslisten sollten nicht zu komplex ausfallen, um bewertbare Kriterien zu erhalten..

2 Vor allem ist es wichtig, die Anforderungen durch Priorisierung und Reduktion überschaubar zu halten. Das ITSM-Projekt darf sich nicht über Jahre hinziehen, sondern muss baldige Erfolge anstreben, auf denen sich aufbauen lässt. ITSM darf also nicht die eierlegende Wollmilchsau zum Ziel haben, denn völlig verkehrt ist die Einstellung Viel hilft viel. Das Gegenteil ist der Fall. Erst auf der Basis dieser Vorüberlegungen geht es an eine Projektbewertung, ein Pflichtenheft, den Business-Plan, ein technisches und ein Support-Konzept. Die Tool-Auswahl Häufig ist der Fehler zu beobachten, dass Anwender sich schon vor der grundsätzlichen Überlegungen mit der Frage befassen, welche Aufgaben dieses oder jenes bereits vorhandene Tool bewältigen könnte. Dabei verliert sich leicht der Blick aufs Ganze. Denn es gibt weit mehr Kriterien als das vorhandene Know-how. Es bestehen prozessuale, fachlich-funktionale, technische, integrative und finanzielle Anforderungen. Prozessuale Anforderungen ergeben sich aus den im Vorfeld definierten umzusetzenden Prozessen. Einfache Abläufe wie Störungsmeldung und -bearbeitung werden meist ergänzt durch Bedarfsanforderungen und ihre Erfüllung. Sie führen zu Änderungen in der Infrastruktur und erweitern das System um den Aspekt des Change Managements. Das unterstreicht die Wichtigkeit der Maxime, Prozesse einfach zu halten und sich auf das Wesentliche zu konzentrieren. Die fachlich-funktionalen Anforderungen beziehen sich nicht nur auf die Notwendigkeit, das ein oder andere Serversystem zu kennen. Im Zentrum steht vielmehr die Datenbasis, auf der die Prozesse aufbauen, nämlich die Configuration Management Database (CMDB). In ihr müssen (ohne Ausnahme!) unter anderem sämtliche Hardware-, Netzwerk- und Softwarekomponenten und ihre Beziehungen zu einander festgehalten sein, um diese effektiv mit dem zukünftigen ITSM-System zu unterstützen. Dabei sollte nicht vergessen werden, dass man ja hoffentlich klein und bspw. mit einem Auszug aus einem viel detailreicheren Inventarisierungssystem angefangen hat. Dem System steht also ein Ausbau bevor, weshalb die CMDB gut skalierbar sein sollte. Das wird jede CMDB aber nur, wenn sie gut strukturiert ist, um performant zu arbeiten. Aus den genannten Aspekten leiten sich bereits technische Anforderungen ab. Diese werden aber durch einen anderen Aspekt wesentlich mitbestimmt, nämlich durch das vorhandene Know-how. Wenn es nur PostgreSQL-Expertise im Hause gibt, sollte man bspw. das ITSM- System und die CMDB nicht auf MySQL aufsetzen. Eine weitere Einschränkung kann die Tool- Auswahl dadurch erfahren, dass grundsätzlich nur eine bestimmte Betriebsplattform, beispielsweise Windows, IT-strategisch zugelassen ist. Ein ITSM-System bezieht direkt oder über die CMDB Informationen von anderen Systemen, weshalb sich zusätzliche integrative Anforderungen stellen. Welcher Verzeichnisdienst ist zu adressieren? Müssen Daten aus CRM- oder ERP-Anwendungen einfließen. Gibt es ein Clientoder Inventory-Managament? Ganz sicher wird man das System-Management oder die vorhandenen Monitoring-Lösungen einbeziehen. Also ist auch bei der Tool-Entscheidung Priorisierung notwendig: Was ist das Wichtigste? Die Suche nach einer Antwort kann leicht in enervierenden Debatten enden. Denn natürlich wird jede Fachabteilung andere Anforderungen haben und genau ihre für die wichtigsten halten. Alle Wünsche sollte man gar nicht erst zu erfüllen versuchen. Der Kompromiss ist der kleinste gemeinsame Nenner, eine Balance zwischen den involvierten Fachabteilungen und dem Anforderungskatalog. Nicht zu verachten sind die finanziellen Anforderungen. Der Budgetrahmen bedarf unbedingt einer Zustimmung durch die IT- oder die Geschäftsleitung. Diese muss ganz klar hinter dem Projekt stehen und auch dafür werben. Der finanzielle Rahmen wiederum schränkt die Freiheit der Tool-Auswahl ein. Und weil die Mittel generell beschränkt sind, tendieren IT-Organisationen immer mehr zu Open-Source-Lösungen, auch für ITSM-Tools.

3 Die eigentlich für die Softwareentwicklung geschriebenen Open-Source-Produkte Bugzilla und Mantis lassen sich zur Not auch für Helpdesk-Aufgaben vergewaltigen. Aber ihre Möglichkeiten sind für diesen Zweck sehr beschränkt. Auch bei Best Practical RT deutet sich eine Stagnation der Ausrichtung zu ITSM und ITIL an. Interessant wird es erst mit dem IT Operational Portal (ITOP) von der französischen Firma Combodo, die ehemalige HP-Mitarbeiter gegründet haben. Das Produkt orientiert sich klar in Richtung ITIL und IT Service Management. Allerdings empfiehlt sich der Leistungsumfang eher für kleine bis mittelgroße Anwenderunternehmen. Der Platzhirsch ist mit weltweit rund Installationen eindeutig OTRS vom gleichnamigen Hersteller aus Bad Homburg, insbesondere mit dem Erweiterungsmodul OTRS::ITSM. Es ist das funktional mächtigste System, gut dokumentiert und bietet unglaublich viele Konfigurations- und Erweiterungsmöglichkeiten. Diese Lösung skaliert ausgesprochen gut bis in massive Anforderungen und stellt Tickets, also Vorgänge und Prozesse, in den Mittelpunkt und fokussiert nicht auf einzelne Konfigurationsobjekte, wie das anderen IT Management-Systemen eigen ist. Desweiteren gibt es eine Menge Module für die unterschiedlichsten funktionalen Erweiterungen, von denen sich viele aus der Anwender-Community kostenfrei im OTRS Package Archive (OPAR) finden. Last not least, gibt es Schnittstellen zur Notifikation per Web, Mail, Fax und mobilen Kommunikations-Devices. Die Phase der Umsetzung Der Charme von Open-Source-Produkten besteht auch darin, dass man sie ohne Kosten herunterladen, installieren und ausprobieren kann. Aus diesem Grund und aufgrund seiner Marktpräsenz beschränken wir uns bei den weiteren Betrachtungen auf OTRS. OTRS ist zügig installiert, und Anwendern dürfte es leicht fallen, die ersten Queues, quasi Warteschlangen für Tickets, einzurichten. So lassen sich erste Erfahrungen mit ITSM in der Praxis sammeln. ein funktionales System wird daraus allerdings nicht. Schon allein, weil kaum ein Unternehmen unausgelastete Mitarbeiter in der IT hat, wird ein ITSM-Projekt in der Regel mit einem spezialisierten Dienstleister realisiert. Solche Dienstleister werden von der Beratung im Vorfeld bis zum späteren Ausbau eines ITSM- Systems an allen Fronten in Anspruch genommen. Einige Aufgaben haben sich dabei als besonders aufwändig entpuppt. An erster Stelle wird ihm nach der Ausprägung des Anfrage Managements die Integration weiterer Prozesse obliegen. Dabei geht es um das Event-, das Konfigurations- und das Change- oder Release-Management. Im Falle OTRS werden Event-Meldungen aus Nagios oder dem Fork Icinga automatisch eingebunden, aber auch andere, proprietäre Monitoring-Tools wie HP OpenView sind möglich. Im Konfigurations-Management lassen sich Erweiterungen wie die automatische Software- Verteilung opsi von der Mainzer uib, Tools von Igel für Thin Clients oder die CMDB i-doit als Alternative oder Ergänzung der OTRS-eigenen CMDB integrieren. Hinzu könnten Bugzilla oder Jira für das Change- und Release-Management kommen. Oder ein MediaWiki und andere Erweiterungen für den Self-Service. Die weitaus größte Projektherausforderung ist die Qualität der Datenbasis, die in die CMDB einfließen soll. In den meisten Fällen sind bei den Inventardaten die Konfigurationsobjekte in verschiedenen Datenbanken, Tabellen oder Listen erfasst, Informationen über die Beziehungen zwischen den Objekten fehlen. Die Einbindung, Strukturierung und Homogenisierung der Konfigurationsdaten verlangt meistens sehr viel Zeit. Nicht viel besser ist es um die Kundendaten bestellt. In der Regel sind alle Informationen über die Mitarbeiter in einem Verzeichnisdienst erfasst, von wo sie sich leicht integrieren lassen. Die Praxis hält allerdings regelmäßig Überraschungen bereit. Bei der Suche nach dem Grund von Fehlermeldungen werden dann Dubletten entdeckt oder das Fehlen von Attributen am Datensatz. Die -Adresse der Endanwender beispielsweise ist bei OTRS ein Pflichtfeld!

4 Eine nicht weniger wichtige Aufgabe ist die Filterung der in das ITSM-System einfließenden Informationen. Ohnehin liefern schon die Basissysteme eine erschlagende Menge an Daten. Der weit überwiegende Teil davon ist für die Organisation von IT-Prozessen völlig unerheblich. Der User-Support muss möglichst schnell Entscheidungen treffen, die dem Endanwender helfen. Tausende Detaildaten verschleiern ein Problem nur, der Helpdesk braucht die wichtigsten Informationen auf einen Blick. Wenn die nicht ausreichen, um den Anfragen auf den Grund zu gehen, kann er sich vertiefende Daten aus den Subsystemen holen. Auf diese Selektion, die Bestimmung des wichtigsten Inputs für den Großteil der Incident-Meldungen sollte großen Wert gelegt werden. Sie wird bei jedem Unternehmen etwas anders ausfallen. Selbstverständlich wollen alle Verantwortlichen Reports. Dabei sind sie als Tätigkeitsnachweis (Wie viele Tickets pro Monat?) nicht wirklich hilfreich. Sinnvoller sind Reports, wenn sie sich an konkreten Indikatoren ableiten lassen und sich mit ihnen beispielsweise Incidents analysieren lassen, um ihnen künftig vorzubeugen. So kann eine Häufung von Router-Ausfällen anzeigen, dass ein Gerätetyp für bestimmte Umweltbedingungen wie Hitze und Staub ungeeignet ist. Oder Auslastungsdaten von Druckern können Hinweise darauf geben, ob Kauf oder Leasing der Geräte wirtschaftlicher sind. Es ist zu hoffen, dass diese Basiseinrichtung eines ITSM-Systems dokumentiert worden ist. Tatsächlich geschieht das aber aufgrund der normalerweise schon hohen Belastung des IT- Personals oft nur sehr lückenhaft. Unabdingbar aber ist, wenigstens die Konfigurationsänderungen gegenüber dem Standard-OTRS festzuhalten. Die Phase der ITSM-Einführung Hier sind eigentlich nur zwei Aspekte wichtig: Erstens sollten die IT-Mitarbeiter gut geschult in die Produktivphase des neuen ITSM-Systems mit ggf. neuen Prozessen starten und nicht learning by doing unterzogen sein. Die Endanwender erkennen intuitiv, wenn mit den neuen Systemen nicht wirklich kompetente IT-Mitarbeiter umgehen. Das Resultat ist eine Ablehnung dieser Neuerung, die das Projekt zu einer Investitionsruine machen wird. Diese Endanwender sind der eigentliche Knackpunkt. Sie sind bestimmte Verfahren bei IT- Problemen gewohnt, zum Beispiel Papierformulare, auf denen sie ihr Anliegen festhalten. Diese Formulare sollte man möglichst genau in elektronische Vorlagen umsetzen. Die Anwender sollen ihre gewohnte Umgebung wiederfinden, dann arbeiten sie auch im produktiven Betrieb mit den neuen Mitteln und einer der wichtigen Quick-Wins ist erreicht. Gleichwohl sollte den Endanwendern erklärt werden, warum sie künftig etwas anders machen müssen, als sie es gewohnt sind. Wichtig ist, dass der Support künftig nur noch über eine zentrale Telefonnummer und Mailadresse zu erreichen ist. Das wird die Kunden nicht davon abhalten, ihnen bekannte Supporter anzurufen oder persönlich aufzusuchen. Die IT-Mitarbeiter werden Geduld brauchen, ihnen wieder und wieder zu erklären, dass sie auch nur ein Ticket öffnen werden, was die Kunden längst auch selbst hätten machen können. Allerdings sei vor der Illusion gewarnt, durch die Tickets seien alle Firmenangehörige gleich. Die Sekretärin vom Chef wird auch in Zukunft gleicher sein. Zu diesem Zweck besitzt man Klassifizierungsmerkmale wie Tickettypen, Services und SLAs, so das Tickets a priori zu priorisieren sind. Die Betriebsphase Diese Einführungsprobleme ziehen sich weit in die eigentliche Betriebsphase hin. In ihr aber gibt es nun die Früchte klugen Vorgehens zu ernten. Aus der Praxis dutzender Projekte lässt sich feststellen, dass ITSM selbst auf der unteren Ebene des Helpdesk ein schier nie endendes Projekt ist. Und das ist durchaus im Sinne der ITIL-Vordenker, nach denen sich die IT dynamisch an die sich wandelnden Anforderungen von Unternehmen und Verwaltungen anzupassen hat. Das manifestiert sich vor allem darin, dass regelmäßig schon bald nach der Produkteinführung neue Wünsche hinsichtlich Funktionalität und Prozesskonfiguration auftauchen.

5 Erstaunlicherweise haben diese meistens herzlich wenig mit den in den Vorbereitungsphase vorgebrachten Wunschanforderungen zu tun. Dies unterstreicht, wie wichtig es ist, die anfängliche Anforderungsliste möglichst klein zu halten und zu priorisieren. Ganz sicher aber wird sehr bald in der IT die Idee aufkommen, man könne die Arbeitslast durch Customer Self Service weiter reduzieren. An dieses Thema ist mit Vorsicht und Planung heranzugehen. Eine Art Jetzt helfe ich mir selbst richtet in der IT eher Schaden an, jedenfalls wenn es um die Behebung von Funktionsstörungen geht. Unproblematischer ist sie zwecks der Bereitstellung von Applikationen oder Zugang zu Dateiverzeichnissen, oder ähnlichen möglich. Dafür bedarf es aber zum Teil neuer innerbetrieblicher Abläufe und ihrer elektronischen Nachbildung. Willkommen zum nächsten Projekt auf dem ITSM-Weg. *Rico Barth ist Mitbegründer und Geschäftsführer der CAPE IT GmbH in Chemnitz. Das Unternehmen ist ein wichtiger Anbieter von Open Source Software und hat sich im deutschsprachigen Raum als führender Dienstleister für die Einführung von IT Service Management mit OTRS positioniert. Das Unternehmen entwickelt u.a. die OTRS-basierte Integrationsplattform KIX4OTRS. Stolpersteine Vage Vorstellungen der angestrebten Serviceprozesse Umfassende Wünsche der Fachabteilungen Überbordende Anforderungslisten Komplexe Ablaufbeschreibungen Wechselnde fachliche und technischen Projektteilnehmer Fließende Ziele Mangelnde Qualität der Datenbasis Schlecht gepflegte Kundendaten Erfolgsfaktoren Reduktion und Priorisierung der Anforderungen Prozesse einfach halten und auf das Wichtigste beschränken Kontinuierliche personelle Verantwortlichkeiten Quick-Wins anstreben Prozessuale, fachlich-funktionale, technische, integrative, finanzielle und zeitliche Anforderungen bedenken CMDB für Skalierbarkeit und Performance gut strukturieren Auf Vollständigkeit der Datenbasis achten Reduktion der Informationen in der CMDB Nur sinnvolle Reports vorsehen Zumindest Konfigurationsänderungen gut dokumentieren Nah an Anwendergewohnheiten (gelebte Prozesse) bleiben Eine einzige zentrale Telefonnummer und Mailadresse für den Helpdesk IT-Mitarbeiter schulen Umfassend mit Endanwendern kommunizieren Spätere Erweiterungsmöglichkeiten vorsehen Das Unternehmen: Die c.a.p.e. IT GmbH hat sich auf die Optimierung der Geschäftsprozesse im Service spezialisiert. Das Chemnitzer Unternehmen ist im deutschsprachigen Raum wichtigster Dienstleister und Anbieter von OTRS-basierten Service-Management-Produkten sowie Integrationsmodulen und Ihr Lösungspartner für OTRS-Projekte. Die Mitarbeiter haben teilweise über 10 Jahre Projekterfahrung im IT Service Management. Die c.a.p.e. IT entwickelt das OTRS-basierte Service-Modul KIX4OTRS, die Service Management Komplettlösung KIXbox und ist auf OTRS-Integrationsmodule z.b. zur Anbindung von Inventarisierungslösungen, Wissensdatenbanken und Telefonanlagen spezialisiert. Das Unternehmen ist u.a. Partner von IBM, Univention, uib, Zarafa, tarent sowie OMQ.