Entwicklung eines Softwaretools zur Behandlung technischer Nachträge bei komplexen Bauvorhaben

Transkript

1 Forum der Forschung 18/2005: BTU Cottbus, Eigenverlag, ISSN-Nr.: Entwicklung eines Softwaretools zur Behandlung Kurzfassung Im Rahmen einer Diplomarbeit am wurde ein Lösungsansatz für den Umgang mit Technischen Nachträgen aus Auftraggebersicht entwickelt. Das Ergebnis ist ein individuelles, anwenderorientiertes und datenbankbasiertes Softwaretool zur Unterstützung des Auftraggebers. Die Bearbeitung des komplexen Themas Nachtragsmanagement wird durch Orientierung und Strukturierung mithilfe des Softwaretools erleichtert. Es wird ein Rahmen für die Entscheidungsfindung geschaffen. Durch die Bereitstellung und Abfrage von Informationen zum richtigen Zeitpunkt sowie eine entsprechende Benutzerführung wird dafür die Grundlage geschaffen. Die Entwicklung dieses Softwaretools und insbesondere seine Gestaltung wird in diesem Artikel vorgestellt. Abstract Within in the scope of a diploma thesis at the chair for site management and construction industry at BTU-Cottbus a method of solution has been designed to deal with technical tenders in a client's view. The result is an individual, application-oriented and data based software tool to support the client managing technical tenders. The editing of a complex revised tender mangement is facilitated with orientation and structuring by use of this software tool. The scope for decision-making is given. By provision and request of information at the appropriate time as well as an according menu prompt groundwork is provided. The development of this software tool and especially the design is presented in this article. Für die ausführenden Unternehmen besteht, aufgrund der sehr engen Kalkulation, die Notwendigkeit, jegliche vermutete Abweichung in einer Vergütungsforderung zu formulieren und mit aller Vehemenz durchzusetzen. Für den Auftraggeber (insbesondere größerer Projekte) stellen die Forderungen des Auftragnehmers ein erhebliches Risikopotential dar. Aus bautechnischer und bauvertraglicher Sicht sind die Bauunternehmen dem Auftraggeber häufig überlegen, wenn er sich keiner Spezialisten für das Projekt- und Vertragsmanagement bedient. Unabhängig davon besteht jedoch in jedem Fall die Notwendigkeit, die Forderungen des Auftragnehmers zu werten und ggf. begründet zurückzuweisen oder zu beauftragen. Für diese Aufgaben müssen auf Auftraggeberseite bewusst Ressourcen und Strukturen geschaffen werden. Dies entspricht einer Managementtätigkeit im institutionalen und funktionalen Sinne, die gemeinhin als Nachtragsmanagement bezeichnet wird. In Praxis und Literatur finden sich für die Sicht des Auftraggebers dafür kaum Ansätze. 1.2 Aufgabenstellung und Abgrenzung Aufgabe der Diplomarbeit war die Entwicklung eines Softwaretools, welches das auftraggeberseitige Nachtragsmanagement abbildet und unterstützt. Aufgrund der fehlenden umfassenden Konzepte in Literatur und Praxis wurde vom Autor eine Analyse der Aufgaben und Risiken im Rahmen des Nachtragsmanagements vorgenommen. Die daraus abgeleiteten Strukturen wurden in eine Software überführt, die jeweils den Benutzer führen, mit Daten versorgen und unterstützen soll. Im Rahmen der Diplomarbeit wurde sich auf den Bereich der technischen Nachträge beschränkt. Das Sonderthema Bauzeitnachträge wurde aufgrund seiner Komplexität ausgeklammert. 1 Einleitung 1.1 Ausgangssituation Die Baubranche leidet seit Jahren unter einem Umsatzrückgang. Dadurch bedingt werden Auseinandersetzungen zwischen den Vertragspartnern, die an sich zur Kooperation verpflichtet sind, mit harten Bandagen geführt. Selbst kleine Abweichungen vom geplanten und vertraglich vereinbarten Bausoll werden zum Anlass erbitterter Auseinandersetzungen genutzt. 2 Hintergrund, Idee & Motivation 2.1 Was ist ein Nachtrag? In der baurechtlichen Praxis wird seit langem der Begriff Nachtrag verwendet, ohne dass dieser juristisch eindeutig abgeleitet werden kann. Der Baujurist hat sich damit der Diktion der Baustelle unterworfen, um die Akzeptanz der Baupraktiker zu erwerben bzw. nicht zu verlieren. Eine Vielzahl der aufgeführten und diskutierten Nachtragsregelungen finden sich in der VOB/B (Vergabe- und Vertragsordnung für 149

