Darstellung einer Vision

Eine Vision kann ein ziemliches Wirrwar an Informationen beinhalten.
Ich habe die Galerie-Vision mit einem Mind Map Diagram gezeichnet. Genausogut hätte ich die Vision nur als Text oder mit ein paar Skizzen beschreiben können.
Das Mind Map Diagram zeigt meiner Meinung nach recht schön und kompakt die einzelnen Themengebiete an.

Wie du sehen kannst, habe ich hier funktionale und nichtfunktionale Elemente miteinander vermischt.
Zum Zeitpunkt der Visionserstellung ist noch nicht klar, was alles genau wie im System abgebildet sein soll.
Aber wenn man die Vision gelesen hat, sollte man verstehen was sich hinter dem Produkt schlussendlich verbirgt.

Die Vision der Galerie

Mit der Galerie soll eine Möglichkeit geschaffen werden, eigene Bilder an einem Ort im Internet verwalten zu können.
Die Bilder sollen auf mehreren Wegen, wie beispielsweise per Mail oder per Upload Funktion in die Galerie eingefügt werden können.
Andere Dienste, wie Facebook oder Blogsysteme, sollen die Informationen der Galerie mitnutzen können.
Um Missbrauch zu vermeiden, sollen die Benutzer der Galerie sich registrieren und in entsprechende Rollen eingeteilt werden.
Die Galerie soll eine interaktive Kommunikation zwischen den Anwendern ermöglichen und den Zugriff auch für ungeübte Menschen erlauben.
Der Funktionsumfang soll einfach erweiterbar sein, damit auch in ein paar Jahren noch Erweiterungen hierfür erstellt werden können.

Kundennutzen

Die Verwaltung der Galerie soll so gestaltet sein, dass nur wenige Handgriffe für die Installation und Konfiguration von Nöten sind.
Kunden erhalten die Möglichkeit ihre Bilder untereinander auszutauschen und zu präsentieren.

Nachdem du diese Vision gelesen hast, solltest du dir ein Bild von der Galerie machen können.
Falls mir das gelungen ist, können wir sie umsetzen

Ähnliche Beiträge

• Business Process Modeling
• Requirements Engineering
• Use Cases
• Sequence Diagrams
• Class Diagrams mit Reverse Engineering
• Zusammenarbeit mit verteilt arbeitenden Teams

anhand der bereits prototypisch erstellten Galerie beschreiben.

Da ich irgendwann mal das Blogsystem wechsle, werde ich im Moment auf eine Serie verzichten. Aber mit einer neuen Kategorie ist das ja auch gut genug abgegrenzt

So, dann werde ich mal in die Tasten hauen und bald mal den ersten Artikel zusammenschrauben.

Bis dahin wünsche ich euch eine sonnige Frühlingszeit

Ähnliche Beiträge

Das Kochrezept und die Kundenanforderungen

Das Kochrezept, in diesem Fall Pfifferlingrisotto, ist mit den Kundenanforderungen zu vergleichen. Die Kundenanforderungen definierten als Musskriterien:

• Reis, der zu Risotto verarbeitet wird
• Pfifferlinge

Ok, Reis hatte ich und Pfifferlinge hatte ich ja schließlich gekauft. Als weitere Anforderungen lagen vor:

• Weißherbst zum Abschmecken
• Knoblauch
• Eine Zwiebel
• Pfeffer
• Etwas Sahne
• Gemüsebrühe

Aus diesen Anforderungen leitete ich ab ob sie muss oder kann Kriterien sind. Der Weißherbst selbst ist keine Mussanforderung. Ich hatte einen anderen Rose da und entschied, die Anforderung in Wein umzustellen. Knoblauch war kein Problem, genauso die Zwiebel, Sahne und der Pfeffer. Die Gemüsebrühe war nicht vorhanden. Also entschied ich um und verwendete eine Rinderbrühe. Somit veränderte ich den Wein und die Brühe.

Kundenanforderungen mit Wirklichkeit abgleichen

