Spezifikation Blivio

Diese Spezifikation beschreibt die Anforderungen und Rahmenbedingungen für die Entwicklung der SaaS-Applikation Blivio, die Bauherrenteams bei der Planung, Umsetzung und Kontrolle von Bauprojekten unterstützt.

Blivio ist eine SaaS-Applikation¹ die es Organisationen mit umfangreichen und/oder professionalisierten Bauherrenteams² ermöglicht, Bauprojekte entlang dem SIA-Phasenmodell zu planen, umzusetzen und zu kontrollieren, mit speziellem Fokus auf der Koordination zwischen Bauherr und Bauberatung.

Die Applikation ist nur für team-interne Koordination und Zugriff ausgelegt; die Zusammenarbeit mit externen Akteuren (z.B. Planer, Unternehmer, Behörden) erfolgt weiterhin über etablierte Kanäle ausserhalb der Applikation³.

Dokumentation: Wir unterscheiden zwischen den Planungs- und Bauprozessen, die wir im System modellieren und die effektiv im Bauprojekt ablaufen, und den Applikationsprozessen, die definieren wie die Applikation zu bedienen ist.
- Bau-Prozesse entlang dem SIA-Phasenmodell (PPM)
- Applikationsprozesse (Planung, Umsetzung, Kontrolle …)
AVOR: (Planung kollidiert mit Bauprozess)
- Stammdatenverwaltung Organisation, Gebäude
- Stammdatenverwaltung Projekt (inkl Gebäude)
- Projektstrukturierung (inkl Organisation und Gebäude, Auswahl der Phasen und Aktivitäten)
- Projektdetaillierung (Qualifikation der Leistungen entlang Vxyz)
- Ressourcen- und Kapazitätsplanung (Rollen, Personen, Zeitaufwand) ?
Umsetzung:
Prozesssteuerung entlang der massgeschneiderten Projektstruktur und -detaillierung
Notifikation der Beteiligten und Verantwortlichen bei anstehenden (und allenfalls abgeschlossenen) Leistungen

Blivio ist dabei eine reine team-interne Prozesssteuerung:
- keine Einbindung externer Akteure (Planer, Unternehmer, Behörden …)
- keine Dokumenten- oder Ergebnisverwaltung (z.B. Pläne, Verträge, Protokolle …), allenfalls Referenzen auf externe Dokumente
- allenfalls Erstellung von Dokumenten aufgrund Projektdefinition zuhanden "externer Prozesse", z.B. projektspezifischer Leistungskatalog für Ausschreibungen
Kontrolle:
Kontrolle der erbrachten / abgeschlossenen Leistungen und Aktivitäten (als Teil der Prozesssteuerung?)

Bauprojektrollen (abschliessend)

BH: Bauherr
BHV: Bauherrenvertretung
PLBH: Projektleiter Bauherr
BHU: Bauherrenunterstützung
BHB: Bauherrenberater
PC: Projektcontrolling

Nutzerrollen (tbd)

Während die obigen Rollen die fachlichen Verantwortlichkeiten und Funktionen im Bauprojekt definieren, müssen wir verstehen, welche Rollen in der Benutzung der Applikation notwendig sind. Haben alle Bauprojektrollen Zugriff auf die Applikation? Gibt es weitere Rollen, die nur für die Applikation relevant sind (z.B. Systemadministrator, Projektmanager, etc.)?

Bauprojektrollen

Bauherrschaft

BH: Bauherr
Gruppe: Vorstand, Steuergruppe
Applikation: reines Lesen, z.B. via Dashboard
Der/die BH ist bezüglich Entscheidung und Gesamtverantwortung oberstes Organ und ist für die Projektsteuerung sowie die strategische und operative Projektführung zuständig. Zur Erfüllung der bauherrenseitigen Aufgaben können aus den eigenen Reihen ein Steuerungs- bzw. Entscheidungsgremium gebildet und die operative Projektführung einer bauherrenseitigen Projektleitung (nachstehend beschrieben) eingesetzt werden. Der/die BH kann sich allerdings auch durch Externe in den strategischen, operativen Aufgaben und fachlichen Themen beraten, vertreten und unterstützen lassen. Die Entscheidungen sowie die Verantwortung und die Haftung bleiben jedoch uneingeschränkt bei dem/der BH.
BHV: Bauherrenvertretung
Gruppe: ja, delegiert, homogen, analog Bauherr
Applikation: ditto Bauherr
Die BHV übernimmt auf Mandatsebene und als Stabsstelle teilweise oder ganz die Funktion der PLBH und vertritt in diesem Rahmen den/die BH gegenüber den direkt untergeordneten Leistungserbringenden sowie Behörden und Dritten. Der Umfang der Vertretungsbefugnis richtet sich nach der zwischen den Parteien vereinbarten Aufgabenübertragung und Vollmacht.
PLBH: Projektleiter Bauherr
Gruppe: inhomogene Gruppe (Lese- oder Schreibrecht)
Applikation: AVOR, Controlling
Die PLBH ist eine Linienfunktion des/der BH. Sie ist zuständig für die Umsetzung von Entscheiden des/der BH, für die operative Projektführung in Bezug auf Qualität, Kosten und Termine und unterstützt den/die BH in strategischen Belangen. Sie vertritt den/die BH gegenüber Behörden, den direkt untergeordneten Leistungserbringenden und weiteren Projektinvolvierten im Rahmen der ihr übertragenen Aufgaben und Kompetenzen. Unterbleibt die explizite Schaffung der Funktion der PLBH, wird sie vom/von der BH übernommen, oder sie kann ganz oder teilweise an eine (externe) Bauherrenvertretung übertragen werden (nachstehend erwähnt).

