213 lines
9.2 KiB
Markdown
213 lines
9.2 KiB
Markdown
# PowerOn Plattform – Features, Setup & Roadmap
|
||
|
||
**Stand:** Februar 2026
|
||
**Zielgruppe:** Intern, Präsentation, Roadmap-Planung
|
||
|
||
---
|
||
|
||
## 1. Überblick
|
||
|
||
Dieses Dokument beschreibt die vorhandenen Features der PowerOn-Plattform, das allgemeine Plattform-Setup (Security, Mandanten, Nutzerverwaltung) sowie die Einordnung in die Roadmap März–Mai 2026.
|
||
|
||
---
|
||
|
||
## 2. Allgemeines Plattform-Setup
|
||
|
||
### 2.1 Mandanten-/User-Management
|
||
|
||
PowerOn ist eine **Multi-Mandanten-Plattform**:
|
||
|
||
- **Mandatenmodell:** Jede Organisation/Kunde wird als Mandant abgebildet.
|
||
- **Datenisolation:** Daten eines Mandanten sind strikt von anderen Mandanten getrennt.
|
||
- **Zugehörigkeitsprüfung:** Bei jedem Zugriff wird geprüft, ob der Nutzer dem Mandanten angehört (via `UserMandate`).
|
||
- **Request-Kontext:** `mandateId` und `featureInstanceId` werden über Header (`X-Mandate-Id`, `X-Feature-Instance-Id`) übergeben.
|
||
- **Mehrfachmandanten:** Nutzer können in mehreren Mandanten tätig sein; der Kontext wird pro Anfrage festgelegt.
|
||
|
||
**Zentrale Entitäten:**
|
||
|
||
| Entität | Beschreibung |
|
||
|---------|--------------|
|
||
| Mandate | Mandant (Organisation, Abteilung, Kunde) |
|
||
| UserInDB | Nutzer (Benutzername, Profil) |
|
||
| UserMandate | Zuordnung Nutzer ↔ Mandant (mit enabled) |
|
||
| UserMandateRole | Rollenzuweisung auf Mandanten-Ebene |
|
||
| FeatureInstance | Instanz eines Features innerhalb eines Mandanten |
|
||
| FeatureAccess | Zugriff Nutzer auf Feature-Instanz |
|
||
| FeatureAccessRole | Rollen pro Feature-Instanz |
|
||
|
||
### 2.2 Rollenbasierte Zugriffskontrolle (RBAC)
|
||
|
||
- **AccessRule-Kontext:** System, API, DATA
|
||
- **AccessLevel:** NONE, MY, GROUP, ALL
|
||
- **Template-Rollen:** Pro Feature können globale Rollenvorlagen definiert werden; bei Erstellung einer Feature-Instanz werden diese kopiert.
|
||
- **Namespaces:**
|
||
- `data.uam.*` → Mandanten-UAM
|
||
- `data.chat.*`, `data.files.*`, `data.automation.*` → nutzer-eigen (MY)
|
||
- `data.feature.{code}.*` → Mandanten-/Feature-spezifisch
|
||
|
||
### 2.3 Authentifizierung
|
||
|
||
- **Lokal:** Benutzername + Passwort, JWT
|
||
- **Microsoft (Azure AD / Entra ID):** SSO
|
||
- **Google:** SSO
|
||
- **Token:** HTTP-only Cookies, automatische Erneuerung, Widerruf möglich
|
||
|
||
### 2.4 Security-Baseline (Compliance)
|
||
|
||
- **Verschlüsselung:** AES (Fernet), PBKDF2-HMAC-SHA256 für Konfiguration
|
||
- **DSGVO:** Auskunft, Löschung, Datenübertragbarkeit, Berichtigung als Self-Service
|
||
- **Audit-Trail:** Zugriffe, Sicherheitsereignisse, DSGVO-Aktionen, Berechtigungsänderungen
|
||
- **OWASP:** CSRF, Rate Limiting, parametrisierte Queries, CORS
|
||
- **Neutralisierung:** Optionales Modul zur Maskierung/Pseudonymisierung von PII vor KI-Versand
|
||
|
||
---
|
||
|
||
## 3. Feature-Übersicht (`gateway/modules/features`)
|
||
|
||
### 3.1 Chatbot
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `chatbot` |
|
||
| **Zweck** | KI-gestützter Chat mit Workflows, Tools, Memory |
|
||
| **DB** | `poweron_chatbot` |
|
||
| **Besonderheiten** | RBAC pro `featureInstanceId`, streaming, Multi-Round, Tools (z. B. Websuche), Event-Manager |
|
||
|
||
### 3.2 Chatplayground
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `chatplayground` |
|
||
| **Zweck** | Sichere Testumgebung für KI-Chat |
|
||
| **Besonderheiten** | Wrapper um `interfaceDbChat` mit Feature-Instanz-Kontext; isolierte Umgebung pro Mandant |
|
||
|
||
### 3.3 TeamsBot
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `teamsbot` |
|
||
| **Zweck** | Microsoft Teams Bot mit authentifiziertem Nutzer, Protokollierung |
|
||
| **DB** | `poweron_teamsbot` |
|
||
| **Besonderheiten** | Sessions, Transcripts, Bot-Antworten; System-Bots (mandantenbezogen); Browser-Connector für Interaktionen |
|
||
|
||
### 3.4 Trustee (BuHa-Integration)
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `trustee` |
|
||
| **Zweck** | Treuhand/Buchhaltung: Organisationen, Verträge, Dokumente, Positionen, Buchungssynchronisation |
|
||
| **DB** | `poweron_trustee` |
|
||
| **Accounting-Connectors** | Bexio, Abacus, RMA |
|
||
| **Besonderheiten** | Feature-eigene Rollen (admin, operate, userreport), RBAC + feature-spezifische Zugriffslogik |
|
||
|
||
### 3.5 Neutralization (Dokumentbearbeitung mit KI)
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `neutralization` |
|
||
| **Zweck** | Maskierung/Pseudonymisierung sensibler Daten in Dokumenten (PII) vor KI-Verarbeitung |
|
||
| **DB** | `poweron_neutralization` |
|
||
| **Besonderheiten** | PDF in-place (PyMuPDF), Platzhalter (z. B. `[name.uuid]`), konfigurierbare Muster; Neutralize Playground |
|
||
|
||
### 3.6 Automation
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `automation` |
|
||
| **Zweck** | Zeitgesteuerte / Event-getriggerte Workflows |
|
||
| **DB** | `poweron_automation` |
|
||
| **Besonderheiten** | AutomationDefinition, AutomationTemplate (System + Instanz), Event-Management, Callback-Registry |
|
||
|
||
### 3.7 RealEstate
|
||
|
||
| Aspekt | Inhalt |
|
||
|--------|--------|
|
||
| **Code** | `realestate` |
|
||
| **Zweck** | Immobilienverwaltung: Projekte, Parzellen, Dokumente, Kanton/Gemeinde, Geo-Daten |
|
||
| **DB** | `poweron_realestate` |
|
||
| **Besonderheiten** | BZO-Extraktion, Swiss Topo Scraping, LangGraph |
|
||
|
||
---
|
||
|
||
## 4. Einordnung der strategischen Features (Roadmap-relevant)
|
||
|
||
| Feature | Status | Beschreibung |
|
||
|---------|--------|--------------|
|
||
| **Chatbot / Playground** | Live | Sichere Umgebung für Nutzer; Chatplayground als abgegrenzte Testinstanz |
|
||
| **Private LLM** | Live | Ollama-basierter Connector (`privatellm`); lokal/on-premise; kein Datenabfluss |
|
||
| **BuHa-Integration** | Live | Trustee mit Connectors Bexio, Abacus, RMA; Sync zu Buchhaltungssystemen |
|
||
| **TeamsChatbot** | Live | Bot in Teams mit identifiziertem Nutzer; voll protokolliert |
|
||
| **Dokumentbearbeitung mit KI** | In Arbeit | Neutralization (Masking) + Referenzprozess ERP/Dokument-Extraktion; strukturierter Output |
|
||
|
||
---
|
||
|
||
## 5. Roadmap März–Mai 2026: Maßnahmenplan
|
||
|
||
*Ziel bis Ende Mai: erste produktive Deployments live, Standard-Onboarding v1, Paid Usage gestartet, Security & Compliance als Default.*
|
||
|
||
### März 2026 – Foundations + Pilot→Prod
|
||
|
||
| Maßnahme | Verantwortlich |
|
||
|----------|----------------|
|
||
| Go-Live Readiness Checklist v1 (Monitoring, Logging, Backup/Restore, Incident-Flow, Release-Prozess) | Platform/Engineering |
|
||
| Mandanten-/User-Setup „v1“ (Roles, Zugriff, Audit-Logs minimum viable) | Security/Compliance |
|
||
| Security-Baseline aktivieren: Masking/Neutralisierung als Standard pro Workflow + Definition „Datenklasse A/B/C“ | Security/Compliance |
|
||
| 1 Referenzprozess auswählen & finalisieren (z. B. ERP/Dokument-Extraktion mit strukturiertem Output) | Platform/Engineering |
|
||
| Erste produktive Installation vorbereiten (Kunde A) | Customer Success |
|
||
|
||
**Output Ende März:** 1 produktiver Kunde „go-live ready“, Onboarding-Runbook v1, Security Default aktiv
|
||
|
||
---
|
||
|
||
### April 2026 – Erste produktive Deployments + Reproduzierbarkeit
|
||
|
||
| Maßnahme | Verantwortlich |
|
||
|----------|----------------|
|
||
| Produktivsetzung Kunde A inkl. Abnahme (SLA-light, Supportkanal) | Customer Success |
|
||
| Onboarding v1 standardisieren: Templates (Config, Policies, Integrationsmodule), Setup in < 6 Wochen | Platform/Engineering |
|
||
| Workflow Engine hardening: Fehlerbehandlung, Retries, Idempotenz, Kontextgrenzen (wichtigste 20 %) | Platform/Engineering |
|
||
| Kunde B starten (zweites Setup als Wiederholbarkeitstest) | Go-To-Market |
|
||
| Kosten-/Usage-Metering einführen (Nutzer, Runs, Tokens, Zeitersparnis-Indikator) | Platform/Engineering |
|
||
|
||
**Output Ende April:** 1 Kunde produktiv, 2. Kunde im Setup, Onboarding v1 wiederholbar, Usage-Metriken sichtbar
|
||
|
||
---
|
||
|
||
### Mai 2026 – Paid Usage + Skalierbarer Betrieb
|
||
|
||
| Maßnahme | Verantwortlich |
|
||
|----------|----------------|
|
||
| Paid Usage aktivieren (Pricing/Package v1, Billing-Prozess) | Go-To-Market |
|
||
| Support & Betrieb v1: Monitoring-Dashboards, Alerting, Incident-Routinen, Release-Kadenz (z. B. 2-wöchentlich) | Platform/Engineering |
|
||
| Security & Compliance ausbauen: Policy-Sets pro Workflow, Auditierbarkeit (wer/wann/was), Fallback lokales LLM | Security/Compliance |
|
||
| Kunde B go-live + Kunde C als Pipeline-Test | Customer Success |
|
||
| „First Value Moment“ messbar: pro Kunde 1–2 Kennzahlen | Customer Success |
|
||
|
||
**Output Ende Mai:** mindestens 2 produktive Deployments, erste zahlende Nutzung, Betrieb stabil, First Value messbar
|
||
|
||
---
|
||
|
||
## 6. Zuordnung Features ↔ Roadmap
|
||
|
||
| Feature | März | April | Mai | Anmerkung |
|
||
|---------|------|-------|-----|-----------|
|
||
| Neutralisierung | Security Default aktiv | — | Policy-Sets pro Workflow | Datenklasse A/B/C definieren |
|
||
| Trustee/BuHa | Referenzprozess ERP/Dok-Extraktion | Wiederholbarkeit Onboarding | — | strukturierter Output |
|
||
| Chatbot/Playground | — | — | — | bereits produktiv nutzbar |
|
||
| TeamsBot | — | — | — | authentifizierter User, protokolliert |
|
||
| Private LLM | — | — | Fallback-Strategie dokumentieren | für höchste Datenschutzanforderungen |
|
||
|
||
---
|
||
|
||
## 7. Verantwortlichkeiten (Slide-Footer)
|
||
|
||
| Rolle | Verantwortungsbereich |
|
||
|-------|------------------------|
|
||
| **Platform/Engineering** | Stabilität, Deployment, Monitoring, Workflow-Hardening |
|
||
| **Security/Compliance** | Policies, Masking, Audit, Datenklassifikation |
|
||
| **Go-To-Market** | Kundenpipeline, Packaging/Pricing v1, Paid Activation |
|
||
| **Customer Success** | Onboarding-Runbook, Abnahme, Adoption/Value Tracking |
|
||
|
||
---
|
||
|
||
*Dokument basiert auf der Gateway-Codebasis (Stand Februar 2026) und dem Compliance-Dokument `poweron_sicherheit_und_compliance.md`.*
|