Second-system effect

Beim Bau von Produkten und Einführung neuer Technologie sehe ich regelmäßig den Second-system effect: Ein einfaches, gut funktionierendes System kommt an seine Grenzen und wird daraufhin aufgrund überzogener Erwartungen und übertriebenen Selbstvertrauens durch ein viel zu großes, aufgeblähtes Systeme ersetzt – und alle sind unglücklich. 🙂

Kennt ihr vielleicht. In meiner Praxis sah das zum Beispiel so aus, dass zum Beispiel einer kleine hippen Social Media Agentur eine Agenturosftware übergeholfen wird welche für altehrwürdige, große, klassische Werbeagenturen mit Print-Prozessen angelegt ist. Oder, noch krasser, dass ein eCommerce Startup Microsofts Navision einführt, und anschließend nur 20% der ursprünglich eingeführten Funktionalität am Ende des Tages nutzt und sie zu 80% mit eigenen Anpassungen ersetzt oder ergänzt hat.

Branch by Abstraction

Beim der Software Entwicklung gibt es das Prinzip von Branch by Abstraction. Das lässt sich aber auch auf die Entwicklung von Produkten und Einführung von Software im Unternehmen anwenden.

In a Nutshell

Niemals gleichzeitig ein System wechseln und den Funktionsumfang dabei erhöhen!!11

Neue Features oder andere Prozesse erst einführen,nachdem ein neues System (mit altem Umfang) etabliert ist!

Step by Step

Erst einmal Bestandsaufnahme. Was wird derzeit verwendet, was funktioniert? Basiert alles auf einem Excel / Spreadsheet? Welche Workarounds werden gerade gemacht?

Darauf aufbauend kann eine schlanke Software gebaut oder eingeführt werden, welche vom Featureset her aber in Version 1.0 erst einmal exakt die derzeitige Nutzung abbildet und die die derzeitigen Daten importiert. Nicht mehr und nicht weniger. Das ist vermutlich relativ schnell umgesetzt. Dann können die bisherigen Prozesse und Abläufe sich auf der neuen Software erst einmal eingrooven.

Anschließend dann in kurzen Sprints das System für den tatsächlichen Bedarf anpassen. Es empfiehlt sich hier ein Zweiklang:

  1. Welche Prozesse können denn grundsätzlich optimiert werden (In der Abteilung, Synchronisierung mit anderen Systemen, etc. )
  2. Wie kann das im System abgebildet werden?

Zum Schluss möchte ich noch einmal empatisieren, dass man hier mehr vom Nutzer als von der Technik aus denken sollte:

Denn ein schlechter Prozess, der digitalisiert wurde, ist ja immer noch ein schlechter Prozess

Binsenweisheit von Digitalisierungs-Beratern.

(Dieser Eintrag basiert auf einer realen E-Mail, die ich in dieser Woche an ein Startup geschrieben habe, welches gerade aus seinem Spreadsheet heraus wächst).

Veröffentlicht von Klaus Breyer

a CTO and Startup Founder/Advisor, living in Berlin.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.