Author: jthielscher

Sie wollen Anwendungen in die Cloud überführen, wissen aber nicht wie?

Kein Problem: Das EACG Cloud Adoption Framework (CAF) ist eine Sammlung der Best Practices von IBM, Microsoft und Amazon, ergänzt um die Erfahrungen unserer Cloud Architekten und in eine Form gebracht, die es Ihnen leicht möglich macht, sich zu orientieren.

Das CAF strukturiert die Transformationsaufgaben in die sechs Dimensionen Menschen, Prozesse, Betrieb, Geschäftsziele, Architektur und Sicherheit. Durch klare Abgrenzung der Aufgabenblöcke, wird es leichter, in dem komplexen Unterfangen nicht den Überblick zu verlieren. Die einzelnen Module lassen sich zerlegen und ein unternehmensindividueller Migrationspfad ableiten.

CAF

Gerne stellen wir Ihnen das Framework in einem unverbindlichen Workshop vor. Unsere Experten erläutern Ihnen die Dimensionen und helfen Ihnen, die richtige Reihenfolge und den richtigen Migrationspfad für Ihr Unterehmen zu finden.

Sie wollen Cloud Dienste einkaufen, fühlen sich aber mit der Vielzahl Gestaltungsparameter unwohl?

Kein Problem: Die EACG Cloud Practise hat eine Reihe von Richtlinien und Best Practices erarbeitet, die Ihnen Orientierung bei der Wahl der richtigen Anbieter geben. Ob es sich um IaaS-Anbieter, PaaS oder SaaS handelt. Unsere Experten helfen Ihnen, den tatsächlichen Bedarf zu bestimmen, eine taktische Richtung oder eine langfristige Beschaffungsstratgie festzulegen. Überzeugen Sie sich selbst:

(Optimize your Cloud Purchase Strategy from Jan Thielscher, Vortrag anlässlich des ISC Forums „big Data & Cloud COmputing“ @ Frankfurt am Main 2016)

Sprechen Sie mit unseren Spezialisten, die Ihnen helfen, Ihren Cloud-Einkauf richtig auszurichten. Dabei greifen wir nicht nur auf unsere Expertise zurück, sondern nutzen auch gerne die Analysen der Cloud-Analysten von ASCAMSO.

Frankfurt, 8.Juni 2018, EACG und Linux Foundation zeichnen eine Partnerschaftsvereinbarung zur Zusammenarbeit im Projekt OpenChain.

EACG ist bereits seit einigen Jahren verstärkt im Umfeld der Open Source Governnace und Compliance aktiv. Durch eigene Großprojekte auf die Problematik sensibilisiert, ist ECS bzw. heute TrustSource entstanden, eine Plattform für die Automation der Open Source Governance.“Wir sind noch nicht ganz am Ziel, aber auf einem guten Weg“, meint Jan Thielscher, der das Unterfangen federführend treibt.

„Unsere Plattform liefert den technischen Teil: scanning, mapping, Dokumentation und Berichte. Governance ist aber mehr, als ein Werkzeug leisten kann. Um wirklich rechtskonform ud sicher Software zu erstellen und auszuliefern, ist es auch erforderlich, Prozesse und Kultur anzupassen. Hier kommt OpenChain ins Spiel. Die vielen, wohlüberlegten Anforderungen fürhren zu dem erforderlichen Wandel. Wir begrüßen das und bauen die Workflow-Unterstützung der Pplattform so aus, dass sie die Anforderungen bestmöglich unterstützt.“

EACG bietet Beratungsleistungen zum Thema Open Source Compliance und Governance an, sowie die Lösungsplattform TrustSource als SaaS. Es gibt unterschiedliche Editionen, von einer freien Lösung für einzelne Entwickler bis hin zur Enterprise-Lösung on premises. Ausprobieren lässt sich die Löung hier.

In Zuge der Zusammenarbeit wird EACG zunächst die Übersetzung der OpenChain Spezifikation v1.2 in die deutsche Sprache unterstützen und anschließend deutschsprachige Seminare anbieten. Interessierte können sich gerne direkt an uns wenden.

Version Eye streckt die Flügel

Es ist immer schade, wenn ein angesehener Mitstreiter den Markt verlässt. Robert hat mit Version Eye das Thema Versionierung von Open Source Bibliotheken seit 2011 besetzt. Er hat eine große Community aufgebaut und – wie auch in seinem Blog beschrieben – einige Unternehmenskunden gewinnen können. Eine beachtliche und starke Leistung für eine Einzelperson bzw. sein kleines Team.

Zwar hat er in den letzten Jahren vermehrt auch in den Bereich Lizenzprüfung investiert, jedoch hat er mit seinen Kunden scheinbar keinen Weg gefunden, die Sache wirtschaftlich erfolgreich zu gestalten.

Was tun?

Was nun aber tun? Angenommen, die Prozesse sind auf Version Eye eingespielt, jedoch ist ab November, bzw. spätestens Ende Dezember nicht mehr mit der Fortführung zu rechnen.

Wir bieten interessierten Kunden an, für sie die Version Eye-Crawler nach Absprache für einige Monate in unserem Frankfurter Rechenzentrum weiterzubetreiben. Nach Rücksprache mit Robert lässt sich das einfach arrangieren, ohne dass auf Kundenseite viel zu tun ist. In dieser Zeit unterstützen wir Sie auch gerne dabei, einen neuen, für Ihren BEdarf geeigneten Weg zu identifizieren. Gerne stellen wir Ihnen auch unsere Open Source Compliance-Lösung ECS vor.

ECS fokussiert License-Compliance. Neben den OS-Komponenten lassen sich auch Infrastrukturkomponenten (DBs, MQs, etc.) verwalten, Releases einfrieren und Freigabeprozesse auditfähig dokumentieren. Zudem verfügt ECS über eine Logik, die es ermöglicht, die Eignung von Lizenzen auf einen Awnendungskontext zu prüfen und die resultierenden Anforderungen in Form eines Obligations-Reports abzufragen. SPDX Export und Bill of Materials APIs unterstützen die erforderliche Dokumentation.

Probieren Sie es aus oder sprechen Sie uns an!

Lassen Sie uns wissen, welche Herausforderungen Sie beschäftigen!
Name*
E-mail:*
Message:*
Recaptcha Word Verification:

Vorteile aus Open Source konsequent nutzen

Oft wird hierzulande der Begriff „Open Source“ nur mit lizenzfreier Software in Verbindung gebracht. Das ist aber nur eine sehr beschränkte Sicht. Dieser Artikel beleuchtet kurz weitere Vorteile und Chancen, die sich durch gezielten Einsatz von die Open Source für Unternehmen ergeben.

