Systemeinführung | Veränderungsmanagement

Automatisch? Oder doch lieber manuell?

Software-Systeme erleichtern uns Menschen die Verwaltung von Daten. Was früher auf Papier niedergeschrieben wurde, wird heute in Datenbanken gespeichert und von Applikationslogik verarbeitet. Der Mensch kann sich im Umgang mit Daten je länger je mehr auf das System verlassen, welches ihm die Daten automatisch verarbeitet, verdichtet, konsolidiert etc. Aber wo ist hier die Grenze? Wie weit kann eine Software die Datenverarbeitung selbständig übernehmen?

In Zeiten, wo es noch keine Datenverarbeitung gab, so wie wir sie heute als selbstverständlich erachten – in jenen Zeiten hat der Mensch die Daten noch selbst verarbeitet, von Hand. Wir können uns dies aus heutiger Sicht nicht mehr wirklich vorstellen. Wie kann das wohl gewesen sein? Eine Unternehmensbuchhaltung auf Papier zu führen, regelmässig zu aktualisieren und daraus KPIs für das Management abzuleiten...? Aber in wenigen Jahrzehnten hat sich die Geschäftswelt in dieser Hinsicht radikal verändert. Von der Betriebsbuchhaltung (von daher kommt dieses Wort ja wohl auch) zur elektronischen Datenverarbeitung mit Computern. Und dies natürlich bei Weitem nicht nur im Finanzmanagement. In allen Bereichen, wo mit Daten gearbeitet wird, sind Software-Systeme nicht mehr wegzudenken und übernehmen enorm viel Arbeit, welche in früheren Zeiten unmöglich von Hand machbar gewesen wären.

Automatisch – was heisst das eigentlich?

Die meisten von uns (und wohl insbesondere auch der Leser dieses Artikels) sind bereits mit Computern und Software-Systemen aufgewachsen. Wir sprechen dann ganz natürlich von Dingen, die "halt einfach automatisch gehen". Es ist für uns Digital Natives ja klar, dass zum Beispiel Texte in Word-Dokumenten automatisch am Zeilenende umgebrochen werden (das ist fast schon banal) oder dass der Jahresgewinn in der Erfolgsrechnung automatisch auf Basis der Einnahmen und Ausgaben berechnet wird. Wir gehen schon so salopp mit dem Begriff automatisch um, dass wir uns gar nicht immer bewusst sind, dass teilweise komplexe Logiken und Algorithmen in den Software-Systemen bzw. hinter den Vorgängen stecken, deren Ergebnisse wir dann bloss noch zu sehen bekommen.

Das Wort automatisch bedeutet gemäss Duden von selbst erfolgend. Daneben gibt es noch einige sinngemässe Definitionen. Das Wort entstammt ursprünglich dem griechischen Begriff autómatos, was etwa soviel bedeutet wie selbst denkend. Und das passt ja in Bezug auf Software eigentlich auch heute noch ganz gut – v.a. wenn wir gerade derzeit immer öfter von künstlicher Intelligenz (KI) sprechen, die ja fast schon ein Synonym für den Begriff automatisch darstellt. Zumindest wenn man daran denkt, was man sich alles von ihr verspricht.

Wenn wir uns vergegenwärtigen, was der Nutzen von Software eigentlich ist, nämlich uns Menschen die Datenverarbeitung abzunehmen, dann ist KI eigentlich bloss die ultimative Form von Software: KI versucht ganz einfach, möglichst viel Datenverarbeitung zu automatisieren. Der Computer beginnt mit KI, für uns "zu denken" (im ursprünglichen Sinn des Wortes). Etwas abstrakt formuliert: Wir geben dem intelligenten System einen Input, und dieses produziert mit ganz viel, ganz schlauer Datenverarbeitung einen nützlichen Output. Konkretes Beispiel? Ich sitze am Ende des Arbeitstages in mein Auto (dies ist mein Input), und mein Smartphone (mein intelligentes System) zeigt mir sofort, wie lange ich auf dem Nachhauseweg brauche und ob ich vielleicht besser einen Umweg fahre, um dem Stau auszuweichen (dies ist dann der Output). In diesem Beispiel muss ich den Input nicht einmal mehr "eintippen"; das System bekommt diesen automatisch anhand von Sensordaten. "Ich bin jetzt mit dem Auto verbunden und es ist Abend eines Werktages, ergo möchte mein Besitzer wohl nach Hause fahren, was er ja meistens tut in dieser Situation."

Automatische Planung im Ressourcen- und Projektmanagement

Lenken wir die Diskussion auf unser Blog-Thema Multiprojekt- und Ressourcenmanagement. Was kann ein System denn hier automatisieren? Unserer Überzeugung nach natürlich sehr viel, was wir mit PQFORCE ja auch mit jedem neuen Release in die Praxis umsetzen. Die Frage im Titel "Automatisch? Oder doch lieber manuell?" stellt sich aber trotzdem. Denn nicht alles, was automatisierbar ist, sollte auch automatisiert werden. In gewissen Situationen ist es für jedermann offensichtlich, was der Output auf einen gegebenen Input sein soll, in anderen Situation ist dies aber bei Weitem nicht so. Was für dein Einen ein "logisches Ergebnis bei diesen Eingaben" ist, ist für den Anderen "überhaupt nicht so klar".

Schauen wir uns ein einfaches Beispiel aus der Projektplanungspraxis an. Ein Projektleiter hat in seinem Projekt einen Vorgang (Task) eingeplant und darauf Ressourcen alloziert. Diesen Vorgang verschiebt er nun (aus welchen Gründen auch immer) um einen Monat in die Zukunft. Was passiert mit den Auslastungen der allozierten Ressourcen? "Logisch, die verschieben sich natürlich auch um diesen Monat." Da sind sich wohl alle einig. Die Auslastung ist ja per Definition (etwas vereinfacht) gegeben aus der Zeitperiode des Vorgangs und dem zugeteilten Zeitbudget der Ressource. Da hat wohl keiner etwas dagegen, dass das System die Auslastung automatisch nachführen soll, ja sogar muss.

