Diversifikation oder Spezialisierung? – IT-Governance Blog

Eine Herausforderung, die mich seit dem Beginn meiner Beratungspraxis beschäftigt, ist die Frage nach dem strategisch besseren Ansatz, nämlich Spezialisierung oder Diversifikation. Dass Diversifikation bei Finanzanlagen sinnvoll ist, ist unbestritten. Anders sieht es meiner Meinung und Erfahrung nach bei der Wahl des Kompetenzprofiles eines Unternehmens oder auch bei der persönlichen Karriereplanung aus. Der Generalist wird regelmäßig als Ideal gesehen. Wenn es aber zur Entscheidung kommt, bevorzugen Kunden und Arbeitgeber regelmäßig die Spezialisten.

Spezialisierung – wie geht das?

Die fundierteste Aussage dazu kommt von Wolfgang Mewes, dem Begründer der EKS („Engpasskonzentrierte Strategie“). Mehr zur EKS gibt es auch in meinen Podcasts hier. Die EKS unterscheidet drei grundsätzliche Spezialisierungsmöglichkeiten, wobei diese in aufsteigender Reihenfolge präferiert werden:

  1. Primärspezialisierung: Fokussierung auf bestimmte Produkte, Materialien, Dienstleistungen etc. Die klassische Form der Spezialisierung, vielfach erfolgreich, aber auch risikoreich, weil mit Substitution durch Innovationen gerechnet werden muss. Die EKS wertet diese Variante als immer noch viel besser als keine Spezialisierung. Sie sollte aber nur ein Durchgangsstadium zu den besser abgesicherten Spezialisierungsformen sein.

  2. Problemspezialisierung: Der Trend zu dieser Form der Spezialisierung ist heute weit verbreitet: Automobilhersteller und die Bahn positionieren sich als Spezialisten für Mobilität, Telekomunternehmen als Spezialisten für Kommunikation etc. Diese Spezialisierung ist wesentlich nachhaltiger. Sie erfordert aber entsprechendes Potenzial, um die versprochenen Leistungen auch tatsächlich zu erbringen. Wenn man seine Fertigungstiefe reduziert und das eigene Leistungsportfolio durch Kooperationen sinnvoll ergänzt, kann man auch mit limitierten Ressourcen eine Problemspezialisierung umsetzen.

  3. Zielgruppenspezialisierung: Das strategische Ziel einer EKS-konformen Strategie ist es, „Zielgruppenbesitzer“ zu werden. Diese Spezialisierung ist die höchste und nachhaltigste Variante. dazu gehört ein tiefes Verständnis einer Gruppe von Menschen, die durch gemeinsame, identitätsstiftende Merkmale verbunden sind. Dazu genau selektierte Problemspezialisierungen. Schließlich macht das Vertrauen dieser Zielgruppe in die eigene Person oder ein Unternehmen den Kern dieser Variante der Spezialisierung aus. Red Bull exerziert das in großem Maßstab vor. Man adressiert Menschen, die einen gewissen Kick suchen und bietet diesen ein Getränk (das man nicht selbst herstellt) an. Man sponsert zum Image passende Sportler bzw. Sportarten und Events. „Nebenbei“ verkauft man dieser Zielgruppe und allen, die gerne dazu gehören würden noch Fernsehen, Mobiltelefon (auch hier wird die Produktion anderen überlassen), Zeitschriften etc.. Das Kapital des Unternehmens besteht überwiegend aus ideellen Werten.

Praktische Anwendungsfälle der EKS

Prominente Anwendungsfälle der EKS sind Kärcher, Fielmann und Kieser Training. Auch die wenig bekannten, aber durchwegs am Weltmarkt führenden mittelständigen Unternehmen, die Hermann Simon als Hidden Champions bezeichnet und analysiert und vorgestellt hat gehören dazu. Sie  sind – ob aufgrund bewusster oder intuitiver Anwendung – Belege für das Erfolgspotenzial der EKS. Nicht zuletzt ist auch Lothar Seiwerts Positionierung als „Zeitmanagement-Experte“ und nachfolgend die Weiterentwicklung (gemeinsam mit Tiki Küstenmacher) zum vielschichtigen Konzept des „Simplify your life“ ein Paradebeispiel. Hier wurde ganz bewusst gemäß der EKS vorgegangen. Schließlich ist Lothar Seiwert einer der Autoren der offiziellen Einführung in die EKS. 