Dass Open Source die Kosten für die Beschaffung von Software reduzieren helfen kann, ist inzwischen allgemeinhin akzeptiert. Neben Geschwindigkeit und Kostenreduktion durch die Nutzung von Open Source Komponenten existieren noch andere Vorteile. Auch die Anwendung entsprechender Prinzipien innerhalb des eigenen Hauses oder die Bereitstellung eigener Entwicklungen in Form von Open Source-Projekten birgt vielfältige Vorteile.

Inner Source als Sonderform des Open Source

Ein möglicher Aspekt ist es, Entwicklungen im eigenen Hause in Form von Open Source-Projekten oder sogenannten „Inner Source“ zu organisieren.

Dabei werden die internen Projekte organisiert und behandelt wie Open Source Projekte: ein für die „Unternehmens-Öffentlichkeit“ zugängliches Repository, öffentlich zugängliche Dokumentation, ggf. Ticketsystem für Bugs und Pull-Requests von beliebigen Kontributoren, etc.; sie verbleiben jedoch innerhalb der Organisation. Das bedeutet, die Sourcen werden der Öffentlichkeit nicht zur Verfügung gestellt, sind innerhalb der Organisation jedoch für alle Entwickler sichtbar.

Diese Vorgehensweise mag auf den ersten Blick befremdlich wirken, geht aber oft mit einer erheblichen Qualitätsverbesserung des Codes einher. Ein Treiber dabei ist der persönliche Antrieb, nicht den Ruf eines schlechten Coders zu erhalten. Auch können Konsumenten des Systems zur Qualität beitragen, indem sie die für sie dringlichen Themen selbst analysieren und entspechende Fixes einstellen.

Analog dazu wird es für die Konsumenten von APIs möglich, das Zustandekommen von Rückgabewerten zu verstehen und somit Fehler in der Interpretation zu vermeiden. Zudem lässt sich die Mehrfachentwicklung von Routinen für gleiche Aufgabenstellungen über Entwicklunsgsteams hinweg reduzieren; eine gute Suchoption vorausgesetzt.

Natürlich stellt diese Form der „Öffnung“ auch neue Herausforderungen an die Entwicklungsteams. Der Aufwand an Dokumentation  – was ein gewünschter Nebeneffekt sein kann – und die Transparenz über das, was in den jeweiligen Teams passiert, erhöhen sich. Das kann bereinigend und positiv auf die Unternehmenskultur wirken, Silodenken reduzieren und Budget-Druck verändern.

Opensource für unliebsame Pflichtaufgaben

In einem weiteren Schritt ist es auch denkbar, unliebsame aber erforderliche Aufgaben in offene Projekte zu stecken, um sie über die Unternehmensgrenzen hinweg verfügbar zu machen. Das stärkt das Bil des Unternehmens als Innovationstreiber, hilft aber auch, die typischerweise knappen Entwicklungsressourcen durch externe Leidensgenossen aufzustocken.

Diese Denkweise  ist recht undeutsch, aber effektiv. Beispielsweise hat Zalando die Aufgabe in einer Micro-Service-Umgebung eine effektive und sinnvolle Frontend-Architketur zu entwicklen als notwendige, aber im Sinne der eigenen Differenzierung wenig hilfreiche Aufgabe erkannt. Daher hat man sich entschieden, tailor als Open-Source-Projekt zu gestalten. Nun ist die Schlagkraft für dieses Thema nicht mehr nur auf  die eigenen Entwickler beschränkt, die Zanlando dafür bereitstellen könnte. Da die Thematik fast alle Micro-Service-Nutzer trifft, besteht ein wesentlich größeres Entwicklerpotential, um das Thema qualitativ voranzubringen.

Um ein Projekt erfolgreich einzurichten, ist es wichtig, dass das Projekt nicht bei Null anfängt. Sind sinnvolle Ansätze vorhanden, die auch Dritten einen Nutzen bieten, ist das Thema hinreichend relevant und wird darüberhinaus etwas in die Öffentlichkeitsarbeit investiert, kann so ein Ansatz sehr erfolgreich werden.

Als netter Nebeneffekt wird das Unternehmen in der einschlägigen Community bekannt und gewinnt gleichzeitig an Attraktivität als Arbeitgeber für Entwickler. Es schlägt also mehrere Fliegen mit einer Klappe:

  • Eine notwendige Aufgabe wird mit mehr Kapazität erledigt, als zu bezahlen ist
  • Es entsteht ein Zugang zu potentiell mehr Knowhow und Innovationskraft
  • Die Attraktivität als Arbeitgeber in der einschlägigen Community erhöht sich
  • Im Erfolgsfall wirkt dies positiv auf die Wahrnehmung der Innovationskraft des Unternehmens

Um jedoch diese Vorteile zu erschließen, sind auch einige rechtliche Voraussetzungen zu schaffen, damit nicht plötzlich Urherberrechtsklagen auf den Benutzer der so geschaffenen Open Source Lösungen hereinprasseln. Hierzu werden üblicherweise sogenannte „Contributor Agreements“ geschlossen.

Die Liste der Vorteile und Heruasforderungen lässt sich noch fortsetzen. Anhand der vorstehenden bemerkungen sollte jedoch klar werden, dass Open Source als strategische Option in das Handlungsportfolio jedes erfolgsorientierten Unternehmens gehört.

Klares Rollenverständnis Voraussetzung für effektiven Einsatz

Um die Chancen für das Unternehmemn zu nutzen und die Risiken zu beherrschen hat EACG mit seinem Legal-Partner CMS drei Schulungen konzipiert, welche den Informationsbedarf der wichtigsten Rollen adressieren:

Rollen

Detaillierte Informationen zu den Inhalten der Schulungen finden Sie in dieser Präsentation oder unter den nachstehenden Links:

Für Fragen zu den Trainings oder zur Gestaltung von Open Source Strategien für Ihr Unternehmen kontaktieren Sie uns.

Das Ziel eines Architektur-Audits ist es, die Komponenten eines Systems, ihre Verantwortlichkeiten und ihr Zusammenspiel zu ergründen und zu dokumentieren.

Mit Hilfe dieser Information lassen sich Aussagen zu

  • Entscheidungen über die Zukunftfähigkeit (Eignung zur Fortführung),
  • die erfordelrichen Anpassungen zur Erreichung bestimmter Ziele,
  • die Güte bzw. Eignung des Betriebes oder
  • die Sicherheit des Systems

treffen.

Wichtig für einen erfolgreichen Architektur-Audit ist daher die genaue Spezifikation des Umfangs (Scope). Dieser definiert zusamme mit dem gewählten Zeitraum, bis die Ergebnisse vorliegen müssen, auch die Betrachtungstiefe (Granularität).

Ein Audit kann auf ganz unterschiedlichen Ebenen stattfinden. So ist es möglich, die Eignung einer Systemlandschaft für einen bestimmten Geschäftszweck oder  die Eignung eines Systems bzgl. einer bestimmten Funktionalität zu beurteilen. Während sich der erste Fall eher mit der funktionalen Architektur und den Informationsflüssen zwischen ganzen Systemen beschäftigt, adressiert die zweite Variante die Innereien eines Systems und das Zusammenspiel seiner Komponenten.