Bauberatung

BHU: Bauherrenunterstützung
Gruppe: ja, homogen
Applikation: lesender Zugriff
Die BHU unterstützt auf Mandatsebene die Stabsstelle des/der BH bzw. der PLBH in ihren Aufgaben durch fachliche Begleitung in der strategischen und operativen Projektführung sowie ggf. auch im Controlling (vgl. nachstehendes Mandat des Projektcontrollings). Sie verfügt in der Regel über keine Vertretungs- und Entscheidungsbefugnis. Die BHU ist aufgrund Ihres Mandats in der Regel stärker in das Bauprojekt eingebunden als die BHB und im Projekt nicht nur beratend, sondern oft auch operativ tätig.
BHB: Bauherrenberater
Gruppe: homogen
Applikation: Notifikation, Leserecht
Die BHB wird auf Mandatsebene seitens BH für die Begleitung von Aufgaben in Stabsstel-le beauftragt und bringt ihr fachspezifisches Wissen auf der Bauherrenseite ein. Sie verfügt wie die BHU in der Regel über keine Vertretungs- und Entscheidungsbefugnis. Das Mandat der BHB beinhaltet insbesondere die Beratung des/der BH bzw. der PLBH in der strategischen und operativen Projektführung und eignet sich auch für eine Mandatsbeschränkung auf gewisse Projektthemen oder -teile sowie spezifische Prüfaufgaben. Ihr Mandat kann ggf. auch das Projektcontrolling beinhalten (vgl. nachstehendes Mandat des Projektcontrollings).
PC: Projektcontrolling
Gruppe: homogen
Applikation: Durchführung
Das PC kann im Zusammenhang mit dem Mandat als BHU bzw. BHB oder besser im Rahmen eines eigenständigen Mandats durch den/die BH für die prüfende und beurtei-lende Begleitung des Gesamtprojekts oder auch nur von Teilphasen oder fachspezifische Aufgaben sowie spezifische Prüfmandate beigezogen werden. Bei einem eigenständigen Mandat besteht der Vorteil, dass das Controlling durch eine weitere Stelle mit mehr Aus-sensicht erfolgt, was besonders bei grossen und/oder komplexen Bauvorhaben sinnvoll ist.

Fragen

sind das Einzelpersonen oder Gruppen?
sind diese Gruppen aus Prozesssicht homogen, d.h. werden sie alle zusammen bei jeden relevanten Leistungen gleichzeitig notifiziert (z.B. BHB?)
was sind typische Projektzusammensetzungen (können wir "Personas" definieren, pro Projektteam oder pro Rolle)?

Nutzerrollen

wir gehen davon aus dass alle Rollen Zugriff auf die Applikation haben / haben müssen?
wie sind diese Rollen im Applikationsprozess (Planung, Umsetzung, Kontrolle) involviert?

Applikationsprozesse und Beteiligte (wer macht was?)

Planung:
- Stammdatenverwaltung Organisation und Gebäude
- Stammdatenverwaltung Projekt (inkl Organisation und Gebäude)
- Projektstrukturierung (Auswahl der Phasen und Aktivitäten)
- Projektdetaillierung (Qualifikation der Leistungen entlang Vxyz)
- Ressourcen- und Kapazitätsplanung (Rollen, Personen, Zeitaufwand) ?
Umsetzung:
Prozesssteuerung entlang der massgeschneiderten Projektstruktur und -detaillierung
Notifikation der Beteiligten und Verantwortlichen bei anstehenden (und allenfalls abgeschlossenen) Leistungen

Blivio ist dabei eine reine team-interne Prozesssteuerung:
- keine Einbindung externer Akteure (Planer, Unternehmer, Behörden …)
- keine Dokumenten- oder Ergebnisverwaltung (z.B. Pläne, Verträge, Protokolle …)
- allenfalls Erstellung von Dokumenten aufgrund Projektdefinition zuhanden "externer Prozesse", z.B. projektspezifischer Leistungskatalog für Ausschreibungen
Kontrolle:
Kontrolle der erbrachten / abgeschlossenen Leistungen und Aktivitäten (als Teil der Prozesssteuerung?)

Laufende offene Fragen