Ich hätte mich am Sonntag auf den Kopf stellen und mit den Ohren wackeln können. Damit hätte ich immer noch keinen Weißherbst und keine Gemüsebrühe gehabt. Ok, meine Nachbarin hat schon eine Zwiebel von mir bekommen. Vielleicht hätte sie im Gegenzug mit Wein und Gemüsebrühe herhalten können. Doch da ich den Pfifferlingrisottokunden recht gut kenne, ich bins ja selbst gewesen, wollte ich sie mit solchen Lapalien nicht belasten. Bei der IT ist es ebenfalls häufig einfach finanziell oder technisch nicht möglich einige Anforderungen zu erfüllen. Wenn die Anforderung heißt, dass du zwei Rechenzentren im Abstand von mindestens 15km benötigst und deine Rechenzentren einfach nur fünf Kilometer Abstand voneinander haben, dann kannst du diese Anforderung nicht erfüllen. Du musst mit deinem Kunden darüber reden und die Anforderung abändern. Und genau das habe ich mit der Rinderbrühe und dem anderen Wein gemacht.

Kundenanforderungen erweitern

Nachdem die Anforderungen geklärt sind, werden von der IT noch technische Anforderungen generiert. Das neue System muss betreibbar sein, es muss wartbar sein und wir müssen es z.B. auch noch überwachen können. Wir fügen zu den bestehenden Kundenanforderungen noch weitere Anforderungen hinzu. In meinem Fall war ich mit den Gewürzen nicht einverstanden. Ich hatte noch frischen Schnittlauch und frischen Oregano. Diese Gewürze wollte ich auch noch zum Menü hinzufügen. Damit wollte ich dem Gericht den nötigen Schliff geben. Somit habe ich das ursprüngliche Rezept doch schon ziemlich abgewandelt. Solange die Kunden damit einverstanden sind, entsteht so eine machbare (und sehr gut schmeckende) Lösung. Wenn ich nun einen externen Kunden gehabt hätte und dieser Kunde z.B. Vegetarier ist, wäre meine Rinderbrühe ein Killerkriterium gewesen. Also immer auf die Umgebung achten! Übrigens, dass Risotto war wunderbar. Und im Vergleich zu Programmen kann man beim Kochen das Ergebnis einfach aufessen und den Rest abspülen. Es bleiben keine Spuren mehr vorhanden und ein Refacturing ist normalerweise nur auf dem Konzeptlevel (Rezept) sinnvoll

Ähnliche Beiträge

Was sollte in einem Testprotokoll vermerkt werden?

Über dieses Thema kann man ganze Bücher schreiben.
Was ich auf alle Fälle in einem Testprotokoll erwarte sind folgende Eintragungen:

Was wurde getestet

Wenn man beispielsweise eine Webseite testet, sollte man beschreiben welche Tests man durchgeführt hat.
Beispiele:

• Broken Link Test
  Wurde ein Automat zum Auffinden von Broken Links verwendet?
  Wurden die veränderten Links angeklickt und kommt man zu den erwarteten Seiten?
• CSS Test
  Sind die CSS Dateien fehlerfrei? Beispielsweise können Farben falsch kodiert sein.
• HTML Seiten Valide?

Was wurde nicht getestet

Falls man z.B. die Texte nicht nochmals gelesen hat, da man daran nichts verändert hat, ist es gut dies zu vermerken. Vielleicht findet später jemand einen Fehler und man kann dann sagen “Stimmt! Die müssen schon länger drin sein”.

Welche Fehler und Warnungen traten auf?

Das ist sehr interessant, falls Fehler auftreten die zuvor schon im System waren.
Beispielsweise haben wir im Guggat emol Blog diverse Fehler, die von nicht sauber programmierten Plugins herkommen. Cool ist es, diese Fehler aufzuschreiben und z.B. an die Plugin Entwickler weiterzuleiten. Wenn die Kollegen etwas von den Fehlern erfahren, können sie eher diese korrigieren

Weitere Testbeschreibungen

Unregelmäßigkeiten, wie fehlende Elemente die eventuell noch benötigt werden sollten auch vermerkt werden.
Dann kann man noch all die schönen Dinge in ein Testprotokoll schreiben, die in jedem Lehrbuch erläutert werden.
Beispiele:

• Wer hat getestet?
• Wann wurde getestet?
• Ist der Test erfolgreich?
• Wie viele Testfälle konnten durchlaufen werden?
• Wie viele Fehler traten auf? (Leichte, Mittlere, Schwere Fehler)
• …

