Selbstorganisation als Wettbewerbsvorteil
Software-Tools erleichtern die tägliche Arbeit. Egal ob beim Projektmanagement, bei der Zeiterfassung oder im Wissensmanagement. Kleine und zuweilen auch umfangreiche Helfer gibt es für beinahe jede Aufgabenstellung. Wie gut, dass neue Software innerhalb weniger Minuten per Download auf dem Rechner verfügbar ist. Die Anmeldung bei Software-as-a-Service (SaaS) Angeboten kann teilweise sogar mit einem Klick erledigt werden.
Die einfache und schnelle Verfügbarkeit von Standardsoftware bringt Vorteile mit sich. Verbesserungen in den eigenen Abläufen können schneller umgesetzt werden als man die Worte “Prozessoptimierung” oder “Arbeitserleichterung” aussprechen kann. Vor allem Start-ups, KMUs und agile Organisationen sind in der Lage diese Vorteile zu nutzen. Im Gegensatz zu Großunternehmen, die meist über eine standardisierte Systemlandschaft verfügen, besitzen und gewähren derartige Organisationen mehr Freiraum in diesem Bereich. Freiheiten, die den Mitarbeitern eine selbstständige Auswahl der für sie besten Softwareunterstützung ermöglichen. Eine selbstorganisierte Arbeitsweise, die zu mehr Effizienz führen soll.
Die Tücken der Selbstorganisation
Mit zunehmender Freiheit geht bekanntermaßen ebenfalls steigende Verantwortung einher. In diesem Fall für ein sinnvolles Design und eine reibungslose Funktion der Systemlandschaft. Ist man sich dieser Verantwortung nicht bewusst, kann es schnell zu einer ungewollten Fehlentwicklung kommen: Eine historisch gewachsene, unübersichtliche Systemlandschaft entsteht. Im schlimmsten Fall inklusive redundanter Datenhaltung und mangelhafter Integration. Das Sahnehäubchen ist: vorhandene Softwareprodukte von denen nur die Hälfte des Teams weiß und deren Potentiale nicht ausgeschöpft werden. Und die Kirsche auf dem Systemchaos-Eisbecher? Die Nutzung mehrerer Produkte für die Erfüllung identischer Aufgaben!
Die Folge sind langatmige Suchprozesse, ineffiziente Kommunikation und doppelte Pflege von Daten und Systemen. Kurzum: Einbußen der Effizienz, die gewonnene Vorteile der Selbstorganisation zunichte machen und irgendwann sogar überwiegen.
10 Tipps für die Selbstorganisation bei der Systemlandschaft
Das Ziel ist damit klar. Die Vorteile der Selbstorganisation müssen bei der Auswahl von digitalen Arbeitsmitteln unter gleichzeitiger Vermeidung von Effizienzverlusten durch Wildwuchs gewahrt werden. Oder anders ausgedrückt: Eine performante, homogene und anpassbare Systemlandschaft soll selbstorganisiert entstehen, ohne ein Übermaß an Standardisierung einsetzen zu müssen.
Am Ende des Tages sollen auch dadurch die Individuen und deren Interaktion in den Vordergrund treten, wobei Prozesse und Werkzeuge lediglich als Unterstützung dienen.
Um das Ziel zu erreichen, bedarf es eines gewissenhaften Umgangs mit der eigenen Systemlandschaft. Und das über den gesamten Lebenszyklus der Produkte innerhalb der Organisation. Denn die Ursachen für eine Entwicklung hin zu einer unübersichtlichen Systemlandschaft liegen in allen Phasen. Von der Einführung über die Nutzung bis hin zur (Nicht-)Abschaltung.
- Klarheit über die Aufgabenstellungen, die Schmerzen und den Nutzen für einen sauberen Start
- Anforderungen auf dem richtigen Niveau für mehr Effizienz
- Frühe und umfangreiche Kommunikation für mehr Akzeptanz
- Schnelles Feedback und frühe Anpassungen der Anforderungen für eine optimale Auswahl
- Berücksichtigung der Fähigkeit zur Integration über Schnittstellen für mehr Durchgängigkeit
- Testflüge im geschützten Bereich für mehr Qualität und weniger Überraschungen
- Definition der Aufgabenbereiche der Systeme für eine intuitive Nutzung
- Anwenderschulungen für einen produktiven Einsatz
- Entscheidungen zur Abwicklung treffen für weniger Wildwuchs
- Systeme abwickeln und Daten überführen für den Erhalt von Know-how
1. Klarheit über die Aufgabenstellungen, die Schmerzen und den Nutzen für einen sauberen Start
Für den Anfang hilft eine Beschreibung der Aufgaben, die durch die Software unterstützt werden sollen. Anschließend fällt es leichter die aktuellen Schmerzen anhand unangenehmer oder ungewollter Situationen zu erörtern. Die Formulierung des Nutzens ergibt sich aus den Erwartungen an eine Situation, in der die Schmerzen und Probleme gelöst sind.
Eine visuelle Unterstützung bei der Erarbeitung dieser Inhalte bietet die rechte Seite des Value Proposition Canvas. Der Kunde ist in diesem Fall die eigene Firma, Abteilung oder das eigene Team.
2. Anforderungen auf dem richtigen Niveau für mehr Effizienz
Die Anforderungen leiten sich als Fähigkeiten oder Eigenschaften eines Systems zur Erreichung eines Ziels direkt von den aktuellen Schmerzen bzw. den Nutzen ab. Sie ergeben sich z.B. aus der Beschreibung wie negative Situationen verhindert werden können.
An dieser Stelle ist es wichtig nicht in eine detaillierte Lösungsbeschreibung abzudriften und die Art und Weise der Umsetzung von Anforderungen kleinteilig zu definieren. Besser ist es ein höheres Abstraktionsniveau beizubehalten. Die Software soll schließlich nicht selbst entwickelt werden. So sollte, wenn es bspw. um eine Software für das Projektmanagement geht, nicht beschrieben werden welchen einzelnen Status eine Aufgabe haben kann. Besser ist es zu beschreiben, dass die Aufgaben des Teams übersichtlich einem Status zugeordnet werden sollen.
Als Unterstützung für diese Aufgabe kann die linke Seite des Value Proposition Canvas herangezogen werden (Grafik siehe Tipp 1).
3. Frühe und umfangreiche Kommunikation für mehr Akzeptanz
Eine neue Standardsoftware wird nur bei einer ausreichend großen Akzeptanz durch die Anwender wirklich genutzt. Deshalb ist es notwendig neue Software intern bestmöglich zu “verkaufen”. Das geschieht nicht durch die Präsentation von Hochglanz-Folien oder den Verweis auf die Designer-Homepage des Herstellers. Die Akzeptanz kommt durch eine konsequente Einbeziehung der betroffenen Personengruppen von Beginn an, d.h. bereits bei der Auseinandersetzung mit den Problemstellungen. So werden die Fakten frühzeitig kommuniziert. Ziele werden verdeutlicht und Vorteile aufgezeigt. Kurzum: Der Grund für die Einführung einer Standardsoftware wird verdeutlicht.
Die Kommunikation und Einbeziehung muss selbstverständlich auch im späteren Stadium beibehalten werden.
4. Schnelles Feedback und frühe Anpassungen der Anforderungen für eine optimale Auswahl
Eine frühe und umfangreiche Kommunikation führt neben Akzeptanz zu schnellem Feedback der Kollegen. Die Anforderungen können so frühzeitig angepasst und geschärft werden. Auch die Sondierung des Markts führt häufig zu Änderungen der Anforderungen. Nicht selten werden Dinge entdeckt, von denen man nicht wusste, dass sie eigentlich wichtig sind. Es geht aber auch in die andere Richtung, nämlich wenn sich das Gefühl breit macht man sei mit seinen Anforderungen alleine auf der lieben weiten Welt. Der Prozess der Anforderungsvalidierung sollte in jedem Fall strukturiert vonstatten gehen, sodass sich stets die aktuellen Anforderungen im Blick befinden.
Wichtig ist, sich nicht bei dem Versuch zu verlieren die “eierlegende Wollmilchsau” zu finden. Ob es die perfekte Lösung im Standardsoftware-Dschungel gibt, ist ohnehin fraglich. Schließlich ist eine Standardsoftware mit handhabbaren Konfigurationsmöglichkeiten gefragt. Ein sechsmonatiges Software-Einführungsprojekt mit hohem Customizing-Aufwand ist für das kleine "Helferlein" im Geschäftsalltag nicht zielführend. Mit dieser Haltung ist es nicht gravierend gewisse Beschränkungen und Umsetzungskonzepte der Anbieter zu akzeptieren.
5. Berücksichtigung der Fähigkeit zur Integration über Schnittstellen für mehr Durchgängigkeit
Bei der Auswahl neuer Software sollte darauf geachtet werden, dass sie sich mit der bestehenden Systemlandschaft verträgt. Die Vereinfachung oder Automatisierung an der einen Stelle darf nicht zu Lasten der Durchgängigkeit an einer anderen Stelle führen. Zusätzliche, manuelle Arbeitsschritte sind zu vermeiden.
Bei der Einführung eines Tools zur Zeiterfassung ist daher bspw. darauf zu achten, dass diese mit dem System zur Rechnungserstellung kommunizieren kann. Eine nutzerfreundlichere Erfassung der Arbeitszeit hilft wenig, wenn sie die Zeiten am Ende des Monats händisch in die Rechnung übertragen werden müssen.
Wenn der Arbeitsfluss durch neue Software schon nicht verbessert werden kann, darf er ihn zumindest nicht beeinträchtigen. So steht hier eine Abwägung zwischen der Funktionalität im Einzelnen der Durchgängigkeit des Gesamtprozesses gegenüber.
6. Testflüge im geschützten Bereich für mehr Qualität und weniger Überraschungen
In der Entwicklung wird Software vor dem produktiven Einsatz anhand der Akzeptanzkriterien getestet. Auch bei der Einführung neuer Standardsoftware ist es mehr als ratsam vor der umfassenden, produktiven Nutzung zu prüfen, ob die Anforderungen wie gewünscht umgesetzt werden können. Das gilt auch bei überschaubaren Szenarien wie bspw. der Einführung einer Software für die Durchführung von Retrospektiven in einem Scrum-Team.
Dabei ist es wichtig, einen abgesteckten Zeitraum zu definieren, in dem die neue Software getestet wird. Auch die Kriterien für die Go bzw. No-Go Entscheidung sollten vor den Tests definiert sein.
Im Idealfall kann die Software in einem geschützten Bereich getestet werden, z.B. innerhalb eines kleinen, internen Projekts.
7. Definition der Aufgabenbereiche der Systeme für eine intuitive Nutzung
In heterogenen Systemlandschaften kommt es nicht selten dazu, dass sich verschiedene Softwareprodukte zu Teilen in ihren Funktionen überschneiden. Ist keine Abgrenzung zwischen den Systemen erfolgt, führt dies zu Unsicherheit bei der Nutzung. Wo soll beispielsweise die Anforderungsänderung samt Screenshot dokumentiert werden, wenn die Software für das Projektmanagement einen Bereich für die Dokumentation bietet, es ein geteiltes Laufwerk gibt und auch noch eine Wiki-Software im Einsatz ist?
Aus diesem Grund ist es notwendig gemeinsam eine einheitliche Nutzung der verschiedenen Produkte zu definieren, sodass die Systemlandschaft als Ganzes einheitlich und intuitiv genutzt werden kann. Einstellungen und Konfigurationen der Infrastruktur, welche die Nutzung der kollaborativen Produktwelt unterstützen, müssen von Beginn an beachtet und vorgenommen werden. Poka-yoke.
8. Anwenderschulungen für einen produktiven Einsatz
Mindestens genauso wichtig für die Akzeptanz neuer Standardsoftware wie die richtige Kommunikation ist die Anwenderschulung. Auch wenn die Software noch so klein und noch so einfach wirkt. Für den einen oder anderen Anwender kann sie verwirrend oder wenig intuitiv erscheinen.Werden solche Mitarbeiter nicht wenigstens kurz in die neue Software eingeführt, macht sich schnell Unmut breit und das kleine Projekt droht zu scheitern. Denn klar ist: Erst durch die richtige Bedienung einer Software kann deren Potenzial voll ausgeschöpft werden. Bei komplexen Programmen lohnt sich ggf. eine etwas umfangreichere Schulung.
9. Entscheidungen zur Abwicklung treffen für weniger Wildwuchs
Das wahrscheinlich wichtigste Instrument zur Vermeidung von Wildwuchs in der Systemlandschaft ist aktiv Entscheidungen zu treffen. Vor allem die Entscheidung, Softwareprodukte abzuschaffen bzw. abzuschalten. Wird ein System nicht mehr genutzt, bringt es keinen Mehrwert und sollte die Systemlandschaft nicht unnötigerweise aufblähen. Die Entscheidung zur Abschaltung eines Systems spart ganz nebenbei nicht selten bares Geld.
Um eine solche Entscheidung treffen zu können ist es notwendig zu beobachten, ob die Systemlandschaft so genutzt wird wie gedacht. Schleichen sich in der täglichen Arbeit Veränderungen ein heißt das nicht, dass Maßnahmen ergriffen werden müssen, um an der ursprünglichen Idee zur Nutzung festzuhalten. Es ist vielmehr ratsam zu erörtern warum sich die Veränderungen ergeben und sich gemeinsam auf eine neue Art und Weise der Nutzung zu verpflichten. Dies kann bspw. innerhalb einer regelmäßig stattfindenden Retrospektive geschehen.
10. Systeme abwickeln und Daten überführen für den Erhalt von Know-how
Ist die Entscheidung zur Abschaltung eines Systems gefallen, ist das bereits die halbe Miete. Die Abschaltung sollte jedoch nicht kopflos von heute auf morgen erfolgen. In dem abzuwickelnden System wurde gearbeitet und es steckt ggf. wichtiges Know-how darin. Dieses Wissen kann sowohl sehr direkt in Form von Dokumentation vorliegen oder indirekt bspw. in angelegten Workflows stecken. Wichtig ist, dass das Know-how in das neue oder in andere Systeme übertragen wird, sodass keine Verluste entstehen.