❏ Leistungen sind immer nur entweder als Entscheid oder Mitarbeit markiert. Kann man im Vxyz in einer Entscheidungs-Leistung eine Mitarbeit definieren? Falls nicht, können wir Leistungen im Katalog definitiv als Arbeit oder Entscheid klassieren?
❏ Sollen wir Leistungen als Deliverable übersetzen (statt Service, was eher Prozess-Charakter hat)?
❏ es gibt Aktivitäten die "pro Xyz" durchgeführt werden müssen, z.B. "pro Anbieter" im Beschaffungsprozess. Gibt es andere solche "pro Xyz" Aktivitäten?

Geklärte Fragen

✓ Leistungen können im Vxyz als "nicht in der aktuellen Aktivität zu erbringen" markiert werden (Standardwert ist "müssen in der aktuellen Aktivität erbracht werden").
D.h. Leistungen haben "Todo-Charakter", sind keine Prozess-Aktivitäten.
✓ Leistungen können im Vxyz als nicht notwendig markiert werden.

Domänenbegriffe und Prozessobjekte

Definition der relevanten Domänenobjekte, wobei der Fokus auf prozessführenden Objekten liegt. Dazu gehören zentrale Einheiten wie Vorgänge, Fälle, Aufträge oder ähnliche Objekte, die durch verschiedene Statusübergänge den Prozessfluss repräsentieren. Ergänzend werden alle attributiven Objekte definiert, die den Prozess beeinflussen oder von ihm abhängen.

End-to-End-Prozesse / Prozessketten

Bevor die Prozessabläufe beschrieben werden, werden die vier bis fünf Hauptprozesse explizit identifiziert. Diese Hauptprozesse bilden das strukturelle Rückgrat der gesamten Applikation und dienen als Ausgangspunkt für alle weiteren Verfeinerungen. Narrative Darstellung der zentralen Prozessabläufe, die das System vollständig abbilden soll. Für jeden Prozess wird beschrieben, wie er startet, welche Rollen beteiligt sind, welche prozessführenden Objekte entstehen oder weitergeführt werden und unter welchen Bedingungen ein Prozess als vollständig abgeschlossen gilt. Übergabepunkte, Eskalationen und Entscheidungsknoten werden klar benannt.

Capabilities

Beschreibung der Fähigkeiten des Systems aus prozessualer Sicht. Jede Capability wird im Kontext der Prozesslogik formuliert, beispielsweise Erfassung eines neuen Vorgangs, Steuerung von Statusübergängen, Delegation von Aktivitäten oder automatische Auslöser innerhalb definierter Prozessabschnitte. Der Schwerpunkt liegt darauf, wie das System Prozessschritte ermöglicht, kontrolliert oder automatisiert.

Nicht-funktionale Anforderungen

Ein Abschnitt zu Qualitätsanforderungen, insbesondere solche, die für prozessorientierte Systeme besonders relevant sind. Durchlaufzeit, Robustheit gegenüber Unterbrechungen, Revisionssicherheit, Konsistenzanforderungen bei Statuswechseln und Auditierbarkeit von Prozessschritten.

Systemkontext und Modulübersicht

Beschreibung, wie die SaaS-Applikation mit externen Systemen interagiert und welche Module zur Abbildung der Prozesslogik beitragen. Dazu gehören Integrationen, die Prozessfortschritte auslösen oder Daten bereitstellen, sowie interne Module wie Prozesssteuerung, Benachrichtigungssystem oder Rollenmodell.

Prozessbezogenes Domänenmodell und Invarianten

Darstellung des domänenlogischen Modells mit besonderem Fokus auf Statusmodellen, Übergangsregeln und Invarianten, die die Prozesslogik stabil halten. Hier werden die erlaubten und nicht erlaubten Übergänge sowie zwingende Bedingungen (z. B. erforderliche Dokumente, Genehmigungen oder Validierungen) beschrieben.

Security-, Rollen- und Mandantenkonzept

Beschreibung des Sicherheitsmodells mit Betonung auf prozessbezogene Berechtigungen. Dies umfasst Zugriffskontrolle entlang des Prozessfortschritts, tenant-spezifische Trennung der Prozessdaten und differenzierte Rollen, die unterschiedliche operative Rechte innerhalb derselben Prozesskette besitzen.

MVP-Abgrenzung und Roadmap

Skizzierung, welche Prozessketten und Statusmodelle in der ersten Version vollständig realisiert werden und welche erst später folgen. Der Schwerpunkt liegt darauf, einen minimal funktionsfähigen Prozessfluss zu definieren, der fachlich kohärent und betriebsfähig ist.

Eine SaaS-Applikation ist eine online bereitgestellte Softwarelösung, die vollständig vom Anbieter betrieben, gewartet und aktualisiert wird und beim Nutzer ohne lokale Installation über einen Webbrowser konsumiert wird. Die Anwendung läuft in einer mandantenfähigen Cloud-Infrastruktur, so dass Rechenleistung, Datenhaltung, Skalierung und Sicherheitsmaßnahmen zentral orchestriert werden.
↩
Im wesentlichen sind das öffentliche Bauherrschaften sowie institutionelle private Bauherrschaften.
↩
Allenfalls mit Ausnahme des Beschaffungsprozesses, dies aber vermutlich erst in einer späteren Phase.
↩