Was kann man jetzt mit dem Testprotokoll anfangen?

Zum Einen kann man hiermit beschreiben was man wie getestet hat.
Das hat den Vorteil, dass andere Kollegen relativ schnell erkennen können was man noch testen sollte.
Außerdem kann man sich somit gegenüber den Kunden und dem Management ausweisen, dass Tests durchgeführt wurden.
Für Open Source und private Projekte bietet das Testprotokoll die Möglichkeit, die vorhandenen Fehler und Unschönheiten an die betroffenen Entwickler weiterzuleiten.
Wie ich schon erwähnt habe, ein Entwickler eines Plugins kann nur dann einen Fehler korrigieren, wenn er davon weiss.
Wenn man was entwickelt hat und keine Rückmeldung erhält, geht man zuerst davon aus, dass alles in Ordnung ist.

Aufgabe an Jozo

Wenn du die Fehler, die wir am Samstag besprochen haben, korrigiert hast, teste den Webauftritt nochmals.
Erstelle diesmal ein elektronisches Testprotokoll und füge die von dir erkannten Fehler dort ein.
Wir schauen uns das Testprotokoll dann gemeinsam an.
Das Resultat werden wir, falls wir kein Futter für Scriptkiddies finden, veröffentlichen. Wir kennen da schon ein paar Fehler, die in den verwendeten Plugins drin sind. Gelle?

Ähnliche Beiträge

Was ist die Infrastruktur und Systemkomponenten Anforderung?

Die Produktionsumgebung hat folgende Konfiguration:

• Apache Webserver (aktuelle Version)
• PHP 5.X
• MySQL (aktuelle Version)
• AMD 64 Bit Root-Server

Was für eine Entwicklungsumgebung verwende ich?

Ich habe zwei Rechner mit denen ich die meiste Zeit entwickle:

• Asus Eee 900 für Unterwegs. Da ich viel Reise, ist das Teil im Moment wirklich meine primäre Maschine Kaum zu glauben oder? Aber ich kann darauf wirklich arbeiten.
• Desktop Quad Core Pentium Maschine mit 4 GByte RAM, zwei Monitoren usw.

Was man hier sieht ist, dass ich von Hardwareseite aus schon einen ziemlichen Zoo beieinander habe und die Komponenten nicht nah an der Produktion sind.
Auf den Maschinen habe ich die gleichen Softwareumgebungen drauf wie auf der Produktion.
Das heisst, nicht ganz. Ich führe zuerst auf den Entwicklungsrechnern Softwareupdates durch. Wenn die funktionieren und unsere Komponenten immer noch gut zucken, wird die Produktion aktualisiert.
Eigentlich logisch oder?

Abnahmeumgebung

Damit die Produktionsumgebung nur dann umgestellt wird wenn sichergestellt ist, dass wir funktionsfähige Software einsetzen, haben wir einen weiteren Rechner für die Abnahmeumgebung aufgebaut.
Dieser Rechner ist ein AMD 64 bit Rechner. Damit ist die Prozessorarchitektur mit der des Root-Servers übereinstimmend.
Er hat auch das gleiche Betriebssystem mit den identischen Libraries wie der Produktionsrechner.

Was erreichen wir mit dieser Konfiguration?

Die Entwicklungsrechner verwenden identische Software wie in der Produktion.
Das hat folgende Vorteile:

• Wir entwickeln mit den gleichen Softwarepaketen wie in der Produktion. (Apache, PHP, MySQL usw.)
• Die Konfiguration des Webservers (httpd.conf usw.) können wir schon in der Entwicklung üben. Die Unterschiede zur Produktion sind relativ gering und wir sind für die Migration trainiert.
• Upgrades können auf der Entwicklungsmaschine ausprobiert werden.
• Ich kann immer und überall mit meinem kleinen Netbook entwickeln. Das hat sich schon oft als Vorteil erwiesen, falls ein paar kleinenere Anfragen von Kunden schnell behandelt werden mussten. Ich war damit nicht ortsgebunden.

Nachteile dieser Entwicklungsumgebung