Meine praktische Erfahrung damit: Es leuchtet fast jedem Menschen ein, dass diese Empfehlung richtig ist. Nur wenn es um einen selbst geht, kann man auf kein Geschäftsfeld verzichten etc. Es ist wahrscheinlich kein Zufall, dass die meisten EKS-Erfolgsgeschichten mit einer ganz schlimmen Krise oder mit einem überraschend großem Erfolg begonnen haben. Aus einer moderaten Komfortzone heraus ist der Schritt sehr schwierig.

Wenn Sie das als Podcast hören wollen, gibt es hier die erste Folge einer Einführung in dieses Thema.

Eine Zusammenführung der Ansätze von „Business Model YOU“ und der EKS gibt es in einem ausführlichen Blogbeitrag hier. 

Wenn Sie das Buch zur EKS lesen wollen, finden Sie es hier:

Projekte und ihre Auftraggeber – IT-Governance Blog

Der Fisch beginnt am Kopf zu stinken. Das ist eine allgemeine Volksweisheit.

Richtig: die wichtigsten Entscheidungen fallen bevor ein Projekt startet und auch danach vor allem außerhalb des Projektes. Kein Projektmanager kann in vielen langen Arbeitstagen soviel falsch oder richtig machen wie es Projektauftraggeber innerhalb von Minuten ganz nebenbei schaffen.

Projekte sind wie Autos. Die Macken, die auf den ersten Kilometern auftreten, bleiben einem bis zum Ende erhalten. Wenn also der Projektauftrag unklar ist, keine Entscheidungen fallen, Verbindlichkeit ein Fremdwort bleibt, die Personalzuordnungen nicht geklärt werden usw. usw. Gehen Sie davon aus, dass Sie genau diese Probleme bis zum Abschluss des Projektes begleiten werden!

Was kann man tun? Wenn Flüchten keine Option ist, dann sollte man zuerst auf das eigene Überleben achten. Auch wenn es für ambitionierte Projektmanager sehr schwer zu akzeptieren ist, man kann solche Mängel nicht durch noch so intensives und professionelles Projektmanagement ausgleichen. Man kann aber Schadensbegrenzung betreiben. Vielleicht gibt es Stakeholder, mit denen man sich verbünden kann und die einflussreich genug sind, für die unbedingt notwendigen Weichenstellungen zu sorgen. Aber Vorsicht, das kann ins Auge gehen, wenn man naiv in Machtspiele hinein tappt.

Meine Empfehlung: Immer versuchen, das zu tun, was man für vernünftig hält und wofür man sich nicht genieren muss. Auch wenn das Projekt scheitert, kann man wenigstens weiter in den Spiegel schauen ohne zu erröten. Aber man soll auch darauf achten, dass man mit seinen Kräften haushält. Ich habe schon zu viele exzellente Leute erlebt, die an einem „Todesmarschprojekt“ zerbrochen sind, weil sie ihre ganze Energie in ein Projekt investiert haben, das von Anfang an zum Scheitern verurteilt war.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Es gibt kein Perpetuum mobile

Projekte liefern Ergebnisse innerhalb zu einem definierten Termin mit einem gewissen Aufwand. Das „magische Dreieck“ des Projektmanagements bildet das einfach und treffend ab.

Der Gesamtaufwand hängt von vielen Faktoren ab. Die entscheidenden Weichen werden in den Anfangsphasen eines Projektes gestellt. Fehlentscheidungen können später nur noch mit beträchtlichem Aufwand rückgängig gemacht werden. Welche Faktoren den Aufwand bestimmen, habe ich hier ausführlicher beschrieben.

Wie viel man leisten kann, hängt auch davon ab, wie gut man arbeitet, also von den Prozessen. Ist das Projekt gestartet, kann man durch Drehen an diesen Schrauben auch nur limitierte Effekte erreichen.