Oft ist es sinnvoll, zunächst eine grobe Übersicht zu erzeugen und dann einzelne Systeme bzgl. spezifischer Aspekte zu verteifen. So mag es sinnvoll sein, das zunächst das Zusammenspiel und die Flexibilität des Informationsflusses innerhalb des Unternehmens an sich zu beurteilen. In einem zweiten Schritt lassen sich dann die Internet-gerichteten Systeme bzgl. Sicherheit, die Kernprozess-unterstützenden Systeme bzgl. Informationsflexibilität untersuchen.

Neben einer fokussierten und schrittweisen Voregehensweise ist es für den Architekten aber auch wichtig, einen ganzheitlichen Blick auf die Systeme zu behalten. Sehr oft lassen insbesondere technische Audits die organisatorischen und prozessualen Aspekete außer Acht: Anforderungsgestaltung, Release-Prozesse, Test-Management oder die Skill-Profile der Teams spielen eine wichtige Rolle in der Beurteilung der Gesamtsituation.

Die EACG Architetur-Methodik sowie das EACG Architecture Framework sorgen für die Ganzheitlichkeit der Betrachtung. Das Statement of Work, welches wir vor jedem Audit zusammen mit unserem Kunden erarbeiten, gibt die genaue Zielrichtung vor und grenzt den Scope klar ab. In diesem Zuge klären wir mit Ihnen auch, was an Informationen (Evidence) benötigt wird, um solide Schlussfolgerungen zu ziehen.

Somit stellen wir sicher, dass Sie Ihre  gewünschten Antworten in Kürze erhalten.

Zögern Sie nicht, kontaktieren Sie uns jetzt!

Lassen Sie uns wissen, welche Herausforderungen Sie beschäftigen!
Name*
E-mail:*
Message:*
Recaptcha Word Verification:

Value_Migration

#Disruption, #innovate your #business model, #re-invent yourself sind Schlagworte fast jeder Top-Management Agenda. Aber wie lässt sich eine „Disruption“ antizipieren? Wie kann ich für mein Geschäft klären, wie sich die „Digitalisierung“ auswirken wird? Dieser Artikel stellt das „Value-Sport“ Konzept vor (s.a. http://bit.ly/2ltN1GB ), welches wir bereits seit langem erfolgreich als Stütze für die Gestaltung von Geschäftsmodellen einsetzen und gibt einige Hinweise, wie es sich gewinnbringend einsetzen lässt.

Grundidee des Value Spot Konzeptes

Die Grundidee des Konzeptes ist einfach: Jedes lebensfähige Unternehmen macht irgendetwas, wofür es seine Kunden wirklich bezahlen. Leider ist das nicht immer der eigentliche Geschäftszweck. Vielleicht war er das mal, das kann sich aber über die Jahre wandeln. Wertschöpfung verlagert sich.

Lang der Wert eines Verpackungsherstellers früher in der Herstellung alleine, so ist es heute mit Sicherheit die Verpackungsgestaltung und die Fähigkeit, die Verpackung just-in-time an den Einsatzort zu befördern.

Wesentliche Treiber für diese Veränderung sind zum einen der Wettbewerbsdruck aber auch zum anderen das Sedimentieren von Technologie.

Wesentliche Treiber für diese Veränderung sind zum einen der Wettbewerbsdruck aber auch zum anderen das Sedimentieren von Technologie. War es vor zehn Jahren ein teures Unterfangen ein ausfallsicheres Rechenzentrum in mehreren geographischen Regionen zu betreiben, so reichen dafür heute eine Kreditkarte, ein Internetanschluss und etwas Know-how.

IBM ist aus meiner Sicht ein interessantes Beispiel für eine bewusste Wandlungs- und Adaptionsfähigkeit. Das Unternehmen existiert deshalb so lange, weil es immer wieder rechtzeitig erkennt, wann es sich von weniger aussichtstarken Geschäftsfeldern trennen muss. So hat es vor mehr als 10 Jahren den Trend zu Mobile Devices antizipiert und die PC und Laptop-Produktion an Lenovo veräußert, um sich stärker auf den damaligen Wachstumsmarkt Software und Services zu konzentrieren. Das hat einige Jahre getragen. Jetzt ist jedoch schon die nächste Migration in Richtung pay-by-use Plattformen wie Softlayer, Bluemix oder Watson (Artificial Intelligence) um ein Haar zu langsam gewesen.

Wer sich über seine aktuellen Value-Spots im Klaren ist, kann besser antizipieren, wie sich das Unternehmen entwickeln und ab wann mit Einbußen im Cash-Flow zu rechnen sein wird. Die Verlagerung des Value Spots insbesondere durch die Veränderung der technologischen Möglichkeiten sollte antizipiert und als Bestandteil der Unternehmensentwicklung solide geplant werden.

Case-Study: Value Spots identifizieren und nutzen

2004 kamen wir zu einem Anbieter von Geräten der Medizintechnik. Das Unternehmen stellte mehr als 50% aller im Einsatz befindlichen Geräte in seinem Segment (Micro-invasive Chirurgie), jedoch machte es trotz der erstaunlichen Installationsbasis keinen Gewinn. Margendruck und schlechte Wechselkursentwicklung wurden für die schwache Marge verantwortlich gemacht.

Sicher wichtige Faktoren; unsere Value-Spot-Analyse zeigte jedoch schnell, dass die Ursache woanders lag: Das Unternehmen machte nur noch 25% seines Umsatzes mit den Maschinen, der weitaus größere Teil resultierte aus langlaufenden Verträgen zu den Verbrauchs­materialien. Hunderttausende Schläuche wurden jedes Jahr an die gewaltige Installationsbasis ausgeliefert: Leider mit Verlusten von mehreren EUR pro Stück. Diesen stetig wachsenden Verlust konnten die neuen Maschinenverkäufe nicht mehr ausgleichen.

Durch das Verschieben des Value-Spots von der Maschine auf das Verbrauchsmaterial konnten wir eine Restrukturierung der Produktion einleiten, die in nur 12 Monaten den Verlust pro Schlauch in einen Gewinn pro Schlauch verwandelte. Dadurch ließen sich nun die Maschinen günstiger anbieten, was den Umsatz mit Verbrauchsmaterialien weiter steigerte. Das Unternehmen machte einen Gewinnsprung, der Börsenkurs verdreifachte sich.

Die Fähigkeit, sich über das bestehende Modell zu erheben, es in Frage zu stellen und im Rahmen der Möglichkeiten der Organisation das nächste Modell zu definieren, ist eine Kunst.

Value Spots im eigenen Kontext gestalten

Die Fähigkeit, sich über das bestehende Modell zu erheben, es in Frage zu stellen und im Rahmen der Möglichkeiten der Organisation das neue Modell zu definieren, ist eine Kunst. Externe Unterstützung kann durch neuen Perspektiven und offenen Fragen hierbei sehr nützlich sein. Um den eigenen Denkprozess selbst zu strukturieren, kann unser Modell der fünf Cs helfen.

Um unseren Kunden Orientierung zu geben als um die Jahrtausendwende das Internet den Handel und die Medien verändert hat, haben wir das Beziehungskonstrukt der fünf „Cs“ (Content, Communication, Convenience, Consulting und Commerce) entwickelt. Es hat damals gute Ergebnisse geliefert. Etwas modifiziert eignet es sich auch heute als Orientierungsrahmen.

digitrans3_01

Betrachtet man anhand des Modells die Kundenbeziehung, so zeigt sich mit zunehmender Interaktion eine Vertiefung der Kundenbindung. Das liegt auf der Hand, denn der „Share of Attention“, die Aufmerksamkeit, nimmt mit steigender Auseinandersetzung zu. Gleichzeitig ist aber auch der technologische Anspruch für die Gestaltung einer solchen Beziehung höher. Warum ist das wichtig? Weil zukünftige Geschäftsmodelle eine Tendenz zu nutzungsbasierten bzw. abonnementartigen Vergütungsmodellen aufweisen. Das reduziert den Einmalumsatz, führt aber zu laufenden Einnahmen. Hohe Kundenbindung hilft, die Einkommensströme zu sichern.

Ein gutes Beispiel für eine erfolgreiche Transformation stellt MICROSOFT dar. Microsoft hat lange gut vom Lizenzgeschäft gelebt. Jedoch wurde die Begründung für eine Upgrade-Investition immer schwieriger. Durch den Wechsel zum Betreiber von Office365 ist aus dem gefährdeten Lizenzmodell-Geschäft ein wachstumsstarker, kontinuierlicher Cash-Flow geworden. Die zusätzlichen Anwendungen und die „inkludierten Updates“ erhöhen die Kundenbindung. Mit Marketplace bezieht ein neues Commerce-Modell Position.

Ein anderes Beispiel für eine clevere Gestaltung ist beispielsweise AMAZON PRIME. Wäre im traditionellen Geschäftsmodell von OTTO oder NECKERMANN jemals jemand auf die Idee gekommen, 69 EUR im Jahr zu überweisen? Vermutlich nicht. Dennoch tun dies mehrere Millionen Kunden bei AMAZON. Die Grundfunktion Shopping wurde durch Beobachtung um eine Convenience-Leistung „kostenfreier Versand“ – sowie inzwischen einige andere Mehrwert-Leistungen – erweitert, die Kundenbindung gleichzeitig um ein Vielfaches erhöht und ein zusätzlicher Cash-Flow generiert.

Kennt man den eigenen Value Spot, lässt sich die Evolution des zugrundeliegenden Dienstes oder Produktes entlang der aufgezeigten Cs relativ gut prognostizieren. Die Eintrittszeitpunkte bleiben zwar unscharf, für die Ableitung eines ungefähren Realisierungszieles reicht es jedoch allemal.

Transfer auf technische Capabilities

Ein Ziel zu kennen ist für den Kapitän essentiell. Ist es klar, sind gute Leitfiguren gerne schnell unterwegs. Gerade im Kontext „Digitale Transformation“ und „IoT“ erfordert der Weg nach vorne jedoch ausreichend Contenance. Die technologische Komplexität ist hoch, sogar sehr hoch. Gute, motivierte und ausreichend befähigte Mitarbeiter womöglich sogar mit langjähriger Erfahrung sind jedoch rar und davon braucht es mit Sicherheit mehr; und das auch noch bei allen Marktteilnehmern gleichzeitig!

Wer bei der Abstimmung von Wertschöpfungsvision und technologischer Fähigkeiten die Organisation falsch einschätzt, riskiert den Totalausfall

Die Abstimmung der Wertschöpfungsvision mit der tatsächlich leistbaren technologischen Komplexität ist eine äußerst kritische Herausforderung. Wer hier die Organisation über- oder unterfordert, riskiert den Totalausfall. Es geht um nichts weniger als die Zukunft der Unternehmung. Zu anspruchslose Ziele führen zu einem Erodieren der Wertschöpfungsposition und somit zur Schwächung der zukünftigen Ertragskraft, da das Unternehmen den Anschluss verliert. Zu ehrgeizige Ziele ziehen fehlerhafte Dienste oder Produkte nach sich und damit einhergehend Verlust der Brand-Power und wiederum Erosion der Ertragskraft.

Wie also den richtigen Grad an technologischer Komplexität bestimmen?

Auf diese wichtige Frage gibt es keine pauschale Antwort, da sie von der Firmenkultur, den Möglichkeiten des Unternehmens sowie dem bereits bestehenden Produktportfolio geprägt wird. Dennoch lassen sich einige Eckpunkte als Gedankenstützen identifizieren. Nachstehende Abbildung zeigt die Abhängigkeiten der technologischen Fähigkeiten eines IoT-Stacks auf. Es liegt auf der Hand, dass das gesamte Gebäude ins Wanken gerät, wenn eine der zugrundeliegenden Bausteine zerbröselt. Wer zu schnell zu hoch baut, riskiert den Zusammenbruch. Der Abgleich der technologischen Fähigkeiten mit der Wertschöpfungsvision ist daher kritischer Erfolgsfaktor einer Digitalen Transformation.

Der Abgleich der technologischen Fähigkeiten mit der Wertschöpfungsvision ist kritischer Erfolgsfaktor einer Digitalen Transformation.

digitrans3_02

Das sind alles technologisch anspruchsvolle, komplexe Fähigkeiten. Jedoch sind sie allesamt sedimentiert und heute bereits aus der Dose (Opensource oder Managed Service) erhältlich. Man muss sie also nicht mehr neu erfinden, man kann sie einfach bei AWS als Managed Service einkaufen. Mit dem Bezug eines „Managed Service“ entbindet man sogar seine Organisation der Pflicht, es zu betreiben, was auch alles andere als trivial ist.

Wer sich mit unbesetzten Stellen, fehlender Erfahrung im Umgang mit moderner Software-Entwicklung oder der gefühlt großen Menge an Aufgaben zum Aufbau der erforderlichen technischen Fähigkeiten konfrontiert sieht, tut gut daran, seine Wertschöpfungstiefe kritisch zu hinterfragen. Welche Dienste sind wirklich differenzierend? Reicht es, sich vielleicht auf die Auswertung der Daten zu konzentrieren oder muss ich die gesamte Erhebungskette beherrschen? Die gesunde Abwägung von „Machen“ vs. „Kaufen“ entscheidet über Erfolg oder Misserfolg der Mission.