Wir haben einen Zoo an Rechnern rumstehen.
Wenn wir genug Geld hätten, könnten wir uns einen Typ von Hardware kaufen und betreiben. Das würde viel Aufwand und somit Geld sparen.
Mein Asus Eee 900 ist eine nette Maschine, aber es ist und bleibt ein Zwerg. Eigentlich ist es nicht vernünftig so eine kleine Maschine für diesen Einsatzbereich zu verwenden.
Aber wie hat schon einer meiner Profs gesagt: “Alle wünschen sich die besten Studenten, aber wir haben nur sie!”.
Ich bin auch ein grosser Bastler und deshalb habe ich halt im Moment die kleine Maschine.
Dirk hat mir eine lange Mail geschrieben in der er ausführt, dass ich auf einen leichteren Webserver umsteigen sollte.
Damit könnte ich wichtige Systemresourcen einsparen und mein Asus wäre dann wohl etwas schneller.
Doch hierzu kann ich nur sagen, dass es mir wichtig ist mit dem Webserver zu arbeiten, den ich später auch in der Produktion einsetze. Spezielle Flags, die ich Beispielsweise für BuddyPress benötige, möchte ich gleich bei mir auf der Maschine ausprobieren und optimieren können.

Fazit

Es ist wichtig mindestens die Abnahmetestumgebung mit der Produktionsumgebung gleich aufzusetzen.
Wenn möglich, sollte identische Hard- und Softwarekonfigurationen eingesetzt werden.
Häufig ist dies aus Kostengründen nicht möglich. Dann muss man wenigstens versuchen so nah wie möglich an die Produktionsumgebung heranzukommen.
Bei der Entwicklungsumgebung sollte wenigstens der gleiche Softwarestack eingesetzt werden. Die Entwickler arbeiten dann mit den gleichen Tools, die später in der Produktion eingesetzt werden. Somit können Unterschiede und Problemstellungen schon während der Entwicklung erkannt werden.
Ein Mix von Komponenten sollte, wenn möglich, immer vermieden werden.

Ähnliche Beiträge

Eine Vorgehensweise: Betriebsmitarbeiter arbeiten von Anfang an mit

Wie wollten schon während der Design Phase so viel wie möglich von unseren Betriebsmitarbeitern einbringen.
Sie sollten lernen, verstehen und ihre Erfahrungen einbringen.

Vorteile

• Produktionsprobleme können gleich während des Designs erkannt und verhindert werden
• Mitarbeiter fühlen sich ernst genommen
• Mitarbeiter wissen was auf sie zukommt
• Arbeitsprozesse sind von Anfang an klar. Lücken bekannt.

Nachteile

• Mitarbeiter sind im Projekt eingebunden und fehlen im täglichen Betrieb
• Projekt wird gebremst, da mehr Anforderungen aus dem Betrieb einfliessen
• Gefahr dass sich die Mitarbeiter im Projekt verzetteln
• Akzeptanz im Projekt bei Teammitgliedern nicht gegeben

Ok, eventuell sind die Nachteile an den Haaren herangezogen, doch kann man nicht leugnen, dass die Mitarbeiter während des Projektes nicht an ihren normalen Aufgaben arbeiten können.

Neue Vorgehensweise: Probleme werden parallel zum Projekt gelöst

Das Projekt hat einen klaren Auftrag und kann ihn ohne Zutun des Betriebs lösen.
Dementsprechend kann es Sinn ergeben, dass das Projekt so schnell wie möglich und mit so wenig Overhead wie möglich durchgeführt wird.
Die anfallenden Probleme werden in einem Clean Up Prozess neben dem Projekt korrigiert.
Dort sind die Betriebsmitarbeiter integriert und können ihre Problemstellungen als Kunde äussern.

Vorteile dieser Lösung

• Das Projekt läuft mit wenig zusätzlichen Anforderungen durch und kann seine Ziele erreichen
• Klare Abgrenzung zwischen Bau und Betrieb
• Mitarbeiter vom Betrieb fehlen nicht bei den täglichen Problemstellungen
• Politisch gesehen eine sehr angenehme Art Projekte durchzuführen, da die Aufgaben sauber verteilt sind.

Nachteile

