Kategorie: Transformation

Wo sind die ITler hin? Zu ChatGPT??

Daemonic Coder

„Aus Gründen“(tm) beschäftige ich mich gerade mit dem IT Stellenmarkt… War es vor ein paar Jahren noch ziemlich problemlos möglich, im Bereich IT, Transformation und Agilität offene Stellen zu finden, so ist dies derzeit etwas schwieriger. Und immer wieder liest man von Unternehmen, die große Mengen an Stellen abbauen.

Die aktuelle Welle an Stellenstreichungen im IT-Bereich wird oft mit einem einfachen Argument begründet: Künstliche Intelligenz übernimmt Aufgaben, also braucht es weniger IT-Fachkräfte. Klatr, warum irgendwelche Junior-Entwickler, wenn Chat GPT das doch auch gut kann, das Entwickeln. Klingt logisch – ist aber nur die halbe Wahrheit. Denn wer mehr IT in einem Unternehmen will, braucht in der Regel auch mehr IT-Expertise, nicht weniger.Von ChatGPT ausgespuckter Code ist oft nicht fehlerfrei und insbesondere nicht automatisch in der IT-Landschaft deployed.

Gleichzeitig ist es jedoch nicht von der Hand zu weisen, dass viele Unternehmen in den letzten Jahrzehnten massive Overhead-Strukturen aufgebaut haben, die nun auf den Prüfstand kommen.

AI ersetzt IT? Nicht so schnell.

Die Vorstellung, dass AI-gestützte Tools die Entwickler, Systemadministratoren oder Architekten ersetzen, ist verlockend – aber kurzsichtig. Automatisierung kann Prozesse effizienter machen, aber sie schafft auch neue Herausforderungen:

  • Mehr IT bedeutet mehr Komplexität: Systeme müssen integriert, gewartet und angepasst werden. Automatisierung nimmt Routineaufgaben ab, aber jemand muss die Werkzeuge implementieren und weiterentwickeln.
  • AI produziert keinen Wert von selbst: Code, den AI generiert, muss überprüft, getestet und gewartet werden. Und je mehr Unternehmen sich auf generative AI verlassen, desto wichtiger wird die menschliche Expertise, um Fehlentscheidungen oder ineffiziente Lösungen zu vermeiden.
  • Neue Technologien bringen neue Sicherheitsrisiken: Mit der steigenden Automatisierung wächst auch die Angriffsfläche für Cyberangriffe. Unternehmen, die IT automatisieren, müssen gleichzeitig in Sicherheit und Governance investieren. Und wie wohl man sich mit dem Datenschutz fühlt, davon möchte ich gar nicht erst anfangen.

Das eigentliche Problem: Overhead und „Bullshit Jobs“

Trotzdem ist es nicht falsch, dass viele Unternehmen aktuell aufgeblähte Strukturen abbauen. David Graeber beschreibt in seinem Buch Bullshit Jobs, wie viele Organisationen im Laufe der Zeit Stellen schaffen, die wenig bis gar keinen direkten Wert erzeugen – oft im Bereich Management, Controlling oder interner Prozesse.

IT-Teams sind oft von solchen Strukturen betroffen. Je größer ein Unternehmen wird, desto mehr Layer an Projektmanagement, Koordination und Verwaltung entstehen. Plötzlich gibt es mehr Meetings als Codezeilen, und Entwickler verbringen mehr Zeit mit Excel-Reports als mit der eigentlichen Softwareentwicklung. Ich selbst habe in den letzten Jahren sicher mehr Powerpoint-Folien erstellt als „echte“ Architekturen. Dass Unternehmen diese Strukturen nun in Frage stellen, ist nicht falsch, streng genommen sogar zu spät.

Der richtige Fokus: IT als Werttreiber, nicht als Kostenfaktor

Anstatt einfach nur IT-Stellen zu streichen, sollten Unternehmen sich fragen: Wie kann IT zum Wachstum beitragen? Der Fokus sollte nicht auf der Reduktion von IT-Mitarbeitern liegen, sondern auf der Beseitigung von bürokratischen Hürden, die die Arbeit der IT-Teams ineffizient machen.