Oft geht mit dieser Entscheidung die Frage nach dem Dilemma von Geschwindigkeit und Abhängigkeit einher. Ich bin ein klarer Verfechter der Geschwindigkeit. Denn wer zuerst (zum Kunden) kommt, malt zuerst. Und Abhängigkeit ist, wenn die Architektur bewusst und gezielt gestaltet wurde, ein beherrschbares Risiko. DROPBOX wäre ohne AWS nie in der Geschwindigkeit gewachsen, hätten Sie nicht S3 (AWS Secure Storage Service) als Basis genutzt. Erst als sie groß genug waren (März/2016), hat es sich dann gerechnet, von AWS in ein eigenes Rechenzentrum zu wechseln.

Jeder CxO, der die verantwortungsvolle Aufgabe hat, die Digitale Transformation seines Unternehmens zu konzipieren oder zu treiben, sollte die Evolution des Geschäftsmodells mit den technischen Fähigkeiten seiner Organisation in Einklang bringen. Dabei sollte aus meiner Sicht Geschwindigkeit Vorrang vor technologischer Tiefe erhalten. Denn am Ende geht es immer nur um die langfristige Stabilisierung bzw. Stärkung des Cash-Flows. Und den gibt es nur vom Kunden gegen Mehrwert (Consulting), Convenience oder Commerce.

Wenn Sie noch unklar über die richtige Vorgehensweise für Ihre Digitale Transformation sind, sprechen Sie uns an!

Dieser Beitrag ist der dritte Artikel aus der Reihe „Mastering Digital Transformation“. Bisher sind bereits die Beiträge „Kulturelle Unterschiede verstehen“ und „Agilität erzeugen“ erschienen. Weitere Informationen zu EACG und Jan. Der nächste Artikel wird sich mit den Möglichkeiten beschäftigen, Entwicklungsgeschwindigkeit durch moderne Software-Technologien zu erhöhen.

DigiTrans2pic
Digitale Transformation steht nach wie vor ganz oben auf der Agenda vieler CxOs. Plötzlich greifen Wettbewerber, die bisher gar nicht auf dem Radar waren, Kunden mit Software-gestützten Leistungen ab und die eigene Wertschöpfung droht zur abhängigen Nebenleistung zu werden. Mit Sicherheit gilt das nicht für alle Wertschöpfungsmodelle gleich. Eine Airline genießt mehr Substitutionsschutz als ein Taxi-Unternehmen. Jedoch ist die Verbreitung kostengünstiger, compute-fähiger Endgeräte eine potentielle Substitution für fast jede Art von Mess-, Steuerungs- oder Vertriebssystemen. Die Möglichkeit ergänzender Analyseinformationen im Anwendungskontext birgt stets ein Einfalltor für clevere Software-Lösungen und somit Gefahr für die direkte Kundenbeziehung.

Ich empfehle daher allen Unternehmen, sich mit den wesentlichen Grundsätzen des „digitalen“ Unternehmens vertraut zu machen, um die erforderlichen Änderungen rechtzeitig einzuleiten.

Bei EACG haben wir in den letzten Jahren viele Kunden dabei begleitet, sich mit innovativen Ansätzen und Geschäftsmodellen auseinander zu setzen. Dabei haben wir einige Beobachtungen gemacht, welche die erfolgreichen von den weniger erfolgreichen unterscheiden. Einige der wichtigsten Beobachtungen möchte ich in dieser Reihe von Beiträgen teilen und zur Diskussion stellen.

Organisationscharakteristika eines „Digitalen Unternehmens“

Obwohl wir bei EACG bereits 2012 den Kunstbegriff „Digitization“ – Digitalisierung war uns dann doch zu kurz gesprungen – für unser Beratungsgeschäftsfeld gewählt haben, fühle ich mich nicht wohl mit dieser unspezifischen und eigentlich auch falschen Bezeichnung für einen solchen Umbruch. Das „eBusiness“ vom Anfang des Jahrtausends empfinde ich viel treffender und charmanter. Aber weg vom Wording, hin zum Inhalt: Was verbirgt sich hinter der „Digitalisierung des Unternehmens“?

Ich will die Unterschiede zwischen einem digitalen und einem traditionell orientierten Unternehmen anhand folgender Aspekte kurz darlegen:

Struktur

Eine traditionelle Organisation setzt auf Ressourcen-Pools und Projekt­organisation. Die in den achtziger und neunziger Jahren identifizierten Neuerung der Projektorganisation gegenüber der Linienorganisation wurden mit Flexibilität und Spezialistentum begründet. Dies war auch für eine Zeit korrekt, in der es galt, mit Hilfe von Projekten wiederkehrende Tätigkeiten mittlerer Qualifikationsstufe zu organisieren bzw. zu optimieren.

Die Digitale Organisation versteht sich als Einheit, die eine Wissensdomäne besetzt und über intelligente Mitarbeiter verfügt.

Die Digitale Organisation dagegen, versteht sich als Einheit, die eine Wissensdomäne besetzt und über intelligente Mitarbeiter verfügt. Daher löst sie die Paradigmen der Projektorganisation wieder auf und favorisiert dedizierte Teams. Ein Team bleibt zusammen, lernt sich kennen und optimieren; es übernimmt Verantwortung für Entwicklung und Betrieb der von ihm geschaffenen Dienste.

Der dem Ressourcen-Pool übliche Fokuswechsel und das mit dem Ende eines Spezialisten-Assignments einhergehende Verantwortungsnirwana soll unterbunden werden. Die Bindung eines Teams an seine Leistung dient der Identifikation mit dem Geschaffenen sowie der Qualitätssicherung und dem Erfahrungsaufbau. Die Organisationsform implementiert somit das Verständnis und implizit die Erfahrung, dass Fehler auf einen zurückfallen, dass fehlerfreie Produktion die Ausstoßmenge und somit den direkt sichtbaren Erfolg erhöht.

Prozesse und Akteure

