Processes without people – Hope springs eternal

Ages ago I started my career in the Unix company with the nice logo. In transition projects when Windows infrastructure was changed to Unix, there was a golden rule: Find new jobs for the old administrators – a good inter company choice was the client environment. The reason is simple, it takes a lot of training and time to become familiar with a different architecture and learn about new approaches. In other words: If you try to re-educate existing staff, there is a high chance that the “everything used to be better” minded will win the game by time.

[Link to German version]

Dear reader, feel free to flip the place-holders “Windows” and “Unix” or substitute them by any other things that are different in concept and you’ve a general rule.

Let us use the place-holders “historical IT operational sequences” and “operations guided by ITIL® practices” in this article. The astonishing fact about this flavour of the general rule is: There are people out in IT industry who believe that something like this can work satisfyingly.

We use the example of a certain IT department, which is according to industry benchmark too rich staffed. The results of this department are not good, but tolerable in quality, using a lot of overtime work. This example is not completely unfounded, such set-ups can be easily found. Take a look at established internal IT organizations who did the usual mistake negotiating special terms with a lot of internal customers. All these special agreements weaved to a thick complex network, that is operated manually and eats a lot of resources. From a corporate perspective, usually without any deeper reason or benefit.

In fact such a situation is perfect to structure everything towards ITIL. A project could implement and standardize internal agreements (OLAs) which ensure that extra-services are only carried out against extra-money. A change management could take care to focus and prioritize changes. The formerly too rich department would be enabled to separate important from unimportant things using a business perspective. After standardization, change requests will be professionally evaluated, communicated and implemented. Something like this can work and will save a lot of money in the end.

In such situations I often notice that the old team is almost not supported. A consultant explained them ITIL upfront in a three sessions course, even sometimes including the necessary changes in correctly amended detail. Taken the short time into account – means no time to think – the team understands: “They want to bother us, the consultant understands not a single bit of our business needs; and oh, god, we will get an extra burden of bureaucracy!” Depending on the behaviour of the management team, usual after initial defensive battles of the team in which management just gets the “everything used to be better” attitude, management switches to high pressure mode and cuts headcount.

The reaction of the old team, that still does not gets the meaning and benefits of industrialization and good practices, will start to play a role, e.g. masquerades a process flow that makes no sense. In reality, they do their old job. But now much worse, with fewer resources and supporting this extra “process” bureaucracy. Such “ITIL implementation” becomes ludicrous when there is a high 6-digit budget for the design, but almost no money left for implementation and management decides to assign this task to the old teams and who apparently get nothing more than some material to read.

I always wonder, what is the mindset of people who want develop service management using this approach. Essentially this is as worse as sending initially mentioned Windows administrators to a short Unix training. With the next problem popping up this short trained guys are clueless. To build a bridge from problem to solution was a no brainer for those guys in their familiar environment, because the solved similar cases in the past. Now with the new technology everything seems to be difficult and unmanageable. No one understands why managements goes for this stupid Unix. (Again feel free to interchange “Windows” by “Unix” administrators).

The missing knowledge to bridge a gap applies as is also for operating processes: the well known evolved processes are familiar, in an ITIL world a way walking along the accepted practices is unknown and hard to find.

The reason is familiarisation and can be observed by the example of a new employee in the old department structures: In the first working days the new employees will realize the existing procedures as complex, confusing and he finds the need of improvement obvious. After half a year he gets along quite well in the chaos and the impression of complicated will start to dissolve. After a year he will already be absorbed in the processes and all his initial suggestions to improve the mess are refused as too simple, because by his current knowledge all suggestions do not reflect all the different special rules of each internal customer.

My finding is: In existing structures only a few people are able switch to an abstraction level that enables them to map the existing to a new system. One key to success is to find and utilize those employees to communicate with ITIL experienced staff or consultants. You will need them to leverage solutions until the major part (e.g. 80%) of the problems were solved by alternatives. Beware those alternatives, are developed by experts of the new system. A Windows administrator is not able to develop a Unix-style solution. When the architects of the old system develop the new solution, you will get the worst of both worlds. Basically a concept of the ancient world, with a lot of whopping and tinker to be amended to the new world.

