THU FIS: Arbeitsfassung Viewpoints, Kollaboration, Routing und Informationsharmonisierung
0. Einordnung
Diese Arbeitsfassung ergänzt die bestehenden THU-FIS-Arbeitsfassungen um eine vierte Perspektive: Information, Metadaten und Routing. Die bisherige Struktur aus Value Chain, Capabilities und Touchpoints bleibt erhalten. Ergänzt wird ein pragmatisches Konzept, wie Projekt-, Qualitäts-, Ressourcen- und Finanzinformationen harmonisiert, beschrieben und prozessfähig gemacht werden können.
Die Leitidee lautet:
Damit wird THU-FIS nicht als weiteres Datensilo gedacht, sondern als kollaborative Steuerungsschicht für Forschungsprojekte, Drittmittelprozesse, Qualitätsmerkmale, Finanzinformationen und Prozessentscheidungen.
1. Empfohlene Viewpoints und Reihenfolge
Die Viewpoints sollten so aufgebaut werden, dass zuerst der fachliche Kontext klar wird und erst danach Daten, Metadaten, Plattform und Technik kommen. So bleibt die Story nachvollziehbar und verliert sich nicht zu früh in Systemfragen.
Reihenfolge | Viewpoint | Leitfrage | Ergebnis |
|---|---|---|---|
1 | Zielbild / North Star | Welcher Nutzen soll entstehen? | Gemeinsames Zielbild für Forschungsprojektsteuerung |
2 | Value Chain Viewpoint | Welche Wertschöpfungsstufen gibt es? | Ablauf von Idee bis Verwendungsnachweis und Verwertung |
3 | Stakeholder- und Rollen-Viewpoint | Wer ist beteiligt und wofür verantwortlich? | Rollen, Verantwortlichkeiten, Interessen, Entscheidungsrechte |
4 | Collaboration- und Touchpoint-Viewpoint | Wo arbeiten Rollen konkret zusammen? | Kollaborationsbereiche, Touchpoints, Übergaben, Pain Points |
5 | Capability Viewpoint | Welche Fähigkeiten braucht die Organisation dauerhaft? | Capability Map für FM, FIN, Governance, HR, IT, Kommunikation |
6 | Workflow- und Routing-Viewpoint | Wie wird Information aktiv durch den Prozess geführt? | Workflow-Baukasten für Abstimmung, Prüfung, Freigabe, Eskalation |
7 | Informations- und Concept-Viewpoint | Welche fachlichen Objekte gibt es? | Harmonisiertes Konzeptmodell für Projekt, Antrag, Budget, Qualität usw. |
8 | Metadaten- und Prozesssteuerungs-Viewpoint | Welche Metadaten treiben Status, Fristen, Owner und Entscheidungen? | Metadatenmodell für Routing, Audit, Qualität, Datenherkunft |
9 | Datenquellen- und Integrations-Viewpoint | Wo entstehen die Daten und wie werden sie zusammengeführt? | Quellenlandkarte, Schnittstellen, Mapping, Datenherkunft |
10 | Application- und Plattform-Viewpoint | Welche Rolle spielen Teams, SharePoint und SQL/Azure SQL? | Zielarchitektur für Pflege, Kollaboration und harmonisierte Datenbasis |
11 | Reporting- und Entscheidungs-Viewpoint | Welche Sichten brauchen Stakeholder? | Projektstatus, Budgetstatus, Qualitätsranking, Risiken, Fristen |
12 | Governance- und MVP-Viewpoint | Was kommt zuerst und wie bleibt es beherrschbar? | MVP-Scope, Standards, Rollen, Definition of Done, Roadmap |
Empfohlen ist eine agile Darstellungslogik:
2. Neutrale, casual Kernformulierung
Der Drittmittelprozess ist keine reine Abfolge von Formularen, Mails und Ablagen. Er ist eine hochschulweite Wertschöpfungskette, in der Forschungsideen in förderfähige, finanzierbare, steuerbare und nachweisfähige Projekte überführt werden.
Damit das funktioniert, braucht es drei Dinge gleichzeitig:
klare Rollen und Verantwortlichkeiten,
saubere Kollaboration an den kritischen Touchpoints,
eine harmonisierte Informationsbasis, die Status, Budget, Ressourcen, Qualität und Entscheidungen sichtbar macht.
Der entscheidende Shift liegt in der Prozesslogik:
So wird aus einer Ablage ein steuerbarer Prozessraum.
3. Collaboration Areas und Touchpoints
Die bisherigen Touchpoints können zu Collaboration Areas gebündelt werden. Das macht die Darstellung übersichtlicher und zeigt besser, an welchen Stellen mehrere Stakeholder gleichzeitig wirken.
3.1 Collaboration Area 1: Intake & Forschungsopportunität
Zweck: Eine Forschungsidee wird sichtbar, qualifiziert und in den passenden Einstiegskanal gebracht.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Projektleitung, Forschungsmanagement, ggf. Prorektorat Forschung |
Typische Touchpoints | Erstgespräch, Ideenskizze, Call-Matching, strategische Vorabinfo |
Zentrale Informationen | Idee, Thema, Förderlinie, strategische Passung, grobe Laufzeit, erste Risiken |
Prozessmetadaten | Intake-Status, Owner, nächste Aktion, Zieltermin, Priorität, strategische Relevanz |
Output | Qualifizierte Projektidee / Opportunity Record |
3.2 Collaboration Area 2: Förderfähigkeit & Projektkonzept
Zweck: Die Idee wird in ein antragsfähiges Projektkonzept übersetzt.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Projektleitung, Forschungsmanagement, Partner, ggf. Labor / Transfer / Kommunikation |
Typische Touchpoints | Call-Analyse, Projektlogik, Arbeitspakete, Partnerrollen, Ergebnislogik |
Zentrale Informationen | Förderbedingungen, Ziele, Arbeitspakete, Deliverables, Partnerstruktur, Impact |
Prozessmetadaten | Förderfähigkeitsstatus, Review-Status, offene Klärungen, Abhängigkeiten |
Output | Antragsfähiges Projektkonzept |
3.3 Collaboration Area 3: Ressourcen-, Zeit- und Kostenplanung
Zweck: Wissenschaftliche Logik und Finanzlogik werden zusammengebracht.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Projektleitung, Forschungsmanagement, Finanzabteilung, HR, Labor, Beschaffung |
Typische Touchpoints | T&M-Klärung, Personalkosten, Sachmittel, Geräte, Reisen, Eigenanteile, Laufzeiten |
Zentrale Informationen | Personenmonate, Stellenlaufzeiten, Kostenarten, Budgetplan, Sachmittel, Unteraufträge |
Prozessmetadaten | Kalkulationsstatus, FIN-Prüfstatus, HR-Prüfstatus, Budgetrisiko, Freigabebedarf |
Output | Kalkulations- und Antragsreife |
Diese Collaboration Area ist der zentrale Knoten. Hier treffen Förderlogik, Kostenlogik, Ressourcenlogik und Umsetzbarkeit zusammen.
3.4 Collaboration Area 4: Interne Governance & Einreichung
Zweck: Der Antrag wird intern freigegeben und formal eingereicht.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Projektleitung, Forschungsmanagement, Finanzabteilung, Rektorat / Prorektorat |
Typische Touchpoints | Antragsreview, Finanzprüfung, Unterschrift, Freigabe, Portal-Einreichung |
Zentrale Informationen | Antrag, Kalkulation, Risiken, Freigabedokumente, Zeichnungsrechte |
Prozessmetadaten | Gate-Status, Approver, Entscheidungsfrist, Unterschriftenstatus, Einreichungsfrist |
Output | Eingereichter Antrag / Skizze |
3.5 Collaboration Area 5: Bewilligung, Annahme & Projektstart
Zweck: Aus der Bewilligung wird ein administrierbares Drittmittelprojekt.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Finanzabteilung, Rektorat, Projektleitung, Forschungsmanagement, HR, Beschaffung |
Typische Touchpoints | Zuwendungsbescheid, Drittmittelanzeige, Kostenstelle, Personalstart, Beschaffung |
Zentrale Informationen | Bescheid, Auflagen, Budget, Kostenstelle / PSP, Projektstart, Mittelabrufe |
Prozessmetadaten | Annahmestatus, Bescheidprüfung, Auflagenstatus, Projektkonto-Status, Startfreigabe |
Output | Operativ startfähiges Projekt |
3.6 Collaboration Area 6: Projektbetrieb, Controlling & Änderungen
Zweck: Das Projekt bleibt fachlich, finanziell und formal steuerbar.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Projektleitung, Finanzabteilung, Forschungsmanagement, Projektträger, HR, Beschaffung |
Typische Touchpoints | Budgetüberwachung, Mittelabrufe, Änderungsanträge, Personaländerungen, Fristen |
Zentrale Informationen | Ist-Buchungen, Planbudget, gebundene Mittel, Restmittel, Meilensteine, Risiken |
Prozessmetadaten | Ampelstatus, Abweichungsstatus, Eskalation, Änderungsworkflow, Fristenstatus |
Output | Laufend steuerbares Projekt |
3.7 Collaboration Area 7: Verwendungsnachweis, Abschluss & Sichtbarkeit
Zweck: Das Projekt wird nachweisfähig abgeschlossen und sichtbar gemacht.
Element | Beschreibung |
|---|---|
Beteiligte Rollen | Projektleitung, Finanzabteilung, Forschungsmanagement, Rektorat, Kommunikation |
Typische Touchpoints | Sachbericht, zahlenmäßiger Nachweis, Abschlussprüfung, Ergebnisverwertung |
Zentrale Informationen | Sachbericht, Buchungen, Belege, Ergebnisdaten, Publikationen, Transferdaten |
Prozessmetadaten | Nachweisstatus, Dokumentenstatus, Prüffrist, Ergebnisstatus, Sichtbarkeitsstatus |
Output | Abgeschlossenes, nachgewiesenes und verwertbares Projekt |
4. Workflow-Baukasten: Routing statt Ablage
Der Prozess sollte nicht als ein großer, starrer Workflow modelliert werden. Besser ist ein Baukasten aus kleinen, kombinierbaren Workflow-Typen. So bleiben agile Anpassungen möglich, ohne jedes Mal die komplette Prozesslogik umzubauen.
Workflow-Baustein | Zweck | Typischer Trigger | Ergebnis |
|---|---|---|---|
Informieren | Rolle bekommt relevante Info | Statuswechsel, neuer Antrag, neue Frist | Kenntnisnahme dokumentiert |
Rückfrage / Klärung | Offener Punkt wird geklärt | Unvollständige Daten, unklare Kostenart | Antwort / Entscheidung liegt vor |
Review | Fachliche Prüfung | Antrag, Kalkulation, Bescheid, Bericht | Review-Ergebnis mit Kommentar |
Freigabe einfach | Eine Rolle entscheidet | Schwellenwert nicht kritisch | Freigabe / Ablehnung |
Freigabe mehrstufig | Mehrere Rollen entscheiden nacheinander | Antrag, Bescheid, Vertrag, Änderung | Vollständige Genehmigungskette |
Parallelabstimmung | Mehrere Rollen prüfen gleichzeitig | HR, FIN, Labor, FM müssen Input geben | Synchronisierter Prüfstand |
Bedingte Freigabe | Routing abhängig von Wert / Risiko | Budgethöhe, Eigenanteil, Risikoklasse | Dynamische Entscheidungskette |
Änderungsworkflow | Änderung wird kontrolliert umgesetzt | Budgetverschiebung, Laufzeitänderung | genehmigte Änderung mit Historie |
Eskalation | Frist oder Risiko wird kritisch | Überfällige Aufgabe, Budgetabweichung | Eskalierter Vorgang mit Owner |
Datenqualitätsprüfung | Daten werden validiert | Neue / geänderte Stammdaten | geprüft, zurückgewiesen oder ergänzt |
Abschlussprüfung | Projekt wird formal geschlossen | Projektende / Nachweisfrist | Abschlussstatus und offene Punkte |
4.1 Routing-Prinzipien
Informationen haben Owner: Jede offene Aktion gehört einer Rolle oder Person.
Status ist explizit: Kein „liegt irgendwo“, sondern klarer Status mit nächstem Schritt.
Fristen steuern Priorität: Fälligkeiten, Förderfristen und Nachweisfristen erzeugen Arbeitslisten.
Entscheidungen sind nachvollziehbar: Wer hat wann was entschieden und auf welcher Datenbasis?
Routing ist konfigurierbar: Schwellenwerte, Rollen, Gremien und Genehmigungsarten werden nicht hart verdrahtet.
Metadaten treiben den Prozess: Status, Risiko, Budgethöhe, Fördergeber, Kostenart und Phase bestimmen den nächsten Pfad.
5. Harmonisiertes Informations- und Datenkonzept
Die Harmonisierung sollte mit einem fachlichen Concept Model starten. Erst danach folgen Tabellen, Listen, JSON-Schemas oder Schnittstellen. Sonst entsteht schnell nur eine neue technische Ablage mit schöner Oberfläche.
5.1 Zentrale Fachkonzepte
Fachkonzept | Kurzbeschreibung | Typische Beziehungen |
|---|---|---|
Forschungsprojekt | fachlicher Projektcontainer | hat Antrag, Förderung, Budget, Arbeitspakete, Qualitätsbewertungen |
Opportunity / Projektidee | früher Projektkandidat | wird zu Projektskizze oder Antrag |
Förderprogramm / Call | externer Förderrahmen | definiert Regeln, Fristen, Förderquoten, Nachweise |
Antrag / Skizze | einzureichendes Projektdokument | gehört zu Projekt, Förderprogramm, Partnern, Budgetplan |
Zuwendungsbescheid | Bewilligungsgrundlage | erzeugt Budget, Auflagen, Nachweispflichten |
Projektpartner | externer oder interner Partner | übernimmt Rollen, Beiträge, Arbeitspakete |
Arbeitspaket | fachliche Projektstruktur | hat Aufgaben, Ressourcen, Deliverables, Meilensteine |
Ressource | Personal, Sachmittel, Gerät, Reise, Unterauftrag | wird geplant, gebucht, nachgewiesen |
Budgetplan | Soll-Struktur der Finanzierung | enthält Budgetlinien nach Kostenart und Zeitraum |
Finanzbewegung | Ist-Buchung, Mittelabruf, Bindung | wird Projekt, Kostenart, Zeitraum zugeordnet |
Qualitätsmerkmal | definierte Bewertungsdimension | erzeugt Score, Ranking, Status, Nachweis |
Entscheidung | fachliche oder formale Entscheidung | gehört zu Workflow, Rolle, Zeitpunkt, Ergebnis |
Workflow-Aufgabe | routbare Aktion | hat Owner, Status, Frist, Eingangsdaten, Ergebnis |
Dokument / Artefakt | Antrag, Bescheid, Bericht, Nachweis | trägt Version, Status, Bezug, Ablageort |
Status-Event | dokumentierter Zustandswechsel | erzeugt Historie und Audit Trail |
5.2 Stamm-, Bewegungs-, Plan- und Ist-Daten
Datenart | Beispiele | Zweck |
|---|---|---|
Stammdaten | Projekt-ID, Projektleitung, Organisationseinheit, Fördergeber, Kostenstelle | stabile Identifikation und Zuordnung |
Bewegungsdaten | Statuswechsel, Aufgaben, Kommentare, Freigaben, Buchungen | aktueller Prozess- und Projektzustand |
Plandaten | Budget-Soll, Personenmonate, Meilensteine, Mittelabrufe, geplante Kosten | Steuerung, Forecast, Soll-Ist-Vergleich |
Ist-Daten | Buchungen, Mittelabfluss, Personalkosten, Belege, gebundene Mittel | Nachweis und Controlling |
Qualitätsdaten | Scores, Bewertungen, Kriterien, Gewichtungen, Evidenzen | Ranking, Priorisierung, Qualitätsmanagement |
Metadaten | Owner, Quelle, Version, Status, Frist, Routingregel | Prozessführung, Datenqualität, Auditfähigkeit |
6. Metadaten als Prozess-Treibstoff
Metadaten sind hier nicht nur technische Zusatzinformationen. Sie sind die Steuerungslogik des Prozesses. Besonders bei mehreren gleichzeitig wirkenden Stakeholdern muss klar sein, welche Information gerade wo steht, wer handeln muss und wodurch der nächste Schritt ausgelöst wird.
6.1 Metadaten-Kategorien
Kategorie | Beispiele | Nutzen |
|---|---|---|
Identitätsmetadaten | Canonical ID, Projekt-ID, Quellsystem-ID, Version | eindeutige Zuordnung über Systeme hinweg |
Ownership-Metadaten | fachlicher Owner, technischer Owner, Responsible Role, Delegate | klare Zuständigkeit |
Prozessmetadaten | Phase, Status, Gate, aktuelle Aufgabe, nächster Schritt | aktive Prozessführung |
Zeitmetadaten | Startdatum, Fälligkeitsdatum, Fristtyp, Eskalationsdatum | Fristensteuerung und Priorisierung |
Entscheidungsmetadaten | Entscheidungstyp, Approver, Ergebnis, Kommentar, Entscheidungsdatum | Governance und Nachvollziehbarkeit |
Qualitätsmetadaten | Kriterium, Score, Gewichtung, Evidenz, Bewertungsstand | Ranking und Qualitätssteuerung |
Finanzmetadaten | Soll/Ist, Kostenart, Budgetlinie, Buchungsperiode, Mittelbindung | Plan-Ist-Sicht und Budgetsteuerung |
Integrationsmetadaten | Quelle, Ladezeitpunkt, Mapping-Version, Sync-Status | Datenherkunft und Datenqualität |
Compliance-Metadaten | Klassifizierung, Aufbewahrung, Prüfpfad, Datenschutzstatus | Audit, Datenschutz, Nachweisfähigkeit |
Kollaborationsmetadaten | Kommentar, Erwähnung, Aufgabe, Benachrichtigung, Eskalation | Zusammenarbeit und Routing |
6.2 Prozessführende Metadaten
Für die Prozesssteuerung sind besonders diese Felder relevant:
6.3 Datenqualitäts-Metadaten
6.4 Herkunfts- und Mapping-Metadaten
7. Technisches Beschreibungskonzept: pragmatisch und modern
Die Beschreibung von Informationen und Metadaten sollte nicht mit zu viel Semantik überladen werden. Für den ersten Schritt reicht ein schlanker, kontrollierter Mix.
7.1 Empfehlung
Ebene | Format / Technik | Einsatz |
|---|---|---|
Fachliches Concept Model | Markdown + YAML | verständliche Dokumentation der Konzepte, Beziehungen, Regeln |
Validierbare Datenstrukturen | JSON Schema | Prüfung von API-Payloads, SharePoint-Exporten, Importdaten, Workflow-Objekten |
Persistente Datenbasis | MS SQL / Azure SQL | harmonisierte Tabellen, Views, Reporting, Historisierung |
Konfiguration | YAML | Workflow-Templates, Routingregeln, Schwellenwerte, Rollenmapping |
Schnittstellen | JSON bevorzugt, XML bei Bedarf | moderne Integrationen; XML nur dort, wo Systeme oder Förderportale es verlangen |
Semantische Schicht | RDFS / OWL light, optional | kontrolliertes Vokabular und Beziehungen, aber nur wenn fachlich wirklich nötig |
7.2 Klare Empfehlung zu XML, JSON, YAML, RDF/OWL
JSON / JSON Schema sollte der Standard für strukturierte, validierbare Austauschobjekte werden. Das passt gut zu modernen Schnittstellen, Workflows, Power Platform, Azure Functions und API-orientierten Szenarien.
YAML eignet sich sehr gut für Konfiguration und fachnahe Dokumentation: Workflow-Templates, Routingregeln, Felddefinitionen, Mappingregeln, View-Definitionen. YAML ist gut lesbar und lässt sich trotzdem maschinell verarbeiten.
XML / XSD sollte nicht als primäres internes Modell verwendet werden, außer externe Systeme oder Förderprozesse verlangen XML. XML ist stabil und formal, aber für agile Modellierung und schnelle Anpassungen oft schwerfälliger.
RDFS / OWL sollte nur in einer leichten Variante eingesetzt werden. Sinnvoll ist eine kleine semantische Schicht für kontrollierte Begriffe, Beziehungen und Synonyme, zum Beispiel:
Für den Start reicht also:
8. Zielarchitektur auf pragmatischem Niveau
Die Plattformlogik kann so geschnitten werden:
Schicht | Rolle im Zielbild |
|---|---|
MS Teams | Arbeitsraum, Kommunikation, Benachrichtigung, kontextbezogene Kollaboration |
SharePoint Online | strukturierte Listen, Dokumente, einfache Eingabemasken, Aufgaben, Versionen |
Workflow-Schicht | Routing, Freigaben, Eskalationen, Erinnerungen, Statuswechsel |
MS SQL / Azure SQL | harmonisierte Datenbasis, Historie, Views, Reporting, konsolidierte Projektlogik |
Reporting / Dashboard | Projektstatus, Budgetstatus, Qualitätsranking, Fristen, Risiken, offene Aufgaben |
Integrationsschicht | Übernahme aus Excel, Buchhaltung, proprietärer Projektdatenbank, HR / Beschaffung |
Wichtig: SharePoint ersetzt nicht das Datenmodell. SharePoint ist die kollaborative Oberfläche. SQL / Azure SQL bildet die konsolidierte, auswertbare Datenbasis.
9. Erste harmonisierte Sichten
Für den ersten Schritt sind diese Sichten besonders relevant:
Sicht | Zweck | Kerninformationen |
|---|---|---|
Projekt-Cockpit | Gesamtzustand je Projekt | Status, Owner, Phase, Budget, Qualität, Risiken, Fristen |
Budget-Status | Finanzielle Steuerung | Soll, Ist, gebundene Mittel, Restmittel, Forecast, Kostenart |
Ressourcen-Sicht | Personal und Sachmittel | Personenmonate, Stellen, Geräte, Reisen, Unteraufträge |
Qualitätsranking | Vergleich und Priorisierung | Kriterien, Scores, Gewichtung, Evidenz, Ranking |
Workflow-Queue | aktive Arbeit statt Ablage | offene Aufgaben, Owner, Fristen, Eskalationen |
Entscheidungslog | Governance | Freigaben, Ablehnungen, Kommentare, Entscheidungsgrundlage |
Datenqualitäts-Sicht | Datenpflege steuern | fehlende Felder, ungültige Werte, Sync-Probleme, Mappingfehler |
Nachweis-Sicht | Abschluss und Compliance | Berichte, Belege, Nachweistermine, Prüfpunkte, Auflagen |
10. PlantUML-Diagramme
10.1 Viewpoint Map
10.2 Collaboration Context
10.3 Routing-Workflow als Activity Diagram
10.4 Fachliches Informationsmodell
10.5 Prozessmetadaten und Datenherkunft
10.6 Application / Data Architecture
11. MVP-Schnitt für die erste Umsetzungsstufe
Die erste Stufe sollte bewusst klein, aber wirksam geschnitten werden.
MVP-Ziel
MVP-Bausteine
Baustein | Inhalt |
|---|---|
Concept Catalog | zentrale Fachbegriffe, Beziehungen, Verantwortlichkeiten |
Projekt-Cockpit | einheitliche Sicht auf Projektstatus, Budget, Qualität, Fristen |
Budget-Plan-Ist-Sicht | Soll-Budget, Ist-Buchungen, gebundene Mittel, Restmittel |
Workflow-Queue | offene Aufgaben nach Rolle, Frist, Status, Priorität |
Qualitätsmerkmale | 5–10 Kriterien, Gewichtung, Score, Evidenz, Ranking |
Datenimport | kontrollierte Übernahme aus Excel, Buchhaltung und Projektdatenbank |
Metadatenmodell | Owner, Status, Quelle, Version, Frist, Entscheidung, Eskalation |
Reporting Views | SQL-Views für Management, FM, FIN, Projektleitung |
Definition of Done für das MVP
Ein Informationsobjekt gilt als MVP-tauglich, wenn diese Fragen beantwortet sind: