20101112c Opitz Optimiertes IT Service Management durch Competence Center
|
|
|
»manage
it«
als
|
Optimiertes IT-Service-Management durch Competence Center Service durch Kompetenz Kostenoptimierungen und eine verbesserte Serviceorientierung stehen heute auf der Agenda nahezu jeder IT-Organisation, sowohl in Großunternehmen als auch im Mittelstand. Sollen gleichzeitig IT-Konzepte wie Service-orientierte Architekturen (SOA) oder Business Intelligence (BI) eingeführt werden, stoßen konventionell in Betrieb und Entwicklung strukturierte IT-Organisationen an ihre Grenzen. Der Querschnittscharakter dieser Konzepte sowie die notwendige, enge Verzahnung von IT und Fachbereichen lassen sich nur unzureichend abbilden, die angestrebten Optimierungspotenziale werden nicht realisiert. Ein erfolgreicher Lösungsansatz liegt in der Etablierung themenbezogener Competence Center. Sie gewährleisten ein effektives, flexibles, auf die speziellen Anforderungen von SOA beziehungsweise BI abgestimmtes IT-Service-Management unter Einbeziehung von Standardframeworks wie ITIL.
ontagmorgen: Herr Müller aus dem Marketing ruft verzweifelt das Helpdesk seines internen IT-Dienstleisters an. Die neuesten Absatzzahlen in den Wochenreports sind offenkundig falsch und in 2 Stunden will sein Chef den Bericht auf dem Schreibtisch haben. Das Helpdesk nimmt den Anruf freundlich entgegen. Der dortige Mitarbeiter leitet es an den Datenbankbetrieb weiter. Dieser schaut sich den Betriebszustand an und meldet »Alles okay, die Daten wurden über Nacht geladen. Die Datenbank zeigt grün.« Diese Antwort hilft Herrn Müller wenig. Er muss den ganzen Vormittag selbst herumtelefonieren und seinen Chef auf den nächsten Tag vertrösteten. Was war das Problem? Die IT funktionierte technisch korrekt, die angelieferten Daten aber waren fachlich nicht korrekt. Ein anderer Fachbereich hatte in der letzten Woche eine Umstellung in den Produktreferenzen vorgenommen, die für den Report von Herrn Müller verwendet werden. Die Änderung wurde aber nicht kommuniziert und war nicht auf Anhieb erkennbar. Herr Müller kann sich bei der IT allerdings nicht beschweren. Sein SLA wurde eingehalten, die Daten waren zum vereinbarten Zeitpunkt da. Nur, dass es die falschen Daten waren. Dieses Beispiel aus dem Umfeld von Business Intelligence (BI) ist eines von vielen, bei denen typische IT-Services zum Betrieb einer Infrastruktur nicht ausreichen, um die Anforderungen der Kunden zu erfüllen. Der folgende Artikel zeigt auf, wie diese Lücke insbesondere in den Bereichen BI und SOA (Service-orientierte Architekturen) mithilfe von Competence Centern geschlossen werden kann. Es geht nicht um Technologie, sondern um Konzepte Geht es nach den Buchstaben in der Abkürzung, haben BI und SOA zunächst nichts gemeinsam. Und auch inhaltlich finden sich auf den ersten Blick wenige Berührungspunkte, wenn man vielleicht von dem noch relativen jungen Feld des SOA-Reportings absieht, bei dem Reports als Web-Service angeboten werden. Eine Gemeinsamkeit gibt es dennoch: beide Begriffe beschreiben keine Technologie, sondern ein Konzept. BI erschöpft sich nicht in der Bereitstellung von Datenbanken und Applikationen. Ebenso wenig reicht für eine SOA die Installation eines ESB (Enterprise Service Bus) aus. BI und SOA erfordern ein hohes Maß an Kooperation und Koordination zwischen Fachbereichen und IT-Abteilungen oder IT-Teams [1] und müssen in einem Unternehmen ganzheitlich betrachtet werden. Wie gehen konventionell aufgestellte IT-Organisationen heute mit BI und SOA um? Ihrer Natur nach fokussieren sie sich auf die technischen Bestandteile und versuchen, sowohl den Entwicklung- als auch den Betriebsanteil in ihre etablierten Abteilungen zu integrieren. Dies führt oftmals dazu, dass die Fachbereiche den Sinn der rein technischen Vorhaben nicht erkennen und eine ablehnende Haltung einnehmen. Dies hat weitreichende Konsequenzen: · Projekte kommen über den Pilotcharakter nicht hinaus, · der im Unternehmen erforderliche Mentalitätswandel setzt nicht ein, · die Fachbereiche schaffen sich vermehrt IT-Inseln.
Im Endeffekt wird der versprochene Return on Invest nicht erzielt. Die IT-Abteilung trifft daran aber nur eine Teilschuld. Sie ist in dem Bestreben, ihre Leistungen zu industrialisieren und standardisierte Services für Infrastruktur und Software anzubieten, nicht alleine in der Lage, die alle Unternehmensbereiche durchdringenden Konzepte zu stemmen. Dazu hilft ein Blick auf die unterschiedlichen Ebenen eines IT-Serviceportfolios (Abbildung 1).
Angelehnt an die aus dem Cloud Computing geläufigen Begriffe unterscheidet man die drei Ebenen Infrastruktur-, Plattform- und Software-Services. BI und SOA jedoch benötigen noch eine vierte Ebene: Information-Services. Das Beispiel von Herrn Müller zeigt, dass er einen Service braucht, der ihm Informationen bereitstellt, in diesem Fall einen Report mit Absatzkennzahlen. Es geht ihm nicht nur um die Funktionalität des BI-Tools oder die pünktliche Auslieferung. Auch die Inhalte müssen korrekt und mit einer definierten Datenqualität bereitgestellt werden. Ähnliches findet sich auch bei einer SOA. Wird das Konzept vollständig umgesetzt, kann eine SOA den Fachbereichen komplexe Business-Services anbieten. Ein Beispiel: der Service »Produkt empfehlen« stellt einem Call-Center-Agenten Informationen zur Kundenberatung zur Verfügung. Dieser Service setzt sich aus den granularen Services »Ermittle Kaufhistorie«, »Lese Kundenstatus«, »Ermittle Cross-Selling Einkaufskorb« und »Priorisiere Produkte im Einkaufskorb nach Regeln« zusammen. Für die Betriebsführung bedeutet dies, dass nicht nur die SOA-Infrastruktur als Ganzes, sondern jeder einzelne Service mit seinen Abhängigkeiten überwacht werden muss [3]. Hierbei erwartet der Kunde, dass der Service sowohl technisch läuft, als auch eine zuvor definierte Qualität der Daten liefert. Informations- statt funktionsgetrieben Es braucht also eine ganz neue Qualität von Services, die im Rahmen einer SOA oder von BI angeboten werden müssen. Am Beispiel von BI soll dies detailliert diskutiert werden. Greifen wir dazu wieder auf den Fall von Herrn Müller zurück. Was für Services benötigt er, um sein Tagesgeschäft, das Reporting, zu erledigen?
· Seine Daten müssen aus einem Quellsystem, hier einem CRM, in das Data Warehouse geladen werden. Dort werden die Daten einer ersten, technischen Qualitätsprüfung unterworfen und ggf. über ein Regelwerk bereinigt (Data Cleansing). · Dann überführt ein überwachter Ladeprozess die Daten in einen Data Mart für Marketing. Diese Daten können mit weiteren Informationen, beispielsweise zur Aktualität der Referenzen angereichert werden. Zusätzlich sind abgeleitete, fachliche Qualitäts-Kennzahlen wie der Abdeckungsgrad von Produktgruppen denkbar, die in speziellen Qualitätsreports zur Verfügung gestellt werden. · Zu guter Letzt werden über ein BI-Tool die Daten aus dem Data Mart in einen HTML-Report überführt und zu einem vereinbarten Zeitpunkt mit aktualisierten Daten Herrn Müller zur Anzeige gebracht. · Zuvor erfolgt noch eine fachliche Datenkontrolle, die anhand der Qualitätsreports und festgelegter Kriterien überprüft, ob die in den Reports enthaltenen Kennzahlen wirklich aktuell und plausibel sind.
Abbildung 2 zeigt beispielhaft, wie diese Servicekategorien mit dazugehörigen Services in einer BI-Infrastruktur ausgeprägt sein können. Dies beginnt bei grundlegenden Basis-Services wie der Bereitstellung einer Datenbank (RDBMS) und endet bei komplexen Services wie einer fachlichen Datenkontrolle. Die zur Erbringung der Services erforderlichen Fähigkeiten wechseln dabei in gleicher Richtung von eher technisch zu vermehrt fachlich geprägt.
Die Services bauen aufeinander auf. Services aus der Kategorie »Data Mart« sind immer auf Services aus der Kategorie » DWH« angewiesen, die wiederum Services aus der Kategorie »Staging Area« abrufen. Der Servicenehmer sieht immer nur die für ihn wichtige oberste Ebene und kauft die darunter liegenden Services nach Bedarf mit ein. Für die Servicekategorie »Data Mart« soll das Serviceportfolio nochmals detaillierter betrachtet werden (siehe Abbildung 3). Der Data Mart ist in diesem Fall ein Oracle Datenbank-Schema, es wird der Infrastruktur-Services »RDMBS« verwendet. Damit überhaupt Daten in den Data Mart fließen, sind alle darunter befindlichen Infrastruktur-Komponenten über Services der Kategorie »DWH« eingebunden, sie werden hier nicht weiter aufgeschlüsselt. Auf Seiten der in Form von Dienstleistungen ausgeprägten Services wird in Standard- und Premium-Services unterschieden.
Über den einmaligen Service »Schnittstelle DWH« wird der erforderliche Datenfluss zu dem Data Mart hergestellt. Diese Dienstleistung besitzt zwar Projektcharakter, kann aber als Service angeboten werden, da sie in der technischen Umsetzung her sehr standardisierbar ist. Den Hauptservice bildet der fortlaufend zu betreibende Ladeprozess mit den schon erwähnten Qualitätskennzahlen. Der 2nd-Level-Support rundet das Serviceportfolio ab. Da es sich bei den Anwendern, die direkt auf einen Data Mart zugreifen, meist um Poweruser handelt, kann der 1st-Level entfallen. Immer wichtiger wird bei der unternehmensweiten Informationsbereitstellung der Datenschutz. Für Reportings werden immer häufiger Datenschutzkonzepte eingefordert, die initial erstellt und dann immer auf dem aktuellen Stand gehalten werden müssen. Auch dies kann als Service angeboten werden. Darüber hinaus ist eine Vielzahl von Premium-Services denkbar. Dies fängt bei der im Beispiel von Herrn Müller genannten fachlichen Datenkontrolle an, die über die bloße, automatisierte Erzeugung von Qualitätsangaben hinausgeht. Des Weiteren kann es erforderlich sein, dass dem Kunden Detaildaten bereitgestellt werden, damit er selber in eine tiefergehende Fehleranalyse einsteigen kann. Ebenso muss geklärt sein, was passiert, wenn falsche Daten in den Data Mart geladen oder Daten verspätet aus den Quellen angeliefert wurden. Dann ist ein Rollback beziehungsweise ein Nachladen erforderlich, ebenfalls Kandidaten für Services. Eine permanente Datenbereinigung kann vereinbart werden, um etwa Vertragsstatus für das Reporting zu konsolidieren. Die gezielte Unterstützung bei der Datenanalyse oder die Ableitung neuer Kennzahlen bei Erweiterung der Quelldaten runden das Service-Portfolio ab. Competence oder Competency? Die Beispiele aus dem BI-Bereich zeigen deutlich, dass die aufgeführten Services teilweise wenig gemein haben mit typischen IT-Services wie »Bereitstellung Office-Paket«, »Fileserver« oder »Druck-Service«. Wie unterscheiden sie sich von ihnen?
Hieraus lässt sich schließen, dass weder eine IT-Organisation, die nach Geschäftsdomänen (Produktion, Marketing, …) oder nach Anwendungen (CRM, Billing, Technik, ...) ausgerichtet ist, noch ein einzelner Fachbereich für sich alleine genommen der richtige Partner sind, um diese Services anzubieten. Ein erfolgversprechender Lösungsansatz liegt hier in der Etablierung von Competence Centern. Der Begriff »Competence Center« – im Folgenden der Einfachheit halber mit CC abgekürzt, – ruft bei vielen die Assoziation mit einem großen Gebäude hervor, in dem viele Menschen arbeiten. Deshalb wirkt er, insbesondere auf CFOs, eher abschreckend als problemlösend. Das Wesen eines CC ist dabei, ganz im Gegenteil, äußert flexibel und dynamisch. Ein CC kann im kleinsten Anwendungsfall aus 2-3 Personen bestehen, die im Unternehmen einen bestimmten Wissensbereich bündeln und diesen in verschiedenste Geschäftsprozesse geregelt einfließen lassen. Auf der anderen Seite der Skala umfasst es tatsächlich 100 oder sogar mehr Mitarbeiter, die Aufgaben von der Strategieentwicklung bis zum Support übernehmen. Dazwischen ist alles möglich: virtuelle Teams, Stabsstellen, Spezial-Abteilungen oder Querschnittsfunktionen in einer Matrix-Organisation. Eines aber haben alle CCs gemeinsam: Sie unterscheiden nicht zwischen IT und Fachbereich, sondern bilden mit ihren Zielen, ihrem Know-how und ihren Aufgaben eine Brücke im Sinne des Business-IT-Alignment. Dadurch können sie fachliches Know-how, welches zur Serviceerbringung erforderlich ist, besser integrieren als es bei einer reinen IT-Abteilung der Fall wäre. Diese Eigenschaft prädestiniert CCs dazu, fachlich orientierte, informationsgetriebene IT-Services anzubieten (siehe Abbildung 1). CC und IT arbeiten dabei nicht gegen- sondern miteinander. Das CC bietet seinen Kunden die Services über entsprechende SLAs an und vereinbart mit dem internen IT-Dienstleister OLAs, beispielsweise über die oben genannten Basis-Services wie Middleware oder RDBMS (Abbildung 4).
Derzeit sind vor allem BICC in der Diskussion [2] und auch im Umfeld von SOA stehen seit einigen Jahren CC auf der Agenda von Unternehmen, teilweise unter dem Begriff »Integration Competence Center«, kurz ICC. Weitere Beispiele lassen sind um Umfeld von SAP finden und auch der Bereich Enterprise Architecture (EA), welcher ebenfalls Informationen unternehmensweit zusammenträgt und wieder »anbietet«, ist oftmals als CC ausgeprägt. ITIL als gemeinsamer Rahmen Soll ein CC ein komplettes Service-Portfolio wie das oben für eine BI-Infrastruktur skizzierte anbieten, reichen 2-3 Experten nicht aus. Es muss eine Vielzahl von Funktionsbereichen wie Entwicklung, Betrieb und Support abdecken und seine Rolle geht über einer Beratungs- oder Koordinierungsstelle hinaus. Es tritt als Volldienstleister auf. In diesem Fall ist es naheliegend, einen Blick auf die aus der IT bekannte Best-Practice zu werfen. Auch wenn sich die Services eines CC teilweise erheblich von typischen IT-Services unterscheiden, kann das Portfolio eines CC mithilfe des in ITIL V3 beschriebenen Lebenszyklus Strategy, Design, Transition, Operation und Improvement gemanagt werden [ITIL V2 ist genauso anwendbar]. Dabei sind allerdings einige Besonderheiten zu beachten: Die ITIL-Prozesse müssen zunächst den Funktionsbereichen des CC zugeordnet und dann gegebenenfalls adaptiert werden. In einem BICC lassen sich Funktionen für Support, Betrieb und Entwicklung sehr gut durch ITIL-Prozesse unterstützen. Im Bereich Architektur bspw. bestehen hingegen Lücken. Zudem müssen für die ITIL-Prozesse die Kategorien Ziel und Zweck, Bereich, geschäftlicher Nutzen und Grundkonzepte für BI konkretisiert werden [2]. Für eine SOA gilt Ähnliches, auch hier ist eine SOA-spezifische Anpassung der ITIL-Prozess erforderlich. So sollte., analog zu BI, in dem Abschnitt Service Strategy ein Architekturmanagement hinzugefügt werden. Im Abschnitt Service Design muss das SOA-spezifische Entwicklungsmodell berücksichtigt werden [1]. Resümee. Competence (oder Competency) Center bilden eine hervorragende Möglichkeit, die Informationsbereitstellung in einem Unternehmen – sei es über BI, eine SOA oder EA – zu vereinheitlichen und über Services professionell abzuwickeln. Sie vereinen dabei die Vorteile standardisierter Services mit der Flexibilität agiler Organisationseinheiten. Es gibt aber auch offene Fragen: Wie misst man die Qualität eines Informations-Services? Typische Kennzahlen im IT-Bereich wie Lösungsquoten und Durchlaufzeiten von Tickets beziehungsweise die Verfügbarkeit von IT-Systemen reichen nicht aus. Und wie sieht es mit der Kostenseite aus? Erfahrungen aus Kundenprojekten haben gezeigt, dass sich Prozesskosten durch die schlankere Organisationsstruktur eines CC reduzieren lassen und damit Services günstiger angeboten werden können. Eines ist aber sicher. Mit einem BICC in seinem Unternehmen kann Herr Müller am nächsten Freitag beruhigt ins Wochenende fahren, denn er weiß seinen Report ab jetzt in guten Händen. Thore Kleinschmidt, Martin Weber __________________________________________ Thore Kleinschmidt ist Projektmanager bei OPITZ CONSULTING Bad Homburg GmbH und betreut unter anderem Projekte zur Daten-, Prozess- und Organisationsoptimierung. Martin Weber entwickelt seit 1996 Kennzahlensysteme und Reports in unterschiedlichen Branchen. Er ist BI-Berater bei OPITZ CONSULTING.
__________________________________________ Literatur [1] Beinhauer, Wolfgang; Herr, Michael; Schmidt, Achim (Hrsg.) (2008): SOA für agile Unternehmen. Symposion Publishing [2] Gansor, Tom; Totok, Andreas; Stock, Steffen (2010): Von der Strategie zum Business Intelligence Competency Center (BICC). München, Wien [3] Zeithammer, Uwe; Jung, Andreas; Kriegel, Dr. Ulrich (2009): Service-orientierte Architekturen – Leitfaden und Nachschlagewerk, Umsetzung und Betrieb. www.soa-know-how.de
|
