Bei der Einführung von PQFORCE bei unseren Kunden stossen wir typischerweise auf folgende Situation: Da ist eine Organisation mit Dutzenden oder gar Hunderten von Mitarbeitenden. Alle diese Menschen arbeiten schon seit langer Zeit nach gewissen Abläufen. Da gibt es Projektleiter, die nach Methodik X oder Y ihre Projekte planen und steuern. Da kommen viele Entwicklungsingenieure hinzu, die Ihre tägliche Arbeit anhand von ihnen zugeteilten Tasks machen. Da gibt es aber auch Linienvorgesetzte, welche ihre Angestellten einplanen und dafür sorgen, dass alle sicherlich genügend aber auch nicht zuviel zu tun haben.

Alle diese Menschen haben mehr oder weniger eingeschliffene Tagesabläufe. Einige haben einen stark strukturierten Prozess, nach dem sie arbeiten; bei anderen sieht jeder Tag wieder etwas anders aus. Alle würden aber wohl von einer gewissen Routine sprechen, nach der sie arbeiten.

Die Firmenkultur bestimmt die Abläufe

Das hat mit den vorgegebenen Prozessen zu tun, wie sie das Management (eventuell) vorgibt. Zum Beispiel Workflow-Diagramme, nach denen die Mitarbeitenden zu arbeiten haben. Das ist je nach Arbeit und Tätigkeitsfeld natürlich auch nötig – dass ein Takt vorgegeben wird und die verschiedenen Funktionen sprich Menschen optimal zusammenarbeiten. Abläufe in einer Unternehmung haben aber sehr viel auch mit der Kultur einer Organisation zu tun. Und oftmals spielen auch die Persönlichkeit und die Gewohnheiten der Menschen hinter diesen Abläufen eine grosse Rolle, wie denn ein typischer Tagesablauf aussieht. Wer macht wann Pause, und mit wem? Ist jemand eher ein Morgen- oder Abendmensch und kommt entsprechend früher oder später zur Arbeit? Solche Aspekte haben einen grossen Einfluss auf die Kultur einer Firma.

Der Mensch, das Gewohnheitstier

Genau mit solchen Gewohnheiten der Anwender kämpfen wir bei der Systemeinführung oftmals. An den Gewohnheiten der Anwender kristallieren sich die Tool-Diskussionen. "Weshalb kann ich jetzt hier diesen Task nicht gleich verschieben?" "Wieso muss ich zuerst einen Planungsaufwand eintragen, bevor ich Ressourcen allozieren kann?" So oder ähnlich lauten die Fragen der Anwender, wenn wir PQFORCE bei Kunden vorstellen. "Naja" könnte man darauf antworten. "Weshalb machen Sie es denn anders?" – "Weil es bei uns halt so gemacht wird." lautet dann die Antwort. Und schon haben wir es. Es wird halt einfach so gemacht, aus Gewohnheit meistens. Und nicht etwa, weil ein Prozess der Unternehmung es genauso vorschreibt. Man dürfte es also durchaus auch anders machen.

Solche Gewohnheiten sind teils so stark, dass Firmen bei der Systemevaluation sehr detaillierte Testfälle vorgeben, die vom Lieferanten mit seinem System dann möglichst genau demonstriert werden sollen. Diese Testfälle widerspiegeln genau die Firmenabläufe. Dieses Evaluationsvorgehen ist nicht per se zu verurteilen. Dadurch erhält der Systemanbieter nämlich einen Einblick in die Firmenkultur. Trotzdem würde es in vielen Fällen aber völlig reichen, wenn die Essenz gefordert wird, nämlich: Was soll das Tool können, und nicht wie es dies im Detail macht. Dadurch kann der Systemhersteller auch seine Benutzungsphilosophie ins Spiel bringen und die Stärken seiner Lösung in den Vordergrund stellen.

Hinter einem (guten) Tool steckt eine Philosophie

Ein mächtiges Tool wie PQFORCE verfolgt nun eine konkrete "Benutzungsphilosophie". Und dies ist bei anderen Software-Systemen hoffentlich nicht anders. Bei der Entwicklung einer solchen Applikation macht sich der Hersteller grundlegende Gedanken, was das System können soll (d.h. Scope und Funktionsumfang) und wie es bedient werden soll (Bedienungskonzept, siehe hierzu auch diesen Artikel). Im Falle von PQFORCE haben wir dies nicht im stillen Kämmerlein gemacht, sondern in langjähriger, enger Zusammenarbeit mit Praktikern aus der Schweizer Industrie. So ist eine optimale Lösung entstanden, die auf typische Prozesse in der Industrie passt. Klar ist aber auch: Man geht bei der Umsetzung einer Benutzungsphilosophie auch Kompromisse ein. Hier ist dann die Konfigurierbarkeit gefragt, um das Tool in den Details doch auch auf die Bedürfnisse der Anwender adaptieren zu können. Also: Tool oder Prozess?

Wenn sich eine Unternehmung dazu entscheidet, ein Tool einzuführen, um die Effizienz, Produktivität, Time-to-Market etc. zu steigern, dann muss zwangsläufig auch folgende Frage beantwortet werden: Sind wir bereit, unsere Prozesse dem Tool bzw. der Benutzungsphilosophie anzupassen, oder nicht? Wer A sagt, muss auch B sagen. Wer ein Tool einführt, muss auch kompromissbereit sein. Zumindest wenn die Kosten tief gehalten werden sollen. Dann nämlich kann es nur eine Standardlösung sein, die mit einer vorgegebenen Philosophie daher kommt. Wer bereit ist, viel Geld auszugeben und sich viel Zeit zu nehmen, der kann sich eine massgeschneiderte Lösung entwickeln lassen. Diese Zeiten sind aber in unserer schnelllebigen Welt vorbei.

PS: Hier ein Link zu einem LinkedIn Post zum selben Thema.