Effiziente IT bedeutet:

  • Reduktion unnötiger administrativer Aufgaben
  • Klare Fokussierung auf wertstiftende Arbeit
  • Sinnvolle Nutzung von AI als Unterstützung, nicht als Ersatz

IT ist heute das Rückgrat fast aller Geschäftsmodelle. Wer hier vorschnell den Rotstift ansetzt, könnte langfristig eine Schwächung des Unternehmens riskieren – und genau das Gegenteil von dem erreichen, was man eigentlich will: Effizienz.

Holokratie – Taylorismus 2.0?

Daemonic Coder

Winslow Taylor gilt als der Erfinder des „Scientific Management“ mit der Idee, die Arbeitsabläufe eines Unternehmens vollständig zu beschreiben und so „perfekte“ Abläufe schaffen zu können. Und er gilt heute beinahe schon als Feindbild der agilen Unternehmen, da seine Ideen als hierarchisch und starr wahrgenommen werden. Und zugegebenermaßen waren seine Ideen Grundlage für eine gewisse Dehumanisierung in der Arbeitswelt. Aber: Das ist meist gar nicht die hauptsächliche Kritik am Taylorismus aus Sicht Agiler Transformationscoaches. Diese merken eher an, dass es in der komplexen Arbeitswelt nicht möglich sei, eine exakte, immer gültige Arbeitsaufteilung vorzugeben. Softwareentwicklung beispielsweise funktioniert nicht „wie am Fließband“.

Dem stimme ich übrigens uneingeschränkt zu.

Um so mehr wundert mich der Zuspruch, den Holokratie oft erfährt. Ich möchte hier nicht Holokratie beschreiben, das ist sicher an anderer Stelle ausführlich genug geschehen, nur meine Kritik oder Verwunderung daran formulieren: Die Idee von Holokratie ist es, dass es ein „Betriebssystem“ ist, das eine Beschreibung „perfekter“ Abläufe hervorbringen kann. Sicher, im Unterschied zum Taylorismus wird diese Beschreibung kollaborativ und nicht vom „allwissenden Management“ erzeugt, aber nichts desto trotz ist das Ziel eine möglichst vollständige (wenn auch veränderliche) Beschreibung der Prozesse.

Für mich klingt daher Holokratie wie ein Taylorismus 2.0.

 

Entschieden entscheiden – egal wer da ist

Daemonic Coder

In „klassischen“ Organisationsstrukturen ist die Frage, wer entscheiden darf, oft recht eindeutig geregelt: Der Chef bestimmt. Und wenn es keine hierarchische Chef-Rolle gibt, dann oft eine fachliche Führung, die entscheidet und die Verantwortung für die Entscheidungen trägt oder zumindest tragen sollte.

Beim Wechsel hin zu einer agileren Organisation beobachte ich oft, dass Teams für sich einen Weg suchen, wie Entscheidungen im Team gemeinschaftlich getroffen werden können. Mehrere Methoden stehen dabei oft zur Diskussion:

  • Mehrheitsentscheid
  • Konsenzverfahren
  • Widerstandsmessung
  • Konsentverfahren

Sicher gibt es nicht die eine Methode, die immer und für alle am besten funktioniert. Aber ich möchte an dieser Stelle aus einem bestimmten Grund die Lanze für das Konsentverfahren brechen:

Gut abgestimmte Teams müssen beim Konsentverfahren keine Beschlussfähigkeit feststellen und sie sind jederzeit flexibel, Entscheidungen zu treffen.

Der erste Reflex vieler Teams für eine Entscheidungsfindung ist oft ein Mehrheitsentscheid. In der Diskussion wird dann aber schnell deutlich, dass zu besprechen ist, wie viele aus dem Team anwesend sein müssen, um eine Entscheidung überhaupt treffen zu können oder ob anstehende Entscheidungen gar im Vorfeld (Agenda) angekündigt werden müssen, um eine Beschlussfähigkeit zu haben. Meiner Meinung nach ist das bei einem Konsentverfahren gar nicht nötig.

