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-Applikation1 die es Organisationen mit umfangreichen und/oder hochgradig professionalisierten Bauherrenteams2 ermöglicht, Bauprojekte entlang dem SIA-Phasenmodell zu planen, umzusetzen und zu kontrollieren.

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 Applikation3.

  • Dokumentation:

    • Bau-Prozesse entlang dem SIA-Phasenmodell (PPM)

    • Applikationsprozesse (Planung, Umsetzung, Kontrolle …​)

  • 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?)

Nutzerrollen (abschliesend)

  • BH: Bauherr

  • BHV: Bauherrenvertretung

  • PLBH: Projektleiter Bauherr

  • BHU: Bauherrenunterstützung

  • BHB: Bauherrenberater

  • PC: Projektcontrolling

Stakeholder und Nutzerrollen

  • BH: Bauherr

  • BHV: Bauherrenvertretung

  • PLBH: Projektleiter Bauherr

  • BHU: Bauherrenunterstützung

  • BHB: Bauherrenberater

  • PC: Projektcontrolling

Fragen:

  • sind das Einzelpersonen oder Gruppen?

  • sind diese Gruppen aus Applikationssicht homogen, d.h. werden sie alle zusammen bei jeden relevanten Leistungen gleichzeitig notifiziert (z.B. BHB?)

  • wir gehen davon aus dass alle Rollen Zugriff auf die Applikation haben / haben müssen?

  • was sind typische Projektzusammensetzungen (können wir "Personas" definieren, pro Projektteam oder pro Rolle)?

  • wie sind diese Rollen im Applikationsprozess (Planung, Umsetzung, Kontrolle) involviert?

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 als Arbeit oder Entscheid klassieren?

  • ❏ Sollen wir Leistungen als Deliverable übersetzen (statt Service, was eher Prozess-Charakter hat)?

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.

  1. 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.

    ↩

  2. Im wesentlichen sind das öffentliche Bauherrschaften sowie institutionelle private Bauherrschaften.

    ↩

  3. Allenfalls mit Ausnahme des Beschaffungsprozesses, dies aber vermutlich erst in einer späteren Phase.

    ↩