My letter to the protectors of the budget, if there is no budget for implementation available, please wait for the next fiscal year. Delay is a far better idea, than the abuse of the old team plus some prayers for a miracle.

Last note: Initial general rule is in general not commutative. People who are used to higher maturity, can easily manage lower maturity structures. This is a usual smack in corporate acquisitions. Nevertheless there is a direct link to higher attrition if such simple structured operations become the main task of senior employees.

Issue: Incident and Problem

ITIL® provides a set of good practices which is a kind of general direction. In ITIL there are processes and roles that need to be provided. How exactly is a matter of the individual organization. In the ITIL books you will also find remarks, anecdotes or even sometimes (inappropriate) generalizations that give a good indication of how processes and functions are implemented in reality. A very common question of ITIL beginners is, how an incident becomes a problem. The short answer is: „Never“. The full answer is as follows …

[Link to German version]

„Issue: Incident and Problem“ weiterlesen

Die Geschichte der Availability ist eine Geschichte voller Mißverständnisse

Es gibt leider mehr IT Abteilungen als man denkt die wesentliche Leistungsmerkmale ihrer Dienste gar nicht beschreiben oder steuern. In ITIL®-Sprache fehlt das managen von OLAs (Operational Level Agreements) im Service Level Management. Die Einführung interner SLAs oder eben OLAs funktioniert bei der richtigen Vorgehensweise bis zu einem gewissen Punkt ganz gut. Werteinschätzung oder auch technische Aspekte wie „ein Service der Klasse 1 muss ein tägliches Backup haben“ sind schnell vermittelt. Erstaunlicherweise kommt es bei dem Thema Verfügbarkeit (Availabilty) immer zu wundersamen Missverständnissen. Woran das liegt? Meist Mangel an Erfahrung und Wissen über die Eigenschaften der eigenen Systeme. „Die Geschichte der Availability ist eine Geschichte voller Mißverständnisse“ weiterlesen

Prozesse ohne Leute – Die Hoffnung stirbt zuletzt

Vor Urzeiten habe ich mal bei einer Unix-Firma, die mit dem schönen Logo, angefangen. Bei Konsolidierungsprojekten in denen Windows-Infrastruktur gegen Unix ausgetauscht wurde, galt immer die goldene Regel: Seht zu dass ihr für die alten Administratoren andere Jobs besorgt zum Beispiel im Client-Umfeld. Denn es braucht viel Zeit sich auf andere Herangehensweise, andere Architektur zu gewöhnen und nur allzu leicht gewinnt die „Früher war alles besser“-Fraktion die Oberhand. Dem freundlichen Leser sei es freigestellt für die Platzhalter „Windows“ und „Unix“ zu tauschen oder beliebige andere Dinge einzusetzen, die vom Konzept her unterschiedlich sind und schon hat man eine allgemein gültige Regel. „Prozesse ohne Leute – Die Hoffnung stirbt zuletzt“ weiterlesen

Kategorienbaum: Weglassen und Flexibel bleiben

Bei Einführung, Umstrukturierung oder Effizienzsteigerung von IT Service Management haben heutzutage schon viele Firmen ein ITSM Tool aka Ticket Tool. Nehmen wir als  Beispiel für eine anstehende Veränderung Outsourcing einiger IT Services. Bei den meisten Firmen führt das Hinzufügen von Services oder Providern zu einem neuen Ast im Kategorienbaum und einigen neuen Blüten, die sich im Laufe der nächsten Monate in veritable Blätter ausdehnen.

Der vernünftige Umgang mit einem Kategorienbaum ist eigentlich auch nur ein Beispiel für den vernünftigen Umgang mit Funktionen zur Verwaltung von Ordnung. Starten die Verantwortlichen nicht ab und zu Mal ihren Hubschrauber und betrachten den schützenswerten Informationsgewinn von oben, kommt es zur Zunahme von Entropie. Statt Komplexität nach Belieben zuzulassen und somit im Praxiseinsatz Unordnung und Verwirrung zu schaffen, gilt hier die Regel: Erst wenn nichts mehr weggelassen werden kann ist es perfekt. „Kategorienbaum: Weglassen und Flexibel bleiben“ weiterlesen