360PM_Magische_Dreieck

Soll es also schneller gehen, müssen ab einem relativ frühen Zeitpunkt im Projekt entweder die Ergebnisse reduziert oder die Ressourcen aufgestockt werden.

Soll mehr geliefert werden, müssen die Ressourcen aufgestockt und meist muss auch der Termin verschoben werden. Das Aufstocken des Projektteams bringt in späteren Projektphasen wenig oder ist sogar kontraproduktiv. Die Prozessqualität liegt innerhalb eines gewissen Korridors und ist nicht mehr wesentlich steigerbar.

Es gibt nicht nur in der Physik keine Maschine, die mehr Output bei gleichem Input produziert.

Geht nicht gibt’s doch! – IT-Governance Blog

Sehr beliebt sind bei manchen Top-Managern Statements wie: „Geht nicht gibt‘s nicht“ oder „Kommen Sie mit Lösungen zu mir, nicht mit Problemen“.

Wenn man das regelmäßig hört, gibt es eine ganz einfache Regel: Nichts wie weg! In so einem Umfeld gelingen nur triviale Projekte, bei allem was anspruchsvoll und risikoreich ist, sollte man die Katastrophe schon fix einplanen. Und wenn diese eintritt, ist es immer besser, weit weg zu sein.

Wenn die Rahmenbedingungen eines Projektes nicht stimmen, kann das niemand und nichts ausgleichen. Ambitionierte Termine, knappe Budgets, hohe Qualitätsansprüche: alles OK, das gehört dazu, stachelt zu Leistungen an, die man sonst niemals bringen würde. Aber Unmögliches wird auch in Projekten nicht sofort erledigt und Wunder dauern leider ewig.

Kluge Auftraggeber rechnen immer damit, dass etwas nicht so läuft wie geplant und reagieren gelassen und unterstützend, wenn Probleme auftreten.

Wenn Sie regelmäßig über neue Blogs informiert werden wollen, tragen Sie sich bitte hier ein. Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Änderungsschneider sind keine Couturiers – IT-Governance Blog

Es ist ein prinzipieller Unterschied, ob man ein vorhandenes System schrittweise verbessert oder ein gänzlich neues System entwickelt. Wenn z.B. nach meist Jahrzehnten eine historisch gewachsene Software-Landschaft großflächig abgelöst werden soll, braucht man die Kenner des Ist-Systems um die Anforderungen an das neue System zu definieren.

Leider sind aber genau diese Personen es gewohnt, in kleinen Schritten und überschaubaren Einheiten zu denken und zu arbeiten. Der große Wurf (eine grundlegend geänderte Systemphilosophie) verlangt aber ein Verlassen gewohnter Lösungsmuster.

In der Praxis übernehmen die Neuplanung oft Berater, die das Ist ignorieren: wir wollen ja etwas ganz Neues machen. Der Teufel liegt im Detail und je näher man am Ziel zu sein meint, umso härter schlagen diese Lücken der Spezifikation zu.

Überlässt man die Entwurfsarbeit allerdings den Kennern des historisch gewachsenen Ist-Systems, kommt nur wenig Innovation zustande.

Die beste Lösung ist es, die kühnen Entwürfe der professionellen Innovatoren einer sorgfältigen Prüfung gegen alle Details zu unterziehen, die von den Hütern des Ist-Systems vorgebracht werden. Diesen für alle Beteiligten anstrengenden Dialog konstruktiv abzuwickeln, fordert die soziale Kompetenz der Projektmanager.

Business Rules Engines – wirkungsvoller Hebel zur Flexibilisierung

Seit Anfang der 90-er Jahre beschäftigt mich das Thema der Implementierung von Geschäftsregeln. Am Anfang stand für mich die Frage, wie man die Geschäftsregeln von Versicherungen in einer Weise in Software umsetzen könnte, dass dies nicht mehrfach erfolgen muss. Dazu kam für mich noch der Anspruch, dabei die regelmäßig auftretenden Kommunikationsprobleme zwischen den Entwicklern und den Wissenden der Fachbereiche zu vermeiden.

