Ratgeber zum Erreichen Ihrer Ziele

Erfolgreich kommunizieren in der IT

Dr. Torsten Langner ist Sr. Business Development & Sales Manager für das Thema Platform as a Service (PaaS) in der Digital Division der T-Systems. Vorherige Stationen waren u. a. Enterprise Architekt und Technology Category Lead Incubation Sales bei Microsoft sowie Senior Architect Financial Services bei IBM Platform Computing.
Um Ziele zu erreichen, genügt es nicht nur die richtigen Kollegen mit ins Boot zu holen. Auch die Art und Weise der Ansprache ist von Bedeutung. Dieser Artikel gibt Ihnen hilfreiche Beispiele.
Die Problematik des Alltags ist, dass die Kommunikation zwischen IT'lern in der Regel nur die technische Ebene adressiert. Derjenige, der Entscheidungen für oder gegen Technik treffen muss, benötigt meistens einen Übersetzter, der ihm ganz einfach erklärt, warum dieses Vorhaben gut für das Unternehmen, ist.
Die Problematik des Alltags ist, dass die Kommunikation zwischen IT'lern in der Regel nur die technische Ebene adressiert. Derjenige, der Entscheidungen für oder gegen Technik treffen muss, benötigt meistens einen Übersetzter, der ihm ganz einfach erklärt, warum dieses Vorhaben gut für das Unternehmen, ist.
Foto: lassedesignen - Fotolia.com

Stellen Sie Sich vor: Sie wollen Innovationen einführen und müssen in Ihrem Unternehmen etwas verändern. Doch Sie treffen mit hoher Wahrscheinlichkeit auf eine resistente Organisation. Wie können Sie dennoch Ihr Auditorium davon überzeugen, Sie bei Ihrem Vorhaben zu unterstützen und die Veränderung anzugehen? Alles beginnt mit erfolgreicher Kommunikation. Abgesehen von einigen IT Administratoren und Programmierern besteht die Hauptarbeitszeit eines IT Mitarbeiters darin, mit Menschen zu kommunizieren: Man schreibt E-Mails, liest E-Mails, telefoniert, sitzt in Meetings oder nimmt an Webkonferenzen teil. Die reine Technik nimmt nur geschätzte zehn Prozent der Arbeitszeit in Anspruch.

Kafkaeske IT

Wäre Franz Kafka nicht 1883 sondern 1983 geboren worden, hätte er sicherlich etwas über die Wirren der IT verfasst. Denn: in der IT erinnert Manches an anonyme und bürokratische Mächte, deren Absurdität und Sinnlosigkeit oftmals Ihresgleichen suchen. Zudem trifft man heutzutage auf:

  • Vorstudien, die niemals in einer Realisierung enden,

  • Meetings, die jemand einberuft und bei denen man sich fragt, welchen Nutzen sie stiften,

  • E-Mails, die unendlich lang sind, die man gar nicht zu Ende liest und die an die halbe Firma adressiert sind,

  • Konversationen, bei denen jemand behauptet, man müsse endlich handeln - aber warum man handeln sollte ist nicht transparent

Und Sie sind mittendrin. Doch wie kommt so etwas zustande? Es geschieht definitiv nicht absichtlich. Es ist vielmehr das Resultat großer Hierarchien mit vielen unterschiedlichen Zielen. Und je größer das Unternehmen, desto undurchsichtiger wird das Einzelne.

Software Defined Infrastructure in Deutschland 2016

Software Defined Infrastructure in Deutschland 2016

Software Defined Infrastructure (SDI) hilft Ihnen IT-Ressourcen kosteneffizienter und flexibler zu nutzen.
Weitere Vorteile und eine Roadmap zur SDI laut IDC erfahren Sie in dieser Studie.

Dies ist kein rein deutsches Phänomen. In einem Vortrag erzählte Ferry Heilemann einmal, wie agil die Organisation rund um das Berliner Startup DailyDeal war - bis es von Google übernommen wurde. Der Konzern hat sprichwörtlich die Handbremse anzogen, indem er die Entscheidungswege hierarchischer und intransparenter machte. Am Ende der Geschichte kauften die Gründer das Unternehmen von Google wieder zurück, da die Gefahr bestand, dass Google DailyDeal abwickeln könnte.

Ein typisches Beispiel aus Kafkas IT

Zuvor haben wir gesagt, dass alles mit erfolgreicher Kommunikation beginnt. Schauen wir uns nun dieses fiktive Beispiel an, das zunächst zeigt, wie Kommunikation nicht erfolgreich verläuft:

Nehmen wir an, Ihr Unternehmen hat vor zwei Jahren einen Vertrag mit der Firma SuperConservative&More abgeschlossen. Sie müssen sicherstellen, dass das E-Mail System reibungslos funktioniert.
Es kommt zum Ausfall. Die Emotionen schlagen hoch. Gemäß ITIL Incident (= INM), Problem (= PRM) und Change (= CHM) wird alles unter die Lupe genommen. Nach vier Tagen gibt es den Verbesserungsvorschlag von den Kollegen. Sie trauen dem Braten nicht und haken nach. Sie laden zum Workshop mit den Experten ein. Erschreckender Weise stellen Sie fest, dass einige Teilnehmer angeben, schon vor sieben Monaten davor gewarnt zu haben. Die Gründe und eine mögliche Lösung wurden auch bereits damals erkannt.

Sie wissen nun, dass eigentlich etwas viel, viel Wichtigeres verändert werden müsste. Eine Entscheidung muss her. Sie schreiben eine Zusammenfassung Ihrer Erkenntnisse in einer ganz, ganz langen E-Mail an die Entscheidungsebene (10 Personen):

Sehr geehrte Kolleginnen und Kollegen,
auf Grund des großen Ausfalls bei unserem Kunden SuperConservative&More haben sich die Herren Müller, Maier, Schmitz und ich letzte Woche zusammengesetzt, um über proaktive Maßnahmen der Verbesserung der Servicequalität zu diskutieren.
Hierbei haben wir überlegt, wie der Service heute und zukünftig verbessert werden kann. Wir haben im Rahmen eines Brainstormings herausgefunden, dass eine E2E Monitoring Initiative, die initiiert, aber vor gut 5 Monaten wieder eingestellt wurde, uns dabei helfen wird, ausfallende Komponenten wie beispielsweise den Cisco Router 7200 schneller zu identifizieren […] Insbesondere die Zusammenarbeit der Bereiche SSE und GED müssen hierbei verbessert werden, da die LIM und SDM Kandidaten immer wechseln. Wir brauchen darüber hinaus auch Change-Approvals bei PL-übergreifenden Emergency Changes.[…]
Ich möchte Sie bitten, dieses Vorhaben zu unterstützen.

Inhalt dieses Artikels