Ein Konstentverfahren beschreibe ich so: Steht eine Entscheidung an, so können alle Teammitglieder entweder ihre Zustimmung ausdrücken (Daumen hoch), eine Entscheidung des Teams mittragen (Daumen seitlich) oder gegen die Entscheidung stimmen (Daumen runter). Letzteres ist aber nur mit einem „qualifizierten Einwand“ möglich, also einem Vorschlag, wie der Widerspruch aufgelöst werden kann. Ein solcher Einwand kann auch sein „das können wir nur unter Einbeziehung einer weiteren Person entscheiden“.

Ein Beispiel: Ein Team möchte über eine Änderung der Softwarearchitektur entscheiden, beispielsweise, ob bestimmte Funktionalitäten aus einem Monolithen herausgezogen und in Microservices migriert werden sollen. Bei der Entscheidung darüber kommt es zu einem Widerspruch mit der Begründung „Heute ist Sarah nicht da, die am meisten Erfahrung mit Microservices hat, wir sollten sie auf jeden Fall in die Entscheidung einbeziehen, wenn sie morgen wieder da ist.“

Der Vorteil dessen ist, dass man eine Entscheidung nicht von einem bestimmten Quorum abhängig macht, sondern von der Entscheidungskompetenz der Teammitglieder. Es würde in diesem Beispiel nichts bringen, wenn aus dem Team alle Frontend-Entwickler anwesend wären, die kaum Aussagen zu Microservices machen können.

Voraussetzung, damit dies funktioniert, ist allerdings eine gewisse Teamreife. Nur, wenn man die Fähigkeiten der anderen im Team einschätzen kann, ist ein solcher Widerspruch überhaupt nötig. Aber dann ist das Verfahren meiner Meinung nach besser geeignet, als ein Quorum, das eventuell am Ziel vorbei geht oder eine Verpflichtung zur Vorveröffentlichung, was die Flexibilität sehr einschränken kann.

Kurz gesagt: Nutzt das Konsentverfahren ohne Quorum. Erst, wenn das nicht greift, sollten meiner Meinung nach andere Entscheidungsverfahren genutzt werden.

Was redet der da? Wenn Juristen mit Coaches und Informatikern zusammentreffen

Daemonic Coder

Vor einer ganzen Weile bereits durfte ich (ja, sowas mache ich gerne) eine Abschlussarbeit eines Kollegen und Freundes zur Korrektur lesen. Es handelte sich um eine Arbeit im Fach Wirtschaftsinformatik. Allerdings hatte der Autor vorher einige Semester Jura studiert, was dazu führte, dass ich über einige Formulierungen in der Arbeit sehr stolperte. So wurde im Text ab und an darauf hingewiesen, dass manches „grundsätzlich anders“ gemacht werden solle, als der gewählte Umsetzungsweg, außerdem wurde an der ein oder anderen Stelle eine „billige“ Umsetzung gewählt.

Nach Rücksprache mit meinem Kollegen wurde mir klar, dass er die Begriffe einfach anders verstand, als ich es tat. „Billig“ war für ihn nicht auf die Kosten der Umsetzung bezogen, schon gar nicht war das abwertend „billig“, sondern „angemessen“. Und wenn ein Weg, der „grundsätzlich“ gegangen werden sollte, nicht gegangen wurde, so wich man nur (mit guten Gründen) vom Grundsatz ab. Wir hatten von den verwendeten Begriffen auf Grund unserer unterschiedlichen Ausbildungen ein anderen Verständnis.

Sprachbarrieren existieren nicht nur hin zu Fremdsprachen, sondern auch innerhalb einer Sprache, dort sind sie aber für die Beteiligten oft schwerer zu erkennen.

Wenn sich ein Unternehmen transformiert, so brechen bisherige „Sprachgruppen“ unter Umständen auch auf. Sei es innerhalb eines Teams, weil es sich cross-funktional aufstellt, oder sei es, weil klassische Kommunikationswege durch direktere Kommunikation ersetzt werden. Auf einmal muss der Informatiker mit dem Juristen reden. Erwähnt dann der Informatiker eine Regel als „grundsätzlich“, so ist es etwas, wovon er wohl nicht abweichen will. Alleine die Aufführung des „grundsätzlichen“ erweckt im Juristen die Erwartung, dass im Folgenden auf die Ausnahme eingegangen wird und für einen Coach mögen die „Grundsätze“ die Basis sein, auf der weiter detailliert werden sollte.