2 Bauleistungen Teil B). Allerdings wird der Begriff Nachtrag dort nicht verwendet. Nachträge sind in der Regel sämtliche Mehrkosten (=Vergütung, Aufwendungs- oder Schadensersatz), die der Bauunternehmer nach Abschluss des Bauvertrages über den bisher vereinbarten Preis geltend macht (ausgenommen Mehrmengen/-massen beim Einheitspreisvertrag). Ein Nachtrag ist der Ober- bzw. Sammelbegriff für Vergütungsansprüche nach 2 Nr. 5, 6, 7 und 8 VOB/B, d. h. Vergütungsansprüche für geänderte und zusätzliche Leistungen, die entweder vom Auftraggeber bei Einheits- und Pauschalpreisverträgen angeordnet wurden (= 1 Nr: 3 und Nr. 4 S. 1 VOB/B i. V. m. 2 Nr. 5 und Nr. 6 i. V. m. 2 Nr. 7 Abs. 1 S. 4 VOB/B) oder nicht angeordnete, aber notwendige Maßnahmen, die gem. 2 Nr. 8 VOB/B oder als Massenmehrung nach den Grundsätzen des Wegfalls der Geschäftsgrundlage nach 2 Nr. 7 Abs. 1 S. 2 VOB/B zu vergüten sind. Aus den vorstehenden Definitionsversuchen ergibt sich bereits, wie komplex das Thema Nachträge und damit deren Handhabung in der juristischen und praktischen Bewältigung ist. 2.2 Risiken und Aufgaben Die Aufgaben im Zusammenhang mit Nachtragsforderungen des Auftragnehmers bestehen für den Auftraggeber im Wesentlichen in der Notwendigkeit, eingereichte Nachtragsforderungen sachgerecht zu beurteilen und ggf. zurückzuweisen bzw. zu beauftragen. Darüber hinaus sollte der Fokus auf die präventive Vermeidung von Nachträgen gelegt werden. Das Nachtragspotential kann durch intensive Vorbereitung erheblich gesenkt werden. Diese Tätigkeiten bedürfen neben grundsätzlichen, organisatorischen Strukturen insbesondere vertiefter bautechnischer und baurechtlicher Kenntnisse. Wie eingangs bemerkt, wird das Nachtragsmanagement auf Auftragnehmerseite auch aufgrund der engen Marktsituation sehr intensiv betrieben. Auf Auftraggeberseite sind die Abläufe und Strukturen diesbezüglich nicht vollständig beleuchtet. Zudem verfügen Auftraggeber größerer Projekte nicht unbedingt über das notwendige Fachwissen. Dabei kann jeder einzelne Nachtrag das Erreichen der gesteckten Projektziele hinsichtlich Kosten, Qualitäten und Termine gefährden. Das größte Risiko liegt dabei im Bereich der Kosten: ist der Finanzierungsrahmen erschöpft, kann das Projekt unter Umständen nicht mehr beendet werden. Nicht selten müssen daraufhin Abstriche bei der Qualität vorgenommen werden, die den wirtschaftlichen Erfolg im Nachhinein mindern. Die Notwendigkeit eines auftraggeberseitigen Nachtragsmanagements liegt somit auf der Hand. Es kann grundsätzlich zwischen zwei Hauptaufgaben unterschieden werden: Nachtragsvermeidung und Nachtragsbearbeitung. Im Rahmen der Arbeit wurden Teilaufgaben herausgearbeitet und den Hauptaufgaben Nachtragsvermeidung und Nachtragsbearbeitung zugeordnet. Einen Überblick darüber gibt die folgende Abb. 1. Abbildung 1: Aufgaben Nachtragsmanagement 150

