Was mir fehlt, ist die Möglichkeit zur Eskalation. Ist die nächste Managementstufe (Du?) auch in Bereitschaft?

Keine Lösung in einer halben Stunde -> Eskalation. Das hält dem arbeitenden Admin den Rücken frei (eventuell Telefonumleitung)

Das hätte ich mir beispielsweise bei meinem längsten Bereitschaftsfall gewünscht.

Variable Vergütung? Dann aber bitte nur an Zielen, die man wirklich erreichen will. Ihr wollt sicherlich nicht möglichst wenig Einsätze am Wochenende. Ihr wollt zufriedene Kunden. Dazu benötigt ihr vermutlich wenig Downtime UND relaxte und freundliche Mitarbeiter. Das passt leider in keine gehaltstaugliche Kennzahl. Es wird immer auf das optimiert, was die Kennzahl misst. Also genau überlegen, ob man das wirklich will!

Pointer: Interessanter Artikel (und ausführliche Diskussion in den Kommentaren) zum Thema Rufbereitschaft in der IT findet sich im Managing Tech Blog.
…

Allerdings: nicht immer hat der Mitarbeiter der die Bereitschaft hat die Möglichkeit die Architektur zu ändern, schon aus diesem Grund ist es sinnvoll dessen Entschädigung nicht zu kürzen wenn er oft die Probleme (anderer) ausbaden muss.

Aber: jeder Vorfall sollte ein Followup Problem Management nach sich ziehen.

Gruss
Bernd

Ich kann aus meiner aktiven Bereitschaftszeit (1996-1999 - das Klingeln des S4 lösst bei mir immer noch einen Adrenalinstoss aus) noch ein paar Tipps geben:

1) Einen Mailverteiler für Betriebsvorfälle einrichten. Bereitschaftseinsätze mit Lösung werden gleich nach Einsatzende dokumentiert und an den Verteiler verschickt. Auf diese Weise wissen auch wenn der betreffende Kollege noch in der Heia liegt alle anderen schonmal Bescheid. Cut ‘n Paste fähige Rezepte werden auch gern genommen. An den Verteiler sollten natürlich auch sonst Dinge geschickt werden, die die Bereitschaft interessieren (könnten). Also Changes, Tests, Downtimes, Launches, etc.

2) Der Bereitschafter der abends “dran” sein wird, sollte auch tagsüber das “rote Telefon” haben und sich um das Incident-Management kümmern (das gibt den anderen Kollegen Zeit, sich um Dinge zu kümmern, die längere Konzentrationsphasen benötigen).
Die extra vergütete Bereitschaftszeit beginnt natürlich trotzdem erst nach der Bürozeit.

3) Bei uns wurden Bereitschaftsstunden als Teil der vereinbarten Ziele festgesetzt. Dabei ging es nicht um die Anzahl der Einsätze sondern die Teilnahme an der Bereitschaft. Wer sich oft zur Bereitschaft gemeldet hat, konnte u. a. so seinen variablen Anteil verdienen.

Ansonsten kann ich noch die Bücher von Thomas A. Limoncelli empfehlen, wenn es um Tipps zu diesem Bereich geht.

1. Der Magenta-Riese z.B. steuert die gesamte IT nach ein paar wenigen Kennzahlen. Eine zentrale z.B. ist die Dauer der Uptime zwischen zwei Ausfällen in Stunden. Ob eine Festplatte abgeraucht ist oder jemand mutwillig den Stecker gezogen hat, ist an der Stelle total egal. Wenn das System unten ist, dann verliert das Unternehmen Geld und die IT hat ihren Job nicht gemacht.