Dass ein Software-Entwicklungsprozess nach SCRUM effizient gestaltbar ist, hat sich herumgesprochen. Jedoch ist der Umfang, mit dem die SCRUM-Methodik die Organisation bestimmt, sehr verschieden. Ich will hier nicht SCRUM als Allheilmittel preisen und wage nicht zu behaupten, dass eine effektive Anwendung von SCRUM (http://agilemanifesto.org/) bis hin zu SCRUM of SCRUM und vielleicht sogar SAFe die Organisation des Digitalen Unternehmens sicherstellt. Vielmehr birgt der Fokus auf die Methode die Gefahr, wesentliche Gestaltungsaspekte zu übersehen.

Weder SCRUM noch SAFe machen eine Organisation zum Digitalen Unternehmen

Demgegenüber kann der Mangel an SCRUM ein Indikator für die Verhaftung in traditioneller Denke und Werten sein. Arbeitet nur die Entwicklung nach SCRUM, die Qualitätssicherung jedoch nicht, können die prozessimmanenten Verantwortlichkeitsprinzipien nicht greifen. Erhalten die SCRUM-Teams, wenn auch mit Testern versehen, nicht das Feedback aus dem Betrieb, da dieser beispielsweise in einer Betriebsorganisation abgekoppelt ist, fehlt vielleicht das erforderliche Korrektiv.

Aber nicht nur auf der Abnahme-Seite, auch auf der anderen, der Input-Seite des Prozesses lässt sich viel falsch machen. Eine Schlüsselfunktion im SCRUM kommt dem Product Owner zu. Er identifiziert die User Stories, den Arbeitsvorrat, den das Team zu bewältigen hat. Hier gilt analog zu jeder Produktionsfunktion „Shit-in-Shit-out“. Die Qualität der Funktion ist von entscheidender Bedeutung für den Unternehmenserfolg.

Während traditionelle Unternehmen hier gerne noch Stellvertreter der tatsächlich Produktverantwortlichen schicken, ist in Digitalen Unternehmen der Product Owner entscheidungsstark und zumeist eng am Kunden. Im Idealfall verfügt er über die Produktverantwortung, kann schnell entscheiden und hat Unterstützer, die ihm helfen, seine Produktvision in User Stories und Acceptance Criteria zu kleiden. In wirklich Digitalen Unternehmen ist er auch dem Investment Committee Rechenschaft schuldig. Das macht ihn zu einer zentralen Triebkraft der Produkt- und Unternehmensentwicklung.

Die traditionellen Linien-Manager treten einen Schritt zurück und übernehmen die unterstützende Funktionen, wie das Bereitstellen erforderlicher Rahmenbedingungen: eine motivierende Umgebung, ein gut organisiertes Team, Coaching und Mitarbeiterentwicklung oder Unterstützung bei Eskalationen.

Kontinuierliche Verbesserung

Zum Abschluss noch ein Aspekt, der eigentlich beiden Welten gleich ist, jedoch aufgrund unterschiedlicher Bezeichnungen und Ausprägungen oft als Unterschied interpretiert wird. Jedes gute Produktionsunternehmen kennt „KVP“-Termine, in denen Qualitätsbeauftragte und Industrial Engineering Experten die Performance-Kennzahlen des Produktionsprozesses betrachten und nach Optimierungspotential suchen. Prozesstreue und vorausschauende Kennzahlenbildung sind zentrale Elemente für eine erfolgreiche KVP.

Das gleiche gilt für die Software-Entwicklung. Mit SCRUM wurde ein knallhartes Verfahren entwickelt, welches die Softwareentwicklung einem kontinuierlichen Verbesserungsprozess unterwirft. Unter Beachtung des Produktionsfaktors Mensch sind geeignete Mechanismen für die Effizienzsteigerung etabliert worden, die im Zusammenspiel unweigerlich Produktivität erzeugen. Leider wird dies selten richtig verstanden. Vermutlich würde keiner auf die Idee kommen, einen KVP ohne Qualitätsmanager zu organisieren. Die Notwenigkeit eines SCRUM-Masters wird jedoch oft noch angezweifelt. KVP ohne KPIs würde niemandem einfallen, SCRUM ohne Estimations lässt sich jedoch immer wieder finden.

KVP ohne KPIs würde niemandem einfallen, SCRUM ohne Estimations lässt sich jedoch immer wieder finden.

Jede erfolgsorientierte Organisation braucht einen kontinuierlichen Verbesserungsmechanismus. Die Implementierung eines soliden, vollumfänglichen SCRUM in einer Software-Organisation ist so zentral für die Effektivität der Software-Entwicklung wie die Implementierung eines KVP in der Produktion und sollte mit der gleichen Priorität und Ernsthaftigkeit betrieben werden.

Finanzen

Ein weiteres, zentrales Feld zur Schaffung von Agilität: Funding vs. Budgeting. Traditionelle Organisationen hangeln sich durch jährliche Budgetrunden. Je nach Größe der Organisation kann so ein Prozess auch mal ein viertel bis halbes Jahr andauern. Erst nach der offiziellen Festlegung lassen sich die ergatterten Projektbudgets wieder ausgeben, nach vorne schauen, umsetzen. Auf jeden Fall wird alles kritisch und zäh, was nicht im Voraus erkannt wurde oder bekannt war. Am Ende des Finanzjahres werden mühsam gehortete Budgets noch schnell ausgegeben…

Das ist einer Digitalen Organisation fremd. Sie lebt mit einem kontinuierlichen Portfolio- und Funding-Management. Gute Business Cases erhalten das erforderliche Budget, sobald ein Investment Committee eine Idee angenommen hat. Und nur gute Mitarbeiter bringen auch gute Business Cases. Die Vorarbeit für einen guten Business Case braucht gute sechs bis zwölf Wochen, je nach Domaine. Schafft es ein Produktmanager diese Zeit in eine Idee zu investieren – man kann ihm hier mit methodischer Beratung und Unterstützung zur Seite stehen – und kann er die Idee auch vertreten, wird er auch den Ehrgeiz haben, das MVP erfolgreich zu liefern. Zeigt das MVP dann eine positive Resonanz, werden die vereinbarten KPIs erreicht, kann das Funding für den Produkterfolg bereitgestellt werden. Dies eröffnet fähigen Mitarbeitern erhebliche Chancen und steigert somit die Attraktivität als Arbeitgeber für fähige Köpfe.

Der Umbau der Vorhabenfinanzierung von Budgetierung zu Funding kann nur von oben getrieben werden

Die Vorstellung, den traditionellen Budgetprozess aufzumachen oder auch nur anzufassen, lässt viele Unternehmer und Senior Manager vor Ehrfurcht erstarren. Um dennoch schnell voran zu kommen, empfehlen wir von EACG, mit dem CFO zunächst innerhalb des bestehenden Budgeting-Prozesses einen entsprechenden Betrag für Fundings bereitzustellen und die Vorgehensweise auszuprobieren. Es liegt auf der Hand, dass solche Voraussetzungen von ganz oben einzuleiten sind.

Erfolg muss man wollen

Das zentrale Grundprinzip der Digitalen Organisation – Vertrauen auf die Mitarbeiter und deren Assets – braucht den in den agilen Methoden geschaffenen Raum, um das kreative Potential der Mitarbeiter zu entfalten. Wie ein Staat muss sich die Organisation darauf verstehen, die Einhaltung der Regeln auch einzufordern. Die Verkündung neuer Spielregeln reicht nicht aus. Nur, wenn alle die gleichen Regeln kennen und sie sich auf deren Einhaltung verlassen können, wird sich das Vertrauen entfalten und die Kreativität mobilisiert. Diese Aufgabe obliegt den Linienvorgesetzten und SCRUM-Mastern. Diese wiederum entsprechend zu motivieren und die richtigen Anreize zu setzen, ist Chefsache.

Somit gilt für die Digitale Transformation, was für alle organisatorischen Änderungen gilt: Sie müssen wirklich von oben gewollt und verstanden werden, um erfolgreich zu greifen.

Für die Digitale Transformation gilt analog zu allen organisatorischen Änderungen: Sie müssen von ganz oben gewollt und verstanden werden, um erfolgreich zu greifen.

Es gehört viel Mut und Entschlossenheit dazu, eine bestehende Organisation, die bisher vielleicht noch nicht mal Schmerzen hat, so umzukrempeln. Nicht alle Mitarbeiter begrüßen die neu entstehende Verantwortung oder sehen Chancen darin. Diese Kandidaten gilt es zu erkennen und abzuholen.

Eine unzureichend ausgeprägte Fehlerkultur – also die Offenheit und Fähigkeit mit Fehlern umzugehen – wird eine Digitale Transformation scheitern lassen. Eine Kultur der Schuldsuche und -zuweisung eliminiert den Raum für experimentelle Fehlschläge und tötet die gewünschte Kreativität. Das ist unabhängig von der Organisationsform, aber keine andere Form ist so sehr abhängig von dieser kreativen Triebkraft. Die eigene Situation zu kennen und realistisch einzuschätzen, ist daher für die Wahl der geeigneten Transformationsmaßnahmen ausgesprochen wichtig.

Parallel-Organisation

Als verantwortlicher Entscheider sollte man durchaus das Konzept der Parallel-Organisation in Erwägung ziehen. Die Grundidee hierbei ist es, das Bestandgeschäft und die bewiesene Organisation zunächst zu bewahren, jedoch parallel dazu eine neue Organisation mit neuer Kultur aufzubauen. Diese kann dann zunächst in ihrer eigenen Geschwindigkeit Erfolge erzielen und sukzessive die Bestandsprodukte integrieren. Dieser Ansatz birgt viele Vorteile jedoch auch das Risiko der Entkopplung. Letzteres lässt sich jedoch leichter managen, als die Folgen einer verfehlten Transformation der Bestandsorganisation.

Sie suchen noch den richtigen Asatz für Ihr Unternehmen? Sprechen Sie uns an!

—–

Dies ist der zweite Artikel in einer Reihe zur Digitalen Transformation. Der erste Artikel behandelt die Werte einer Digitalen Organisation. Im nächsten Artikel werfe ich einen Blick auf die Änderungen, welche sich durch geänderte Geschäfts- und Vergütungsmodelle ergeben und wie sich dies adressieren lässt.

 

Digitale Transformation = Kulturwandel

Digitale Transformation steht ganz oben auf der Agenda vieler CxOs. Unternehmen, die sich bisher mit der Gestaltung von Maschinen oder Geräten beschäftigt haben, stehen plötzlich vor der Herausforderung, zum Software-Hersteller werden zu müssen. Software-Entwicklung ist jedoch ein seit über 30 Jahren gereifter und stark industriealisierter Prozess, der gelernt sein will.
Bei EACG haben wir in den letzten Jahren mehrere Unternehmen auf dem Weg zur digitalisierten Wertschöpfung begleitet. Zumeist haben wir für traditionelle Maschinenbau-Unternehmen SaaS-Lösungen konzipiert, entwickelt und in den Betrieb überführt. Dabei konnten wir viele Aspekte identifizieren, welche die erfolgreichen Vorhaben auszeichnen. Einige dieser Beobachtungen will ich in dieser Reihe von Beiträgen teilen und diskutieren.

Kulturunterschiede erkennen

Als ich vor gut fünfzehn Jahren meine ersten Projekte im Maschinenbau machte, gab es immer wieder Kleinigkeiten, die für Verwunderung sorgten. Seien es andere Arbeitszeiten, andere Rollenverteilungen oder auch ein anderes Eskalationsverhalten. Im Laufe der Zeit wurde mir klar: Maschinenbau und Informatik agieren in extrem unterschiedlichen Kulturen!
Dies war überraschend für mich. Kulturunterschiede kannte ich aus internationalen Projekten, nicht jedoch auf nationaler Ebene. Bildungsniveau und Nationalität aller Beteiligter waren doch gleich! Dennoch haben sich aufgrund von Ausbildung, Fokus und unterschiedlicher Herausforderungen ganz andere Verhaltens- und Denkweisen etabliert.
Auf dem Weg zur „Digital Company“ sind die Kulturunterschiede zwischen Informatik und Maschinenbau zu verstehen und zu überbrücken!
Einer der wichtigsten Schritte auf dem Weg zur „Digital Company“ liegt aus meiner Sicht darin, dies zu verstehen und anzunehmen! Bei der digitalen Transformation geht es nicht nur um Prozesse, Fertigkeiten und Technologien. Die sind notwendig, ja. Aber auch der schnellste Läufer wird nicht gewinnen, wenn er die Regeln nicht kennt, nach denen die Zeit gemessen wird. „Becoming Digital“ bedeutet einen Kulturwandel anzustreben, die Unterschiede der Herstellungsprozesse und Herangehensweise zu erkennen und zusammen zu führen.

Kundenbedarf fokussieren

Ein ganz zentraler – aus meiner Sicht der wichtigste – Aspekt ist die Zielsetzung. Während das traditionelle Unternehmen seine Produkte und Leistungen im Fokus hat, orientiert sich das „digitale“ Unternehmen noch viel stärker am Kunden. Aber was bedeutet das?
Traditionell steht im Maschinenbau am Anfang die Idee, ein Gerät zu bauen, das etwas kann, was bisher nicht geht: Automatisiertes Ernten, Züge ziehen, Gewichte heben oder bewegen, Haut sanft dehnen, um Platz für Operationen zu haben, Metall millimetergenau biegen, stanzen, fräsen, … Alles wunderbare Errungenschaften. Die Fähigkeit es zu können, macht das Gerät wertvoll. Die Funktionalität steht im Fokus der Wertschöpfung.

„Digitale Unternehmen“ stellen den Kundenbedarf noch stärker in den Mittelpunkt ihrer Wertschöpfung

„Digitale Unternehmen“ unterstellen ein anderes Grundprinzip. Sie fokussieren sich nicht auf spezielle Funktionen, sie stellen den Kundenbedarf in den Mittelpunkt: Uber fokussiert Transport, AirBNB Unterkunft, Amazon im Consumer-Bereich Beschaffung oder im B2B-Bereich den Bedarf nach flexibel nutzbarer Rechenzentrumsleistung.
Dabei ist es zunächst unerheblich, wie die zugrundeliegende Funktionalität bereitgestellt wird. Der Paketdienst spielt für Amazon-Kunden keine Rolle, weil Amazon den Kundenbedarf der zeitnahen und reibungslosen Zustellung sicherstellt. Funktionalität rückt in den Hintergrund. Das Besetzen der Kundenschnittstelle, das Bedienen des Kundenbedarfes steht im Fokus.
Das ist kein neues Rezept. Bereits Jack Welch hat mit Kundenfokus jahrelang zweistelliges Unternehmenswachstum generiert. Er erkannte in den neunziger Jahren die Bedeutung des Service- und Wartungsgeschäftes. Nicht mehr nur der Produktabsatz zählte in den Umsatz, auch die bereits ausgelieferte Basis ließ sich über Wartungsverträge kapitalisieren und trug zu Umsatzsteigerungen bei. Dabei lernte GE, sich auf die Bedarfe seiner Kunden einzulassen, was wiederum neue Produkt- und Service-Bündel entstehen ließ, die ihrerseits neue Umsatzchancen eröffneten.

MVP richtig verstehen und einsetzen

Digitale Unternehmen folgendem diesen Ansatz, gehen aber aufgrund der Möglichkeiten, die ihnen die Software-Technologie gibt, noch einen Schritt weiter: Sie konfrontieren ihre Kunden so schnell es geht mit ihrer Wertschöpfungsidee und bieten schnellstmöglich ein Minimum Viable Product (MVP) an. Sie besetzen damit den Markt oder Funktionsbereich und entwickeln das Angebot dann entlang des beobachteten Kundenverhaltens sukzessive weiter.
Dieses Konzept steht zunächst entgegen den Erfahrungen des Maschinenbauers. Ein guter Produktentwicklungsprozess sieht zwischen Produktidee und Markteintritt viele Meilensteine und Tests vor, in denen das Produkt reift. Die Sorge vor einem Rückruf bestimmt die Produktgestaltung. Hat das Produkt erst mal das Werkstor passiert, lässt es sich nicht mehr kostengünstig ändern.
Anders beim digitalen Produkt: Aufgrund der Möglichkeit, zeitnah und aufwandsarm Funktionalitäten zu ergänzen oder zu ändern, ist der MVP-Ansatz darauf ausgerichtet, das Produkt auf Basis des Kundenfeedbacks weiter zu entwickeln. Das entspricht im Maschinenbau-Verständnis einer schier endlosen Reihe, kurzläufiger Vorserien.

„Digitale Unternehmen“ stimmen MVP-Ansatz und funktionalen Fokus behutsam aufeinander ab

Die Kombination von Produkt und Software erfordert es, diese gegenläufigen Ansätze mit viel Behutsamkeit unternehmensspezifisch aufzulösen. Dabei wird je nach Produkt- bzw. Leistungsspektrum das Pendel mal stärker Richtung MVP ausschlagen, mal in Richtung abgesichertem Meilensteinprozess. Wichtig ist aus meiner Sicht vor allem der bewusst geführte Dialog, die Abwägung der Auswirkungen, die eine Öffnung der Kultur in Richtung MVP haben wird. Die Ingenieure sind darauf vorzubereiten, dass sie plötzlich MVPs entwickeln sollen. Es sind strategische Entscheidungen zur Produktgestaltung erforderlich, um die Grenze zu bestimmen, was man mit Software steuern und dem MVP-Ansatz unterwerfen will und was nicht.
Werden diese Entscheidungen nicht getroffen, besteht die Gefahr, dass die Produktpalette auf kurz oder lang in einem Update-Chaos versinkt oder die Stückzahlen zu gering ausfallen, um rentabel zu sein. Eine flexibel am Kundenbedarf ausgerichtete Wertschöpfung erfordert ein präzises Messen und Beobachten sowie ein schnelles Reagieren und Nachjustieren. Diese Abstimmung zwischen flexibler Kundenorientierung und funktionalem Fokus muss als Unternehmens-Capability verstanden und entsprechend aufmerksam durch das Management gestaltet werden.

Produktionsprozess gestalten

Ein weiterer, oft unterschätzter Aspekt ist der Produktionsprozess für Software. Kaum ein Unternehmer oder Senior-Manager würde es sich nehmen lassen, die Planung einer Produktions- oder Fertigungsstraße für ein neues Produkt zu prüfen. Aber wie viel Aufmerksamkeit und Ressourcen werden auf die Deployment-Infrastruktur für digitalen Güter investiert?
Die Software-Industrie ist seit 30 Jahren gereift. Gerade in den letzten Jahren hat sie mit dem „Infrastruktur as Code“-Paradigma eine nie dagewesene Professionalität und Reife erreicht. Die Mächtigkeit innerhalb weniger Minuten rund um den Globus Rechenzentren zu erzeugen, zu bestücken und in Betrieb zu nehmen, stellt eine unvergleichliche Effizienz dar. Sich diese Vorteile nicht zu erschließen, grenzt an Fahrlässigkeit. Die Bedeutung der Lieferkette für Software ist für Digitale Unternehmen ebenso wichtig, wie die Fertigungsstraße für produzierende Unternehmen.

Die Produktionsstraße des „Digitalen Unternehmens“ ist sein Deployment-Prozess

Unternehmen, welche die Software-Entwicklung analog zur Produktentwicklung im F&E-Bereich ansiedeln, müssen dafür sorgen, dass ein Bewusstsein für den Produktionsprozess entsteht. Eine Software-Lösung als Plattform kann nicht mehr mit einer Projekt-Kultur, welche nach dem Meilenstein X ein neues Projekt beginnen lässt, bewirtschaftet werden!
Gerade in Verbindung mit dem zuvor dargestellten MVP-Ansatz erfordert das kontinuierliche Anpassen und Ändern ein ausgefeiltes auf Regression ausgelegtes Testen sowie einen hohen Grad an Automation der Produktionskette. Ein tiefes Verständnis um die Gestaltung von Änderungen bleibt erforderlich, um schrittweise besser zu werden. Das bedeutet, der erschaffende Ingenieur muss für die Anpassungen verfügbar bleiben und kann sich nicht einfach in ein neues Projekt abseilen.

Kulturwandel als Erfolgsvoraussetzung begreifen

Die Verbindung von Software und Produkt (i.S.v. IoT) eröffnet neue Chancen. Ein Produkt bietet viel mehr Lock-In als eine reine Software-Lösung. Wechselkosten und emotionale Bindung steigen. Dennoch wird sich mittel bis langfristig nur durchsetzen, wer die Optimierungspotentiale entlang der Produktionskette ausschöpft und möglichst reibungsfrei produziert. Das wird nur gelingen, wenn die kulturellen Hintergründe der Protagonisten ausreichend berücksichtigt werden.
In den folgenden Artikeln dieser Reihe werde ich weitere Aspekte einer „Agilen Organisation“ sowie die daraus resultierenden Konsequenzen für die „Digitale Transformation“ diskutieren.
Gerne stehe ich für Diskussionen zur Verfügung. Weitere Informationen zu EACG auch unter www.eacg.de.
Oder in meinem Vortrag auf der Cloud Expo Europe diese Woche, Donnerstag, 23.11..