• Fehler im Design werden erst im Betrieb gefunden und erzeugen hohe Reparaturkosten
• Betriebsmitarbeiter müssen hinterher geschult werden
• Höhere Betriebsaufwände wegen nicht erkannter Schwachstellen
• Betriebsmitarbeiter fühlen sich nicht ernst genommen

Was nun?

Das gute ist, dass auch hier die unterschiedlichen Vorgehensweisen zum Ziel führen können.
Das Unangenehme ist, dass man vor einem Projekt nie weiss, welche Lösung besser zum Ziel führt.
Man weiss sogar nicht, ob die andere Vorgehensweise besser gewesen war. Man hat es ja nicht durchgeführt.
Schön finde ich, dass beide Varianten mögliche Lösungen im Lösungsraum darstellen. So bleibt das Leben wenigstens spannend

Ähnliche Beiträge

Umfang des Capacity Managements

Mit dem Capacity Management im Service Design Umfeld werden folgende Aufgaben bearbeitet:

• Mit den Kunden sprechen und dem Kunden seine Bedürfnisse ermitteln
• Die erkannten Anforderungen in die Planung der Systemauslastung umsetzen
• Kontrolle ob die erforderlichen Ressourcen (Maschinen, Mitarbeiter) überhaupt in der Firma vorhanden sind
• Erstellung des Kapazitätsplanes
• Überwachung durchführen und Feinabstimmungen vornehmen

Am letzten Punkt kann man wieder mal schön erkennen, dass ITIL V3 sich von seinen Vorgängern unterscheidet.
Die Überwachung und die Feinabstimmung ist definitiv eine operative Tätigkeit.
Diese wird jedoch im Capacity Management auf der Service Design Seite definiert.
Es ergibt Sinn, dass die Veränderungen und die Überwachung von einem Prozess abgedeckt wird.
Ein Prozess ist schliesslich ein Regelkreis und keine Steuerung.
Er hat Rückführungen.
An diesen Stellen bin ich mit ITIL V3 so richtig glücklich, da man hiermit die Grenzen zwischen Engineering und Betrieb verwischt.
Die Gefahren, dass am Ende ein Entwickler in der Produktion herumfummelt, sind relativ gering, da die einzelnen Rollen schlussendlich wieder auf unterschiedliche Teams aufgeteilt werden können.

Ähnliche Beiträge

• Wieso ist der so teuer?
• Wieso ist der so langsam?
• Warum ist der nicht verfügbar?
• Ich habe aber erwartet, dass…

Wenn der Service im Betrieb ist, muss das Service Level Management kontrollieren ob alle Service Level Agreements wirklich eingehalten werden.
Weiterhin muss das Service Level Management jederzeit kontrollieren, was man am Service besser machen kann.
Dazu muss er mit dem Kunden sprechen und fragen, was dieser von ihm alles erwartet.
Wenn du seit 5 Jahren immer den gleichen Service zu deinen Kunden lieferst kann es ansonsten passieren, dass deine Kunden nicht mehr zufrieden sind.
Stell dir vor dein Telekomprovider verkauft dir nur ein 56k Modem anstatt DSL. Bleibst du bei diesem Provider?

Konkrete Aufgaben des Service Level Management

Der Service Level Manager muss folgende Aufgaben abwickeln:

• Kundenbeziehungen aufbauen
• Mit Kunden über SLA verhandeln
• Monitoren und erstellen der notwendigen Berichte
• Ständiges verbessern des Services, mit planen und durchführen der notwendigen Änderungen
• Mit dem Kunden bei Review Meetings über die aktuelle SLA Einhaltung sprechen
• Erarbeiten von notwendigen OLAs für andere Organisationseinheiten
• Erarbeiten und Pflege von Unterpinning Contracts für weitere Zulieferer

Ähnliche Beiträge

Was macht das Service Catalogue Management?

Es kümmert sich darum dass die Services, die im Lauf der Zeit innerhalb der Firma erstellt werden, immer sauber beschrieben sind.
Wenn also eine Änderung an unserem Telefon stattfindet, z.B. eine Applikation hinzukommt mit der wir Twittern können, dann wird dies im Service Catalogue eingetragen.
Es wird hiermit sichergestellt, dass wir nichts vergessen was unsere Firma so anbietet.
Im Service Catalogue werden nur die Services angeboten, die tatsächlich vom Kunden bezogen werden können.
Im Gegensatz dazu beinhaltet das Service Portfolio auch Services die wir noch nicht anbieten oder die wir nicht mehr anbieten.
Mit diesem Prozess kann innerhalb der Organisation das Bewusstein aufgebaut werden