Und mein Lieblingsbeispiel der „ausbildungsinduzierten Sprachbarriere“: Wenn ein Psychologe von „5 plus minus 2“ als idealer Teamgröße spricht, so ist nicht der vom Mathematiker verstandene feste Zahlenraum gemeint, sondern „Mittelwert 5, Standardabweichung 2“.

Mein Appell: Werdet euch der verdeckten Sprachbarrieren bewusst, drückt aber niemandem „eure“ Definition auf. Fragt, was das Gegenüber meint und nehmt am besten diese Definition — grundsätzlich. 😉

 

Nachtrag:

Zum Juristendeutsch habe ich noch einen empfehlenswerten Artikel bei leemata gefunden:
https://www.leemeta-uebersetzungen.de/blog/interessantes/deutsch-der-rechtswissenschaft

 

Digitalisierung – Was ist das?

Daemonic Coder

Bei „Captain Power and the Soldiers of the Future“ war das mit der Digitalisierung noch ganz einfach: Ab und an kam der Antagonist, ein fliegender Roboter namens Soaron und digitalisierte Menschen, die dann zu Robotern werden sollten. (Okay, ich gebe es zu: Ich bin ein alternder Nerd.) Heute ist das etwas schwieriger – jetzt wollen alle digitalisieren und eigentlich wissen die meisten gar nicht, was sie damit überhaupt meinen.

Digitalisierung ist „Agilität“, „Schnelligkeit“, „Kundenzentrierung“… Ich weiß gar nicht, was ich alles schon an Erklärungen gehört habe, was Digitalisierung sei. Es scheint also in erster Linie zu sein: Ein Buzzword ohne Bedeutung.

Trotzdem wird jedoch versucht, mit dem Begriff ein Phänomen zu beschreiben, das uns und die Wirtschaft sehr betrifft.

Die ursprüngliche Bedeutung des Wortes ist übrigens ziemlich nahe an dem „Captain Power“-Beispiel: Dokumente werden beispielsweise mit einem Scanner digitalisiert, also in ein Dateiformat für den Computer verwandelt. Die „Digitalisierung“, die in der Wirtschaft oft gemeint ist, ist davon meiner Meinung nach gar nicht so weit entfernt, hier geht es um die Abbildung von Geschäftsprozessen und Vertriebswegen in der IT. Sicherlich begann nach dieser Definition die Digitalisierung bereits, als Mainframe-Computer mit COBOL-Programmen die Folianten in manchen Unternehmen ablösten – aber wenn man nur dies unter Digitalisierung verstehen würde, so wären sogar deutsche Amtsstuben schon vorbildlich digitalisiert.

Digitalisierung geht meiner Meinung nach insofern noch weiter, als dass die IT nicht nur unterstützende Funktion in einzelnen Prozessschritten hat, sondern indem der (Geschäfts-)Prozess an sich durch die IT verändert wird. Das mag nach einer etwas haarspalterischen Unterscheidung klingen, ist jedoch ein fundamentaler Unterschied, ob ich einen Computer verwende, um in einer Autowerkstatt die Fehlerbeschreibung eines Kunden zu erfassen, oder ob der Motor selbst per IoT-Technologie einen Wartungstermin ausmacht, zu dem die benötigten Ersatzteile bereits geliefert wurden.

Die Herausforderung besteht daher in der „Digitalisierung“ darin, dass Entwickler nicht mehr nur in der Umsetzung der Geschäftsprozesse zuarbeiten. Früher war es durchaus möglich, dass sich der „Fachbereich“, der die Geschäftsprozesse definierte, der IT nur als Unterstützung bedienen konnte. Durch die Digitalisierung ist dies nicht mehr ausreichend! Der Fachbereich braucht selbst tiefes IT-Wissen, da das Design des Geschäftsprozesses von der IT stark beeinflusst werden muss.

Gerade für große Unternehmen und Konzerne bedeutet dies meiner Meinung nach, dass einige bisherige Trennung von operativen Bereichen und der IT aufgehoben oder zumindest aufgeweicht werden muss; die Rollen von CEO und CIO müssen verschmelzen.