Seit ihrem Aufkommen im letzten Jahrhundert wird die Informationstechnologie (IT), in Deutschland gerne auch etwas sperrig Elektronische Datenverarbeitung (EDV) genannt, rein als Kostenfaktor behandelt. Software wird von der Stange gekauft oder maßgefertigt, betrieben und gewartet. Ihre Aufgabe ist die Unterstützung der Unternehmensprozesse. Effizienz und Stabilität lauten ihre wesentlichen Ziele. Anpassungen sind die Ausnahme und erfolgen im Rahmen von Projekten. In einer Zeit, die sich treffend mit dem Akronym VUCA (kurz für volatility, uncertainty, complexity und ambiguity) beschreiben lässt, müssen sich Unternehmen und ihre Prozesse und nicht zuletzt ihre IT deutlicher schneller als in der Vergangenheit auf neue Chancen und Herausforderungen einstellen können. Und sich von IT-Projekten als Werkzeug zur Veränderung verabschieden.
Information technology so far may well have done serious damage to management, because it is so good at getting additional information of the wrong kind. Based upon the 700-year-old accounting system designed to record and report inside data, information technology produces more data about the inside. It produces practically no information about anything that goes on outside of the enterprise.
Peter F. Drucker, Management’s new paradigms
Die Bedeutung von Software wandelt sind sich seit Jahren in fast allen Branchen von einer unterstützenden Technologie hin zu einem immer wesentlicheren Element in der Wertschöpfung. Und das ist erst der Vorgeschmack auf ein Internet of Things und den mit dieser Vernetzung möglichen Diensten. Sehr schön zu beobachten ist dieser Wandel in der Automobilbranche, wo immer mehr die Software in den Fahrzeugen (Stichwort: Autonomes Fahren), aber auch die Software-Ökosysteme, in die diese Fahrzeuge eingebettet sind (Stichwort: Over-the-Air-Updates), zum maßgeblichen Differenzierungsmerkmal wird. In gewisser Weise sind Autos heute die Handys der Prä-Smartphone-Ära: auch schon ein bisschen intelligent und ganz praktisch, so richtig verstehen werden wir, was uns gefehlt hat, aber erst rückblickend. Freilich wird es dann für einige Hersteller zu spät sein. So wie für Nokia.
An enterprise, whether a business or any other institution, that does not innovate, and does not engage in entrepreneurship will not survive long.
Peter F. Drucker, Management’s new paradigms
Je mehr die Software im Produkt oder im Ökosystem des Produkts zum Differenzierungsmerkmal wird, desto mehr ist die IT gefordert zum Innovationstreiber zu werden. Einmal entworfene und dann jahrzehntelang möglichst effizeit und stabil betriebene Softwaresysteme wird es immer weniger geben. Stattdessen wird aufgrund des unkalkulierbaren Marktumfelds und der immer zentraleren Stellung der Software in der Wertschöpfung die Veränderung die Regel und nicht mehr die Ausnahme sein. Diesem neuem Primat der Anpassungsfähigkeit und Agilität muss aber auch strukturell Rechnung getragen werden. Plangetriebene Projekte mit langem Vorlauf zur Genehmigung werden der geforderten Schlagzahl eher nicht gerecht werden.
Wir arbeiten in Strukturen von Gestern mit Methoden von heute an Strategien für Morgen vorwiegend mit Menschen, die die Strukturen von gestern geschaffen haben und das Übermorgen in der Unternehmung nicht mehr erleben werden.
Knut Bleicher
Die Unternehmens-IT muss lernen, in Produkten statt in Projekten zu denken. Wie Google oder Spotify. Und Produkte brauchen feste Teams, die diese Produkte permanent optimieren; einerseits auf Anforderung von außen und andererseits durch eigene innovative Ideen. Software ist eben nicht einfach – oder jedenfalls nicht mehr – eine Maschine, die betrieben und ein bisschen gewartet werden muss oder in größeren Projekten umgebaut werden muss. Software kann, sollte und wird mehr sein als ein Kostenfaktor.
12 Kommentare
„Die Unternehmens-IT muss lernen in Produkten zu denken“ … Genau so ist es. Und nicht nur die, auch IT-Unternehmen, also Unternehmen, die da noch viel mehr drin sind, müssen das. Und es gibt viel zu tun. Darum werden selbstorganisierte Teams und agile Methoden immer wichtiger. Zeit für jeden sich damit zu beschäftigen.
Danke für deine Ergänzungen, Patrick. In der Tat allerhöchste Zeit sich mit agilen Methoden auseinanderzusetzen!
Die U‑IT muß vor allem lernen, in Gesamtaufwänden zu denken und sich als Dienstleister für die Belegschaft und das Unternehmen zu verstehen, denen sie die geeignetsten Tools und Umgebungen bereitstellen soll.
Ich finde die Abgrenzung zwischen ‚EDV‘ (Elektronische Datenverarbeitung, gestern) und ‚IT‘ (InformationsTechnologie, InnovationsTreiber, heute) zu wichtig, um die Begriffe einfach gleichzusetzen.
Dementsprechend setze ich die Begriffe auch getrennt voneinander ein, um zwischen Bestand (bzw. gut gemeint) und Vision (gut getan und nachhaltig) zu unterscheiden.
Da gebe ich dir recht, Thilo: Wir reden viel zu oft von IT, wo in Wahrheit nur EDV drin ist.
Deswegen hieß das auch mal „Einsamer Datenverarbeiter“ ;-)
Sich als Dienstleister für Belegschaft und Unternehmen zu verstehen, setzt aber auch voraus, dass man der Unternehmens-IT die Möglichkeit dazu gibt.
In dem Zusammenhang hilft es vielleicht, sich selbst mit dem Kontext vertraut zu machen, in dem sich die IT bewegt: Einerseits muss sie nämlich Bestandspflege machen, also das in Schuss halten, was schon da ist. Andererseits muss sie aber auch Rechnung dafür tragen, dass sie auch zukünftigen Anforderungen gerecht wird. Allein die Aufgabe, beides unter einen Hut zu bringen, ist schwierig. Die Frage, die man sich also stellen muss, ist: Wie kann man der eigenen IT-Abteilung dabei unter die Arme greifen? Einfach nur verlangen, dass sie sich als Dienstleister sehen soll, wird nicht ausreichen.
Genau darum geht es mir, Patrick: die Unternehmens-IT muss natürlich entsprechend aufgestellt werden. Das ist sie heute aufgrund der einseitigen Ausrichtung auf Effizienz und den inzwischen völlig anderen Anforderungen an Anpassungsfähigkeit noch nicht. Und ich weiß aus erster Hand mit welchen Problemen die IT zwischen Bestandspflege (Stichwort: Zoo) und Innovation zu kämpfen hat.
Ja, Marcus, ich stimme Dir zu. Jetzt muss ich in meinem Kopf zwei Dinge klar bekommen:
Unternehmen haben Produkte, das steckt IT drin, da darf die IT in Produkten denken. Kauf ich so
Jetzt trägt nicht alles, was die IT so herstellt, direkt zu den Unternehmensprodukten bei. Indirekt sicher und ich bin kein Freund davon den Wertbeitrag von Office zu preisen. Daher darf es noch etwas zweites geben: Die Produkte der IT – die Services. Die Dienst, die die Menschen konsumieren, die direkt am Kunden / Produkt arbeiten.
Richtig?
Robert
Auch und gerade bei den Systemen und Services die nicht ins Endprodukt an den Kunden gehen muss die IT in Produkten denken. Diese bilden die Geschäftsprozesse ab und müssen sich mit dem Unternemen und den eigentlichen Produkten schnell wandeln können. Schneller als das Großprojekte mit Budgets in Jahresscheiben zulassen. Sicherlich gibt es in dem Spiel aber auch sehr stabile Basisausstattung zu der ich Office zählen würde.
Hallo Marcus,
nun hast Du mich inspiriert ;o)
Ziemlich kniffelig das Ganze…
Zum Einen denke ich dabei an die Diskrepanz zwischen der betriebswirtschaftlichen
und der technischen Sicht:
Die Betriebswirtschaftliche betrachtet das Unternehmen als übergeordnetes System.
Mitarbeiter verrichten in diesem, (idealerweise) unterstützt durch die IT (die etwas KOSTET), Ihre Arbeit.
Die technische Sicht sieht das (die) Informationsystem(e) als übergeordnetes System.
Infrastruktur, Hardware, Software, Daten und (idealerweise) UserNUTZEN
(Idealprozesse: End to End also von Kunden zum Kunden) stehen im Vordergrund.
Der Großteil der Entscheider bevorzugt me idR die erste Sichtweise,
da für sie „das Unternehmen“ im Vordergrund steht (und nicht die ‑übergreifenden- (Informations)Flüsse).
Manche (neueren) Unternehmen haben die Vorteile der zweiten Sichtweise erkannt, integriert
und „transformieren“ den NUTZEN in PRODUKTE (zb digitale Infoprodukte oder Prozesse selbst),
die dann tatsächlich (halb) automatisch erstellt werden können.
ooo
Das bringt mich zum nächsten Punkt – dem IT-Produktivitätsparadoxon:
Das IT-Produktivitätsparadoxon tritt an der Stelle auf, wo die eingesetzte IT,
Dinge wie Informationsflüsse und Prozessabläufe (zB Automatisierungsmöglichkeiten) verbessert / erweitert.
Eigentlich gilt, dass der Einsatz und Ausbau der IT KEINEN POSITIVEN Effekt
auf die volkswirtschaftliche Produktivität hat.
(Zu gut Deutsch: Wenn man einen Rechner aufstellt und ein Office installiert ergibt sich daraus kein positiver Effekt auf die Produktivität,
ausser vlt. dem, dass die Leute ausgebildet werden müssen und je nach Richtlinien(Rechtvergaben) WENIGER Produktiv werden. ;o) )
Können durch die IT allerdings die (Unternehmens)Prozesse verbessert werden,
kann das dazu führen, dass das Unternehmen nicht nur leistungsfähiger wird,
sondern auch NEUE Prozesse (und Produkte) „initiieren“ (und halten) kann.
Wenn beispielsweise die Produkterstellung „gelernt“, stabilisiert und automatisiert ist,
kann man mehr vom Gleichen schaffen oder sich zB Schulungen widmen und damit ein neues Produkt (Geschäftsmodell !!) erschliessen.
In diesen Fällen hat also die IT doch – sogar einen MASSIVEN – POSITIVEN Einfluß auf die Produktivität.
(Wird aber auch zu einem entsprechenden Risiko…)
In den Fällen, in denen so etwas gelingt, sollte man me auf jeden Fall über ein (zumindest internes)Produkt – mit einem entsprechendem Team – nachdenken.
Auch wenn diese Fälle oft der Unternehmens-IT zugeschrieben werden,
liegen sie aber erfahrungsgemäß meist eher in gut ausgearbeiteten Fachkonzepten
oder in engagierten Fachbereichen und entsprechender Kooperation begründet.
(Sonst würde der UserNutzen nicht entstehen – und gehalten werden – können ;o) ).
ooo
Das bringt mich zum letzten Punkt:
Aus Usability ist mittlerweile UX (User-eXperience Design) geworden.
Das darin enthaltene Vorgehensmodell „User Centered Design“ passt ebenso zu älteren iterativen Methoden, wie zu den neueren „Agilen“ (like Scrum).
Mit der Produktorientierung sollte man me doch auch die Gebrauchstauglichkeit bzw. (User)Zufriedenheit koppeln!?!
Nicht nur Agilität, sondern auch Usability/UX und Systemergonomie gehören dann also auf den „Produkt-Radar“ eines solchen Teams.
Ansonsten 100% Zustimmung, wenn man für jede Änderung in einem solchen Produkt, System, oder Prozess erst budgetieren und auf die Entscheidungverfahren warten soll, wird das Ganze zu langsam (und der Verwaltungsaufwand zu hoch und teuer).
Danke nochmal für die Inspiration!
Es ist immerwieder bereichernd Deine Beiträge zu lesen.
Wünsche Dir weiterhin einen schönen Sonntag!
Bernd
Vielen Dank für deinen sehr inspirierenden Kommentar (der ja schon länger ist wie mein Artikel), lieber Bernd! Ich habe auch aus der ersten Sichtweise argumentiert: Das Unternehmen mit seinem Zweck und seinen (analogen oder halb-digitalen) Produkten und die IT als Unterstützungsfunktion. Wenn sich aber nun das Unternehmen schnell anpassen muss, dann muss es auch die IT, sonst wird sie zum Flaschenhals. Verstärkt wird dieser Effekt – und jetzt komme ich zu deiner zweiten Sicht – dadurch dass die Produkte und Geschäftsmodelle immer digitaler werden. Insofern geht es gar nicht um entweder-oder, sondern sowohl-als-auch. Für beides, also für eine anpassungsfähige IT als Unterstützungsfunktion als auch für eine IT die Teil der Wertschöpfung und der Geschäftsmodelle ist braucht es den Produktfokus mit agilen Produktteams. Und natürlich muss für diese Teams (egal ob Ihr Kunde der Fachbereich oder der Endkunde ist) UX eine Rolle spielen. Gut dass UX und Agilität so gut zusammenpassen: Meiner Meinung nach ist Agilität eine Voraussetzung für gute UX.
Das sehe ich 100% genauso Marcus!
…und Danke, dass Du meinen Kommentar beachtet hast, obwohl er so lang geworden ist.