3 3 Umsetzung und Ergebnis 3.1 Nachtragsmanagement als Geschäftsprozess Die Aufgaben wurden im Rahmen der Arbeit näher analysiert und ein Lösungskonzept überführt. Es wurde herausgestellt, dass insbesondere die Nachtragsbearbeitung durch eine Software unterstützt werden kann. Diese Aufgabe wurde in den Mittelpunkt gestellt und als Geschäftsprozess aufgefasst. Die Aufgaben der Nachtragsbearbeitung wurden in einem Workflow strukturiert und beschrieben. Es werden vor- und nachgelagerte Prozesse definiert. Der Workflow umfasst in der obersten Gliederungsebene sechs Schritte, die in eine sequentielle Reihenfolge gebracht wurden: Vorprüfung Technische Prüfung Vertragliche Prüfung Preisliche Prüfung Terminliche Prüfung Zusammenfassung Die einzelnen Schritte wurden anschließend detailliert. So teilt sich z. B. die Vorprüfung in 4 Einzelschritte gem. Abb. 2. sition. Dadurch konnte ein Vorteil relationaler Datenbanken die Einmaligkeit der Datenablage genutzt werden. Auf den Überlegungen zum Workflow aufbauend wurde eine Oberflächenstruktur entwickelt, anhand derer der Benutzer die Daten aufrufen, editieren und ergänzen kann. Der entwickelte Workflow wurde mit seinen einzelnen Schritten und Teilschritten in der Oberfläche graphisch umgesetzt. Die dem Workflow vor- und nachgelagerten Prozesse wurden entsprechend eingeordnet. Der Anwender wird auf der Oberfläche durch die Prozesse und den Workflow geführt. An den entsprechenden Schritten werden die relevanten Daten erfasst bzw. wiedergegeben. Es wird ein roter Faden durch die gesamte Nachtragsbearbeitung gelegt. Durch diesen roten Faden wird sichergestellt, dass die Aufgaben der Nachtragsbearbeitung möglichst strukturiert, nachvollziehbar und vollständig vom Anwender abgearbeitet werden. Für die Aufgaben der Nachtragsvermeidung und zur fachlichen Unterstützung des Anwenders wurde der Datenbank ein Hilfesystem angegliedert. Das Hilfesystem unterstützt darüber hinaus die Aufgabe der Nachtragsvermeidung durch die Bereitstellung von Checklisten, Musterverträgen und erweitertem Fachwissen. 3.3 Struktur der Softwareoberfläche Die Oberfläche wurde mit Hilfe von Formularen und Unterformularen in Microsoft Access umgesetzt. Dabei sind zwei Prinzipien (Prinzip 1: Vom Groben ins Feine; Prinzip 2: Thematische Trennung) verfolgt worden. Vom Groben ins Feine bedeutet allgemein, dass die Benutzerführung an der Struktur der entwickelten Datenbank orientiert ist und speziell, dass der Vertrag (grob) am Anfang der Bearbeitung steht und die Bearbeitung über den Nachtrag hin zur Nachtragsposition (fein) vollzogen wird. 3.2 Umsetzung des Lösungskonzeptes Abbildung 2: Detailierung Workflow Für die einzelnen Teilschritte wurden die Datenfelder bestimmt, die es in einer Software abzubilden galt. Dabei wurde erkannt, dass sich die Struktur in einer relationalen Datenbank abbilden lässt. In einer relationalen Datenbankstruktur werden die Daten in Tabellen abgelegt, welche untereinander in Beziehung gesetzt werden. Ausgehend vom Objekt Projekt wurden die weiteren Objekte Vertrag, Nachtrag und Nachtragsposition diesem untergeordnet. Es entstand so eine Verfeinerung der Datenstruktur bis hin zur Nachtragspo- Die Thematische Trennung betrifft im Wesentlichen die einzelnen Schritte des entwickelten Workflows: Hier soll jeder Schritt getrennt behandelt werden. Dies wird erreicht durch die Anordnung der Schritte auf einzelnen Registerkarten. Aber auch die Objekte wie Verträge und Nachträge der Datenbank werden getrennt dargestellt. Auch hier wird die Trennung durch den Einsatz von Registerkarten erreicht. Ziel ist die Konzentration des Anwenders auf das jeweils Wichtige, z. B. den aktuellen Schritt des Workflows. Den Mittelpunkt der Anwendung bildet ein Hauptformular, welches sich als Ebene 0 bezeichnen lässt. Auf dieses Hauptformular werden zwei weitere Ebenen gelegt (vgl. Abb. 3). Eine Box mit fünf Registerkarten bildet die Ebene 1. Die einzelnen Registerkarten folgen den vorgestellten Prinzipien. Die erste Registerkarte bietet einen globalen Überblick über das gesamte Projekt. Die zweite Registerkarte bildet das Objekt Verträge ab und die dritte Registerkarte das Objekt Nachträge mit den dazugehörigen Positionen. Der Workflow Nachtragsbearbeitung ist auf der vierten Registerkarte abgebildet. Die fünfte Registerkarte umfasst die Reportingelemente. Die Inhalte der Registerkarten werden jeweils auf der Ebene 2 angezeigt. 151