• Welche Services werden dem Kunden geliefert?
• Wie werden diese Services geliefert und wie können sie vom Kunden genutzt werden?
• Welches Qualitätsniveau kann der Kunde erwarten?
• Welcher Zweck hat dieser Service?

Insgesamt kann das Service Catalogue Management helfen die Qualität der angebotenen Services zu erhöhen.

Ähnliche Beiträge

Ähnliche Beiträge

Service Portfolio Management

Mit diesem ITIL Prozess soll erreicht werden, dass der richtige Mix von Services dem Kunden angeboten werden.
Die Geschäftsleitung muss festlegen, welche Produkte die nächsten Jahre auf dem Markt kommen und dort bleiben.
Diese Entscheidung hat natürlich direkte Auswirkungen auf die Produktion.
Wenn z.B. ein Internet Service Provider festlegt, ab 2010 nur noch Ubuntu Linux anzubieten, dann muss der Betrieb dies entsprechend vorbereiten.
Die Entscheidung, welche Strategie gefahren wird, wird in kurzfristige (taktische) oder langfristige (Strategie) Entscheidungen festgelegt.
All diese Überlegungen und Ziele werden in diesem Bereich festgelegt.
Wenn dir zufällig eine Firma gehört, wirst du mit diesem Prozess festlegen, welche Dinge du deinem Kunden anbieten willst.

Finance Management

Es ist ja schön, wenn unsere Strategen festlegen, dass wir nur noch Ubuntu anbieten.
Wenn aber die Kunden abspringen, da wir eigentlich eine Windows-Bude sind, ist das sicherlich nicht gerade hilfreich.
Informationen über den tatsächlichen Absatz und die daraus abzuleitenden Gewinne wird vom Finance Management geliefert.
Weiterhin kann festgestellt werden, ob wir überhaupt in der Lage sind, neue Produkte auf den Markt zu werfen.
Es ist daher sinnvoll, wenn das “Finanzministerium” in der Service Strategy mitsprechen kann.
Ohne eine solide Finanzierung läuft in einer Firma nunmal nichts.

Demand Management

Gegenüber früheren ITIL Versionen hat sich die Position des Demand Managements verändert.
Mit dem Demand Management wird die Information, welche Services unsere Kunden kaufen, gesammelt.
Deshalb ist es sinnvoll, wenn das Demand Management sehr nah an der Service Strategy angesiedelt ist.
Die Geschäftsleitung sollte permanent darüber im Bilde sein, welche Produkte und Services von den Kunden gewünscht werden.
Weiterhin kann im Demand Management ein Trendverhalten der Kunden festgestellt werden.
Wenn unsere Kunden tatsächlich nur Ubuntu bestellen, wäre es sinnfrei wenn wir blos Windows anbieten gelle?

Zusammenfassung

Mit den drei Prozessen der Service Strategy Kategorie werden die für den Betrieb notwendigen strategischen Entscheidungen gefällt und verwaltet.
Die Service Strategy hat Verbindungen zu allen anderen Hauptkategorien, da eine Strategie sich durch den täglichen Betrieb ändern kann und muss.

Ähnliche Beiträge

Das Statement das gegen ITIL Prozesse spricht

Bist du mal in einer Helpdesk (Service Desk) Telefonwarteschleife gehängt?
Hast du mal dein Problem dem netten Menschen des Service Desks geschildert, um dann zwei Stunden später das gleiche Problem wieder beim Second Level Support zu schildern?
Soll ich noch mehr retorische Fragen stellen?
Ich denke mal, die meisten von uns haben schon Probleme mit den schlechten Supports von diversen Firmen gehabt.
Wenn man also einen 1st Level Support aufbaut und die Probleme der Kundschaft damit eigentlich nur verschlimmert, hat man nichts gewonnen.
Stimmt das so?

Das Statement für ITIL Prozesse