Machen wir das Beispiel etwas komplizierter. Der zu verschiebende Vorgang 1 ist über eine Ende-zu-Start-Abhängigkeit mit einem anderen Vorgang 2 verbunden. D.h. Vorgang 2 darf nicht beginnen (so die Bedeutung der Abhängigkeit), solange Vorgang 1 nicht abgeschlossen wurde. Wenn nun durch die Verschiebung von Vorgang 1 dessen Ende über den Starttermin von Vorgang 2 hinausragt, was soll dann passieren? Auf den ersten Blick ist es auch wieder klar: Vorgang 2 soll auch in die Zukunft verschoben werden, "schliesslich habe ich ja deshalb auch die Abhängigkeit eingezeichnet." Auf den zweiten Blick gibt es aber Fragen. Wenn zwischen den zwei Vorgängen noch ein zeitlicher Puffer von 1 Woche vorhanden ist, um wieviel verschiebt sich dann Vorgang 2 in die Zukunft? Einen Monat? Oder bloss 3 Wochen? Hier ist es nun nicht mehr so klar. Es hängt von den Präferenzen des Projektleiters und den Rahmenbedingungen ab, die er zu befolgen hat. Der eine möchte solche Puffer genau für solche Verschiebungen nutzen, der andere betrachtet den Puffer als starr und unveränderlich (weshalb auch immer).

Und plötzlich sind Automatismen nicht mehr erwünscht

Treiben wir das Beispiel noch etwas weiter: Was, wenn Vorgang 2 gar nicht zu meinem Projekt 1 sondern zu einem Projekt 2 eines anderen Projektleiters gehört? Soll dann die automatische Verschiebung auch aktiv sein? Weiss ich denn, was das für Konsequenzen auf Projekt 2 hat? Und ist mein Projektleiterkollege glücklich damit, dass sich sein Projekt ohne sein Zutun automatisch verändert hat? Wohl kaum.

Man sieht an diesem an sich sehr einfachen Beispiel (denn die Praxis im Multiprojektmanagement ist effektiv viel komplexer...), dass automatische Systemaktionen nicht immer für jeden Anwender sinnvoll sind. Die Grenze, wo man nicht einfach mehr automatisieren sollte, könnte man etwa wie folgt ziehen bzw. definieren: Wenn der Lösungsraum der möglichen Outputs der Automatisierung klein ist (alle Befragten finden, "es gibt nur ein sinnvolles Ergebnis"), dann kann man getrost automatisieren. Sobald aber der Lösungsraum grösser wird und v.a. wenn mehrere Systemanwender von den möglichen Automatisierungsergebnissen betroffen sind (unsere zwei Projektleiter oben), dann muss eine Automatisierung sorgfältig geprüft werden. Es ist nämlich nichts schlimmer, als wenn durch eine Benutzeraktion (z.B. ein Projektleiter verschiebt einen Task in Projekt 1) im Hintergrund automatisch Daten verändert werden, die ich nicht unmittelbar sehe und deren Konsequenzen daraus ich erst später wahrnehme (z.B. der Plan von Projekt 2 hat sich nun halt auch verändert, aber das habe ich erst viel später erfahren).

Konservativer Einsatz von Automatismen, dafür genügend Hinweise bei Inkonsistenzen

Bei der Entwicklung von PQFORCE achten wir äusserst sorgfältig darauf, welche Mechanismen wir automatisieren. Die Rückmeldungen von unserer Anwenderbasis bzw. von praxiserprobten Fachleuten im Planungsgeschäft zeigt uns sehr deutlich, dass kritische Datenänderungen nicht immer zu automatischen Konsequenzen sprich Datenanpassungen führen dürfen. Unser Prinzip hier lautet: Es ist immer noch der dafür ausgebildete und erfahrene Anwender (Projektleiter etc.), der die kritischen Entscheide zu fällen hat und die entsprechenden Anpassungen an den Systemdaten (Projektpläne etc.) vornimmt. Das System soll den Menschen aber immer darauf hinweisen, wo durch Datenänderungen Integritätsverletzungen entstehen. Dieser kann dann darauf mit menschlicher Intelligenz reagieren, d.h. wohlüberlegte Entscheide treffen und umsetzen.

Wie künstliche Intelligenz (KI) im Multiprojekt- und Ressourcenmanagement trotzdem äusserst nützlich sein kann, darauf gehen wir in einem späteren Artikel ein. Bleiben Sie dran.

Über den Autor


Managing Director INTRASOFT AG

Dr. Daniel Hösli ist Managing Director und Lead Consultant bei der INTRASOFT AG, deren SaaS-Lösung PQFORCE die führende Plattform für agile, projekt-orientierte Unternehmensführung ist. Er ist seit 15 Jahren täglich mit dem Aufbau von Projektmanagementsystemen in beratender und projektleitender Funktion tätig - organisatorisch wie technisch - und hat so die Erfahrung aus unzähligen Kontakten und Aufgabenstellungen aus den unterschiedlichsten Unternehmungen und verschiedenen Managementebenen.

Nicht verpassen

Mit PQFORCE Insights bekommen Sie unsere neuesten Nachrichten, Best Practices, Tipps und Angebote direkt in Ihre Mailbox geliefert.
Wir werden Ihnen nur relevante, spamfreie E-Mails senden.
Sie können sich jederzeit mit einem Klick wieder abmelden.
Jetzt ausprobieren