Das Ergebnis war 1995 ein Produktdefinitionssystem für Versicherungen, dessen Architektur ich von den CAD/CAM-Systemen in der Industrie übernommen hatte. Einerseits ein Definitionsarbeitsplatz (vergleichbar dem CAD-System eines Konstrukteurs) und andererseits eine ausführende Instanz (vergleichbar den numerisch gesteuerten Werkzeugmaschinen). Ausführlichere Informationen dazu gibt es auf Wikipedia und auf meiner persönlichen WebSite hier.

Heute, gut 20 Jahre später erscheint das vergleichsweise logisch, immerhin sprechen wir über 3D-Drucker, die dieses Paradigma für alle möglichen Produkte umsetzen. Erstaunlich allerdings, dass auch heute noch Anwendungen entwickelt werden, in denen die Geschäftsregeln auf Grundlage von Pflichtenheften oder sogar weitgehend unstrukturierten Vorgaben der Fachbereiche von Softwareentwicklern „hart“ codiert werden. Soeben begegnete ich in einem Projekt einem Gutachter, der den Nutzen einer Separierung der Geschäftsregeln von der sonstigen Ablauflogik als unerheblich abtat.

Mittlerweile gibt es eine Reihe von Produkten, die den Ansatz einer Regeldefinition in der Sprache des jeweiligen Fachexperten verfolgen und aus dieser möglichst natursprachlichen Regeldefinition ausführbaren Code erzeugen, der in verschiedene Anwendungssysteme eingebunden werden kann. Ich nenne hier Oracle Intelligent Advice, IBM Decision Center Business Console und die SAP Business Rules Management Technologies.

Anzumerken ist, dass bei Versicherungsprodukten das Zusammenspiel von anspruchsvollen Berechnungen und logischen Regeln eine besondere Herausforderung darstellt, die von den gängigen Business Rules Engines auch heute noch nicht bewältigt werden kann. Das ist aber kein Argument gegen deren Einsatz in zahllosen Bereichen, die solche Anforderungen nicht aufweisen.

Wer sich mit dem Thema der Geschäftsregeldefinition ganz allgemein vertraut machen möchte, findet in der Business Rules Community ein hochinteressantes Angebot. Meine Motivation, dieses Thema wieder verstärkt zu bearbeiten, wurde durch diese Community deutlich gesteigert.

 

Big Data ist mehr als ein Hype und auch mehr als nur Technologie

Die Kombination von Daten unterschiedlichster Struktur galt in der Ära der unternehmensweiten Datenmodelle als Todsünde gegen den Heiligen Geist des Software-Engineering. Ich gebe zu, dass ich diese Einstellung nie geteilt habe und seit einigen Jahren dabei immer sicherer wurde.

Big Data werden nun Daten kombiniert, die eigentlich imkompatibel sind. Sie haben unterschiedliche Zeitstempel, unterschiedliche Schlüssel (bezogen auf einzelne Personen, Gruppen von Personen, Orte und Regionen etc.). Siehe da, diese Kombination erweist sich als sinnvoll und es sind Erkenntnisse möglich, die es so bisher nicht gab (jedenfalls nicht mittels Datenverarbeitung). Als Psychologe mit dem Schwerpunkt mathematische Psychologie habe ich die Arbeit mit angeblich weichen Daten schon früh kennen und schätzen gelernt. Persönliche und ein wenig polemische Anmerkung: Seit man erlebt, wie die harten Daten von Bankbilanzen um zweistellige Milliardenbeträge (Euro, nicht Schilling!) falsch sein können, frage ich mich allerdings, welche Daten wirklich hart und welche weich sind.

Mit Big Data geht es auch um eine andere Art der Projektabwicklung. Wasserfallmethoden sind hier völlig inadäquat, explorative, iterative und letztlich agile Vorgehensmodelle sind der Normalfall, wenn man erfolgreich sein will. Ich fühle mich in dieser Welt sehr wohl, es ist fast so etwas wie eine Heimkehr zu den Anfängen meiner beruflichen Laufbahn (das im Sinne eines Spiralmodells zu verstehen, denn ich denke, dass ich heute schon weit mehr davon verstehe als damals).