4 Im Rahmen der Entwicklung des Lösungsansatzes wurde zwischen dem eigentlichen Workflow sowie vor- und nachgelagerten Prozessen unterschieden. Die vorgelagerten Prozesse sind auf den Registerkarten 2 bis 3 abgebildet, der Workflow auf der Registerkarte 4 und die nachgelagerten Prozesse auf der Registerkarte 5. Auf der vierten Registerkarte Nachtragsbearbeitung wird in der Ebene 2 eine weitere Box mit Registerkarten angeordnet, um den Workflow abzubilden. Die einzelnen Registerkarten bilden die einzelnen Schritte des vorgestellten Workflows ab. Auf den Registerkarten ist die weitere Differenzierung der einzelnen Schritte des Workflows in einzelnen Boxen dargestellt. Die folgende Abb. 4 zeigt einen Screenshot mit der Registerkarte Vorprüfung (vgl. auch farbige Abb. 4 auf der Titelseite dieses Heftes). Die Umsetzung der vier Teilschritte in einzelnen Boxen (grau hinterlegt) ist zu erkennen. 3.4 Farbkonzept zur Benutzerführung Abbildung 3: Grundstruktur der Oberfläche Ein Ziel des entwickelten Datenbanksystems ist wie erwähnt, den Benutzer durch die Nachtragsbearbeitung wie an einem rotem Faden zu führen. Es besteht dadurch u. a. die Aufgabe, die geschachtelten und komplexen Daten (Vertrag Nachtrag Nachtragsposition) übersichtlich darzustellen. Dies wird einerseits erreicht über die eingeführten Ebenen. Zum anderen wird ein Farbkonzept berücksichtigt. Dabei werden die Objekte Vertrag, Nachtrag und Nachtragsposition mit jeweils einer eigenen Farbe gekennzeichnet. Für alle Darstellungen, die Elemente von Verträgen enthalten, wird ein dunkelgrauer Hintergrund mit weißer Schrift gewählt. Nachtragselemente sind mit hellgrauem Grund und schwarzer Schrift, Nachtragspositionen dagegen mit hellgelben Hintergrund und schwarzer Schrift gekennzeichnet. Teilschritte des Workflowschrittes: Hellgrau hinterlegt Abbildung 4: Screenshot Datenbank (vgl. auch farbige Abb. 4 auf der Titelseite dieses Heftes) 152

