… ist das noch zeitgemäß?
Scannt man das oft weit gefächerte Softwareangebot der Anbieter von Bausoftware, dann bemerkt man, dass diese ihr Portfolio unterschiedlich gliedern. Die meisten sprechen von einer kaufmännischen und einer baubetrieblichen Welt bzw. von betriebswirtschaftlichen und bautechnischen Softwaremodulen. Andere meinen das Gleiche und nennen die beiden Bereiche „Bauen“ und „Finanzen“ oder verwenden ähnliche Begriffe, um Bautechnisches von Kaufmännischem abzugrenzen. Ist diese Systematik zielführend und noch zeitgemäß?
Die Antwort auf diese Frage und das Fazit gleich vorneweg: nein, sie ist nicht mehr zeitgemäß! Und vor allem sorgt diese Systematik häufig auch für eine unlogische und ungünstige Bündelung von „kaufmännischen“ und „bautechnischen“ Softwarebausteinen. Weitaus sinnvoller ist eine Gliederung in Prozesse, die der Projektabwicklung zuzuschreiben sind und in solche, die unabhängig von den Projekten sind und stattdessen die Unternehmenssteuerung und -verwaltung betreffen. Also: „Projekt / Unternehmen“ statt „kaufmännisch / technisch“. Derart strukturierte Softwarelösungen haben den Vorteil, dass alles, was zur Abwicklung der Projekte erforderlich ist, auch tatsächlich einheitlich und durchgängig in einer Projektlösung abgebildet wird. Lediglich die projektunabhängigen Querschnittsfunktionen werden mit der Unternehmenslösung abgewickelt.
Die „alte Welt“ spricht von „kaufmännisch / technisch“
Sehr verbreitet sind heute jedoch Lösungen, die zwischen „Software für Kaufleute“ (kaufm. Module, finance, betriebswirtschaftliche Module, …) und „Software für Techniker und Ingenieure“ (Bauen, Bausoftware, Bautechnik, Baubetrieb, …) unterscheiden. Häufig wird diese tradierte Zweiteilung der Softwarelandschaft mit bereichsübergreifenden Komponenten abgerundet. Ein Dokumentenmanagement, ein MIS, usw. bilden bei verschiedenen Softwaresystemen den Unterbau bzw. die integrierende Klammer über den beiden Bereichen. Gelegentlich werden weitere Softwaremodule flankierend positioniert, so wie CAD, BIM, Spezialsoftware für Facility Management, etc. Teilweise sind es Drittprodukte von anderen Herstellern, die die Lösung ergänzen. Hierzu zählen bei einigen Herstellern die mobilen Baustellen-Apps.
Was wird welchem Bereich zugeordnet?
Interessant ist die Frage, welche Prozesse in der „alten kaufmännisch/technischen Welt“ welchem Bereich zugeordnet sind. Bei der Lohnabrechnung, der Finanz- und Anlagenbuchhaltung und der Baukalkulation stellt sich wohl kaum die Frage, wohin sie gehören. Bei der Materialwirtschaft, dem Gerätemanagement, beim Projektcontrolling und bei einigen weiteren Themen wie z.B. der Bürgschaftsverwaltung hingegen scheiden sich jedoch die Geister, ob sie besser auf der kaufmännischen oder auf der bautechnischen Seite anzusiedeln sind. Außerdem ist es schwer zu erklären, warum in einigen Softwarelösungen die Beschaffung von Nachunternehmerleistungen (AVA) der Bautechnik zugeschlagen wird, die Beschaffung von Material jedoch dem kaufmännischen Part, obwohl es sich doch ganz offensichtlich lediglich um zwei verschiedene Ausprägungen eines einheitlichen Beschaffungsprozesses handelt.
Welche Auswirkungen hat die Trennung in diese Bereiche?
Warum und in wie weit ist es denn überhaupt relevant, ob ein Prozess im Bereich der sog. kaufmännischen oder der sog. bautechnischen Software abgebildet wird, wenn es doch Softwarelösungen gibt, die beide Bereiche integrieren? Wären das Programme, bei denen alle Module durchgehend auf dem gleichen Datenmodell und der gleichen Datenbank basieren, die in sich schnittstellenfrei sind und die mit einheitlichen Tools entwickelt wurden, dann träte die Frage der Zuweisung der Prozesse in die jeweiligen Bereiche tatsächlich in den Hintergrund. Aber solche Lösungen sind in der Praxis eher selten anzutreffen.
Meist trifft man jedoch mehr oder weniger heterogene Softwarelandschaften an. Das liegt einerseits daran, dass Lösungen von Herstellern eingesetzt werden, die Module mit unterschiedlichen Software-Entwicklungs-Werkzeugen erstellt haben und daher in sich nicht gänzlich schnittstellenfrei sind. Außerdem werden auch Programme von Herstellern genutzt, die Softwarebausteine von Drittlieferanten an die Eigenentwicklungen „angedockt“ haben. Zum anderen findet man solche heterogenen Softwarelandschaften auch bei Unternehmungen, die nicht alle Komponenten einer Softwarelösung eines Anbieters einsetzen, sondern einzelne Bereiche mit Software unterschiedlicher Hersteller abdecken. Dazu zählen Firmen, die die Finanzbuchhaltung beim Steuerberater oder in einem Rechenzentrum abwickeln. Ein anderes Beispiel sind Bauunternehmen, die für das Rechnungswesen die Software einer Konzernmutter einsetzen, ansonsten aber eine davon unabhängige baubetriebliche Lösung.
In heterogenen Softwaresystemen ist die Frage besonders wichtig, in welchem der (unterschiedlichen) Systeme welcher Prozess abgebildet wird. Beispiel Beschaffung: will man wirklich die Beschaffung von NU-Leistungen mit einer anderen Software durchführen als die Beschaffung von Material? Beispiel Rechnungseingangsworkflow: will man den in der Finanzbuchhaltung angesiedelt haben, wenn die sachliche Prüfung der Rechnung doch sicher in der Bautechnik besser aufgehoben ist? Beispiel Projektcontrolling: will man es wirklich in der kaufmännischen Schiene abwickeln oder spricht nicht vieles dafür, es zusammen und durchgängig mit den anderen “Projektmodulen” abzuwickeln?
„Projekt/Unternehmung“ statt „kaufmännisch/technisch“
Verabschiedet man sich von dem Gedanken, eine Grenze zwischen kaufmännischen und bautechnischen Modulen zu ziehen, dann stellt sich die Thematik grundlegend anders dar. Unterscheidet man Software, die im weitesten Sinne mit der Projektabwicklung zu tun hat von Software, die ausschließlich der Unternehmenssteuerung und -verwaltung dient, so denkt man in einem Modell, das viel einleuchtender und praxisgerechter ist als das althergebrachte.
Was wird nun welchem Bereich zugeordnet?
Bei dieser Betrachtungsweise gehört die Beschaffung eindeutig zum Projekt, ganz gleich ob es sich um die Beschaffung von Material oder von Leistungen handelt. Das Projektcontrolling ist nicht länger Bestandteil der kaufmännischen Lösung, sondern alle Prozesse von der Istkosten-Erfassung (Rechnungseingang, Lohnstunden, Geräteberichte, Lagerbewegungen, interne Leistungsverrechnung) bis zu den Auswertungen pro Projekt (und auch projektübergreifend) finden auf der „Projektseite“ statt – und zwar zeitnah und unabhängig vom Monatsabschluss des kaufmännischen Systems. Bei dieser Softwaresystematik gehören alle mobilen Komponenten (Baustellen Apps) logischerweise zur Projektsoftware.
Die „Software für die Unternehmenszentrale“ umfasst ausschließlich die Finanzbuchhaltung, die Kostenrechnung und die HR-Module: Lohn, Gehalt, Personal. Wobei sich das Modul „Finanzbuchhaltung“ im Wesentlichen auf die Prozesse des Fiskalreportings, die Sicherstellung der Liquidität, sowie auf die Anlagenbuchhaltung beschränkt. Die „projektnahen“ Buchhaltungsprozesse wie der Rechnungseingangsworkflow sind hingegen Bestandteil der Projektlösung.
Die Kostenrechnung kümmert sich vorrangig um das Unternehmenscontrolling und um die Businessplanung – das Projektcontrolling überlässt sie aber der Projektlösung.
Welche Vorteile hat die Gliederung in diese Bereiche?
Ganz offensichtlich: bei dieser Gliederung dürfte es kaum noch Diskussionsbedarf geben, welcher Prozess wohin gehört. Alles, was zur Abwicklung der Projekte dient – von der Planung bis zur Abrechnung und Controlling – wird durchgängig in der Projektlösung abgebildet. Was nicht impliziert, dass hier keine projektübergreifenden Prozesse stattfinden sollen. Ganz im Gegenteil: eine Multi-Projekt-Lösung bietet hier ganz eindeutig Vorteile. Alles, was jedoch unabhängig von den Projekten – quasi als Querschnittsfunktion – durch das Unternehmen zu bearbeiten ist, wird mit der Unternehmenslösung abgewickelt. So kommt also zusammen, was fachlich zusammengehört. Das wiederum sorgt für durchgängige und leistungsfähigere Prozesse.
Der Idealfall ist sicher, eine durchgängige „Projekt-und-Unternehmens-Lösung“ als integrierte Software von einem einzigen Hersteller. Ist dies aber – aus welchen Gründen auch immer – nicht möglich und löst man den „Unternehmensteil“ mit einer anderen Software als den „Projektteil“, dann geht zumindest die „Trennungslinie“ nicht länger durch Bereiche, die einheitlich und durchgängig gelöst werden müssen. Ein weiterer Vorteil einer „Projekt-und-Unternehmens-Lösung“.
Wir beraten Sie gerne bei der bei der Suche nach einer neuen Bausoftware oder bei der Optimierung Ihrer betrieblichen Prozesse, sowie bei der Implementierung von kaufmännischen und bautechnischen Softwaremodulen. Noch lieber aber unterstützen wir Sie bei der Implementierung einer “Projekt-und-Unternehmenslösung”.