Falls du das Glück, oder das Pech, hast im Second Level zu arbeiten, kann es passieren dass deine Anwender dich direkt anrufen.
Du bist ja ein hilfsbereiter Mensch und kannst die Probleme deiner Anwender meistens sofort lösen.
Der Anwender ist glücklich und du hast einen guten Job gemacht.
Häufig umgehen die Anwender die Supportprozesse, da ihnen ja deutlich schneller geholfen wird.
Dem Anwender wird geholfen, du hast eine gutes Gefühl da deine Anwender glücklich sind und trotzdem bin ich nicht zufrieden.

Ist dein Chef mit dir zufrieden?

Kennst du die Situation dass dein Chef dir noch mehr Arbeit geben will?
Wenn nicht dein Chef dann vielleicht dein Chef-Chef?
Die Chefs messen die Auslastung der Mitarbeiter an gebuchten Stunden oder anderen Messgrössen.
Wenn wieder mal eine Sparübung angesagt ist, muss jeder Mitarbeiter begründen können, warum er benötigt wird und was er den ganzen Tag über macht.
Häufig finden sich dann freundliche Second Level Supporter ziemlich unter Druck gesetzt.
Wenn du, ohne die Zeiten aufzuschreiben, jedem Anwender hilfst, dann machst du das ohne Auftrag.
Und ohne Auftrag bedeutet, dass dein Chef diese Leistungen nicht verrechnen kann.
Es gab schon Handwerksbetriebe, die ihre Aufwände nicht mehr decken konnten, da sie zu viele “Freundlichkeitsaufträge” nebenbei gemacht haben.

Wenn du deine Anwenderhilfe nicht buchen kannst, gibts kein Geld dafür

So hart wie es klingt, aber die Anwender sind nicht deine Kunden.
Dein Kunde bezahlt für deine Arbeit.
Die Mitarbeiter deines Kunden bezahlen dich nicht.
Wenn ein Kunde im 1st Level Support anruft, wird registriert wie viel Aufwand für die Lösung des Problems entstanden ist.
Bei den nächsten Verhandlungen kann ein übermässiger Gebrauch der Hotline entsprechend verrechnet werden.
Wenn deine Firma jedoch nicht weiss, dass du vielen Anwendern geholfen hast, dann ist dein Job in Gefahr.
Plötzlich wirst du gefragt “Warum haben Sie eigentlich nur 30% Auslastung? Sie können doch noch diesen Job übernehmen!”
Und dann beginnt für dich die Zeit, in der du deutlich mehr arbeiten musst, die Leute mit dir unzufrieden sind und du den Job nicht mehr gut findest.

Prozesse einhalten kann beruhigen

Wenn du bei einer grossen Firma arbeitest, und z.B. im 1st Level Support jeden Tag 4’000 Calls bearbeitet werden, von denen 3’800 gleich gelöst werden, dann ist deine Firma effektiv.
Deine Firma hat die Aufwände im Griff und kann jederzeit feststellen warum der Support so viel kostet.
Wenn die Dunkelziffer der gelösten Anwenderprobleme nicht bekannt ist, dann können die Systeme nicht optimiert werden.

Nur messbare Prozesse können optimiert werden

Stell dir vor, jeden Tag ruft ein Anwender an und du löst ihm das Problem innerhalb von 20 Minuten.
Rechne diese Zeit mal auf ein Jahr hoch.
Du wirst eine relativ hohe Zahl finden.
Wenn ein anderer Anwender deinem Kollegen die gleiche Aufgabe gibt, dann werden die Kosten noch höher.
Eventuell kann jedoch dieses Problem für alle gelöst werden.
Wenn Continual Service Improvement etabliert ist, können die Kollegen beschreiben wie das Problem langfristig gelöst werden kann.
Oder aber das Problem Management kann sich diesem Thema annehmen.
Und dann fällt diese Arbeit weg, der Anwender bekommt dieses Problem erst gar nicht mehr und spürt die Infrastruktur nicht.

Fazit

Firmen müssen ihre Kosten im Griff haben. Um dies zu erreichen müssen sie die Probleme innerhalb ihrer Firma erkennen und bereit sein sie zu lösen.
Wenn dem so ist, können Firmen kostengünstigere, schnellere und stabilere Services anbieten.
Um dieses Ziel zu erreichen ist es sinnvoll, die Prozesswege einzuhalten.