2. Noch ein kurzer Exkurs zu den “Best Practices” von großen Unternehmen. Da gibt es beim Support den Unterschied zwischen Incident und Problem Management. Steuerungsgröße beim Incident Management ist die Effizienz, also die schnellstmögliche Wiederherstellung der Arbeitsfähigkeit, damit die Nutzer die Plattform wieder nutzen können (damit Geld verdient wird). Im Problem Management ist die Steuerungsgröße die Effektivität oder die Qualität. Arbeiten am Wochenende würden klassischerweise auf das Nötigste (i.W. Konzentration auf Incident Management) reduziert werden. Problem Management - also die wirkliche Ursachenbehebung - wird dann während der Woche gemacht. Beides kann man mit sehr konkreten KPIs hinterlegen. Wenn es interessiert: Gute weiterführende Literatur dazu gibt es bei http://en.wikipedia.org/wiki/ITIL bzw. http://en.wikipedia.org/wiki/COBIT (und den verweisenden Quellen). Ich habe bei vielen großen Unternehmen gesehen, dass
allein das Bewusstmachen dieser Unterscheidung viel zur Effektivitätssteigerung beigetragen hat.

Ich bin kein ITIL oder COBIT Verfechter, aber ich glaube, dass diese Frameworks dabei unterstützen können, die IT aus unternehmerischer Sicht zu steuern.

@Jan: Dein Eingabefeld für den Text ist definitiv zu klein und das Zeichenlimit zu niedrig

Das heißt aber nicht das variable Vergütung prinzipiell schlecht ist. Aus unternehmerischer Sicht kann sie durchaus Sinn machen, weil man dann als Unternehmen “atmen” kann. Mitarbeiter denken dadurch auch häufig deutlich unternehmerischer bzw. mehr im Sinne des Unternehmens. Die Mischung der Kategorien und das definieren der Ziele ist da aber entscheidend. Variable Gehaltsbestandteile sollten imho immer Top-Down eingeführt werden: erst Unternehmens- dann Bereichs- und evtl. persönliche Ziele.

Aber damit hier nichts falsch rüberkommt: Intrinsische Motivation ist immer die beste Motivation. Bei kleinen Unternehmen ist die meist schon gegeben, warum dann etwas ändern? Man macht häufig mehr kaputt als man gewinnt. Ab einer bestimmten Unternehmensgröße (kann je nach Unternehmenskultur variieren) machen durchaus aber auch extrinsische Anreize Sinn. Warum? Weil die intrinsische Motivation bei größeren Unternehmen im Schnitt abnimmt. Deshalb werden die auch (im Schnitt) deutlich unproduktiver.

Nun zu dem Mist. Natürlich raucht hin und wieder mal eine Festplatte ab. Dadurch wird aber noch nicht die ganze Idee Schrott. Entweder man sagt: “Pech gehabt, ihr seid auch dafür verantwortlich, dass die HW läuft” oder man definiert die Ziele noch in beeinflussbare und nicht beeinflussbare Faktoren (Der letzte Vorschlag erhöht deutlich die Komplexität). Natürlich stimme ich Dir zu, dass es bei so ziemlich jeder Steuerungsgröße Moral Hazard Probleme gibt. Mein Modell kann auf jeden Fall noch verbessert werden. Ich wollte aber auch primär aufzeigen wie man an so ein Thema rangehen kann(!).

Einsätze am Wochenende zu belohnen halte ich prinzipiell für kontraproduktiv. Warum sollte ich dann an einem Festplattenaustausch nicht einfach drei Stunden sitzen wenn ich für jede halbe Stunde bezahlt werde? Wenn schon variable Vergütung einführen, dann auch mit der Orientierung an Unternehmenszielen. Zielsetzung aus unternehmerischer Sicht sollte es doch sein, dass die IT sich so aufstellt, dass Ausfallzeiten und IT-Kosten möglichst minimiert werden und das die IT einen Business-Mehrwert generiert.

Was ist denn aus Deiner Sicht eine gute Steuerungsgröße für den IT-Support (Abteilung)?
Was ist eine gute Steuerungsgröße für den IT-Supportler (Person, die am Wochenende Bereitschaft hat)?

Zum IT Support (Abteilung) noch zwei Punkte:

1. Der Magenta-Riese z.B. steuert die gesamte IT nach ein paar wenigen Kennzahlen. Eine zentrale z.B. ist die Dauer der Uptime zwischen zwei Ausfällen in Stunden. Ob eine Festplatte abgeraucht ist oder jemand mutwillig den Stecker gezogen hat, ist an der Stelle total egal. Wenn das System unten ist, dann verliert das Unternehmen Geld und die IT hat ihren Job nicht gemacht.

2. Noch ein kurzer Exkurs zu großen Unternehmen. Die unterscheiden beim Support in Incident und Problem Management. Steuerungsgröße beim Incident Management ist die Effizienz, also die schnellstmögliche Wiederherstellung der Plattformen, damit die Nutzer die Plattform wieder nutzen können (damit Geld verdient wird). Im Problem Management ist die Steuerungsgröße die Effektivität oder die Qualität. Am Wochenende würde klassischerweise nur Incident Management gemacht. Problem Management - also die wirkliche Ursachenbehebung - während der Woche. Beides kann man sehr detailliert mit KPIs hinterlegen. Gute weiterführende Literatur dazu gibt es bei http://en.wikipedia.org/wiki/ITIL bzw. http://en.wikipedia.org/wiki/COBIT und den verweisenden Quellen.

Ich bin kein ITIL oder COBIT Verfechter, aber ich glaube, dass diese Frameworks dabei unterstützen können, die IT aus unternehmerischer Sicht zu steuern.

@Jan: Das Textfeld zum Eingeben von Text ist definitiv zu klein

Das ist großer Mist. Schließlich rührt nicht jeder Einsatz von einem vorhergehenden Versäumnis.

Einer Festplatte ist es ziemlich wurscht, ob du sie dreimal die Woche streichelst, die sagt einfach irgendwann “aus die Maus” und dann muß einer hin.

Anders sähe es aus, wenn es die Woche dreimal klingelt …

Sowas endet damit, daß z.B. nötige Einsätze “verschoben” werden oder Probleme verheimlicht und damit Chancen vertan werden für eine wirkliche Verbesserung der Infrastruktur.

Intrinsische Motivation durch extrinische zu ersetzen, geht meistens anders aus als gedacht.

Über die prozentuale Verteilung kannst Du dann steuern was Euch wichtig ist. Persönliche Ziele würde ich bei jungen Unternehmen eher weglassen. Bei Startups auf jeden Fall.

Für das Beispiel Bereichsziele würde ich die 2-5 entscheidenden KPIs des Bereiches identifizieren, heutigen Stand ermitteln und dann eine quantifizierbare Zielgröße setzen. Da kannst Du z.B. sowas machen wie
- 0 Einsätze = 100% Bonus
- 1 Einsatz = 75%
- 2 Einsätze = 50%
- 3 Einsätze = 25%
- > 4 Einsätze = 0%

Vielleicht sind es aber auch nicht die Anzahl der Einsätze, sondern die Länge (habt Ihr ja heute drin). Die Wahl der Zielgröße ist ziemlich entscheidend, da die Leute dann auch ganz genau darauf schauen werden. Wichtig ist, dass das Thema “moral hazard” soweit wie möglich reduziert wird.

Ein Hinweis aber noch: variable Vergütung hat einen enormen Effekt auf die Unternehmenskultur und wenn man sie einmal eingeführt hat, dann ist sie nur schwierig wieder rauszunehmen (es sei denn man zahlt den Bonus fix aus, darüber wird sich wohl niemand beschweren). Außerdem macht variable Vergütung nicht für alle Positionen Sinn… Aber das ist eine längere Diskussion.

Florian, für eine Woche Rufbereitschaftsdienst gibt es etwa 10% des Bruttolohns.

Manuel, den Tipp mit den Klammerzielen finde ich sehr gut! Derzeit werden Ausfälle in der Tat belohnt. Wie würdest du solche Klammerziele denn gestalten?

Einen Bonus für das ganze Team, wenn die Anzahl der Einsätze unter X bleibt?