5 Auf dem Screenshot in Abb. 4 (vgl. auch farbige Abb. 4 auf der Titelseite dieses Heftes) ist die Umsetzung des Farbkonzeptes zu erkennen. Auf der linken Seite ist dort die Auswahl des betreffenden Vertrages, Nachtrages und der Position angegeben. Die Auswahl ist in der jeweiligen Farbe gehalten. Die Registerkarten der Ebene 1 sind durch entsprechend farbige Symbole gekennzeichnet. Auf Ebene 3 sind die Teilschritte des Workflows Vorprüfung hellgrau hinterlegt. Damit wird deutlich, das sich die Bearbeitung auf den Nachtrag insgesamt und nicht auf die einzelne Position bezieht. 3.5 Hilfesystem Der Aufruf des Hilfesystems erfolgt jeweils über einen Button oder die Taste F1. Dadurch wird das Hilfesystem geöffnet und die kontextspezifische Hilfeseite dargestellt. Durch das Inhaltsverzeichnis, Querverweise und eine integrierte Suche kann innerhalb der Hilfe navigiert werden. Die Abb. 5 zeigt einen Screenshot mit der Startseite der Hilfe und dem Inhaltsverzeichnis. systems in ein Backend und ein Frontend an. Dabei wird das Datenbanksystem wieder in die Bestandteile Datenbank und Oberfläche aufgeteilt. Die Datenbank mit den Tabellen (und damit den Daten) wird in einer eigenen Datei gespeichert. Diese Datei wird als Backend bezeichnet. Das davon getrennte Frontend beinhaltet alle Abfragen, Formulare und sonstigen Verwaltungselemente. Oder vereinfacht gesagt: das Backend beinhaltet die Daten, das Frontend die Oberfläche. Weiterentwicklungen, Änderungen und Anpassungen der Oberfläche werden nur im Frontend vorgenommen und erfolgen so getrennt von den Daten. Das Frontend kann sogar vollständig ausgetauscht werden, ohne dass die Daten davon berührt werden. Die Trennung der Daten und der Oberfläche bietet auch für den Einsatz in Mehrbenutzerumgebungen und die verteilte Bearbeitung wichtige Vorteile. Das Backend als einzige Datendatei liegt dabei auf dem zentralen Server. Die Frontends werden nur auf den Rechnern der Anwender installiert und mit dem zentralen Backend verknüpft. Dadurch wird zum einen die Netzbelastung erheblich reduziert, da nur noch die Daten über das Netzwerk laufen und die eigentliche Anwendung mit der Oberfläche schon auf dem jeweiligen Rechner des Anwenders vorhanden ist. Zum anderen können die Frontends anwenderspezifisch angepasst werden, indem z. B. bestimmte Funktionen deaktiviert werden. Dies ist insbesondere im Hinblick auf die verteilte Bearbeitung mit mehreren Spezialisten interessant (vgl. Schema in Abb. 6). So kann jedem Bearbeiter eine auf ihn zugeschnittene Version zur Verfügung gestellt werden. Durch die Aufteilung des Datenbanksystems in Frontend und Backend wird die Sicherung der Daten erleichtert. Die Ablage des Backends auf dem Server ermöglicht die Einbeziehung dieser Datei in das unternehmenseigene Konzept zur Datensicherung. Das Prinzip zeigt Abb. 6. Abbildung 5: Screenshot Hilfesystem Abbildung 6: Prinzip Frontend, Backend und Datensicherung Die Hilfe ist in die Aufgaben Nachtragsvermeidung und Nachtragsbearbeitung unterteilt. Direkt angebunden an das Datenbanksystem ist die Hilfe zur Nachtragsbearbeitung. Indirekt erreichbar sind die Informationen zur Nachtragsvermeidung. 3.6 Trennung von Daten und Oberfläche Das Datenbanksystem wird offen gehalten, um sowohl eine projektspezifische Anpassung als auch allgemeine Weiterentwicklungen zu ermöglichen. Im Hinblick auf die langen Projektlaufzeiten im Bauwesen ist das System derart gestaltet, dass dabei die Daten nicht gefährdet werden. Microsoft Access bietet dafür die Aufteilung des Datenbank- 3.7 Projektspezifischer Einsatz und Weiterentwicklung Die Software ist als Grundgerüst konstruiert, welches projektspezifisch ergänzt bzw. abgeändert werden kann und auch soll. Die Randbedingungen bei Bauprojekten schwanken von Projekt zu Projekt sehr stark. Mit jedem Projekt werden zudem zusätzliche Erfahrungen gewonnen, die es bei zukünftigen Projekten zu beachten gilt. So wird es nie eine fertige Version dieser Software geben, es werden vielmehr projektspezifische Versionen entstehen, die individuell auf die Randbedingungen des jeweiligen Projektes zugeschnitten sind. 153

