Hallo,
ich soll für unsere IT ein Governance Modell erstellen. Wer kann mir sagen was das ist und was ich da machen muss, um ein Governance Modell aufzubauen?
Im Kern geht es um die Zusammenarbeit mit einem Supplierer in der IT.
Danke und Gruß
AXL
Hallo,
das ist zumindest mal so rein gar nichts für jemanden, der nicht mal weiß, was das überhaupt ist 
Nein, ganz ehrlich: Das Governance Modell ist ein ganz entscheidendes Instrument für die Zusammenarbeit mit dem Dienstleister, und hat insoweit hohe rechtliche als auch wirtschaftliche Relevanz. D.h. das sollte jemand schreiben, der weiß, wo die Fallstricke hierbei liegen. Sonst kann man das auch gleich sein lassen.
Zudem muss sich IT-Governance auch in die Governance des Unternehmens einfügen. D.h. eine isolierte IT-Governance ist maximal der halbe Spaß, und macht nur dort Sinn, wo die IT hier eine Vorreiter-Rolle spielt. Zu dumm, dass es dabei auch oft bleibt.
Wenn Du da einsteigen willst, solltest Du Dich mal etwas intensiver mit ITIL beschäftigen, wobei ich befürchte, dass Dir das auch noch nicht viel sagen wird, und in Eurem Unternehmen vermutlich auch noch keine große Rolle spielen wird.
Aus ITIL-Sicht ergibt sich ein Set an Management-Prozessen, auf die sich die Arbeit der IT stützt. Und innerhalb dieser Prozesse gibt es dann Rollen, die in bestimmten Zusammensetzungen zu bestimmten Themen miteinander sprechen müssen. Im Rahmen des Governance-Modells werden diese Rollen und ihre Aufgaben sowie die Gremien beschrieben, in welcher Häufigkeit sich wer zu welchen Themen trifft, sowie welche Entscheidungskompetenzen und Eskalationsmöglichkeiten bestehen. Dazu braucht es dann ein Governance-Handbuch, in dem konkrete Verfahrensweisen zu beschreiben sind.
Um das ganze mal an einem Beispiel etwas deutlicher zu machen: Es gibt da z.B. einen Prozess für Vertragsänderungen, in dem die Vertragsmanager von Kunde und Auftraggeber eine entscheidende Rolle spielen. Daher treffen diese sich (mit anderen) regelmäßig in einem Vertragsänderungsmeeting. Dieses berät aber natürlich nicht "aus der Luft heraus, sondern es gibt zu beschreibende Eingangskanäle wer unter welchen Voraussetzungen und in welcher Form diesem Gremium Vertragsänderungsanträge stellen darf. Dann ist zu beschreiben, was das Gremium in eigener Gottherrlichkeit entscheiden darf, was es ggf. weiteren Beteiligten/Gremien vorlegen muss, wie ein beschlossener Change zu dokumentieren, umzusetzen und zu kontrollieren ist, …
Um Dir mal einen Eindruck vom Umfang der Sache zu machen, ein reales Beispiel, welche Gremien beispielsweise (was Du konkret brauchst, steht auf einem anderen Blatt) existieren können: Lenkungskreis, Steuerkreis, Service Delivery Board, Architektur Board, Innovation Board, Meeting langfristige Planung, Service Level Review Meeting, Post Katastrophen Meeting, Finanz Meeting, Change Advisory Board, Capacity Planning Meeting, Problem Management Meeting, Incident Management Meeting.
Ich denke, ich habe Dich nicht unnötig geschockt. Das ist wirklich nichts für jemanden, der nicht einmal weiß, was der Begriff bedeutet. Viele Unternehmen holen sich daher für dieses wichtige Thema externe Berater hinzu, die gerne mal einen Tausender und mehr als Tagessatz verschlingen.
Gruß vom Wiz, der die Dinger normalerweise auch nicht selber schreiben, sondern nur korrigieren, anpassen und verhandeln muss
Hallo Wiz,
zunächst ein großes Dankeschön für Deine ausführliche und informative Antwort. Schon jetzt hast Du mir weitergeholfen
Ist das wirklich so, dass das im Lastenheft/Ausschreibungsunterlage formulierte Governance Modell rechtlich so bindend ist? Ich dachte bisher immer, dass letztendlich der Vertag mit seinen Inhalten verbindlich ist und das GM (Governance Modell) im Lastenheft die Vorstellung des Auftraggebers darstellt. Meine Vorstellung war also bisher, dass im Lastenheft die Vorstellung des Auftraggebers steht (quasi Verhandlungsgrundlage) und im Rahmen der Bieterkreise ein GM beiderseitig committet wird. Dies steht dann im Vertrag.
ITIL ist mir durchaus bekannt und auch bei uns ein Begriff. Allerdings ist unser „ITIL-Reifegrad“ doch sehr weit unten. Wir sind gerade dabei die Prozesse Incident Management, Change Management, Asset Management einzuführen bzw. unsere bisherige Arbeit dabei auszurichten.
Von daher haben wir und sind gerade dabei die für uns relevanten Rollen zu definieren.
Ich habe mir jetzt zum Thema GM folgendes vorgestellt:
1. Wir definieren eine Verantwortlichkeitsmatrix. Auf der seinen Seite stehen die Services (z. B. Unix-Server aber auch Change Management) und auf der anderen Seite die ITIL-Rollen bzw. die Rollen durch unsere Organisationsstruktur (Leiter usw.). Die Matrix fülle ich dann entsprechend (wer ist verantwortlich für die Durchführung, für den Prozess, wer muss informiert werden usw.
2. Dann möchten wir von unten (operativ) bis nach oben (strategisch) alle Kommunikationsebenen festhalten und beschreiben. Wer setzt sich zu welchem Thema an einen Tisch und wie oft passiert das.
3. Zuletzt beschreiben wir dann die Schnittstellen zu anderen Abteilungen (themenbezogen)
Was hältst Du aus Deiner Erfahrung davon? Ist das der richtige Weg und was würde da noch fehlen?
Gibt es eigentlich auch so was wie ein Betriebszeiten Modell?
Ach ja, das mit den externen Beratern … Du kennst meinen Chef nicht
AXL
Hallo noch mal,
zunächst ein großes Dankeschön für Deine ausführliche und
informative Antwort. Schon jetzt hast Du mir weitergeholfen
Gerne geschehen
Ist das wirklich so, dass das im
Lastenheft/Ausschreibungsunterlage formulierte Governance
Modell rechtlich so bindend ist? Ich dachte bisher immer, dass
letztendlich der Vertag mit seinen Inhalten verbindlich ist
und das GM (Governance Modell) im Lastenheft die Vorstellung
des Auftraggebers darstellt. Meine Vorstellung war also
bisher, dass im Lastenheft die Vorstellung des Auftraggebers
steht (quasi Verhandlungsgrundlage) und im Rahmen der
Bieterkreise ein GM beiderseitig committet wird. Dies steht
dann im Vertrag.
Es kommt so ein wenig auf die Situation der beteiligten Unternehmen und der ggf. eingesetzten Berater an. Um eine möglichst gute Vergleichbarkeit der Angebote bei gleichzeitig kurzer Vergabedauer zu erreichen hat es sich (leider oft nicht wirklich sinnvoll) gerade bei Großunternehmen eingebürgert, dass der AG im Rahmen eines Ausschreibungsbaukastens auch das Governance-Modell vorgibt, und dann Zustimmung zu x diesbezüglichen Einzelpunkten erwartet. Abweichungen werden dann als „Punktabzug“ in der Bewertung des Angebots vorgenommen, bzw. der Anbieter wird aufgefordert für ihn kritischen Punkten zunächst zuzustimmen, und die Zustimmung monetär zu bewerten, und als Aufschlag in sein Angebot einzupreisen .
Das setzt aber natürlich voraus, dass der AG/sein Berater wirklich die Weisheit mit Löffeln gefressen hat, und sich seines Governance-Modells absolut sicher sein kann. Tatsächlich sind oft aber die AN viel erfahrener in diesen Dingen, und dann kommt man schnell an den Punkt, wo es kurios wird. D.h. der AN hat den eigentlich besseren, erprobten Vorschlag, und bekommt dafür dann einen Punktabzug/muss sich preislich damit rausschießen.
Insoweit sollte man als AG - zum eigenen Vorteil - eine gewisse Offenheit für abweichende Vorschläge mitbringen, und nicht jede Abweichung vom eigenen Vorschlag gleich negativ bewerten. Klar, das kostet etwas mehr Zeit, wenn man so das Governance-Modell gemeinsam voran bringt. Aber die lohnt sich mE immer.
Egal wie es dann zum abgestimmten Modell kommt, es wird dann zum Vertragsbestandteil. Und das macht man, indem man hierauf einfach als Anlage zum Vertrag verweist. Sinnig ist hierbei mE, dass man sich grundsätzlich vorab hierüber dann bereits verständigt hat, z.B. indem man vom AN die Zustimmung verlangt hat, und dann im Rahmen der finalen Preisverhandlung dann noch mal die für den AN kritischen Punkte unter finanziellem Gesichtspunkt betrachtet. D.h. was ist der AN bereit noch nachzulassen, wenn der ein oder andere für ihn kritische Punkt in seinem Sinn gelöst wird?
ITIL ist mir durchaus bekannt und auch bei uns ein Begriff.
Allerdings ist unser „ITIL-Reifegrad“ doch sehr weit unten.
Wir sind gerade dabei die Prozesse Incident Management, Change
Management, Asset Management einzuführen bzw. unsere bisherige
Arbeit dabei auszurichten.Von daher haben wir und sind gerade dabei die für uns
relevanten Rollen zu definieren.Ich habe mir jetzt zum Thema GM folgendes vorgestellt:
1. Wir definieren eine Verantwortlichkeitsmatrix. Auf der
seinen Seite stehen die Services (z. B. Unix-Server aber auch
Change Management) und auf der anderen Seite die ITIL-Rollen
bzw. die Rollen durch unsere Organisationsstruktur (Leiter
usw.). Die Matrix fülle ich dann entsprechend (wer ist
verantwortlich für die Durchführung, für den Prozess, wer muss
informiert werden usw.
So eine RACI-Matrix ist immer gut. Sollte dann aber eben nicht nur die Verantwortlichkeit definieren, sondern auch wer zu informieren ist, mit wem man sich abstimmen muss, … eben RACI. Das ist aber, wenn es in die einzelnen technischen Aufgaben geht, weniger ein Teil des Governance-Modells, sondern eher etwas, das man mit in den Vertrag oder einen einzelnen Leistungsschein unter einem Rahmenvertrag aufnimmt.
- Dann möchten wir von unten (operativ) bis nach oben
(strategisch) alle Kommunikationsebenen festhalten und
beschreiben. Wer setzt sich zu welchem Thema an einen Tisch
und wie oft passiert das.
Ja, das sollte sich im Governance-Modell aber dann vorrangig auf die Rollen nach ITIL beschränken. D.h. es gibt z.B. ein Change Advisory Board, in dem sich primär die beiden Change-Manager treffen, die sich vorab bereits mit den Systemverantwortlichen ihrer Seiten jeweils schon abgestimmt haben. Die kann man dann im Einzelfall mal beiladen, wenn ein Change eben ein konkretes System betrifft. Das CAB sollte aber keine Technikerrunde sein, in der sich jetzt die UNIX-Server-Verantwortlichen die Köpfe wegen der richtigen Reihenfolge von zwei Scripten einschlagen, während die Windows-Server-Verantwortlichen dabei sitzen, und Däumchen drehen oder sich bereits der nächsten Diskussion um ein eigenes Thema widmen.
- Zuletzt beschreiben wir dann die Schnittstellen zu anderen
Abteilungen (themenbezogen)
ITIL ist ja prozessorientiert. Insoweit sehe ich hier nicht in erster Linie die Abteilungen, sondern die Prozesse. D.h. wenn sich aufgrund eines Changes z.B. geänderte Ressourcen-Anforderungen ergeben, dann lautet die Schnittstelle hier nicht „Abteilung IT-Einkauf“, sondern „Capacity Management“
Was hältst Du aus Deiner Erfahrung davon? Ist das der richtige
Weg und was würde da noch fehlen?
Das klingt doch für den Ansatz schon mal ganz gut. Der Appetit kommt dann beim Essen Ich bin zwar ein großer Fan von Prozessorientierung, schlage auch beinahe täglich mit ITIL- und CMMI-Vokabular um mich, habe selbst da aber - ganz bewusst - nie irgendwelche Zertifizierungen oder Lehrgänge gemacht, weil das immer zu einer gewissen „Vergötterung“ der gelernten Methodiken führt. Die sind aber natürlich immer nur Werkzeug, und sind in ihrer reinen Definition natürlich für ein „optimales“ Unternehmen gedacht. Diese gibt es aber natürlich in freier Wildbahn nicht, und so muss man mE nicht immer auf Teufel komm raus versuchen, irgendetwas passend zu machen, damit es 1:1 zum Vorlagensatz aus dem Lehrbuch passt, damit man sein eigenes Köpfchen nicht zu sehr anstrengen muss. Vielmehr halte ich sehr viel davon, in verschiedene Ansätze durchaus auch etwas tiefer einzusteigen, und dann den eigenen Grips zu gebrauchen, was wo passt, was man selbst ergänzen muss, weil mal irgendwo die ein oder andere „reine Lehre“ nicht passt, …
Gibt es eigentlich auch so was wie ein Betriebszeiten Modell?
Aber selbstverständlich. Auch das gehört als Anlage zum Vertrag. Darin kann man dann z.B. verschiedene Betriebszeitmodelle wie Gold, Silber, Bronze definieren, die man dann wiederum einzelnen Services zuordnet. Da gehört dann z.B. rein, wann ein System für den Anwender zur Verfügung zu stehen hat (Betriebszeit), was es für Wartungsfenster gibt, in welchen Zeiträumen bedienter Betrieb mit Serviceleveln angeboten wird (Servicezeit), was man mit laufenden Serviceleveln am Ende der Servicezeit macht (Aussetzung oder Bearbeitung bis Abschluss), wann nur eine Bereitschaft für Fehler mit hoher Priorität geleistet wird, wie man mit Wochenenden und Feiertagen umgeht, …
Ach ja, das mit den externen Beratern … Du kennst meinen
Chef nicht
Da sollte sich Cheffe aber mal besser umorientieren. Denn das in diesem Bereich eingesetzte Geld ist üblicherweise sehr gut angelegtes Geld. Wenn ich einen richtig knackigen Vertrag mit meinem DL schließen kann, kann sich alleine aus den Pönalen aufgrund von SL-Verletzungen jeden Monat anständiges Geld verdienen lassen. Ebenso, wenn ich anständige Korridore für die Abnahme der Leistung vereinbare, … Ich mache das jetzt ja schon einige Jahre (auf DL-Seite), und kämpfe natürlich dafür, dass man als DL auch in Zeiten von Managed Services noch überleben muss. Aber ich sehe natürlich auch, welches Sparpotential da noch in vielen Unternehmen drin steckt, das ein Fachmann da recht schnell heben kann.
Gruß vom Wiz
Hallo Wiz,
ok, ich habe das soweit verstanden was Du mir erklärst und ich sehe das eigentlich auch so. Nur das mit dem „Geld verdienen“ habe ich leider nicht ganz verstanden. Du schreibst ja, dass man als Auftraggeber damit Geld verdient, wenn der DL die vereinbarten SLA/OLA nicht einhält. Damit meinst Du - nehme ich an - Vertragsstrafen? Sorry das ich hier blöd nachfrage, aber wenn ich Deine Feed so lese hört sich das so an, als ob Vertragsstrafen in der Praxis sehr oft vorkommen?!
Was würdest Du denn sagen: Wir arbeiten nur ganz rudimentär nach ITIL und haben auch keine SLA mit dem Business. Es geht nur um die Zusammenarbeit zwischen IT und DL. Wir haben vom Management nur eine Kennzahl zu liefern bzw. zu erfüllen die aber nicht schriftlich fixiert ist. Und das wäre die Verfügbarkeit von 99%.
Das wir dies quasi 1 zu 1 an den DL weitergeben, ist das klug oder sollten wir da auch 99,3% oder so gehen? Und was meinst Du, welche Kenngrößen machen aus Deiner Erfahrung noch Sinn (wenn man bedenkt, dass wir erst am Anfang stehen)?
Noch eine andere Frage:
Aktuelles Thema, wir heute versucht haben im Kollegenkreis zu klären und bisher noch keinen gemeinsamen Nenner gefunden haben. Wir sind dabei unsere Services zu beschreiben. Dort werden auch die Tätigkeiten und die Lieferergebnisse aufgeführt. Wie konkret werden die dort beschrieben?
Beispiel: Es gibt eines „Mail Services“ in dem es letztendlich um den Exchange geht. Jetzt sollten dort die ganzen Aktivitäten aufgeführt werden. Das kann man nun ganz detailliert machen und drei Seiten füllen, oder nur ganz kurz (z. B. nur Support, Monitoring, Betrieb). Lieferergebnis wäre dann auch nur ein „Stabiler Exchange nach SLA“. Wir denken uns, dass ein DL sich damit auskennt und weiß, was er grundsätzlich alles machen muss wenn es um einen Mail Service geht.
Hast Du hierzu vielleicht einen Best Practice für mich, was die Detailtiefe der Beschreibung angeht?
Danke und Gruß
AXL
Hallo,
als Vertreter der AN-Fraktion will ich da jetzt nicht gerade wüstesten SLA- und Pönalenstrukturen das Wort reden, aber ja, das Thema bietet diverse Kostenschrauben, an denen man drehen kann, und pönalisierte SLA sind durchaus üblich und haben - in Maßen - auch ihre Berechtigung, und können bei Verwirklichung durchaus auch Geld in die Kasse des AG zurück spülen.
Dabei ist es vollkommen uninteressant, inwieweit interne SLA/OLA existieren, und wie scharf die sind. Man darf sich da durchaus an Industriestandards und Best Practices orientieren, die marktgängig sind (die kann und werde ich dir aber nicht frei Haus liefern, da meine/unsere Unternehmenssicht natürlich Geschäftsgeheimnis ist).
Inwieweit man bei den externen SLA strengere Maßstäbe anlegt, als bei internen OLA muss man natürlich im Einzelfall sehen. Wenn interne Nacharbeiten einzuplanen sind, muss der DL natürlich einen engeren SLA haben, damit man selbst noch mit seinen Anteilen im OLA bleibt. Umgekehrt kann der DL natürlich bei zwingender Mitarbeit/Zulieferung der internen IT nicht strengere SLA akzeptieren, als diese Zulieferungen ermöglichen.
Was die Beschreibung der Tätigkeiten angeht, so kann ich nur zu einer möglichst hohen Detailtiefe raten, auch wenn die zu Anfang mehr Arbeit macht. Nur so kann man dann abgrenzen, was wirklich wessen konkrete Aufgabe und Tun war, wenn es mal gekracht hat. Wichtig hierbei aber auch die Definition der Beistell- und Mitwirkungsleistungen, die Aufnahme echter Abgrenzungen und Aufnahmen, und insbesondere auch Aussagen zu Leistungen beteiligter Dritter, und wer die wie steuert, anweisen kann, und welche Eskalationsverfahren hierbei gelten. Gerade wenn ein DL die Rolle eines Operational Integrators übernehmen soll, ist das von extremer Wichtigkeit (für beide Seiten).
Gruß vom Wiz
Hallo,
sorry für die späte Rückmeldung, war die letzten Tage viel unterwegs …
Wieder mal ist Deine Ausführung sehr interessant. Gerade der letzte Absatz bzgl. der Detaillierungstiefe ist für mich nach wie vor ein wenig unklar. Wir haben für uns nun einen Stand erarbeitet und die Services entsprechend beschrieben. Allerdings kann man das natürlich noch immer detaillierter machen. Da findet man keine Grenzen. Für mich ist halt noch unklar, wo der Unterschied zu einer Prozessbeschreibung und einer Servicebeschreibung ist. Aber das ist jetzt eigentlich egal, da wir jetzt einen Stand haben der reicht (hoffe ich).
Aber vielleicht darf ich Dich noch mit einer Frage belästigen, an der ich derzeit sitze: Thema Service Agreements
Wir haben ja fixe Servicezeiten, an denen sich der Supplier auch halten muss. Kann man einem Supplier nun auch sagen, dass wir gerne auch flexible Servicezeiten außerhalb der ursprünglichen Servicezeiten haben möchte und ebenso Rufbereitschaftszeit? Oder muss man das im Vorfeld genau wissen, wann man denjenigen haben möchte?
Und ein weitere wichtige Punkt, bei dem ich auf Deine Erfahrungswerte gespannt bin:
Eigentlich haben wir nur eine wichtige Kennzahl, die mit dem Management (Business) abgestimmt ist: 99,3% Verfügbarkeit. Alles andere ist eigentlich egal ;(
Gibt es aus Deiner Erfahrung heraus noch relevante KPIs, die für die Steuerung wichtig sein können? Klar bietet ITIL einen Berg an Kennzahlen, aber wir stehen hier ja erst am Anfang und müssen alles Schritt für Schritt machen.
Du hast ja geschrieben, dass Du auf der Seite der DL unterwegs bist. Dann hast Du sicherlich auch bereits mehrere Bieterkreise miterlebt?! Was stellen DL denn dort so üblicherweise vor? Was kann man vorgeben usw.?
Gruß
AXL
Hallo,
Wieder mal ist Deine Ausführung sehr interessant. Gerade der
letzte Absatz bzgl. der Detaillierungstiefe ist für mich nach
wie vor ein wenig unklar. Wir haben für uns nun einen Stand
erarbeitet und die Services entsprechend beschrieben.
Allerdings kann man das natürlich noch immer detaillierter
machen. Da findet man keine Grenzen. Für mich ist halt noch
unklar, wo der Unterschied zu einer Prozessbeschreibung und
einer Servicebeschreibung ist. Aber das ist jetzt eigentlich
egal, da wir jetzt einen Stand haben der reicht (hoffe ich).
Der Service lebt in diversen Prozessen, die für sich genommen generisch sind. D.h. z.B. ein Release-Management wird so beschrieben, dass es grundsätzlich für Windows als auch für Unix-Systeme gleichermaßen (ggf. mit kleinen Abweichungen) einsetzbar ist. Dito das Incident- und Problem-, sowie das Change-Management.
Der beauftragte Service umfasst jetzt einen, einige oder alle entsprechend beschriebenen Prozesse. Und zudem kann ein oder mehrere Systeme umfassen. D.h. es mag einen DL geben, der nur Incident- und Problem-Management für Windows-Server macht. Es mag aber auch einen anderen DL geben, der für alle UNIX-Systeme (auch Desktops) neben diesen beiden Dingen auch noch Change- und Release-Management macht, …
Aber vielleicht darf ich Dich noch mit einer Frage belästigen,
an der ich derzeit sitze: Thema Service Agreements
Wir haben ja fixe Servicezeiten, an denen sich der Supplier
auch halten muss. Kann man einem Supplier nun auch sagen, dass
wir gerne auch flexible Servicezeiten außerhalb der
ursprünglichen Servicezeiten haben möchte und ebenso
Rufbereitschaftszeit? Oder muss man das im Vorfeld genau
wissen, wann man denjenigen haben möchte?
Fairer- und sinnigerweise spricht man solche Dinge möglichst früh an, da das Dinge sind, die tatsächlich nicht jeder DL erbringen, bzw. nicht für marktgerechte Preise erbringen kann. Wenn man ohnehin als Shared-Service eine RB bereits für x andere Kunden unterhält ist das etwas ganz anderes, als wenn man das als dedizierten Service für einen (ggf. auch noch kleinen) Kunden erbringen muss. Dabei muss so eine RB ja durchaus nicht ständig vorhanden sein, sondern kann natürlich auch nach Vereinbarung mit entsprechender Vorankündigung nur für bestimmte Zeiten/Ereignisse vereinbart werden. Aber auch das gehört natürlich frühest möglich auf den Tisch. Man kann von keinem DL verlangen, der nicht ohnehin entsprechend im Rahmen von Shared-Services entsprechend mit ausreichendem Puffer ausgestattet ist, dass er so etwas „auf Zuruf“ von jetzt auf gleich übernimmt.
Wir haben durchaus Verträge, bei denen wir da sehr abgestufte Dinge vereinbart haben. Z.B. dass bei Incidents mit hoher Prio (auch diese muss natürlich dann präzise beschrieben sein) am Ende der Servicezeit vorhandene Incidents weiter bearbeitet werden müssen, während Dinge mit geringer Prio dann bis zum nächsten Tag pausiert werden. Es gibt generelle Rufbereitschaften aber eben auch vorab mit entsprechendem Vorlauf zu buchende RBs und ggf. sogar zusätzlichem Vor-Ort-Personal, …
Und ein weitere wichtige Punkt, bei dem ich auf Deine
Erfahrungswerte gespannt bin:
Eigentlich haben wir nur eine wichtige Kennzahl, die mit dem
Management (Business) abgestimmt ist: 99,3% Verfügbarkeit.
Alles andere ist eigentlich egal ;(
Gibt es aus Deiner Erfahrung heraus noch relevante KPIs, die
für die Steuerung wichtig sein können? Klar bietet ITIL einen
Berg an Kennzahlen, aber wir stehen hier ja erst am Anfang und
müssen alles Schritt für Schritt machen.
Na ja, also ich sehe da durchaus einige weitere relevante Dinge: Erreichbarkeit (% der in einer bestimmten Zeit angenommenen Meldungen), Reaktionszeit (Zeit zwischen Eingang einer Meldung und Aufnahme der Bearbeitung), Lösungszeit für Incidents und Problems, Erstlösungsquote (% der im Erstkontakt gelösten Tickets), Nutzung der Knowledgebase (% der durch einen Eintrag der auch bei einem Anbieterwechsel erhalten bleibenden Knowledgebase gelösten Tickets), Wiedereröffnungsquote (% der aufgrund nicht funktionierender Lösung wieder geöffneten Tickets), Kundenzufriedenheit (Benotung des Kompetenz und Freundlichkeit), …
Abgesehen davon muss man ja die Frage stellen, was Verfügbarkeit überhaupt bedeutet? Die Zahl für sich genommen sagt ja nichts aus. Da müssen Messpunkte und Verhältnisse definiert werden, … Da müssen die Verantwortlichkeiten klar abgegrenzt werden (wenn jemand nur für Server aber nicht für Storage zuständig ist, kann man ihm nicht ans Bein pinkeln, wenn die gesamte IT wegen eines Storage-Ausfalls steht, die Server für sich genommen aber schön Idle laufen, …
Du hast ja geschrieben, dass Du auf der Seite der DL unterwegs
bist. Dann hast Du sicherlich auch bereits mehrere
Bieterkreise miterlebt?! Was stellen DL denn dort so
üblicherweise vor? Was kann man vorgeben usw.?
Da erlebst Du alles und nichts. Und wie man damit umgeht, kann man nicht mal eben in ein paar Zeilen runter schreiben. Da braucht es einfach jahrelange Erfahrung.
Da gibt es (gerade im Mittelstand) die ganz Harten, die meinen, die Weisheit mit Löffeln gefressen zu haben, mal so richtig mit den großen Jungs pinkeln gegen wollen, und sich einen Spaß daraus machen, DL sinnlos zu knebeln und zu quälen, und bei ihren oft vollkommen überzogenen Forderungen total vergessen, dass sie sich selbst damit die Preise versauen. Die kommen dann mit 30 SLA und 70 KPI daher. Denen begegnet man am besten so, dass man mal den Blick für etwas Realismus schärft. Wenn man denen erzählt, was Großbanken und Industriekonzerne so an Standard-SLA und KPI feinst abgestuft für unterschiedlich kritische Systeme akzeptieren (und damit dann auch erheblich Geld sparen), und dann am Ende der Verhandlung im kaufmännischen Teil dann ein Preisschild an jede Sonderlocke hängt, werden die hausintern schon vom eigenen Einkauf sofort auf Spur gebracht.
Dann gibt es die Ahnungslosen und die Naiven, denen man überhaupt erst einmal so ein mögliches Gerüst aufzeigen muss, …
Dazwischen liegen die Vernünftigen, die sich im Rahmen ihrer Möglichkeiten schlau gemacht haben, ein paar Ideen und Anforderungen mitbringen, und sich durchaus auf die Diskussion mit dem DL einlassen, und insbesondere verstehen, was für wirtschaftliche Auswirkungen bestimmte Anforderungen haben, und sich dann durchaus auch hiervon mal im Einzelfall abbringen lassen, oder geeignete Alternativen im Sinne von üblichen Standards akzeptieren. Richtig einzuschätzen, ob man dabei einen fairen Partner auf der anderen Seite des Tisches hat, oder ob jetzt versucht wird, einen dabei gnadenlos über den Tisch zu ziehen, kann man aber nur, wenn man dabei schon ein paar Jahre in dem Bereich auf dem Buckel hat. Kommt wirklich nicht von ungefähr, dass sich da so viele Firmen dann externe Berater für einige Wochen/Monate einkaufen, um eine entsprechende Ausschreibung durchzuführen und dann die Verträge zu verhandeln.
Gruß vom Wiz