Die Big Data Tagung der ADV, die am 24.9.2014 stattgefunden hat und an deren Konzeption und Organisation ich wesentlich beteiligt war, hat dazu viel an praktischen Erkenntnissen gebracht. Einen Einblick findet man in Twitter mit dem Hashtag #advbigdata2014.

Projektstrukturplan – bitte nicht phasenorientiert!

In der Baseline der PMA (Projektmanagement Austria) finden sich zum Projektstrukturplan folgende Aussagen:

„Ziel des Projektstrukturplans (PSP) ist die phasenorientierte Darstellung der Leistungsplanung in Form eines Baumdiagramms. Das Denken in Projektphasen fördert eine prozessorientierte Strukturierung von Projekten. Der PSP enthält alle in einem Projekt zu erfüllenden Aufgaben, die in Arbeitspaketen abgebildet werden.“

Das klingt gut, denn wer kann schon dagegen sein, prozessorientiert zu denken. Trotzdem ist das eine Empfehlung, die viel Schaden anrichten kann und kürzlich habe ich beim Review eines Projektes auch die negativen Folgen dieses Ansatzes konkret beobachten können. Der Prozess war dort nämlich ein Wasserfallmodell der Softwareentwicklung und die Umstellung auf ein iteratives Vorgehen stieß auf methodische Bedenken unter Berufung auf PMA.

Wofür ist ein PSP wirklich da? Schauen wir in die ISO 21500:

„Das Erstellen des Projektstrukturplans hat den Zweck, eine hierarchisch gegliederte Darstellung der zur Erreichung der Projektziele auszuführenden Arbeiten zu schaffen. … Er kann zum Beispiel nach Projektphasen, zentralen Lieferobjektiven, Fachbereichen und Standorten aufgeschlüsselt sein. … Es ist möglich, andere hierarchische Strukturen für die methodische Bewertung der Elemente wie Lieferobjekte, Organisation, Risiko und Kostenrechnungserfordernisse des Projektes zu entwickeln.“

Siehe da, das Ziel ist eben nicht die phasenorientierte Darstellung, sondern die vollständige Darstellung dessen, was zu tun ist. Und Phasen oder Prozessschritte sind eine von vielen Möglichkeiten, die Vollständigkeit des PSP zu gewährleisten, aber keinesfalls die zu präferierende. Welcher Maschinenbauer käme auf die Idee, die Stückliste nach den Produktionsprozessen zu gliedern. Das geht schon allein deshalb nicht, weil die Prozesse zu komplex und verschachtelt sind.

Die Empfehlung ist auch nicht durch die IPMA Baseline gedeckt, als deren österreichischer Repräsentant PMA sich positioniert. Dort fehlt zwar überraschenderweise das Wort „Projektstrukturplan“ völlig, aber unter dem Titel „Strukturen“ wird durchaus zutreffend festgestellt:

„Projekte können von verschiedenen Gesichtspunkten aus in ihre Bestandteile zerlegt werden, so z.B. bezüglich der Projektstruktur, der Projektorganisation, der Projektkosten oder der Informations- und Dokumentationsstruktur“ … Hierarchische Strukturen dienen dazu, sicherzustellen, dass im Rahmen des Projektes nichts vergessen wird.“

Von PMI gibt es übrigens eine eigene Richtlinie zur Erstellung der Work Breakdown Structure, die selbstverständlich auch die Vielfalt an möglichen Gliederungskriterien darstellt. Die Richtlinie ist für Mitglieder des PMI kostenlos verfügbar.

Daher der Appell: Überladen wir den PSP nicht mit Gesichtspunkten, die dort nicht hingehören. Es hängt vom Projektkontext ab, welche Gliederung sinnvoll ist. Es ist auch nicht für jeden Zweig der Baumstruktur die gleiche Untergliederung sinnvoll und notwendig. Welche Untergliederungen möglich und sinnvoll sind, steht in der ISO21500 und noch detaillierter in der Leitlinie von PMI. Welche Gliederungskriterien es in einem konkreten Projekt sein sollen, muss man selbst herausfinden, die vom PMA als einziges Kriterium empfohlene Phasengliederung ist es allerdings fast nie.