Wenn jedoch die Mitarbeiter und Chefs sich hinter den Prozessen verstecken wird ein gut gemeinter Gedanke, wie ITIL einer ist, schnell zu einem Beamtenmolloch.

Ähnliche Beiträge

• Was wollen wir mit unserem Betrieb überhaupt anfangen?
• Wie bekommen wir unsere Kundenanforderungen geordnet in unsere Betriebsabläufe integriert?
• Wie managen wir unsere Finanzen?
• Wie legen wir fest, welche Services wir anbieten?
• Wie verändern wir unsere Services?
• Wie können wir nach einer Katastrophe weiter existieren
• Wie verfügbar muss unser Service sein?
• Welche Sicherheitskriterien muss unser Service erfüllen?
• Wie managen wir unsere Zulieferunternehmen?
• Wie nehmen wir die Anforderungen auf?
• Wie verwalten wir unsere Daten?
• Wie und wer managed unsere Applikationen?
• Wie bekommen wir unsere Applikationen in den Betrieb überführt?
• Wie führen wir Änderungen an den Systemen durch?
• Wie stellen wir fest welche Komponenten wir miteinander in Betrieb haben?
• Wie wollen wir Releases durchführen?
• Was für Tests wollen wir für die einzelnen Applikationen und Komponenten durchführen?
• Wie sorgen wir dafür, dass wir genügend Wissen über unsere Systeme in der Firma halten können?
• Wie erkennen wir, wenn eine Festplatte volläuft?
• Wie verhalten wir uns bei einer Störung?
• Wie sorgen wir dafür, dass eine Anfrage den Toner an einem Drucker auszutauschen, gemacht wird?
• Wie sorgen wir dafür, dass erkannte Probleme auch analysiert und nachhaltig geklärt werden?
• Welche Mitarbeiter und Kunden dürfen wie auf unsere Systeme zugreifen?
• Wo können Mitarbeiter und Kunden zentral anrufen und ihre Probleme schildern?
• Wie verwalten wir unser technisches Wissen?
• Haben wir genügend Mitarbeiter und Systeme für die Erbringung unserer Services?
• Können wir unsere Infrastruktur und Teams effizient und effektiv managen?
• Wissen wir, wie wir unsere Applikationen im Betrieb halten können?
• Wie kann man dafür sorgen, dass der Betrieb über die Jahre besser wird?

Das ist schon eine ganze Menge an Fragen gelle?
Damit sich die unterschiedlichen Themengebiete ordnen lassen, muss man die hierfür notwendigen Prozesse und Funktionen irgendwie ordnen.
Bei ITIL hat man hierfür fünf Hauptkategorien definiert.

Service Strategy

Kümmert sich um die Themen Service Portfolio, Fincance Management und Demand Management.
Hier werden alle strategischen Überlegungen und Entscheide festgelegt.

Service Design

Diese Kategorie kümmert sich um die Überlegungen wie ein neuer, oder bestehender, Service erstellt und angepasst wird. Welche Applikationen dafür notwendig sind und wie man sie umsetzt.

Service Transition

Wenn die netten Menschen vom Service Design ihre Systeme fertiggestellt haben, müssen sie irgendwie in die Produktion übergeben werden. Ansonsten können unsere lieben Kunden ja die erstellten Systeme nicht verwenden.
Serice Transition kümmert sich exakt um dieses Thema.

Service Operation

Hier werden alle Themen, die für einen geordneten Betrieb benötigt werden, untergebracht.
Wenn eine Störung auftritt, wird sie dort korrigiert. Wenn ein neuer Anwender erfasst werden soll, ist hier der notwendige Prozess dafür hinterlegt.

Continual Service Improvement

Wir haben zwar unsere Services in Betrieb, aber müssen die wirklich so kompliziert sein?
Die Software und Hardware entwickelt sich weiter. Es ergibt keinen Sinn, die Systeme so komplex bestehen zu lassen, wie sie heute sind.
Der Betrieb muss sich permanent weiterentwickeln.
Hierfür wird das Continual Service Improvement verwendet. Die Prozesse und Kollegen kümmern sich darum, dass die Unternehmung stabil bleibt und weiterkommt.

Ähnliche Beiträge