6 4 Zusammenfassung Es wurde mit der vorgestellten Software ein Lösungsansatz für den Umgang mit Technischen Nachträgen aus Auftraggebersicht vorgestellt. Dazu sind im Rahmen der Diplomarbeit die baubetrieblichen Ursachen von Nachträgen herausgearbeitet und darauf aufbauend Aufgaben und Probleme des AGs im Themenbereich Nachträge beleuchtet worden. Es konnten zwei Kernaufgaben identifiziert werden: Nachtragsvermeidung und Nachtragsbearbeitung. OHNE VERFASSER: Verdingungsordnung für Bauleistungen: VOB Teil A und B ; HOAI Verordnung über die Honorare für Leistungen der Architekten und der Ingenieure,, 20.Aufl., Dt. Taschenbuch- Verl., München 2001 DIN FACHBERICHT 50: Geschäftsprozeßmodellierung und Workflow-Management, Forschungs- und Entwicklungsbedarf im Rahmen der Entwicklungsbegleitenden Normung (EBN), DIN Deutsches Institut für Normung e.v. [Hrsg.] 1. Auflage, Beuth-Verlag, Berlin 1996 MINKWITZ, U. V.; SCHMITT, S.; VIERING, M. G.: Nachtragsmanagement, 1. Auflage, Dt. Anwalt-Verl., Bonn 2005 Es hat sich gezeigt, dass insbesondere im Rahmen der Nachtragsbearbeitung ein Softwaretool den Anwender aktiv unterstützen kann. Dazu wurde die Aufgabe Nachtragsbearbeitung als Geschäftsprozess aufgefasst und in einem Workflow strukturiert. Neben der Differenzierung des Workflows wurden die vor- und nachgelagerten Prozesse identifiziert. Der gesamte Prozess wurde anschließend in einem Datenbanksystem abgebildet, welches neben der notwendigen Datenhaltung und Informationsversorgung auch den Bearbeiter über eine speziell entworfene Oberfläche durch den Prozess führt. In diesem Artikel wurde der Schwerpunkt auf die Vorstellung des Ergebnisses gelegt. Es wurde neben der Struktur der Oberfläche und dem Farbkonzept auch das Potential der Software näher beleuchtet. Die ersten Erfahrungen im Einsatz der Software in der Praxis bestätigen die Notwendigkeit der projektspezifischen Anpassung ebenso wie die erhofften Vorteile bei der Bearbeitung von Nachträgen. Dem komplexen Thema Nachtrag wird Information, Strukturierung und Orientierung entgegengesetzt. Durch das Zusammenspiel von Hilfesystem und Datenbanksystem wird ein ganzheitlich orientiertes Nachtragsmanagement umgesetzt. Die Software unterstützt und führt den Bearbeiter, sie legt einen roten Faden durch die zu bewältigenden Aufgaben. Das komplexe Thema Nachträge wird so greifbar und handhabbar. Markus G. Viering (links) und Mathias Stieb (rechts) Mathias Stieb, wurde 1978 in Berlin geboren. Nach Abitur und Wehrdienst studierte er an der BTU Cottbus Bauingenieurwesen und schließt das Studium im Sommer 2005 ab. Als Projektmanager der KVL Bauconsult GmbH in Berlin entwickelt er den hier vorgestellten Ansatz weiter und setzt die Software bei verschiedenen Projekten ein. Prof. Dr.-Ing. Markus G. Viering, studierte Bauingenieurwesen an der Technischen Universität in Darmstadt und arbeitete in mehreren Projektmanagement- und Projektentwicklungsbüros in Frankfurt am Main, Hamburg und Berlin. Parallel zu dieser Tätigkeit promovierte er an der TU Berlin. Als öffentlich bestellter und vereidigter Sachverständiger beschäftigt er sich mit den Themengebieten Kosten und Abrechnung in Hochbau. Seit 2003 ist er als Gastprofessor am der BTU Cottbus tätig. Literatur DREIER, F.: Nachtragsmanagement für gestörte Bauabläufe aus baubetrieblicher Sicht. Diss., Brandenburgische Technische Universität Cottbus, Eigenverlag, Cottbus 2001 ELWERT, ULRICH: NACHTRÄGE IM BAUWESEN: Baurechtliche und baubetriebliche Grundlagen, Nachtragsuntersuchungen, Nachtragsmanagement, Vieweg, Wiesbaden 2005 KOCHENDÖRFER, B.; VIERING, M. G.; LIEBCHEN, J. H.: Bau-Projekt- Management, Grundlagen und Vorgehensweisen, 2. Auflage, Teubnerverlag, Stuttgart Leibzig Wiesbaden 2004 REISTER, R.: Nachträge beim Bauvertrag, Werner Verlag, München 2004 SCHMITT, ST.; KOCHENDÖRFER, B. (HRSG.): Integriertes Vertragsmanagement. Anleitungen für das Bauwesen zur Steigerung der Nutzen-, Erfolgs- und Optimierungspotenziale, Techn. Univ. Berlin, Univ.-Bibliothek, Abt. Publ., Berlin