Büromanagement-Software-Suche: Warum wir uns für die Eigenentwicklung entschieden haben

Antwort: Wir hatten im Vorfeld zwei Branchenlösungen im Einsatz. Die erste von 2005 bis 2014, die zweite ab 2014. Mit beiden sind wir permanent an Grenzen gestoßen. Wir waren schon 2005 von verschiedenen Bauherren als Generalplaner beauftragt. Eine Übersicht, die die komplexe Wirtschaftlichkeit abbildete, gab es einfach nicht. Außerdem wollten wir unseren gesamten Prozess in der Software abbilden. Nicht, dass wir uns hier falsch verstehen: Planung erfolgt mit CAD, Ausschreibung mit einer AVA-Lösung. Aber alle Informationen rund um das Projekt, also, wo stehen wir eigentlich und was ist kurz, mittel- und langfristig zu tun, wer sind die Ansprechpartner, wie ist der Leistungsstand, etc. - all das sollte in einem Tool verbunden werden.

Antwort: Ja, natürlich. Sie sollte flexibel sein, Anpassungen sollten in kurzer Zeit umgesetzt werden können, anwenderfreundlich und zuverlässig.

Antwort: Wir nutzen die Low-Code-Plattform NINOX. NINOX wirbt damit, dass sich auch Laien selbst in diese Art der Programmiersprache einfinden können. Es handelt sich, wie gesagt, um eine Low-Code-Plattform. Das bedeutet, dass es eben keine Programmiersprachenkenntnisse benötigt. NINOX bietet sehr viele Hilfen an, um sich die NINOX-spezifischen Codes anzueignen. Darum kommt man auch hier nicht herum. Allerdings fehlte uns dafür die Zeit. Daher haben wir uns für einen externen „Programmierer“ entschieden. Nach dem ersten „Fehlgriff“ (auch das muss man einkalkulieren, wenn man auf Externe setzt) haben wir die freedom manufaktur gefunden, mit der wir bis heute sehr gut zusammenarbeiten. Es ist auch nicht damit getan, einfach mal loszuprogrammieren, sondern man muss auch hier Struktur in Tabellen und Untertabellen bringen, sonst wird das System unübersichtlich und evtl. auch langsam. Ich kenne aber auch zwei Büros, die es intern übernommen haben. Allerdings ist das, was ich gesehen habe, nicht so umfangreich, wie unsere Anwendung.

Antwort: Das ging bei uns sehr schnell, da wir im Vorfeld schon viel an unseren Strukturen gearbeitet hatten. Diesen Prozess beschreiben wir in unserem Buch „Digital Brain meets architectural heart“. Er ging über viele Jahre. Unterstützung hatten wir dabei von Dr. Werner Preißing, der uns jahrelang begleitet hat. Die von ihm entwickelte Methode ERLAP. half uns, unsere Prozesse zu erkennen, teilweise neu zu definieren und eben auch abzubilden. Als wir mit der freedom manufaktur, die die „Programmierung“ der Anwendung übernehmen sollte, den Workshop zur Leistungsdefinition machten, ging das innerhalb eines Tages. Auch diesen Prozess beschreiben wir in unserem Buch. In diesem Workshop haben wir den gesamten Prozess, den wir als Elefant bezeichnet haben, definiert und einzelne Module als einzelne „Häppchen“ des Elefanten (Bein, Kopf usw.) abgegrenzt.

Antwort: Auf jeden Fall, das war eines unserer wichtigsten Kriterien. Wir wollten keine fertige Lösung bekommen, die dann langwierig getestet wird, sondern Stück für Stück entwickeln. Daraus ergab sich dann auch die Arbeitsweise, die man vielleicht als agile Methode bezeichnen kann. Bekannt ist das aus der EDV- bzw. Scrumwelt. Es wurden Arbeitsabschnitte definiert, die Entwicklung wurde mit einer kleinen Gruppe im Wochenrhythmus besprochen. Daraufhin wurde es an alle Mitarbeitenden zum Testen gegeben. Hört sich vielleicht verrückt an, war es aber in keinster Weise. Durch diese Art der Umsetzung waren alle mit im Boot, konnten Feedback geben, Wünsche äußern. So sind dann manche Dinge vorgezogen worden oder auch nach hinten gerutscht.

Antwort: Wir waren da mit freedom sehr gut aufgestellt. Wir waren in unseren Strukturen sehr sicher. Dadurch konnten wir klar vermitteln, was wir wollten. Die IT-ler lieferten dann das Konzept für die Umsetzung.

Antwort: Ja. Wir wollten einfach nicht wieder eine fertige Lösung, lange Schulungstage für die Mitarbeitenden, die dann zurückkommen und sagen: „ja, das war interessant, die Praxis wird es zeigen“. Durch die Einbindung aller gab es schon von Anfang an eine hohe Akzeptanz. Dass Mitarbeitende nicht alle in gleichem Maße engagiert sind, wissen Sie und wir auch. Aber wer wollte, konnte immer gerne mitreden. So dauerte die allererste Einführung keine 15 Minuten.

Antwort: Begonnen haben wir 2021. In diesem und dem darauffolgenden Jahr haben wir intensiv an der Entwicklung gearbeitet. Die Umsetzung erfolgte ja, wie gesagt, immer in Wellen: Entwicklungspaket definieren, erste Umsetzungen anschauen, testen und in die Liveversion übernehmen.

Antwort: Tja, den Nutzen kann man nicht nur daran messen, was es kostet. Es gibt viele weiche Faktoren, die wir nun in der Umsetzung erkennen: Akzeptanz des Tools durch die Mitarbeitenden, große Transparenz in den Projekten, die es ermöglicht, dass Vertretungen besser agieren können oder kürzere Besprechungszeiten. Wir wollten mit dem Tool insgesamt eine bessere Performance erreichen. Das haben wir in jedem Fall erreicht.

Antwort: Eine der Herausforderungen war die Programmierung der Angebots- und Rechnungslegung. Jeder, der HOAI-konforme Angebote und Abrechnungen erstellt, kennt die Komplexität. Hinzu kommen ja mittlerweile jede Menge Leistungen außerhalb der HOAI. Es gibt einfach unglaublich viele Szenarien. Das alles einem außenstehenden IT-ler zu vermitteln, ja, da rauchten manchmal die Köpfe. Positiv dabei überrascht hat uns dann aber auch wieder die unbestechliche Logik der Anwendungsprogrammiererin. Eine weitere Herausforderung ist natürlich, dass man auch hier nicht völlig unabhängig im freien Raum agiert. Wir sind auf die Entwicklung der Datenbank, die unserer Anwendung zugrunde liegt, angewiesen. Hier kommt der Hersteller ins Spiel. Allerdings haben wir hier im Vorfeld gut recherchiert. Bisher läuft die Entwicklung der Datenbank prima und das Unternehmen expandiert enorm.

Antwort: Ja, das würden wir gerne, wir hatten auch schon einige Vorstellungen. Im Moment arbeiten wir daran, die Anwendung in Module aufzuteilen, die man dann auch einzeln erwerben kann.