docs: add gateway docs and Cursor plan artifacts
Made-with: Cursor
This commit is contained in:
parent
af68f6a8c8
commit
ea566c270f
32 changed files with 7158 additions and 0 deletions
1036
.cursor/plans/swift_ios_app_nachbau_3dc75f35.plan.md
Normal file
1036
.cursor/plans/swift_ios_app_nachbau_3dc75f35.plan.md
Normal file
File diff suppressed because it is too large
Load diff
741
.cursor/plans/swift_ios_app_nachbau_80bb1212.plan.md
Normal file
741
.cursor/plans/swift_ios_app_nachbau_80bb1212.plan.md
Normal file
|
|
@ -0,0 +1,741 @@
|
|||
---
|
||||
name: Swift iOS App Nachbau
|
||||
overview: Vollständiger Implementierungsplan für den Nachbau des React-Web-Frontends (frontend_nyla) als native Swift/SwiftUI iOS/iPadOS-App. Die App kommuniziert mit dem bestehenden FastAPI-Gateway-Backend und bildet alle UI-Screens, Navigation und API-Schnittstellen nach.
|
||||
todos:
|
||||
- id: phase-0
|
||||
content: "Phase 0: Xcode-Projekt erstellen, Ordnerstruktur, SPM-Dependencies, Build-Configs (Dev/Int/Prod)"
|
||||
status: pending
|
||||
- id: phase-1
|
||||
content: "Phase 1: Core Networking Layer -- APIClient, SSEClient, WebSocketClient, CSRFManager (analog api.ts + sseClient.ts)"
|
||||
status: pending
|
||||
- id: phase-2
|
||||
content: "Phase 2: Authentication -- LocalAuth, MSAL, Google, Biometrie, Keychain (analog authApi.ts + AuthProvider.tsx)"
|
||||
status: pending
|
||||
- id: phase-3
|
||||
content: "Phase 3: Domain Models + FeatureStore (analog mandate.ts + featureStore.tsx)"
|
||||
status: pending
|
||||
- id: phase-4
|
||||
content: "Phase 4: App Shell -- NavigationSplitView (iPad) / TabView (iPhone), Dashboard, Settings, backend-driven Sidebar"
|
||||
status: pending
|
||||
- id: phase-5
|
||||
content: "Phase 5: i18n String Catalogs (de/en/fr) + Theme System (Light/Dark)"
|
||||
status: pending
|
||||
- id: phase-6
|
||||
content: "Phase 6: Core Pages -- Store, GDPR, Basedata (Prompts/Files/Connections), Billing Transactions"
|
||||
status: pending
|
||||
- id: phase-7
|
||||
content: "Phase 7: Shared UI Components -- FormGenerator, ContentPreview, ChatMessage, AccessRules, NotificationBell"
|
||||
status: pending
|
||||
- id: phase-8
|
||||
content: "Phase 8: Push Notifications (APNs Registration, Deep-Link Handling)"
|
||||
status: pending
|
||||
- id: phase-9
|
||||
content: "Phase 9: Admin Module -- alle 16 Admin-Seiten (Mandates, Users, RBAC, Invitations, Wizards, etc.)"
|
||||
status: pending
|
||||
- id: phase-10
|
||||
content: "Phase 10: Feature Trustee -- Dashboard, Documents, Positions, Roles, Expense-Import, Scan, Accounting"
|
||||
status: pending
|
||||
- id: phase-11
|
||||
content: "Phase 11: Feature Workspace -- Chat-Streaming (SSE), Files, Datasources, Voice"
|
||||
status: pending
|
||||
- id: phase-12
|
||||
content: "Phase 12: Feature Chatbot -- SSE-Streaming Chat, Threads, Conversations"
|
||||
status: pending
|
||||
- id: phase-13
|
||||
content: "Phase 13: Feature Teamsbot -- Sessions, WebSocket Bot-Kommunikation, Voice, MFA"
|
||||
status: pending
|
||||
- id: phase-14
|
||||
content: "Phase 14: Feature CommCoach -- Coaching Sessions, Audio-Streaming, Personas, Dossier"
|
||||
status: pending
|
||||
- id: phase-15
|
||||
content: "Phase 15: Feature ChatPlayground -- Workflows, Playground mit SSE-Stream"
|
||||
status: pending
|
||||
- id: phase-16
|
||||
content: "Phase 16: Feature Automation -- Definitions, Templates, Logs, Execute"
|
||||
status: pending
|
||||
- id: phase-17
|
||||
content: "Phase 17: Feature CodeEditor -- Editor mit SSE-Stream, Code-Anzeige, Apply"
|
||||
status: pending
|
||||
- id: phase-18
|
||||
content: "Phase 18: Feature RealEstate/PEK -- MapKit-Integration, Parcels, Address-Search, BZO"
|
||||
status: pending
|
||||
- id: phase-19
|
||||
content: "Phase 19: Feature Neutralization -- Config, Neutralize Text/File"
|
||||
status: pending
|
||||
- id: phase-20
|
||||
content: "Phase 20: Billing-Erweiterung -- Admin-Views, Stripe Checkout"
|
||||
status: pending
|
||||
isProject: false
|
||||
---
|
||||
|
||||
# Nyla iOS/iPadOS App -- Vollständiger Implementierungsplan
|
||||
|
||||
## Ausgangslage
|
||||
|
||||
Das bestehende Web-Frontend (`frontend_nyla`) ist eine **React 19 + Vite + TypeScript** Anwendung mit:
|
||||
|
||||
- **12+ Feature-Module** (Trustee, Workspace, Chatbot, Teamsbot, CommCoach, CodeEditor, Automation, RealEstate, Neutralization, ChatPlayground, Billing, Admin)
|
||||
- **21 API-Module** unter `src/api/*.ts` mit insgesamt **200+ API-Endpunkten**
|
||||
- **120+ UI-Komponenten** inkl. dynamischem FormGenerator, ContentPreview, Chat-Streaming, Maps, Charts
|
||||
- **Multi-Tenant-Architektur**: Mandate > Features > Instanzen > Views/Permissions
|
||||
- **3 Auth-Provider**: Local, Microsoft MSAL, Google OAuth
|
||||
- **Echtzeit**: SSE-Streaming (Chat, Workspace, CodeEditor) + WebSockets (Voice)
|
||||
- **Backend**: FastAPI (Python) auf PostgreSQL, erreichbar unter konfigurierbarer `VITE_API_BASE_URL`
|
||||
|
||||
---
|
||||
|
||||
## Technische Entscheidungen
|
||||
|
||||
|
||||
| Aspekt | Entscheidung |
|
||||
| -------------------- | --------------------------------------------------- |
|
||||
| Plattform | iOS 18+ / iPadOS 18+ |
|
||||
| UI-Framework | SwiftUI |
|
||||
| Architektur | **MVVM + Repository Pattern** (s. unten) |
|
||||
| Networking | URLSession + async/await |
|
||||
| SSE | Custom SSE-Client auf URLSession-Basis |
|
||||
| WebSocket | URLSessionWebSocketTask |
|
||||
| Auth | MSAL SDK, Google Sign-In SDK, Keychain + Local Auth |
|
||||
| Biometrie | LocalAuthentication (Face ID / Touch ID) |
|
||||
| State | `@Observable` (Observation Framework, iOS 17+) |
|
||||
| Navigation | `NavigationStack` + `NavigationSplitView` (iPad) |
|
||||
| Dependency Injection | Environment-basiert (SwiftUI `@Environment`) |
|
||||
| Package Manager | Swift Package Manager (SPM) |
|
||||
| Karten | MapKit (SwiftUI) |
|
||||
| Charts | Swift Charts |
|
||||
| i18n | String Catalogs (`.xcstrings`) fuer de/en/fr |
|
||||
| Push | APNs + UserNotifications Framework |
|
||||
| PDF-Anzeige | PDFKit |
|
||||
| Markdown | Native AttributedString (iOS 15+) |
|
||||
| Persistenz | Keychain (Secrets), UserDefaults (Preferences) |
|
||||
| Distribution | TestFlight |
|
||||
|
||||
|
||||
### Architektur: MVVM + Repository Pattern
|
||||
|
||||
```
|
||||
Presentation Layer (SwiftUI Views)
|
||||
|
|
||||
v
|
||||
ViewModels (@Observable)
|
||||
|
|
||||
v
|
||||
Repositories (Protokolle)
|
||||
|
|
||||
v
|
||||
API Services (URLSession)
|
||||
|
|
||||
v
|
||||
Gateway Backend (FastAPI)
|
||||
```
|
||||
|
||||
Begründung: SwiftUI ist nativ MVVM-orientiert. Das Repository Pattern kapselt die Datenzugriffe und macht den Code testbar. `@Observable` (iOS 17+) ist leichter als `ObservableObject` und performanter.
|
||||
|
||||
### Projektstruktur
|
||||
|
||||
```
|
||||
NylaApp/
|
||||
NylaApp.swift // App Entry Point
|
||||
Config/
|
||||
AppConfig.swift // API URLs, Build Configs
|
||||
Environment.swift // Dev/Int/Prod Environments
|
||||
Core/
|
||||
Networking/
|
||||
APIClient.swift // Zentraler HTTP-Client (= api.ts)
|
||||
APIError.swift // Error Types
|
||||
APIEndpoints.swift // Endpoint Definitionen
|
||||
SSEClient.swift // Server-Sent Events Client
|
||||
WebSocketClient.swift // WebSocket Client
|
||||
CSRFManager.swift // CSRF Token Handling
|
||||
RequestInterceptor.swift // Auth/Mandate Headers
|
||||
Auth/
|
||||
AuthManager.swift // Zentrale Auth-Logik
|
||||
LocalAuthService.swift // Username/Password
|
||||
MSALAuthService.swift // Microsoft MSAL
|
||||
GoogleAuthService.swift // Google Sign-In
|
||||
BiometricAuthService.swift // Face ID / Touch ID
|
||||
KeychainService.swift // Secure Storage
|
||||
Navigation/
|
||||
AppRouter.swift // Root Navigation
|
||||
NavigationStore.swift // Backend-driven Nav State
|
||||
DeepLinkHandler.swift // URL Scheme Handling
|
||||
Localization/
|
||||
Localizable.xcstrings // String Catalog
|
||||
LanguageManager.swift // Sprachauswahl
|
||||
Theme/
|
||||
ThemeManager.swift // Light/Dark Mode
|
||||
DesignTokens.swift // Farben, Spacing, Fonts
|
||||
Permissions/
|
||||
PermissionChecker.swift // RBAC Client-Checks
|
||||
Domain/
|
||||
Models/ // Shared Domain Models
|
||||
Mandate.swift // Mandate, Feature, Instance
|
||||
User.swift // User Model
|
||||
Permissions.swift // AccessLevel, TablePermission
|
||||
Pagination.swift // PaginatedResponse<T>
|
||||
I18nLabel.swift // Mehrsprachige Labels
|
||||
Repositories/ // Repository Protokolle
|
||||
AuthRepository.swift
|
||||
MandateRepository.swift
|
||||
FeatureRepository.swift
|
||||
...
|
||||
Data/
|
||||
API/ // API-Implementierungen (= src/api/*.ts)
|
||||
AuthAPI.swift
|
||||
UserAPI.swift
|
||||
MandateAPI.swift
|
||||
FeaturesAPI.swift
|
||||
BillingAPI.swift
|
||||
TrusteeAPI.swift
|
||||
... (21 Module)
|
||||
Repositories/ // Repository Implementierungen
|
||||
DefaultAuthRepository.swift
|
||||
DefaultMandateRepository.swift
|
||||
...
|
||||
Features/ // Feature-Module (je Ordner)
|
||||
Dashboard/
|
||||
Store/
|
||||
Settings/
|
||||
GDPR/
|
||||
Basedata/
|
||||
Prompts/
|
||||
Files/
|
||||
Connections/
|
||||
Billing/
|
||||
Admin/
|
||||
Mandates/
|
||||
Users/
|
||||
Access/
|
||||
Invitations/
|
||||
...
|
||||
Trustee/
|
||||
Workspace/
|
||||
Chatbot/
|
||||
Teamsbot/
|
||||
CommCoach/
|
||||
CodeEditor/
|
||||
ChatPlayground/
|
||||
Automation/
|
||||
RealEstate/
|
||||
Neutralization/
|
||||
Shared/
|
||||
Components/ // Wiederverwendbare UI (= src/components/)
|
||||
FormGenerator/ // Dynamische Formulare
|
||||
ContentPreview/ // PDF, Bild, JSON Vorschau
|
||||
ChatMessage/ // Chat-Nachrichten-Rendering
|
||||
AccessRules/ // Zugriffsregeln-Editor
|
||||
NotificationBell/ // Notification Badge + Overlay
|
||||
SearchBar/
|
||||
LoadingView/
|
||||
ErrorView/
|
||||
EmptyStateView/
|
||||
Extensions/
|
||||
Utilities/
|
||||
Resources/
|
||||
Assets.xcassets
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phasen-Plan
|
||||
|
||||
### Phase 0: Projekt-Setup (1-2 Tage)
|
||||
|
||||
- Xcode-Projekt erstellen (iOS 18+, SwiftUI App Lifecycle)
|
||||
- Ordnerstruktur nach obigem Schema anlegen
|
||||
- SPM Dependencies einrichten:
|
||||
- `MSAL` (Microsoft Authentication Library for iOS)
|
||||
- `GoogleSignIn` (Google Sign-In SDK)
|
||||
- Keine weiteren externen Deps noetig (MapKit, Charts, PDFKit sind System-Frameworks)
|
||||
- Build-Konfigurationen: **Dev** / **Int** / **Prod** mit je eigenem `API_BASE_URL`
|
||||
- Analog zu den `.env.dev` / `.env.int` / `.env.prod` Dateien im Web-Frontend
|
||||
- Werte: `http://localhost:8000` (Dev), INT-URL, PROD-URL
|
||||
- TestFlight-Vorbereitung: App ID, Provisioning Profile, Signing
|
||||
|
||||
### Phase 1: Core Networking Layer (3-5 Tage)
|
||||
|
||||
**Ziel**: Equivalent zu `[src/api.ts](frontend_nyla/src/api.ts)` + `[src/hooks/useApi.ts](frontend_nyla/src/hooks/useApi.ts)`
|
||||
|
||||
**APIClient.swift** -- Zentraler HTTP-Client:
|
||||
|
||||
- `URLSession.shared` mit Custom-Configuration
|
||||
- Cookie-basierte Auth (`httpCookieStorage`)
|
||||
- Request-Interceptor fuer:
|
||||
- `Authorization: Bearer` Header (aus Keychain)
|
||||
- `X-Mandate-Id` / `X-Instance-Id` Header (aus aktuellem Navigation-Context)
|
||||
- CSRF-Token fuer POST/PUT/PATCH/DELETE
|
||||
- Response-Handler:
|
||||
- 401 -> Redirect zu Login (analog Web `api.ts` Zeile 127-151)
|
||||
- 429 -> Rate-Limit Warning
|
||||
- Generische Fehlerextraktion (FastAPI `detail` Array/String)
|
||||
- Generische Request-Methoden: `get<T>()`, `post<T>()`, `put<T>()`, `delete<T>()`, `upload()`
|
||||
- `Codable`-basierte JSON Serialisierung
|
||||
|
||||
**SSEClient.swift** -- Server-Sent Events:
|
||||
|
||||
- Analog zu `[src/utils/sseClient.ts](frontend_nyla/src/utils/sseClient.ts)`
|
||||
- URLSession mit `bytes(for:)` async stream
|
||||
- Parsing von `data:` Lines
|
||||
- Callbacks: `onMessage`, `onError`, `onComplete`
|
||||
- Wird benoetigt fuer: Workspace, Chatbot, CodeEditor, CommCoach Streaming
|
||||
|
||||
**WebSocketClient.swift** -- WebSockets:
|
||||
|
||||
- `URLSessionWebSocketTask`
|
||||
- Fuer Voice-Features (Teamsbot: `/api/teamsbot/{instanceId}/bot/ws/{sessionId}`)
|
||||
- Ping/Pong, Reconnect-Logik
|
||||
|
||||
**CSRFManager.swift**:
|
||||
|
||||
- Token-Generierung und -Speicherung
|
||||
- Analog zu `[src/utils/csrfUtils.ts](frontend_nyla/src/utils/csrfUtils.ts)`
|
||||
|
||||
### Phase 2: Authentication (3-5 Tage)
|
||||
|
||||
**Ziel**: Alle 3 Auth-Provider + Biometrie
|
||||
|
||||
**Mapping Web -> Swift:**
|
||||
|
||||
|
||||
| Web (authApi.ts) | Swift |
|
||||
| ---------------------------------------- | -------------------------------------------- |
|
||||
| `POST /api/local/login` (form-data) | `LocalAuthService.login(username:password:)` |
|
||||
| `POST /api/local/register` | `LocalAuthService.register(...)` |
|
||||
| `POST /api/local/password-reset-request` | `LocalAuthService.requestPasswordReset(...)` |
|
||||
| `POST /api/local/password-reset` | `LocalAuthService.resetPassword(...)` |
|
||||
| `GET /api/local/available?username=` | `LocalAuthService.checkAvailability(...)` |
|
||||
| `GET /api/local/me` | `AuthManager.fetchCurrentUser()` |
|
||||
| `POST /api/local/logout` | `AuthManager.logout()` |
|
||||
| MSAL Login/Callback | `MSALAuthService` via MSAL SDK |
|
||||
| `GET /api/msft/me` | `MSALAuthService.fetchUser()` |
|
||||
| Google Login/Callback | `GoogleAuthService` via Google Sign-In SDK |
|
||||
| `GET /api/google/me` | `GoogleAuthService.fetchUser()` |
|
||||
|
||||
|
||||
**AuthManager.swift** (zentral):
|
||||
|
||||
- Verwaltet aktiven Auth-Provider (`local` / `msft` / `google`)
|
||||
- Speichert Auth-State in Keychain (nicht UserDefaults!)
|
||||
- Published `isAuthenticated`, `currentUser`, `authAuthority`
|
||||
- Analog zu `[src/providers/auth/AuthProvider.tsx](frontend_nyla/src/providers/auth/AuthProvider.tsx)`
|
||||
|
||||
**BiometricAuthService.swift**:
|
||||
|
||||
- `LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics)`
|
||||
- Nach erstem erfolgreichen Login: Credentials in Keychain speichern
|
||||
- Bei App-Start: Face ID/Touch ID -> Keychain Credentials -> Auto-Login
|
||||
|
||||
**Login Screen (SwiftUI)**:
|
||||
|
||||
- Username/Password Felder
|
||||
- "Anmelden mit Microsoft" Button (MSAL)
|
||||
- "Anmelden mit Google" Button (Google Sign-In)
|
||||
- "Face ID / Touch ID" Option (wenn verfuegbar)
|
||||
- Registrierung / Passwort vergessen Links
|
||||
- Analog zu `[src/pages/Login.tsx](frontend_nyla/src/pages/Login.tsx)`
|
||||
|
||||
### Phase 3: Domain Models + Feature Store (2-3 Tage)
|
||||
|
||||
**Ziel**: Alle geteilten Datenmodelle + Feature-State
|
||||
|
||||
Zentrale Models (analog zu `[src/types/mandate.ts](frontend_nyla/src/types/mandate.ts)`):
|
||||
|
||||
```swift
|
||||
// Mandate.swift
|
||||
struct I18nLabel: Codable { var de: String; var en: String; var fr: String? }
|
||||
enum AccessLevel: String, Codable { case none = "n", my = "m", group = "g", all = "a" }
|
||||
struct TablePermission: Codable { var view: Bool; var read, create, update, delete: AccessLevel }
|
||||
struct FieldPermission: Codable { var read: Bool; var write: Bool }
|
||||
struct InstancePermissions: Codable { var tables: [String: TablePermission]; var fields: [String: [String: FieldPermission]]?; var views: [String: Bool]; var isAdmin: Bool? }
|
||||
struct FeatureInstance: Codable, Identifiable { var id: String; var featureCode, mandateId, mandateName, instanceLabel: String; var userRoles: [String]; var permissions: InstancePermissions }
|
||||
struct MandateFeature: Codable { var code: String; var label: I18nLabel; var icon: String; var instances: [FeatureInstance] }
|
||||
struct Mandate: Codable, Identifiable { var id, name: String; var label, code: String?; var features: [MandateFeature] }
|
||||
struct FeaturesMyResponse: Codable { var mandates: [Mandate] }
|
||||
```
|
||||
|
||||
**FeatureStore.swift** (analog zu `[src/stores/featureStore.tsx](frontend_nyla/src/stores/featureStore.tsx)`):
|
||||
|
||||
- `@Observable class FeatureStore`
|
||||
- `loadFeatures()` -> `GET /api/features/my`
|
||||
- Cache: `[String: FeatureInstance]` fuer schnellen Zugriff
|
||||
- Methoden: `getMandateById()`, `getInstanceById()`, `getAllInstances()`, etc.
|
||||
- Injected via SwiftUI `@Environment`
|
||||
|
||||
### Phase 4: App Shell + Navigation (4-6 Tage)
|
||||
|
||||
**Ziel**: MainLayout + FeatureLayout + backend-driven Navigation
|
||||
|
||||
**Adaptive Layout:**
|
||||
|
||||
- **iPad**: `NavigationSplitView` (Sidebar + Detail) -- analog Web-Sidebar
|
||||
- **iPhone**: `TabView` mit Hauptbereichen + Navigation Stack pro Tab
|
||||
|
||||
**Sidebar / Navigation:**
|
||||
|
||||
- Backend-driven: `GET /api/navigation?language={lang}` liefert Navigationsbaum
|
||||
- Analog zu `[src/components/Navigation/MandateNavigation.tsx](frontend_nyla/src/components/Navigation/MandateNavigation.tsx)`
|
||||
- Hierarchie: Mandate > Feature > Instance > Views
|
||||
- Icon-Mapping: SF Symbols statt React Icons (Mapping-Tabelle erstellen)
|
||||
|
||||
**Screen-Routing:**
|
||||
|
||||
- `NavigationStack` mit `NavigationPath` fuer programmatische Navigation
|
||||
- Deep-Link-Schema: `nyla://mandates/{mandateId}/{featureCode}/{instanceId}/{view}`
|
||||
- Feature-View-Dispatcher: analog zu `[src/pages/FeatureView.tsx](frontend_nyla/src/pages/FeatureView.tsx)` `VIEW_COMPONENTS`
|
||||
|
||||
**Screens in Phase 4:**
|
||||
|
||||
- Dashboard (`/`) -- Mandate/Instance-Karten, analog `[src/pages/Dashboard.tsx](frontend_nyla/src/pages/Dashboard.tsx)`
|
||||
- Settings (`/settings`) -- Theme-Toggle, Sprache (de/en/fr), Profil
|
||||
- UserSection im Sidebar-Footer
|
||||
|
||||
### Phase 5: i18n + Theme (2-3 Tage)
|
||||
|
||||
**Internationalisierung:**
|
||||
|
||||
- Xcode String Catalog (`.xcstrings`) fuer de/en/fr
|
||||
- Alle statischen Strings aus den Web-Locales uebernehmen: `[src/locales/de.ts](frontend_nyla/src/locales/de.ts)`, `en.ts`, `fr.ts`
|
||||
- Dynamische Labels (I18nLabel vom Backend): Helper `label.localized(lang:)` analog `getLabel()` im Web
|
||||
- `LanguageManager` speichert Praeferenz in UserDefaults
|
||||
|
||||
**Theme:**
|
||||
|
||||
- SwiftUI `.preferredColorScheme()` fuer System-Integration
|
||||
- Custom `DesignTokens` fuer konsistente Farben/Spacing
|
||||
- Analog zu `[src/styles/themes/light.css](frontend_nyla/src/styles/themes/light.css)` + `.dark-theme`
|
||||
|
||||
### Phase 6: Core Pages (5-7 Tage)
|
||||
|
||||
**Store** (Feature Marketplace):
|
||||
|
||||
- `GET /api/store/features` -> Feature-Liste
|
||||
- `POST /api/store/activate` / `POST /api/store/deactivate`
|
||||
- Analog `[src/pages/Store.tsx](frontend_nyla/src/pages/Store.tsx)`
|
||||
|
||||
**GDPR**:
|
||||
|
||||
- `GET /api/user/me/data-export` + `/data-portability`
|
||||
- `DELETE /api/user/me/`
|
||||
- Analog `[src/pages/GDPR.tsx](frontend_nyla/src/pages/GDPR.tsx)`
|
||||
|
||||
**Basedata - Prompts** (`/basedata/prompts`):
|
||||
|
||||
- CRUD auf `/api/prompts` mit FormGenerator
|
||||
- Analog `[src/pages/PromptsPage.tsx](frontend_nyla/src/pages/PromptsPage.tsx)`
|
||||
|
||||
**Basedata - Files** (`/basedata/files`):
|
||||
|
||||
- `GET /api/files/list`, Upload, Download, Preview
|
||||
- Analog `[src/pages/FilesPage.tsx](frontend_nyla/src/pages/FilesPage.tsx)`
|
||||
- Nutzung von `UIDocumentPickerViewController` (via UIKit-Bridge) fuer File-Upload
|
||||
- `QuickLook` fuer Dateivorschau
|
||||
|
||||
**Basedata - Connections** (`/basedata/connections`):
|
||||
|
||||
- CRUD auf `/api/connections/`
|
||||
- Connect/Disconnect Aktionen
|
||||
- Analog `[src/pages/ConnectionsPage.tsx](frontend_nyla/src/pages/ConnectionsPage.tsx)`
|
||||
|
||||
**Billing** (`/billing/transactions`):
|
||||
|
||||
- `GET /api/billing/balance`, `/transactions`, `/statistics/{period}`
|
||||
- Swift Charts fuer Statistik-Visualisierung
|
||||
- Analog `[src/pages/billing/BillingDataView.tsx](frontend_nyla/src/pages/billing/BillingDataView.tsx)`
|
||||
|
||||
### Phase 7: Shared UI Components (5-8 Tage)
|
||||
|
||||
**FormGenerator** (zentral, wird von fast allen Features genutzt):
|
||||
|
||||
- Analog zu `[src/components/FormGenerator/](frontend_nyla/src/components/FormGenerator/)`
|
||||
- Dynamische Formulare basierend auf `AttributeDefinition[]` vom Backend (`GET /api/attributes/{entityType}`)
|
||||
- Feldtypen: String, Email, Select, Multiselect, Textarea, Checkbox, File, Number, DateTime, Multilingual
|
||||
- Tabellen-Ansicht (`FormGeneratorTable`) + Listen-Ansicht (`FormGeneratorList`)
|
||||
- Action Buttons (Edit, Delete, Download, Custom)
|
||||
- Pagination-Support
|
||||
|
||||
**ContentPreview**:
|
||||
|
||||
- PDF: `PDFKitView` (UIKit PDFView in UIViewRepresentable)
|
||||
- Bilder: AsyncImage
|
||||
- JSON: Syntax-Highlighting
|
||||
- HTML: WKWebView
|
||||
- Analog `[src/components/ContentPreview/](frontend_nyla/src/components/ContentPreview/)`
|
||||
|
||||
**NotificationBell**:
|
||||
|
||||
- `GET /api/notifications/unread-count` (Polling)
|
||||
- Push Notifications via APNs
|
||||
- In-App Notification Sheet
|
||||
- Analog `[src/components/NotificationBell/](frontend_nyla/src/components/NotificationBell/)`
|
||||
|
||||
**Chat Message Components**:
|
||||
|
||||
- Message-Bubbles mit Markdown-Rendering
|
||||
- File-Attachments
|
||||
- Streaming-Indicator (typing animation)
|
||||
- Auto-Scroll
|
||||
- Analog `[src/components/UiComponents/Messages/](frontend_nyla/src/components/UiComponents/Messages/)`
|
||||
|
||||
**AccessRules Components**:
|
||||
|
||||
- Tabelle + Editor fuer RBAC-Regeln
|
||||
- Analog `[src/components/AccessRules/](frontend_nyla/src/components/AccessRules/)`
|
||||
|
||||
### Phase 8: Push Notifications (2-3 Tage)
|
||||
|
||||
- APNs-Registrierung in `AppDelegate`
|
||||
- Device Token an Backend senden (neuer Endpoint oder bestehender `/api/messaging/subscriptions`)
|
||||
- `UNUserNotificationCenter` fuer lokale + remote Notifications
|
||||
- Deep-Link Handling aus Notification-Tap
|
||||
|
||||
### Phase 9: Admin Module (5-7 Tage)
|
||||
|
||||
Alle Admin-Seiten analog zu `[src/pages/admin/](frontend_nyla/src/pages/admin/)`:
|
||||
|
||||
|
||||
| Admin-Seite | API-Endpunkte |
|
||||
| -------------------- | ------------------------------------------ |
|
||||
| Mandates | CRUD `/api/mandates/` |
|
||||
| Users | CRUD `/api/users/` |
|
||||
| User-Mandates | `/api/mandates/{id}/users` |
|
||||
| Access Hub | `/api/rbac/permissions`, `/api/rbac/rules` |
|
||||
| Feature Instances | `/api/features/instances` |
|
||||
| Feature Roles | `/api/features/templates/roles` |
|
||||
| Feature Users | `/api/features/instances/{id}/users` |
|
||||
| Invitations | CRUD `/api/invitations/` |
|
||||
| Mandate Roles | `/api/rbac/roles` |
|
||||
| Role Permissions | `/api/rbac/rules/by-role/{roleId}` |
|
||||
| User Access Overview | `/api/admin/user-access-overview/`* |
|
||||
| Billing Admin | `/api/billing/admin/`* |
|
||||
| Automation Events | `/api/admin/automation-events` |
|
||||
| Logs | `/api/admin/logs` |
|
||||
| Mandate Wizard | Kombination mehrerer Endpoints |
|
||||
| Invitation Wizard | Kombination mehrerer Endpoints |
|
||||
|
||||
|
||||
### Phase 10-20: Feature-Module (je 3-7 Tage pro Feature)
|
||||
|
||||
Jedes Feature folgt demselben Pattern:
|
||||
|
||||
1. **API-Modul** erstellen (alle Endpunkte des Features)
|
||||
2. **ViewModels** fuer jede View
|
||||
3. **SwiftUI Views** fuer jede registrierte View
|
||||
4. **Feature-spezifische Komponenten** wo noetig
|
||||
|
||||
---
|
||||
|
||||
#### Phase 10: Trustee (5-7 Tage)
|
||||
|
||||
Views: Dashboard, Documents, Positions, Instance-Roles, Expense-Import, Scan-Upload, Accounting Settings
|
||||
|
||||
API-Basis: `/api/trustee/{instanceId}/`
|
||||
|
||||
- Organisations, Roles, Access, Contracts, Documents, Positions CRUD
|
||||
- Accounting: Connectors, Config, Sync
|
||||
- Document Upload mit base64-Konvertierung
|
||||
- Options-Endpoints fuer Dropdowns
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- Viele verschachtelte CRUD-Entitaeten (Organisation > Contract > Document > Position)
|
||||
- Scan-Upload: iOS-Kamera-Integration + VisionKit (OCR)
|
||||
|
||||
#### Phase 11: Workspace (5-7 Tage)
|
||||
|
||||
Views: Dashboard (Chat-Stream), Settings
|
||||
|
||||
API-Basis: `/api/workspace/{instanceId}/`
|
||||
|
||||
- SSE-Streaming fuer Chat (`POST .../start/stream`)
|
||||
- Workflows, Messages, Files, Datasources CRUD
|
||||
- Voice: Transcribe, Synthesize, Settings
|
||||
- File Browser mit Ordnerstruktur
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- **Zentrales SSE-Streaming** -- das Keep-Alive-Pattern aus dem Web (`WorkspaceKeepAlive`) muss in Swift via Task/Actor geloest werden
|
||||
- Voice: AVFoundation fuer Audio-Aufnahme, URLSession fuer Upload
|
||||
|
||||
#### Phase 12: Chatbot (3-5 Tage)
|
||||
|
||||
Views: Conversations, Settings
|
||||
|
||||
API-Basis: `/api/chatbot/{instanceId}/`
|
||||
|
||||
- `POST .../start/stream` -- SSE-Streaming via fetch (nicht Axios!)
|
||||
- Threads: List, Get, Delete
|
||||
- Stop Workflow
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- Streaming-Chat mit File-Attachments
|
||||
- Analog zu `chatbotApi.startChatbotStreamApi` -- Custom SSE via POST
|
||||
|
||||
#### Phase 13: Teamsbot (4-6 Tage)
|
||||
|
||||
Views: Dashboard, Sessions, Settings
|
||||
|
||||
API-Basis: `/api/teamsbot/{instanceId}/`
|
||||
|
||||
- Sessions CRUD + Stream (EventSource/SSE)
|
||||
- Config, System Bots, User Account
|
||||
- Voice Test
|
||||
- MFA fuer Sessions
|
||||
- WebSocket fuer Bot-Kommunikation (`/bot/ws/{sessionId}`)
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- **WebSocket** fuer Live-Bot-Interaction
|
||||
- SSE via EventSource fuer Session-Stream
|
||||
- Screenshot-Anzeige
|
||||
|
||||
#### Phase 14: CommCoach (4-6 Tage)
|
||||
|
||||
Views: Dashboard, Coaching, Dossier, Settings
|
||||
|
||||
API-Basis: `/api/commcoach/{instanceId}/`
|
||||
|
||||
- Contexts CRUD + Archive/Activate
|
||||
- Sessions: Start, Message-Stream, Audio-Stream, Complete, Cancel
|
||||
- Tasks CRUD + Status
|
||||
- Personas CRUD, Documents, Badges, Score History
|
||||
- Voice: Languages, Voices, TTS
|
||||
- Export (Dossier, Session)
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- **Audio-Streaming**: Mikrofon-Aufnahme -> POST Audio-Stream
|
||||
- SSE fuer Session-Nachrichten
|
||||
- Score/Badge-Visualisierung
|
||||
|
||||
#### Phase 15: ChatPlayground (3-5 Tage)
|
||||
|
||||
Views: Playground, Workflows
|
||||
|
||||
API-Basis: `/api/chatplayground/{instanceId}/`
|
||||
|
||||
- Start/Stop Workflow (mit SSE-Stream)
|
||||
- Workflows CRUD + Status/Logs/Messages
|
||||
- Attributes, Actions
|
||||
|
||||
#### Phase 16: Automation (3-5 Tage)
|
||||
|
||||
Views: Definitions, Templates, Logs
|
||||
|
||||
API-Basis: `/api/automations/`
|
||||
|
||||
- Automations CRUD + Execute + Duplicate
|
||||
- Templates CRUD
|
||||
- Workflow-Management (gleiche API wie ChatPlayground, anderer Base-Path)
|
||||
|
||||
#### Phase 17: CodeEditor (3-5 Tage)
|
||||
|
||||
Views: Editor, Workflows
|
||||
|
||||
API-Basis: `/api/codeeditor/{instanceId}/`
|
||||
|
||||
- Start/Stop/Apply (mit SSE-Stream)
|
||||
- ChatData, Workflows, Files, File Content
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- Code-Darstellung: Syntax-Highlighting (z.B. via `Highlightr` SPM Package oder custom)
|
||||
- Diff-Ansicht fuer Code-Apply
|
||||
|
||||
#### Phase 18: RealEstate / PEK (5-7 Tage)
|
||||
|
||||
Views: Dashboard (Map), Instance-Roles
|
||||
|
||||
API-Basis: `/api/realestate/{instanceId}/`
|
||||
|
||||
- Projects + Parcels CRUD
|
||||
- Parcel Search, WFS, Selection Summary, Adjacent Parcels
|
||||
- Address Autocomplete
|
||||
- BZO Information, Parcel Documents
|
||||
- Gemeinden
|
||||
|
||||
Besonderheiten:
|
||||
|
||||
- **MapKit** Integration: Parcel-Visualisierung auf Karte
|
||||
- Address-Autocomplete: MKLocalSearchCompleter oder Backend-API
|
||||
- Komplexe Karteninteraktion (Parcel-Selektion, Adjacent Parcels)
|
||||
|
||||
#### Phase 19: Neutralization (2-3 Tage)
|
||||
|
||||
Views: Dashboard/Playground (gleiche View)
|
||||
|
||||
API-Basis: `/api/neutralization/`
|
||||
|
||||
- Config GET/POST
|
||||
- Neutralize File/Text, Resolve Text
|
||||
- Process SharePoint, Batch Process
|
||||
- Stats, Attributes
|
||||
|
||||
#### Phase 20: Billing View-Erweiterung (1-2 Tage)
|
||||
|
||||
Admin-Billing-Views falls in Phase 9 nicht vollstaendig abgedeckt:
|
||||
|
||||
- Checkout (Stripe -- SFSafariViewController fuer Redirect)
|
||||
- Mandate/User Balances und Transaktionen
|
||||
|
||||
---
|
||||
|
||||
## API-Header-Konvention (fuer alle Requests)
|
||||
|
||||
Jeder API-Request muss folgende Header senden (analog `[src/api.ts](frontend_nyla/src/api.ts)`):
|
||||
|
||||
|
||||
| Header | Quelle | Wann |
|
||||
| -------------------------------- | ------------------ | --------------------- |
|
||||
| `Authorization: Bearer {token}` | Keychain | Wenn JWT vorhanden |
|
||||
| `X-Mandate-Id: {mandateId}` | Navigation Context | Bei Feature-Seiten |
|
||||
| `X-Instance-Id: {instanceId}` | Navigation Context | Bei Feature-Seiten |
|
||||
| `X-CSRF-Token: {token}` | CSRFManager | POST/PUT/PATCH/DELETE |
|
||||
| `Content-Type: application/json` | Standard | JSON Bodies |
|
||||
| Cookie (httpOnly) | URLSession | Automatisch |
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Gesamtaufwand-Schaetzung
|
||||
|
||||
|
||||
| Phase | Tage (geschaetzt) |
|
||||
| ------------------------------- | ----------------- |
|
||||
| Phase 0: Setup | 1-2 |
|
||||
| Phase 1: Networking | 3-5 |
|
||||
| Phase 2: Authentication | 3-5 |
|
||||
| Phase 3: Domain Models + Store | 2-3 |
|
||||
| Phase 4: App Shell + Navigation | 4-6 |
|
||||
| Phase 5: i18n + Theme | 2-3 |
|
||||
| Phase 6: Core Pages | 5-7 |
|
||||
| Phase 7: Shared UI Components | 5-8 |
|
||||
| Phase 8: Push Notifications | 2-3 |
|
||||
| Phase 9: Admin | 5-7 |
|
||||
| Phase 10: Trustee | 5-7 |
|
||||
| Phase 11: Workspace | 5-7 |
|
||||
| Phase 12: Chatbot | 3-5 |
|
||||
| Phase 13: Teamsbot | 4-6 |
|
||||
| Phase 14: CommCoach | 4-6 |
|
||||
| Phase 15: ChatPlayground | 3-5 |
|
||||
| Phase 16: Automation | 3-5 |
|
||||
| Phase 17: CodeEditor | 3-5 |
|
||||
| Phase 18: RealEstate | 5-7 |
|
||||
| Phase 19: Neutralization | 2-3 |
|
||||
| Phase 20: Billing Erweit. | 1-2 |
|
||||
| **Gesamt** | **~70-105 Tage** |
|
||||
|
||||
|
||||
Hinweis: Dies ist eine Einzelperson-Schaetzung. Mit Team (z.B. 2-3 Devs) kann parallelisiert werden, besonders ab Phase 10+ (Features sind unabhaengig voneinander).
|
||||
|
||||
---
|
||||
|
||||
## Offene Punkte / Risiken
|
||||
|
||||
1. **Backend-Anpassungen**: Das Backend setzt teilweise httpOnly Cookies nach Browser-Redirect (MSAL, Google). Fuer eine native App muss das Backend ggf. alternative Token-Flows unterstuetzen (z.B. Device Code Flow oder Token-Exchange).
|
||||
2. **Push Notifications**: Das Backend hat aktuell kein APNs-Token-Management. Ein neuer Endpoint `/api/notifications/register-device` muss im Gateway implementiert werden.
|
||||
3. **SSE ueber POST**: Die Web-App nutzt `fetch` POST + ReadableStream fuer SSE (nicht standard EventSource GET). In Swift muss dies mit `URLSession.bytes(for:)` nachgebaut werden.
|
||||
4. **Stripe Checkout**: Im Web oeffnet sich ein Stripe-Redirect. In iOS: SFSafariViewController oder Stripe iOS SDK.
|
||||
5. **SharePoint Integration**: Einige Features nutzen SharePoint-Folder-Picker. In iOS muss eine alternative UI gebaut werden (Liste statt Filepicker).
|
||||
6. **WebSocket Auth**: Der Web-Client nutzt Cookies fuer WebSocket-Auth. iOS `URLSessionWebSocketTask` unterstuetzt Cookies via URLSession Configuration.
|
||||
|
||||
309
docs/althaus-bot-v2-aufwandsschaetzung.md
Normal file
309
docs/althaus-bot-v2-aufwandsschaetzung.md
Normal file
|
|
@ -0,0 +1,309 @@
|
|||
# Aufwandsschätzung Althaus Bot v2 -- Unabhängige Analyse
|
||||
|
||||
**Projekt:** Althaus Bot v2 -- Weiterentwicklung & neue Use Cases
|
||||
**Kunde:** W. Althaus AG, Aarwangen
|
||||
**Erstellt:** 13. April 2026
|
||||
**Basis:** Code-Analyse Gateway-Repository + Offerte v2 vom 14.04.2026
|
||||
**Methodik:** Bottom-Up-Schätzung auf Basis der bestehenden Implementierung, Dreipunktschätzung (Min / Mitte / Max)
|
||||
|
||||
---
|
||||
|
||||
## 1. Ist-Zustand der Implementierung
|
||||
|
||||
### 1.1 Architekturübersicht
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ React Frontend (SSE-Streaming, Chat-UI) │
|
||||
└──────────────────────────┬──────────────────────────────────────┘
|
||||
│ /api/chatbot/*
|
||||
┌──────────────────────────▼──────────────────────────────────────┐
|
||||
│ Gateway (Python/FastAPI) │
|
||||
│ ┌─────────────────────────────────────────────────────────┐ │
|
||||
│ │ Chatbot Feature (modules/features/chatbot/) │ │
|
||||
│ │ ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │
|
||||
│ │ │ Planner │→ │ SQL Plan │→ │ Parse & │→ │Formul. │ │ │
|
||||
│ │ │ Node │ │ Node │ │ Execute │ │ Node │ │ │
|
||||
│ │ └────┬────┘ └──────────┘ └────┬─────┘ └────────┘ │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ ├→ Tavily (Web Search) │ │ │
|
||||
│ │ └→ Direct Answer │ │ │
|
||||
│ └──────────────────────────────────┼──────────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌──────────────────────────────────▼──────────────────────┐ │
|
||||
│ │ PreprocessorConnector (HTTP POST → Azure SQL API) │ │
|
||||
│ └─────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────────────┐ │
|
||||
│ │ KnowledgeService (pgvector/RAG) -- NICHT IM CHATBOT │ │
|
||||
│ │ Produktiv im AgentService + CommCoach │ │
|
||||
│ └─────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
┌──────────────────────────▼──────────────────────────────────────┐
|
||||
│ Azure Preprocessing Server (deployed, ERP-Daten deaktiviert) │
|
||||
│ Tabellen: Artikel, Einkaufspreis, Lagerplatz, Lagerplatz_Art. │
|
||||
│ Repo: github.com/valueonag/gateway_preprocessing │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 1.2 Vorhandene Komponenten (Wiederverwendung)
|
||||
|
||||
| Komponente | Datei / Modul | Status | Wiederverwendbar für |
|
||||
|---|---|---|---|
|
||||
| LangGraph-Workflow | `chatbot/chatbot.py` | Produktiv (deaktiviert) | Alle Positionen -- Grundgerüst |
|
||||
| PreprocessorConnector | `connectors/connectorPreprocessor.py` | Produktiv (deaktiviert) | Pos. 1, 2, 3, 4 -- SQL-Abfragen |
|
||||
| ChatbotConfig | `chatbot/config.py` | Produktiv | Alle -- Konfiguration pro Instanz |
|
||||
| Streaming-Bridge | `chatbot/service.py` | Produktiv | Alle -- SSE ans Frontend |
|
||||
| ChatbotDocument | `chatbot/interfaceFeatureChatbot.py` | Implementiert | Pos. 1.4, 2.1, 2.5 -- File-Handling |
|
||||
| KnowledgeService/RAG | `serviceCenter/services/serviceKnowledge/` | Produktiv (AgentService) | Pos. 5 -- Wiki-Integration |
|
||||
| Automation-Template | `automation/subAutomationTemplates.py` | Produktiv | Pos. 6 -- Preprocessor-Updates |
|
||||
| SQL-Sanitize | `chatbot.py` → `_sanitize_sql_typos` | Produktiv | Pos. 1.1 -- Gesperrte Artikel |
|
||||
| Markdown-Tabellen | `chatbot.py` → `_tool_output_to_markdown_table` | Produktiv | Pos. 1.3, 3.3 -- Darstellung |
|
||||
| File-Upload Backend | `service.py` → `_convert_file_ids_to_document_references` | Implementiert | Pos. 1.4 -- Upload-Pipeline |
|
||||
| Excel-Export | `service.py` → `_create_chat_document_from_action_document` | Implementiert | Pos. 2.5 -- Kalktool-Export |
|
||||
|
||||
### 1.3 Fehlende Komponenten (Neuentwicklung)
|
||||
|
||||
| Komponente | Benötigt für | Komplexität |
|
||||
|---|---|---|
|
||||
| Matching-Engine (exakt → fuzzy → KI) | Pos. 2.2 | Hoch |
|
||||
| Neuer Planner-Pfad "WIKI" | Pos. 5.2 | Mittel |
|
||||
| KnowledgeService → Chatbot Integration | Pos. 5.2 | Mittel |
|
||||
| Wiki-Connector (API/Crawling) | Pos. 5.1 | Unbekannt (Wiki-abhängig) |
|
||||
| Delta-Sync-Mechanismus | Pos. 5.3 | Mittel |
|
||||
| Preprocessor: 8-10 neue Tabellen/Views | Pos. 1.5, 3.1, 4.1 | Mittel (Code-Änderung) |
|
||||
| Frontend: File-Picker, Drag&Drop | Pos. 1.4 | Mittel |
|
||||
| Frontend: Thread-Liste, Suchfunktion | Pos. 1.2 | Mittel |
|
||||
| Kalktool-Excel-Format-Export | Pos. 2.5 | Mittel |
|
||||
| Schwellenwert-Insights | Pos. 4.5 | Mittel |
|
||||
|
||||
---
|
||||
|
||||
## 2. Detaillierte Aufwandsschätzung
|
||||
|
||||
### Position 1: Basics (Plattform-Verbesserungen)
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 1.1 | Gesperrte Artikel filtern | 4 | 3 | 4 | 4 | System-Prompt + SQL-Sanitize-Regel. Kleine Änderung. |
|
||||
| 1.2 | Chat-Verlauf speichern | 12 | 12 | 14 | 16 | Backend existiert. Frontend-Aufwand (Thread-Liste, Suche). |
|
||||
| 1.3 | Längere Antworten | 6 | 4 | 5 | 6 | Streaming-Config + Frontend-Rendering. |
|
||||
| 1.4 | Datei-Upload | 16 | 16 | 18 | 20 | Full-Stack: Drag&Drop + LangGraph-Integration + Extraktion. |
|
||||
| 1.5 | Kundenartikelnummern | 8 | 10 | 12 | 14 | Preprocessor-Code + Prompt + Cross-Ref-Queries. ERP-abhängig. |
|
||||
| 1.6 | Abklärungen & Testing | 8 | 8 | 8 | 8 | Standard. |
|
||||
| | **Subtotal** | **54** | **53** | **61** | **68** | |
|
||||
|
||||
**Delta zur Offerte: +7h (Mitte) / +14h (Max)**
|
||||
**Haupttreiber:** Preprocessor-Erweiterung für Kundenartikelnummern (Pos. 1.5) erfordert Code-Änderung, nicht nur Config. Frontend-Aufwand bei Upload (Pos. 1.4) eher am oberen Ende.
|
||||
|
||||
---
|
||||
|
||||
### Position 2: Use Case Kalktool
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 2.1 | Stücklisten-Upload & Extraktion | 12 | 10 | 12 | 14 | Nutzt Pos. 1.4. serviceExtraction vorhanden. |
|
||||
| 2.2 | Artikelidentifikation & Matching | 20 | 24 | 28 | 32 | **KRITISCH**: Neue Matching-Engine, 3 Stufen, ERP-abhängig. |
|
||||
| 2.3 | Automatische Feldergänzung | 16 | 14 | 16 | 18 | Preprocessor + Enrichment-Logik. |
|
||||
| 2.4 | Alternativartikel-Vorschläge | 12 | 12 | 14 | 16 | KI-Vorschläge + Bestätigungs-Workflow im Chat. |
|
||||
| 2.5 | Excel-Export (Kalktool-Format) | 12 | 10 | 12 | 14 | Basis existiert. Kalktool-Vorlage-Anpassung. |
|
||||
| 2.6 | Erweiterbarkeit neue Felder | 8 | 6 | 8 | 10 | Config-gesteuertes Feld-Mapping. |
|
||||
| 2.7 | Abklärungen & Testing | 12 | 12 | 12 | 12 | Kalktool-Vorlage, Testdaten, UAT. |
|
||||
| | **Subtotal** | **92** | **88** | **102** | **116** | |
|
||||
|
||||
**Delta zur Offerte: +10h (Mitte) / +24h (Max)**
|
||||
**Haupttreiber:** Die Matching-Engine (Pos. 2.2) ist die komplexeste Neuentwicklung im gesamten Projekt. Mehrstufiges Matching (exakt → fuzzy → KI-gestützt) ohne bestehende Basis. Die Qualität hängt stark von der ERP-Datenqualität und der Vielfalt der Kunden-Stücklisten-Formate ab.
|
||||
|
||||
---
|
||||
|
||||
### Position 3: Use Case Materialmanagement 1
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 3.1 | ERP-Daten erweitern | 16 | 16 | 19 | 22 | Preprocessor: Bestellungen, Wareneingänge, Aufträge. Code nötig. |
|
||||
| 3.2 | System-Prompt Materialmanagement | 8 | 6 | 8 | 10 | Prompt-Engineering + SQL-Templates. |
|
||||
| 3.3 | Transparente Statusübersicht | 8 | 6 | 7 | 8 | Markdown-Rendering existiert, Erweiterung nötig. |
|
||||
| 3.4 | Auswirkungsanalyse & Empfehlungen | 12 | 14 | 16 | 18 | Cross-Table-Queries + KI-Analyse. Komplex. |
|
||||
| 3.5 | Abklärungen & Testing | 8 | 8 | 8 | 8 | Standard. |
|
||||
| | **Subtotal** | **52** | **50** | **58** | **66** | |
|
||||
|
||||
**Delta zur Offerte: +6h (Mitte) / +14h (Max)**
|
||||
**Haupttreiber:** Auswirkungsanalyse (Pos. 3.4) erfordert Multi-Table-Joins und KI-gestützte Bewertung, was über einfache SQL-Abfragen hinausgeht.
|
||||
|
||||
---
|
||||
|
||||
### Position 4: Use Case Materialmanagement 2 (KPIs)
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 4.1 | ERP-Daten erweitern | 16 | 16 | 19 | 22 | Lagerjournal, Preishistorie. Aggregierte Views. |
|
||||
| 4.2 | System-Prompt KPI-Analyse | 8 | 6 | 8 | 10 | Prompt-Engineering. |
|
||||
| 4.3 | Liefertermintreue-Analyse | 10 | 10 | 12 | 14 | Zeitreihen, Lieferantenvergleich, komplexe SQL. |
|
||||
| 4.4 | Preisentwicklungs-Analyse | 10 | 10 | 11 | 12 | Preishistorie, Abweichungsberechnung. |
|
||||
| 4.5 | Automatisierte Insights | 8 | 10 | 12 | 14 | Schwellenwert-Warnungen, proaktive Erkennung. Neues Konzept. |
|
||||
| 4.6 | Abklärungen & Testing | 8 | 8 | 8 | 8 | Standard. |
|
||||
| | **Subtotal** | **60** | **60** | **70** | **80** | |
|
||||
|
||||
**Delta zur Offerte: +10h (Mitte) / +20h (Max)**
|
||||
**Haupttreiber:** Automatisierte Insights (Pos. 4.5) erfordern eine neue Logikschicht, die proaktiv Schwellenwerte überwacht und Empfehlungen generiert. Das ist im aktuellen Chat-Flow nicht vorgesehen.
|
||||
|
||||
---
|
||||
|
||||
### Position 5: Use Case Wiki-Anbindung
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 5.1 | Wiki-Anbindung & Indexierung | 16 | 16 | 20 | 24 | KnowledgeService existiert. Wiki-Zugang UNBEKANNT. |
|
||||
| 5.2 | RAG-Integration im Chatbot | 12 | 12 | 14 | 16 | Pattern existiert (AgentService), muss portiert werden. |
|
||||
| 5.3 | Inkrementelle Aktualisierung | 8 | 8 | 11 | 14 | Delta-Sync stark Wiki-abhängig. |
|
||||
| 5.4 | Abklärungen & Testing | 8 | 8 | 9 | 10 | Relevanz-Tuning ist iterativ. |
|
||||
| | **Subtotal** | **44** | **44** | **54** | **64** | |
|
||||
|
||||
**Delta zur Offerte: +10h (Mitte) / +20h (Max)**
|
||||
**Haupttreiber:** Wiki-System ist unbekannt. Bei Wiki mit guter API (Confluence, SharePoint) sind 44h erreichbar. Bei proprietärem System ohne API steigt der Aufwand erheblich.
|
||||
|
||||
**Synergie:** KnowledgeService mit pgvector, Chunking, Embedding und semanticSearch ist bereits produktiv. Die RAG-Pipeline (Ingestion → Embedding → Retrieval) muss nicht neu gebaut werden. Das spart geschätzt 20-30h gegenüber einer Neuentwicklung.
|
||||
|
||||
---
|
||||
|
||||
### Position 6: Azure-Migration
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 6.1 | Migration Preprocessor | 6 | 4 | 6 | 8 | Config-Änderungen, Env-Files, Netzwerk. |
|
||||
| 6.2 | Validierung & Smoke-Tests | 4 | 4 | 4 | 4 | End-to-End-Tests. |
|
||||
| | **Subtotal** | **10** | **8** | **10** | **12** | |
|
||||
|
||||
**Delta zur Offerte: 0h (Mitte)**
|
||||
**Bewertung:** Realistisch. Einfachste Position.
|
||||
|
||||
---
|
||||
|
||||
### Position 7: Projektmanagement
|
||||
|
||||
| # | Anforderung | Offerte | Min | Mitte | Max | Begründung |
|
||||
|---|---|:-:|:-:|:-:|:-:|---|
|
||||
| 7.1 | Kick-off & Workshop | 4 | 4 | 4 | 4 | Standard. |
|
||||
| 7.2 | Projektmanagement | 8 | 10 | 12 | 14 | 10-14 Wochen, 3 Ansprechpartner, 7 Positionen. |
|
||||
| 7.3 | Deployment & Go-Live | 6 | 6 | 7 | 8 | Staging + Prod + erste Betriebswoche. |
|
||||
| | **Subtotal** | **18** | **20** | **23** | **26** | |
|
||||
|
||||
**Delta zur Offerte: +5h (Mitte) / +8h (Max)**
|
||||
**Haupttreiber:** PM-Aufwand bei 3-Monats-Projekt mit mehreren Stakeholdern ist erfahrungsgemäss höher.
|
||||
|
||||
---
|
||||
|
||||
## 3. Gesamtübersicht
|
||||
|
||||
| Pos. | Beschreibung | Offerte (h) | Min (h) | Mitte (h) | Max (h) | Offerte CHF | Mitte CHF |
|
||||
|---|---|:-:|:-:|:-:|:-:|:-:|:-:|
|
||||
| 1 | Basics | 54 | 53 | 61 | 68 | 8'100 | 9'150 |
|
||||
| 2 | Kalktool | 92 | 88 | 102 | 116 | 13'800 | 15'300 |
|
||||
| 3 | Materialmanagement 1 | 52 | 50 | 58 | 66 | 7'800 | 8'700 |
|
||||
| 4 | Materialmanagement 2 | 60 | 60 | 70 | 80 | 9'000 | 10'500 |
|
||||
| 5 | Wiki-Anbindung | 44 | 44 | 54 | 64 | 6'600 | 8'100 |
|
||||
| 6 | Azure-Migration | 10 | 8 | 10 | 12 | 1'500 | 1'500 |
|
||||
| 7 | Projektmanagement | 18 | 20 | 23 | 26 | 2'700 | 3'450 |
|
||||
| | **Gesamt** | **330** | **323** | **378** | **432** | **49'500** | **56'700** |
|
||||
|
||||
### Zusammenfassung
|
||||
|
||||
| Szenario | Stunden | CHF (à 150/h) | Differenz zur Offerte |
|
||||
|---|:-:|:-:|:-:|
|
||||
| Offerte (Kostendach) | 330 | 49'500 | -- |
|
||||
| Eigene Schätzung (Minimum) | 323 | 48'450 | -2% |
|
||||
| **Eigene Schätzung (Mitte)** | **378** | **56'700** | **+15%** |
|
||||
| Eigene Schätzung (Maximum) | 432 | 64'800 | +31% |
|
||||
|
||||
---
|
||||
|
||||
## 4. Risikobewertung
|
||||
|
||||
### Risikomatrix
|
||||
|
||||
| # | Risiko | Wahrscheinlichkeit | Auswirkung | Betroffene Pos. | Möglicher Mehraufwand |
|
||||
|---|---|:-:|:-:|---|:-:|
|
||||
| R1 | Matching-Engine komplexer als erwartet | Hoch | Hoch | 2.2 | +10-15h |
|
||||
| R2 | Wiki-System ohne API | Mittel | Hoch | 5.1, 5.3 | +10-20h |
|
||||
| R3 | ERP-Datenqualität mangelhaft | Mittel | Mittel | 1.5, 2.2, 3.1, 4.1 | +8-16h |
|
||||
| R4 | Preprocessor-Erweiterung aufwändiger | Mittel | Mittel | 1.5, 3.1, 4.1 | +8-12h |
|
||||
| R5 | Frontend-Aufwand unterschätzt | Mittel | Gering | 1.2, 1.4 | +4-8h |
|
||||
| R6 | KI-Modell-Qualität für SQL-Generierung | Gering | Mittel | 3, 4 | +4-8h |
|
||||
|
||||
### Synergien (Aufwandsreduktion durch bestehende Komponenten)
|
||||
|
||||
| Synergie | Geschätzte Einsparung | Betroffene Pos. |
|
||||
|---|:-:|---|
|
||||
| KnowledgeService/RAG existiert produktiv | 20-30h | Pos. 5 |
|
||||
| ChatbotDocument-Modell existiert | 4-6h | Pos. 1.4, 2.1 |
|
||||
| LangGraph modular erweiterbar | 6-10h | Pos. 3, 4, 5 |
|
||||
| Prompt-Engineering über DB-Config | 2-4h | Pos. 1.1, 3.2, 4.2 |
|
||||
| Excel-Export-Pattern existiert | 2-4h | Pos. 2.5 |
|
||||
| **Gesamt Einsparung** | **34-54h** | |
|
||||
|
||||
---
|
||||
|
||||
## 5. Empfehlungen
|
||||
|
||||
### 5.1 Zur Offerte
|
||||
|
||||
Die Offerte mit 330h als Kostendach ist **ambitioniert, aber bei idealem Verlauf erreichbar**. Die grössten Risiken liegen in:
|
||||
- Position 2 (Kalktool): Die Matching-Engine ist die komplexeste Neuentwicklung
|
||||
- Position 5 (Wiki): Komplett abhängig vom Wiki-System, das noch unklärt ist
|
||||
|
||||
**Empfehlung:** Offerte bei 330h als Kostendach belassen, aber intern mit 370-380h planen. Die Differenz (~40-50h) als interne Reserve einkalkulieren.
|
||||
|
||||
### 5.2 Priorisierung
|
||||
|
||||
1. **Must-Have (Prio 1):** Pos. 1 (Basics) + Pos. 6 (Azure-Migration) -- Voraussetzung für alles
|
||||
2. **High-Value (Prio 2):** Pos. 2 (Kalktool) -- Höchster Kundennutzen, aber auch höchstes Risiko
|
||||
3. **Quick-Win (Prio 3):** Pos. 3+4 (Materialmanagement) -- Nutzen vorhandene Architektur
|
||||
4. **Abhängig (Prio 4):** Pos. 5 (Wiki) -- Erst nach Wiki-Klärung starten
|
||||
|
||||
### 5.3 Offene Punkte (vor Projektstart zu klären)
|
||||
|
||||
| # | Offener Punkt | Verantwortlich | Kritisch für |
|
||||
|---|---|---|---|
|
||||
| O1 | Wiki-System und Zugangsart klären | Althaus (Samuel) | Pos. 5 |
|
||||
| O2 | ERP-System identifizieren und Datenstrukturen dokumentieren | Althaus (Stefan) | Pos. 1.5, 3.1, 4.1 |
|
||||
| O3 | Preprocessor-Code-Review für Erweiterbarkeit | PowerOn (Entwicklung) | Pos. 1.5, 3.1, 4.1 |
|
||||
| O4 | Kalktool-Vorlage erhalten und analysieren | Althaus (Reto) | Pos. 2.5 |
|
||||
| O5 | Muster-Stücklisten für Matching-Test | Althaus (Reto) | Pos. 2.2 |
|
||||
| O6 | Azure-Subscription-Details | Althaus | Pos. 6 |
|
||||
|
||||
---
|
||||
|
||||
## 6. Zeitplan (2 Entwickler)
|
||||
|
||||
```
|
||||
Woche 1-2: Kick-off + Azure-Migration (Pos. 6) + Basics 1.1-1.3
|
||||
Entwickler A: Azure-Migration + 1.1 (Gesperrte Artikel)
|
||||
Entwickler B: 1.2 (Chat-Verlauf Frontend) + 1.3 (Lange Antworten)
|
||||
|
||||
Woche 2-5: Basics 1.4-1.6 (Grundlage für Use Cases)
|
||||
Entwickler A: 1.4 (File-Upload Full-Stack)
|
||||
Entwickler B: 1.5 (Kundenartikelnummern + Preprocessor)
|
||||
|
||||
Woche 4-9: Kalktool (Pos. 2) -- längster Block, früh starten
|
||||
Entwickler A: 2.1-2.2 (Upload + Matching-Engine)
|
||||
Entwickler B: 2.3-2.5 (Feldergänzung + Export)
|
||||
|
||||
Woche 6-9: Materialmanagement 1+2 (Pos. 3+4) -- parallel zum Kalktool
|
||||
Entwickler B: 3.1-3.4 + 4.1-4.5 (Preprocessor + Prompts)
|
||||
(Entwickler A bleibt auf Kalktool)
|
||||
|
||||
Woche 9-12: Wiki-Anbindung (Pos. 5) -- nach Klärung des Wiki-Systems
|
||||
Entwickler A: 5.1-5.2 (Connector + RAG-Integration)
|
||||
Entwickler B: 5.3 (Delta-Sync) + Integrationstests
|
||||
|
||||
Woche 12-13: Integrationstests, UAT, Go-Live (Pos. 7.3)
|
||||
Beide Entwickler: E2E-Tests + Deployment + Monitoring
|
||||
```
|
||||
|
||||
**Gesamtdauer:** 12-14 Wochen
|
||||
**Kritischer Pfad:** Pos. 1 → Pos. 2 (Kalktool braucht Upload + Kundenartikelnummern)
|
||||
|
||||
---
|
||||
|
||||
*Dokument erstellt auf Basis der Code-Analyse des Gateway-Repository (Stand 13.04.2026)*
|
||||
143
docs/althaus-bot-v2-fragenkatalog.md
Normal file
143
docs/althaus-bot-v2-fragenkatalog.md
Normal file
|
|
@ -0,0 +1,143 @@
|
|||
# Fragenkatalog Althaus Bot v2 -- Kick-off-Vorbereitung
|
||||
|
||||
**Zweck:** Strukturierte Fragen für den Anforderungsworkshop mit W. Althaus AG
|
||||
**Erstellt:** 13. April 2026
|
||||
**Zielgruppe:** Projektleitung PowerOn + Ansprechpartner Althaus (Reto, Stefan, Samuel)
|
||||
|
||||
---
|
||||
|
||||
## A. Wiki-System (Ansprechpartner: Samuel)
|
||||
|
||||
> **Kritisch für:** Position 5 (Wiki-Anbindung) -- Aufwandsschätzung schwankt zwischen 44h und 64h je nach Wiki-System.
|
||||
|
||||
### A.1 Wiki-Identifikation
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| A1.1 | Welches Wiki-System wird eingesetzt? (z.B. Confluence, SharePoint Wiki, MediaWiki, DokuWiki, Notion, anderes) | Bestimmt die Anbindungsstrategie (API vs. Export vs. Crawling) |
|
||||
| A1.2 | Wo wird das Wiki gehostet? (Cloud-SaaS, On-Premise, Azure) | Netzwerk-Zugang und Firewall-Konfiguration |
|
||||
| A1.3 | Wie viele Seiten/Artikel enthält das Wiki ungefähr? | Dimensionierung der Erstindexierung und Embedding-Kosten |
|
||||
| A1.4 | In welchen Formaten liegen die Inhalte vor? (reiner Text, HTML, Markdown, eingebettete PDFs/Bilder) | Bestimmt die Extraktions-Komplexität |
|
||||
|
||||
### A.2 Technischer Zugang
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| A2.1 | Gibt es eine REST-API oder ähnliche Schnittstelle zum Lesen der Wiki-Inhalte? | API-Zugang = deutlich weniger Aufwand als Crawling |
|
||||
| A2.2 | Gibt es eine Export-Funktion? (z.B. XML-Export, PDF-Export, Datenbank-Dump) | Fallback wenn keine API vorhanden |
|
||||
| A2.3 | Gibt es Authentifizierung (API-Key, OAuth, LDAP)? Welche Credentials werden benötigt? | Konfiguration des Connectors |
|
||||
| A2.4 | Gibt es eine Change-API oder Webhooks, die bei Änderungen notifizieren? | Bestimmt den Aufwand für inkrementelle Updates (Pos. 5.3) |
|
||||
| A2.5 | Gibt es Zugriffsbeschränkungen auf bestimmte Wiki-Bereiche? | RBAC-Überlegungen bei der Indexierung |
|
||||
|
||||
### A.3 Inhaltliche Abgrenzung
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| A3.1 | Soll das gesamte Wiki indexiert werden oder nur bestimmte Bereiche? | Scope-Begrenzung für Erstindexierung |
|
||||
| A3.2 | Gibt es vertrauliche Inhalte, die nicht in den Chatbot einfliessen dürfen? | Datenschutz-/Compliance-Anforderung |
|
||||
| A3.3 | Wie oft werden Wiki-Inhalte aktualisiert? (täglich, wöchentlich, selten) | Bestimmt die Sync-Frequenz |
|
||||
| A3.4 | Welche Sprache(n) haben die Wiki-Inhalte? (Deutsch, Englisch, gemischt) | Embedding-Modell-Auswahl |
|
||||
|
||||
---
|
||||
|
||||
## B. ERP-System & Datenstrukturen (Ansprechpartner: Stefan)
|
||||
|
||||
> **Kritisch für:** Positionen 1.5, 2.2-2.3, 3.1, 4.1 -- Preprocessor-Erweiterungen und Matching-Engine.
|
||||
|
||||
### B.1 ERP-Identifikation
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| B1.1 | Welches ERP-System wird eingesetzt? (z.B. Abacus, SAP, Microsoft Dynamics, bexio, Sage) | Bestimmt Datenstruktur und Zugriffsmöglichkeiten |
|
||||
| B1.2 | Wie werden die Daten aktuell an den Preprocessor geliefert? (direkter DB-Zugriff, API, Export-Datei) | Verständnis der bestehenden Datenpipeline |
|
||||
| B1.3 | In welchem Rhythmus werden die Daten aktualisiert? (Echtzeit, täglich, wöchentlich) | Aktualität der Chatbot-Antworten |
|
||||
|
||||
### B.2 Kundenartikelnummern (Position 1.5)
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| B2.1 | Gibt es im ERP eine dedizierte Tabelle für Kundenartikelnummern? Wenn ja, wie heisst sie? | Preprocessor-Schema-Erweiterung |
|
||||
| B2.2 | Wie ist die Zuordnung: 1 Kundenartikel → 1 ERP-Artikel, oder n:m? | Bestimmt die Mapping-Komplexität |
|
||||
| B2.3 | Wie viele Kundenartikelnummern gibt es ungefähr? | Dimensionierung |
|
||||
| B2.4 | Welche Felder hat die Kundenartikelnummern-Tabelle? (z.B. KundenNr, KundenArtikelNr, InterneArtikelNr, Bezeichnung) | Schema-Definition für Preprocessor |
|
||||
|
||||
### B.3 Bestellwesen & Materialmanagement (Positionen 3 + 4)
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| B3.1 | Welche ERP-Tabellen/Views gibt es für Bestellungen? (Bestellkopf, Bestellpositionen, Status) | Preprocessor-Erweiterung Pos. 3.1 |
|
||||
| B3.2 | Gibt es eine Tabelle für Wareneingänge mit Datum und Menge? | Liefertermin-Treue-Berechnung Pos. 4.3 |
|
||||
| B3.3 | Gibt es eine Preishistorie-Tabelle? Welche Felder enthält sie? (Datum, Preis, Lieferant, Währung) | Preisentwicklungs-Analyse Pos. 4.4 |
|
||||
| B3.4 | Gibt es ein Lagerjournal mit Buchungsdaten? | KPI-Analyse Pos. 4.1 |
|
||||
| B3.5 | Gibt es eine Bestandesbedarfsliste oder Dispositions-View? | Material-Analyse Pos. 3.4 |
|
||||
| B3.6 | Gibt es Felder für "bestätigter Liefertermin" vs. "gewünschter Liefertermin"? | Termintreue-KPI Pos. 4.3 |
|
||||
| B3.7 | Wie viele offene Bestellungen gibt es typischerweise gleichzeitig? | Performance-Dimensionierung |
|
||||
|
||||
### B.4 Datenqualität
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| B4.1 | Wie konsistent sind Lieferanten-Namen im ERP? (exakt gleich oder Varianten wie "Siemens AG" vs. "Siemens") | Matching-Qualität Pos. 2.2 |
|
||||
| B4.2 | Gibt es Pflichtfelder die häufig leer sind? | Feldergänzungs-Logik Pos. 2.3 |
|
||||
| B4.3 | Wie sind Preise gespeichert? (Netto, Brutto, mit/ohne MwSt., Währung) | SQL-Query-Generierung |
|
||||
| B4.4 | Werden gelöschte/gesperrte Datensätze physisch oder nur logisch gelöscht? | Filter-Logik Pos. 1.1 |
|
||||
|
||||
---
|
||||
|
||||
## C. Kalktool (Ansprechpartner: Reto)
|
||||
|
||||
> **Kritisch für:** Position 2 (Kalktool) -- Höchstes Risiko in der Offerte.
|
||||
|
||||
### C.1 Kalktool-Vorlage
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| C1.1 | Können wir die aktuelle Kalktool-Vorlage (Kalktool_Aktuell_2026_V1.4.xlsx) erhalten? | Zielformat für Excel-Export Pos. 2.5 |
|
||||
| C1.2 | Welche Spalten/Felder sind Pflicht in der Kalktool-Vorlage? | Feldergänzungs-Priorität Pos. 2.3 |
|
||||
| C1.3 | Gibt es Formeln in der Vorlage, die erhalten bleiben müssen? | Komplexität des Excel-Exports |
|
||||
| C1.4 | Welches Format haben die Kunden-Stücklisten typischerweise? (PDF, Excel, CSV) | Extraktions-Strategie Pos. 2.1 |
|
||||
|
||||
### C.2 Matching-Anforderungen
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| C2.1 | Können wir 3-5 Muster-Stücklisten von verschiedenen Kunden erhalten? | Testdaten für Matching-Engine Pos. 2.2 |
|
||||
| C2.2 | Welche Identifikationsmerkmale haben Kunden-Stücklisten? (Kundenartikelnr., Hersteller-Typ, Beschreibung) | Matching-Stufen definieren |
|
||||
| C2.3 | Wie hoch ist die erwartete Trefferquote beim exakten Match? (10%? 50%? 90%?) | Gewichtung exakt vs. fuzzy vs. KI |
|
||||
| C2.4 | Welche Felder sollen bei nicht-eindeutigem Match als "Alternative durch KI" markiert werden? | Bestätigungs-Workflow Pos. 2.4 |
|
||||
| C2.5 | Gibt es Produktgruppen, die besonders schwierig zu matchen sind? | Risikobewertung |
|
||||
|
||||
---
|
||||
|
||||
## D. Infrastruktur & Azure (Ansprechpartner: Stefan / IT)
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| D1 | Details zur neuen Azure-Subscription (Subscription-ID, Region, Resource Group) | Pos. 6 -- Migration |
|
||||
| D2 | Gibt es Netzwerk-Einschränkungen (VPN, Private Endpoints, Firewall)? | Zugang Preprocessor ↔ ERP |
|
||||
| D3 | Wer hat Admin-Zugang zur neuen Subscription? | Deployment-Planung |
|
||||
| D4 | Gibt es Budget-Limits auf der Azure-Subscription? | Betriebskosten-Planung |
|
||||
|
||||
---
|
||||
|
||||
## E. Priorisierung & Vorgehensweise
|
||||
|
||||
| # | Frage | Hintergrund |
|
||||
|---|---|---|
|
||||
| E1 | Sollen alle 7 Positionen umgesetzt werden, oder gibt es eine Priorisierung? | Scope-Bestätigung |
|
||||
| E2 | Gibt es einen gewünschten Go-Live-Termin? | Zeitplanung |
|
||||
| E3 | Wie soll die UAT organisiert werden? (dedizierte Testphase, laufend, Key-User) | Testplanung |
|
||||
| E4 | Wer sind die Pilot-User für den reaktivierten Bot? | UAT-Teilnehmer |
|
||||
| E5 | Sollen Schulungen für Endanwender durchgeführt werden? (nicht in Offerte enthalten) | Ggf. Nachtragsofferte |
|
||||
|
||||
---
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
1. **Vor dem Kick-off:** Fragenkatalog an Althaus senden, damit Antworten vorbereitet werden können
|
||||
2. **Im Kick-off:** Fragen durchgehen, fehlende Antworten als Action Items festhalten
|
||||
3. **Nach dem Kick-off:** Aufwandsschätzung anhand der Antworten finalisieren, insbesondere Pos. 2.2 (Matching) und Pos. 5 (Wiki)
|
||||
|
||||
---
|
||||
|
||||
*PowerOn AG -- Vorbereitung Anforderungsworkshop Althaus Bot v2*
|
||||
223
docs/althaus-bot-v2-preprocessor-assessment.md
Normal file
223
docs/althaus-bot-v2-preprocessor-assessment.md
Normal file
|
|
@ -0,0 +1,223 @@
|
|||
# Preprocessor Assessment -- Althaus Bot v2
|
||||
|
||||
**Zweck:** Technische Analyse des Preprocessing-Servers für die Aufwandsschätzung der Erweiterungen
|
||||
**Erstellt:** 13. April 2026
|
||||
**Quellen:** Gateway-Code-Analyse (Repo nicht lokal verfügbar: github.com/valueonag/gateway_preprocessing)
|
||||
|
||||
---
|
||||
|
||||
## 1. Ist-Zustand (abgeleitet aus Gateway-Code)
|
||||
|
||||
### 1.1 Infrastruktur
|
||||
|
||||
| Eigenschaft | Wert |
|
||||
|---|---|
|
||||
| **Host** | Azure App Service (Switzerland North) |
|
||||
| **URL (Datenverarbeitung)** | `poweron-althaus-preprocess-prod-*.azurewebsites.net/api/v1/dataprocessor/update-db-with-config` |
|
||||
| **URL (Abfragen)** | `poweron-althaus-preprocess-prod-*.azurewebsites.net/api/v1/dataquery/query` |
|
||||
| **Authentifizierung** | `X-PP-API-Key` (Abfragen) / `X-DB-API-Key` (Abfragen) |
|
||||
| **Status** | Deployed, ERP-Datenanbindung deaktiviert |
|
||||
| **Quellcode** | `github.com/valueonag/gateway_preprocessing` (separates Repo) |
|
||||
|
||||
### 1.2 Aktuelle Tabellen-Konfiguration
|
||||
|
||||
Aus dem Automation-Template (`subAutomationTemplates.py`) extrahiert:
|
||||
|
||||
```json
|
||||
{
|
||||
"tables": [
|
||||
{
|
||||
"name": "Artikel",
|
||||
"powerbi_table_name": "Artikel",
|
||||
"steps": [
|
||||
{
|
||||
"keep": {
|
||||
"columns": [
|
||||
"I_ID", "Artikelbeschrieb", "Artikelbezeichnung",
|
||||
"Artikelgruppe", "Artikelkategorie", "Artikelkürzel",
|
||||
"Artikelnummer", "Einheit", "Gesperrt",
|
||||
"Keywords", "Lieferant", "Warengruppe"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"fillna": {
|
||||
"column": "Lieferant",
|
||||
"value": "Unbekannt"
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "Einkaufspreis",
|
||||
"powerbi_table_name": "Einkaufspreis",
|
||||
"steps": [
|
||||
{
|
||||
"to_numeric": {
|
||||
"column": "EP_CHF",
|
||||
"errors": "coerce"
|
||||
}
|
||||
},
|
||||
{
|
||||
"dropna": {
|
||||
"subset": ["EP_CHF"]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 1.3 Zusätzliche Tabellen (im Chatbot referenziert, aber nicht in der Config)
|
||||
|
||||
Aus den SQL-Beispielen in `bridges/tools.py` und `chatbot.py`:
|
||||
|
||||
| Tabelle | Spalten (referenziert im Code) | Joins |
|
||||
|---|---|---|
|
||||
| `Lagerplatz_Artikel` | `R_ARTIKEL`, `R_LAGERPLATZ`, `S_IST_BESTAND`, `S_RESERVIERTER__BESTAND` | ON `Artikel.I_ID = Lagerplatz_Artikel.R_ARTIKEL` |
|
||||
| `Lagerplatz` | `I_ID`, `Lagerplatz` (Name) | ON `Lagerplatz_Artikel.R_LAGERPLATZ = Lagerplatz.I_ID` |
|
||||
|
||||
Diese Tabellen sind vermutlich in einer älteren Config-Version oder direkt im Preprocessor konfiguriert.
|
||||
|
||||
### 1.4 API-Schnittstellen
|
||||
|
||||
**Abfrage-API** (genutzt vom `PreprocessorConnector`):
|
||||
- Methode: `POST`
|
||||
- Payload: `{"query": "SELECT ..."}`
|
||||
- Header: `X-DB-API-Key: <api_key>`
|
||||
- Response: `{"success": true/false, "data": [...], "row_count": N, "message": "..."}`
|
||||
- Einschränkung: Nur SELECT-Queries (validiert im Gateway)
|
||||
|
||||
**Update-API** (genutzt vom Automation-Template):
|
||||
- Methode: `POST`
|
||||
- Payload: `configJson` (Tabellendefinitionen + Transformationsschritte)
|
||||
- Header: `X-PP-API-Key: <secret>`
|
||||
- Zweck: Datenbank mit neuer Konfiguration aktualisieren
|
||||
|
||||
### 1.5 Transformation-Steps (bekannte Operationen)
|
||||
|
||||
Aus der Config-JSON abgeleitet:
|
||||
|
||||
| Operation | Parameter | Beschreibung |
|
||||
|---|---|---|
|
||||
| `keep` | `columns: [...]` | Nur angegebene Spalten behalten |
|
||||
| `fillna` | `column`, `value` | NULL-Werte ersetzen |
|
||||
| `to_numeric` | `column`, `errors` | Spalte in numerischen Typ konvertieren |
|
||||
| `dropna` | `subset: [...]` | Zeilen mit NULL in angegebenen Spalten entfernen |
|
||||
|
||||
---
|
||||
|
||||
## 2. Benötigte Erweiterungen (nach Position)
|
||||
|
||||
### 2.1 Position 1.5: Kundenartikelnummern
|
||||
|
||||
**Neue Tabelle: `Kundenartikelnummer`**
|
||||
|
||||
| Spalte (geschätzt) | Typ | Beschreibung |
|
||||
|---|---|---|
|
||||
| `I_ID` | INT | Primary Key |
|
||||
| `R_ARTIKEL` | INT | FK auf Artikel.I_ID |
|
||||
| `Kundenummer` | VARCHAR | Kundennummer |
|
||||
| `Kundenartikelnummer` | VARCHAR | Kunden-eigene Artikelnummer |
|
||||
| `Bezeichnung` | VARCHAR | Kundenbezeichnung (optional) |
|
||||
|
||||
**Config-Erweiterung:**
|
||||
```json
|
||||
{
|
||||
"name": "Kundenartikelnummer",
|
||||
"powerbi_table_name": "Kundenartikelnummer",
|
||||
"steps": [
|
||||
{"keep": {"columns": ["I_ID", "R_ARTIKEL", "Kundenummer", "Kundenartikelnummer", "Bezeichnung"]}}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Aufwand-Bewertung:** Falls der Preprocessor neue Tabellen per Config akzeptiert: ~2-3h Config + Test. Falls neuer Code nötig: ~6-8h.
|
||||
|
||||
### 2.2 Position 3.1: Bestellwesen (Materialmanagement 1)
|
||||
|
||||
**Neue Tabellen (geschätzt 3-4 Tabellen):**
|
||||
|
||||
| Tabelle | Wichtige Spalten | Zweck |
|
||||
|---|---|---|
|
||||
| `Bestellkopf` | ID, Bestellnummer, Lieferant, Bestelldatum, Status, Wunschtermin | Bestellübersicht |
|
||||
| `Bestellposition` | ID, R_Bestellung, R_Artikel, Menge, Preis, Status, Bestätigter_Termin | Positionsdetails |
|
||||
| `Wareneingang` | ID, R_Bestellung, R_Position, Eingangsdatum, Menge, Qualität | Lieferverfolgung |
|
||||
| `Auftrag` | ID, Auftragsnummer, Kunde, R_Artikel, Menge, Termin | Betroffene Aufträge |
|
||||
|
||||
**Aufwand-Bewertung:** 4 Tabellen × ~4h pro Tabelle (Config + Code + Transformationen + Test) = ~16h. Bei komplexen Transformationen (Joins, Aggregationen): +4-6h.
|
||||
|
||||
### 2.3 Position 4.1: KPI-Daten (Materialmanagement 2)
|
||||
|
||||
**Neue Tabellen/Views (geschätzt 3-4):**
|
||||
|
||||
| Tabelle/View | Wichtige Spalten | Zweck |
|
||||
|---|---|---|
|
||||
| `Lagerjournal` | ID, R_Artikel, Buchungsdatum, Menge, Typ | Lagerbewegungen |
|
||||
| `Preishistorie` | ID, R_Artikel, R_Lieferant, Datum, Preis, Währung | Preisentwicklung |
|
||||
| `Bestandesbedarfsliste` | R_Artikel, Bedarf, Bestand, Fehlmenge, Datum | Dispositionsplanung |
|
||||
| `View_Termintreue` | R_Lieferant, Wunschtermin, Bestätigt, Geliefert, Abweichung_Tage | Aggregierte KPIs |
|
||||
|
||||
**Aufwand-Bewertung:** 4 Tabellen/Views × ~4h = ~16h. Aggregierte Views (Termintreue): +4-6h für Berechnungslogik im Preprocessor.
|
||||
|
||||
---
|
||||
|
||||
## 3. Gesamtbewertung Preprocessor-Erweiterungen
|
||||
|
||||
### 3.1 Zusammenfassung
|
||||
|
||||
| Position | Neue Tabellen | Config-Aufwand | Code-Aufwand | Test | Gesamt |
|
||||
|---|:-:|:-:|:-:|:-:|:-:|
|
||||
| 1.5 (Kundenartikelnummern) | 1 | 1h | 3-5h | 2h | **6-8h** |
|
||||
| 3.1 (Bestellwesen) | 3-4 | 2h | 8-12h | 4h | **14-18h** |
|
||||
| 4.1 (KPIs) | 3-4 | 2h | 8-12h | 4h | **14-18h** |
|
||||
| **Gesamt** | **7-9** | **5h** | **19-29h** | **10h** | **34-44h** |
|
||||
|
||||
### 3.2 Offene Fragen (Code-Review des Preprocessor-Repos erforderlich)
|
||||
|
||||
| # | Frage | Auswirkung |
|
||||
|---|---|---|
|
||||
| P1 | Unterstützt der Preprocessor neue Tabellen per Config-Erweiterung, oder muss für jede Tabelle Code geschrieben werden? | Bestimmt ob Config-only (~2h/Tabelle) oder Code (~4h/Tabelle) |
|
||||
| P2 | Können aggregierte Views/Berechnungen im Preprocessor definiert werden? | Termintreue-KPI, Bestandsreichweite |
|
||||
| P3 | Wie werden Joins zwischen Tabellen gehandhabt? (SQLite-seitig oder Preprocessor-seitig) | Komplexität der Cross-Table-Queries |
|
||||
| P4 | Gibt es Rate-Limits oder Grössen-Limits bei der Query-API? | Performance bei komplexen KPI-Abfragen |
|
||||
| P5 | Wie gross ist die aktuelle SQLite-Datenbank? Wie viele Artikel? | Dimensionierung für 8-10 neue Tabellen |
|
||||
|
||||
### 3.3 Empfehlung
|
||||
|
||||
**Vor Projektstart sollte ein Code-Review des Preprocessor-Repos durchgeführt werden** (geschätzter Aufwand: 2-4h). Dabei klären:
|
||||
|
||||
1. Erweiterbarkeit: Kann der Preprocessor neue Tabellen per Config akzeptieren?
|
||||
2. Transformationen: Welche Operationen sind neben `keep`, `fillna`, `to_numeric`, `dropna` verfügbar?
|
||||
3. Performance: Wie skaliert die SQLite-DB mit 8-10 zusätzlichen Tabellen?
|
||||
4. Deployment: Wie wird der Preprocessor deployed? (CI/CD, manuell, Azure DevOps)
|
||||
|
||||
Das Ergebnis dieses Reviews kann die Aufwandsschätzung für Pos. 1.5, 3.1 und 4.1 um jeweils 4-6h nach oben oder unten korrigieren.
|
||||
|
||||
---
|
||||
|
||||
## 4. Aktueller Datenfluss (zur Referenz)
|
||||
|
||||
```
|
||||
ERP (Althaus)
|
||||
│
|
||||
▼ (Power BI Export / API / DB-Zugriff -- Mechanismus unklar)
|
||||
Preprocessor Server (Azure)
|
||||
│
|
||||
├── /api/v1/dataprocessor/update-db-with-config ← Automation-Template
|
||||
│ (Tabellen laden, transformieren, in SQLite schreiben)
|
||||
│
|
||||
└── /api/v1/dataquery/query ← PreprocessorConnector (Gateway)
|
||||
(SQL SELECT auf SQLite ausführen)
|
||||
│
|
||||
▼
|
||||
Gateway (Chatbot LangGraph)
|
||||
│
|
||||
▼
|
||||
React Frontend (Chat-UI)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*Assessment erstellt auf Basis der Gateway-Code-Analyse. Für eine genauere Schätzung ist ein Code-Review des Preprocessor-Repos erforderlich.*
|
||||
BIN
docs/billing-ui-tests.xlsx
Normal file
BIN
docs/billing-ui-tests.xlsx
Normal file
Binary file not shown.
225
docs/briefing-abacus-c-level.md
Normal file
225
docs/briefing-abacus-c-level.md
Normal file
|
|
@ -0,0 +1,225 @@
|
|||
# PowerOn × Abacus — Executive Briefing
|
||||
|
||||
*Vertraulich · C-Level Briefing für Abacus Research AG · Stand April 2026*
|
||||
|
||||
**Zielgruppe:** Geschäftsleitung Abacus (Strategie, Produkt, Partnerschaften)
|
||||
**Zweck:** Abacus ein klares, belastbares Bild davon geben, **wer PowerOn ist, was PowerOn/PORTA leistet und wo der strategische Hebel für eine Zusammenarbeit liegt** — inklusive konkretem Zwischenstand zur Abacus-Schnittstelle.
|
||||
**Lesedauer:** 7 Minuten.
|
||||
|
||||
---
|
||||
|
||||
## 1. Management Summary (60 Sekunden)
|
||||
|
||||
- **PowerOn ist eine Schweizer KI-Plattform** aus Zürich, die Unternehmen KI-gestützte Geschäftsprozesse **sicher, mandantengetrennt und datenschutzkonform** zur Verfügung stellt.
|
||||
- Das Kernprodukt **PORTA** (Powerful Orchestration & Real-Time Automation) ist eine **in der Schweiz gehostete Multi-Mandanten-Plattform** mit vier Kernfunktionen in einem konsistenten System:
|
||||
- **Multi-LLM-Orchestrierung** (Anthropic, OpenAI, Mistral, Perplexity, Tavily, Private LLM – kein Vendor-Lock-in)
|
||||
- **Workflow-Automatisierung** (Graph-basierter Flow-Editor, Scheduler, Execution-Engine)
|
||||
- **Datenneutralisierung** (zentrales AI-Gate, optional Hard-Mode, optional Private LLM)
|
||||
- **Integriertes Audit- und Compliance-Logging** (DSGVO/revDSG, lückenloser Audit-Trail)
|
||||
- PORTA ist modular aufgebaut (**Feature-Store**): Mandanten schalten nur die Module frei, die sie brauchen – u. a. **AI-Chat-Workspace, Treuhand-/Buchhaltungs-Modul mit Abacus-Anbindung, Kommunikations-/Coaching-Modul, Teams-Meeting-Bot, Machbarkeitsstudie Immobilien, Workflow-Designer / Automation-Studio**. Diese Bausteine laufen **produktiv** – der Plattform-Unterbau ist gebaut, Kundenprojekte beschränken sich auf **Konfiguration, Datenanbindung, Tuning, Schulung und Inbetriebnahme**.
|
||||
- **Das Treuhand-Modul besitzt bereits eine abstrahierte Buchhaltungs-Schnittstelle** mit produktiven Connectoren für **Run my Accounts** und **Bexio** – sowie einem **bereits implementierten, lauffähigen Abacus-Connector** (OAuth 2.0, OData V4, Kontenplan, Buchungs-Push, Journal-Read, Debitoren, Kreditoren). Es fehlt nur der produktive Feinschliff mit einem Pilotkunden.
|
||||
- **Strategischer Kern-Punkt für Abacus:** PowerOn ist **nicht** ein weiterer ERP-Wettbewerber. PowerOn ist die **KI- und Workflow-Schicht oberhalb** des ERP. Für Abacus-Kunden bedeutet das: Abacus bleibt System of Record – PORTA liefert Intelligenz, Automatisierung und ein modernes User-Interface auf den Daten, die in Abacus entstehen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Wer ist PowerOn?
|
||||
|
||||
### 2.1 Firma
|
||||
|
||||
- **PowerOn AG**, Birmensdorferstrasse 94, 8003 Zürich – `www.poweron.swiss`
|
||||
- Schweizer Unternehmen, Schweizer Datenhaltung, Schweizer Kundenfokus (DACH).
|
||||
- Entstanden aus der **ValueOn AG** (Strategie-/Beratungshaus) – derzeit in strukturierter Verselbständigung zur eigenständigen Organisation.
|
||||
|
||||
### 2.2 Gründer-/Kernteam
|
||||
|
||||
| Person | Rolle | Profil |
|
||||
|---|---|---|
|
||||
| **Patrick Motsch** | CEO / CTO | Langjährige Erfahrung in der Leitung komplexer IT-Implementierungen und innovativer Softwareentwicklung. |
|
||||
| **Ida Dittrich** | Product Architect | Verbindet wissenschaftliches Know-how mit praktischer IT-Erfahrung und treibt die Produkt-/Architekturentscheide. |
|
||||
| **Stephan Schellworth** | Business Integration | Verbindet strategisches Denken mit praxisnaher Projektsteuerung; Ansprechpartner für Partnerschaften und Kundenintegrationen. |
|
||||
|
||||
### 2.3 Reifegrad & Fokus
|
||||
|
||||
- **Produktstatus:** Early Product-Market-Fit mit produktiv laufenden Features; aktiv im Pilotkunden-Modus; Seed-Runde in Vorbereitung.
|
||||
- **Zielmarkt:** mittelständische Unternehmen in datenschutzsensiblen Branchen – **Treuhand, Finanzdienstleistungen, Immobilien, Professional Services, Legal, Healthcare** – also eine sehr hohe Überlappung mit Abacus-Kernkunden.
|
||||
- **Go-to-Market:** aktuell DACH; in einem strategischen Verbund mit **ValueOn (Strategie-Beratung), Aumico (Frontend/MVP) und Modeso (Hosting/SRE)** aufgestellt – End-to-End abdeckbar, ohne dass Abacus technologische oder operative Lücken schliessen müsste.
|
||||
|
||||
---
|
||||
|
||||
## 3. Was macht PowerOn – und was kann PORTA?
|
||||
|
||||
### 3.1 Die Kernidee in einem Satz
|
||||
|
||||
> **PowerOn liefert Unternehmen einen sicheren KI-Arbeitsplatz, der ihre Prozesse versteht, ihre Systeme anbindet und wiederkehrende Arbeit automatisiert – ohne dass sensible Daten unkontrolliert in fremde KI-Dienste abfliessen.**
|
||||
|
||||
### 3.1.1 Die vier Kernfunktionen von PORTA
|
||||
|
||||
PORTA bündelt in **einer** in der Schweiz gehosteten Multi-Mandanten-Plattform das, was sonst über mehrere isolierte Werkzeuge verteilt ist:
|
||||
|
||||
| Kernfunktion | Was sie leistet | Status |
|
||||
|---|---|---|
|
||||
| **Multi-LLM-Orchestrierung** | Zentrale Modellauswahl und Routing über mehrere Provider (Anthropic, OpenAI, Mistral, Perplexity, Tavily, Private LLM). Billing-Preflight, Streaming, Fallbacks, Operation-Typ-basierte Modellwahl. | **Produktiv** |
|
||||
| **Workflow-Automatisierung** | Graph-basierter Flow-Editor (n8n-Style), Execution-Engine mit topologischer Sortierung, Scheduler, UDM-Dokumentenmodell, drei Modi (Learning / Actionplan / Automation). | **Produktiv** |
|
||||
| **Datenneutralisierung** | Zentrales AI-Gate, das Prompt, RAG-Kontext und Messages vor jedem externen Modellaufruf pseudonymisiert. Hard-Mode blockiert Calls, wenn Neutralisierung nicht möglich. Private-LLM-Option für volle On-Prem-Variante. | **Produktiv** |
|
||||
| **Audit- und Compliance-Logging** | Integrierter, lückenloser Audit-Trail für Zugriffe, Admin-Aktionen, Berechtigungs- und Verschlüsselungs-Events sowie KI-Datenflüsse. DSGVO-/revDSG-Betroffenenrechte als Self-Service. | **Produktiv** |
|
||||
|
||||
### 3.1.2 Produktiver Abdeckungsgrad (Stand heute)
|
||||
|
||||
Die für Treuhand, Finanz und KMU typischen Bausteine sind **bereits produktiv in der Plattform** und werden nicht erst für ein neues Projekt entwickelt:
|
||||
|
||||
- Buchhaltungs-Modul mit **Abacus-Anbindung** (sowie RMA und Bexio)
|
||||
- **Coaching- und Trainings-Modul** (Kommunikations-Coach, Voice, Dossier, Gamification)
|
||||
- **KI-Arbeitsplatz** (Power Desktop / AI-Workspace mit RAG und Agent-Tools)
|
||||
- **Datenneutralisierung** (zentrales AI-Gate + Private-LLM-Option)
|
||||
- **Workflow-Designer** (grafischer Flow-Editor inkl. Scheduler und Execution-Engine)
|
||||
|
||||
Für einen Abacus-nahen Kundenfall oder ein gemeinsames Pilot-Engagement reduziert sich der Projektaufwand damit auf **kundenspezifische Konfiguration, Datenanbindung, Tuning, Schulung und Inbetriebnahme** – nicht auf Plattform-Grundlagenentwicklung. Das ist der entscheidende Geschwindigkeitsvorteil gegenüber „We-build-it-from-scratch"-Angeboten.
|
||||
|
||||
### 3.2 Die fünf Prinzipien hinter „Erfolgreichem KI-Einsatz"
|
||||
|
||||
1. **Use-Cases zuerst:** Schrittweise Einführung statt Big-Bang. Mandanten aktivieren modular die Features, die sie brauchen.
|
||||
2. **Datenschutz by Design:** Ein zentrales AI-Gate neutralisiert sensible Inhalte *vor* jedem externen Modell-Aufruf. Option: komplett lokaler Betrieb über Private LLM.
|
||||
3. **Berechtigungen:** Vierstufiges RBAC (System → Mandant → Feature → Feature-Instanz), granular pro Aktion (Lesen/Schreiben/Bearbeiten/Löschen), vollständige Mandantentrennung serverseitig.
|
||||
4. **Verbindungen:** Toolbox-Registry mit offenen Connectoren zu Microsoft 365, Google Workspace, SharePoint, ClickUp, Jira, E-Mail/SMS, Websuche, Swiss-Topo/Geo-Systemen und **Buchhaltungs-Systemen (RMA, Bexio, Abacus)**.
|
||||
5. **Regeln / Ethik:** Lückenloser Audit-Trail, DSGVO-Betroffenenrechte als Self-Service, kein Training mit Kundendaten.
|
||||
|
||||
### 3.3 PORTA — Feature-Landkarte (Auszug)
|
||||
|
||||
| Feature | Was es tut | Relevanz für Abacus-Kundschaft |
|
||||
|---|---|---|
|
||||
| **Power Desktop / AI-Workspace** | KI-Chat mit RAG über Firmendokumente, Editor, Playground. 40+ Agent-Tools in thematischen Toolboxes. | Sofort-Nutzen für Treuhänder/Berater, die mit Dokumenten arbeiten. |
|
||||
| **Treuhand-Modul** | Positionen, Dokumente, Expense Import, Scan/Upload, Buchhaltungs-Sync. Pluggable Connector-Architektur. | **Direkter Touchpoint zu Abacus** – siehe Kapitel 5. |
|
||||
| **Automation Studio (n8n-Style Flow Editor)** | Graphical Flow Editor, Scheduler, Workflow-Runs, UDM-Dokumentenmodell. | Automatisiert Prozesse um/auf Abacus-Daten (Freigaben, Reports, Benachrichtigungen). |
|
||||
| **Kommunikations-Coach** | KI-gestütztes Gesprächstraining mit Voice (STT/TTS), Dossier, Gamification. | Sales-Coaching, Kundenkommunikation, Onboarding. |
|
||||
| **Teams-Meeting-Bot** | Nimmt an Teams-Meetings teil, transkribiert, antwortet kontextbezogen. | Meeting-Protokolle, Folge-Aufgaben automatisch aus Gesprächen ableiten. |
|
||||
| **Machbarkeitsstudie Real Estate** | Extrahiert BZO/Parzellen-Daten und bewertet Immobilienpotenziale. | Spezialisiertes Branchen-Modul (Immobilien-Treuhand, Verwaltungen). |
|
||||
| **Chatbot / Knowledge Retrieval** | RAG über Firmenwissen, semantische Suche via pgvector. | Interner Helpdesk, Dokumenten-Q&A. |
|
||||
| **Neutralization / Private LLM** | Pseudonymisiert PII/Geschäftsgeheimnisse vor externen KI-Calls oder hält Daten komplett lokal. | Zwingend für Treuhand/Finanz-Kontext. |
|
||||
|
||||
### 3.4 Technische Basis (für das technische Gegenüber bei Abacus)
|
||||
|
||||
- **Backend (Gateway):** FastAPI/Python, PostgreSQL inkl. `pgvector` für Embeddings.
|
||||
- **Frontend (Nyla):** React/TypeScript, Vite.
|
||||
- **AI-Core:** Multi-Provider (Anthropic, OpenAI, Mistral, Perplexity, Tavily, Private LLM) — **Modellunabhängigkeit, kein Vendor-Lock-in**.
|
||||
- **Architektur:** saubere Schichtung **Connectors → Interfaces → Services → ServiceCenter** mit zentraler Orchestrierung, `PublicService`-Wrapper für kontrolliertes API-Surface.
|
||||
- **Workflow-Engine:** eigene Graph-Execution-Engine (topologische Sortierung, Transit-Routing, Schema-Validierung, Resume), drei Modi (Learning, Actionplan, Automation).
|
||||
- **Security:** AES/Fernet + PBKDF2-HMAC-SHA256 für Secrets, JWT + Cookie-Session, CSRF, Rate-Limiting, parametrisierte Queries, RBAC serverseitig. Orientierung an DSGVO, revDSG und OWASP Top 10. Formale ISO-27001-Zertifizierung noch nicht vorhanden – technische Basis dafür vorhanden.
|
||||
- **Betrieb:** Containerisiert, cloud-native, hosted bei Modeso (Partner) auf Google Cloud Infrastruktur, Deployment-Pipelines via GitHub Actions.
|
||||
|
||||
---
|
||||
|
||||
## 4. Differenzierung (warum nicht Microsoft Copilot oder n8n?)
|
||||
|
||||
| Anforderung | Microsoft Copilot / ChatGPT Enterprise | n8n / Zapier | **PowerOn PORTA** |
|
||||
|---|---|---|---|
|
||||
| Datenschutz-Neutralisierer | — | — | **Ja, zentral am AI-Gate** |
|
||||
| Eigenes/lokales LLM möglich | Teilweise | — | **Ja, Private-LLM-Connector** |
|
||||
| Multi-Provider, kein Lock-in | Nein | Ja | **Ja** |
|
||||
| Business-User-fähig (ohne Entwickler) | Ja | Nein | **Ja** |
|
||||
| Workflow- + Chat- + RAG in einer Plattform | Nein | Nur Workflow | **Ja** |
|
||||
| Swiss-hosted, Swiss-built | Nein | Nein | **Ja** |
|
||||
| Branchenmodule (Treuhand, Immobilien, …) | — | — | **Ja, Feature-Store** |
|
||||
| Direkte Buchhaltungs-Integration | — | Generisch | **Ja (RMA, Bexio, Abacus ready)** |
|
||||
|
||||
---
|
||||
|
||||
## 5. Die Abacus-Schnittstelle — konkreter Stand
|
||||
|
||||
Das ist der wichtigste Abschnitt für Abacus. **PowerOn hat die Abacus-Schnittstelle nicht nur sondiert, sondern bereits implementiert** – im Modul `trustee/accounting/connectors/accountingConnectorAbacus.py`.
|
||||
|
||||
### 5.1 Was bereits umgesetzt ist
|
||||
|
||||
| Bereich | Stand | Technik |
|
||||
|---|---|---|
|
||||
| Authentifizierung | **Implementiert** | OAuth 2.0 Client Credentials (Service User) mit OIDC-Discovery (`/.well-known/openid-configuration`), Token-Caching, automatischer Refresh |
|
||||
| Datenmodell (Abacus ↔ PORTA) | **Implementiert** | Entity-API via OData V4, pro Mandant konfigurierbare `apiBaseUrl` und `clientName` |
|
||||
| Kontenplan (`Accounts`) | **Implementiert** | Paginiertes Auslesen inkl. `@odata.nextLink`, Mapping auf einheitliches `AccountingChart`-Format |
|
||||
| Buchung erfassen (`GeneralJournalEntries`) | **Implementiert** | POST mit Mehrzeilen-Journal, Debit/Credit/TaxCode/CostCenter, Rücklieferung `externalId` |
|
||||
| Buchungsstatus lesen | **Implementiert** | GET auf `GeneralJournalEntries({id})` |
|
||||
| Journal lesen (Zeitraum-/Filter) | **Implementiert** | `$filter` auf `JournalDate`, paginiertes Streaming |
|
||||
| Stammdaten | **Implementiert** | `Debtors`, `Creditors` |
|
||||
| Sicherheit | **Implementiert** | Secrets verschlüsselt gespeichert (`TrusteeAccountingConfig.encryptedConfig`), Plugin-Discovery identisch zu Bexio/RMA |
|
||||
|
||||
### 5.2 Architektur-Prinzip
|
||||
|
||||
Die Connector-Schicht ist **abstrahiert** (`BaseAccountingConnector`). Alle Buchhaltungs-Integrationen teilen sich dieselben Datenmodelle (`AccountingBooking`, `AccountingBookingLine`, `AccountingChart`, `SyncResult`) und werden über eine **Plugin-Registry** discovered. Das heisst:
|
||||
|
||||
- Jeder neue Connector (Abacus, SAP Business One, Sage etc.) wird ohne Änderung am Kernsystem angeflanscht.
|
||||
- Abacus steht **auf Augenhöhe** mit Bexio und Run my Accounts im Produkt.
|
||||
- Kunden können in der gleichen PORTA-Oberfläche zwischen den Systemen wählen bzw. umziehen.
|
||||
|
||||
### 5.3 Was noch offen ist
|
||||
|
||||
- **Produktiv-Pilot mit einem realen Abacus-Mandanten** (Credentials, Mandantenstruktur, Konto-Mapping, Kostenstellen-Logik, Beleg-Anhänge via Dokument-Upload).
|
||||
- **Feinheiten**: Mehrwährung, spezifische Abacus-Customizings, Dokument-Anhänge an Buchungen (`uploadDocument` ist im Basis-Interface vorgesehen), Rückkanal für Freigabe-Workflows.
|
||||
- **Zertifizierung/Partner-Listing** auf Abacus-Seite.
|
||||
|
||||
### 5.4 Projektcharakter bei einem gemeinsamen Kundenengagement
|
||||
|
||||
Weil die Plattform-Bausteine (Buchhaltungs-Modul mit Abacus-Anbindung, KI-Arbeitsplatz, Datenneutralisierung, Workflow-Designer, Coaching-Modul) **produktiv laufen**, reduziert sich ein gemeinsames Kundenprojekt auf klar abgrenzbare, planbare Tätigkeiten – nicht auf Plattform-Neuentwicklung:
|
||||
|
||||
| Aufwandsblock | Inhalt |
|
||||
|---|---|
|
||||
| **Konfiguration** | Aktivierung der benötigten PORTA-Module pro Mandant, Rollen-/RBAC-Modell, Feature-Instanzen, Branding |
|
||||
| **Datenanbindung** | Abacus-Credentials (OAuth 2.0), Kontenplan-Mapping, Debitoren/Kreditoren-Synchronisation, ggf. weitere Quellen (SharePoint, Mail, DMS) |
|
||||
| **Tuning** | Prompt-Tuning für die konkreten Use-Cases, Neutralisierungs-Regeln auf Kundenebene, Modellauswahl pro Operation |
|
||||
| **Schulung** | Onboarding Endanwender, Admin-Training, Enablement für Treuhand-Teams |
|
||||
| **Inbetriebnahme** | Pilotbetrieb, Abnahme, Go-Live, Hyper-Care, Hand-Over an Betrieb (Modeso / Abacus-Partnerbetrieb) |
|
||||
|
||||
Das macht ein JV-Angebot an einen Abacus-Endkunden **kalkulierbar und schnell umsetzbar** – ein Setup, das in Wochen, nicht in Quartalen live geht.
|
||||
|
||||
### 5.4 Warum das für Abacus strategisch interessant ist
|
||||
|
||||
1. **Keine Konkurrenz, echte Ergänzung:** PORTA schreibt in Abacus, es ersetzt es nicht. Abacus bleibt das System of Record.
|
||||
2. **Moderne UI-Schicht für Abacus-Kunden:** Treuhänder, die heute für KI-Features zu anderen Werkzeugen greifen, bleiben im Abacus-Ökosystem.
|
||||
3. **Generator für Beleg-Volumen in Abacus:** PORTA verarbeitet Scans, Spesen, Dokumente automatisch und erzeugt saubere Buchungen in Abacus. Das erhöht die Nutzungstiefe pro Abacus-Mandant.
|
||||
4. **Schweizer Stack Ende-zu-Ende:** Schweizer ERP (Abacus) × Schweizer KI-Plattform (PowerOn) × Schweizer Hosting (Modeso auf GCP CH) – ein seltenes Alleinstellungsmerkmal im Markt.
|
||||
5. **Datenschutz-Thema ist vorgelöst:** Der Neutralisierer ist für genau das Szenario gebaut, das Abacus-Kunden (KMU, Treuhand, Finanz) am meisten Sorge macht, wenn sie über KI nachdenken.
|
||||
|
||||
---
|
||||
|
||||
## 6. Mögliche Joint-Venture-Thesen
|
||||
|
||||
Zur Vorbereitung der nächsten Abacus-Gespräche – nicht abschliessend, sondern als Diskussionsgrundlage.
|
||||
|
||||
### These A — „Abacus als strategischer Go-To-Market-Kanal"
|
||||
PowerOn liefert das KI-/Workflow-Produkt, Abacus öffnet die Tür zur bestehenden Treuhand-/KMU-Kundschaft. Co-Marketing, gemeinsame Referenzkunden, Listing im Abacus-Ökosystem.
|
||||
|
||||
### These B — „Abacus-Branded KI-Layer"
|
||||
PORTA wird als Abacus-gelabeltes Modul („AbaAI", „Abacus Intelligence", o. ä.) angeboten. Abacus kontrolliert Pricing und Packaging gegenüber dem Endkunden, PowerOn bleibt die technische Plattform-Basis.
|
||||
|
||||
### These C — „Gemeinsame Produktentwicklung mit Fokus Treuhand"
|
||||
Tiefe Integration des PowerOn-Treuhand-Moduls mit Abacus AbaWeb/AbaNinja – inklusive Automation-Templates für typische Treuhand-Use-Cases (Kreditorenflut, Spesenimport, MwSt-Abstimmung, Mandats-Reporting).
|
||||
|
||||
### These D — „Beteiligung / Minderheits-Invest"
|
||||
Abacus beteiligt sich an der anstehenden Seed-Runde und sichert sich damit strategische Einflussmöglichkeiten, ohne PowerOn als eigenständiges Unternehmen zu vereinnahmen.
|
||||
|
||||
Alle vier Thesen sind kompatibel und können gestaffelt umgesetzt werden (A → C → B → ggf. D).
|
||||
|
||||
---
|
||||
|
||||
## 7. Empfohlene nächste Schritte
|
||||
|
||||
| # | Schritt | Owner | Zeithorizont |
|
||||
|---|---|---|---|
|
||||
| 1 | Technisches Deep-Dive: Live-Demo des Abacus-Connectors auf einer Abacus-Testinstanz | PowerOn (P. Motsch) × Abacus (Tech/Produkt) | 2 Wochen |
|
||||
| 2 | Gemeinsamer Pilot-Kunde aus dem Abacus-Treuhand-Segment | Abacus (Sales) × PowerOn (S. Schellworth) | 4–6 Wochen |
|
||||
| 3 | Strategie-Workshop zu JV-Modell (Thesen A–D) | beide GL | 4 Wochen |
|
||||
| 4 | NDA + DPA für vertiefte technische Zusammenarbeit | Legal beider Seiten | sofort |
|
||||
| 5 | Gemeinsamer Messeauftritt / Webinar Treuhand-KI | Marketing beider Seiten | Q3 2026 |
|
||||
|
||||
---
|
||||
|
||||
## 8. Kontakt
|
||||
|
||||
**PowerOn AG**
|
||||
Birmensdorferstrasse 94 · 8003 Zürich · Schweiz
|
||||
`www.poweron.swiss` · `info@poweron.swiss`
|
||||
|
||||
- **Patrick Motsch** – CEO / CTO – Produkt- und Technikthemen
|
||||
- **Stephan Schellworth** – Business Integration – Partnerschaften und Kundenintegration
|
||||
- **Ida Dittrich** – Product Architect – Architektur und Roadmap
|
||||
|
||||
---
|
||||
|
||||
*Dieses Dokument ist eine konsolidierte Aufbereitung des aktuellen Produkt- und Technikstands von PowerOn PORTA auf Basis der internen Wiki-Kanon-Seiten (`a-strategy/product-vision.md`, `a-strategy/product-strategy.md`, `b-reference/product.md`, `b-reference/gateway/architecture.md`, `b-reference/gateway/ai-agent.md`, `b-reference/platform/neutralization.md`, `e-compliance/security-overview.md`) sowie einer direkten Code-Verifikation im Gateway-Repository (Stand April 2026). Angaben ohne Gewähr – für verbindliche Zusicherungen gelten die jeweiligen Vertragsvereinbarungen.*
|
||||
100
docs/brochure-poweron-investor-clevel.md
Normal file
100
docs/brochure-poweron-investor-clevel.md
Normal file
|
|
@ -0,0 +1,100 @@
|
|||
# PowerOn – KI-gestützte Automatisierung
|
||||
*Fertiger Copy-Stand für Canva / PowerPoint / PDF-Export. 5 Folien.*
|
||||
|
||||
**Schreibweise:** durchgängig **PowerOn** (nicht PowerON).
|
||||
|
||||
---
|
||||
|
||||
## Folie 1 von 5 – Intro
|
||||
|
||||
### PowerOn
|
||||
|
||||
**KI, die Ihre Kapazität freisetzt.**
|
||||
|
||||
Von manuellen Prozessen zu KI-unterstützten Abläufen – schnell, konkret, sicher.
|
||||
|
||||
**www.poweron.swiss · info@poweron.swiss**
|
||||
|
||||
> **Visual-Hinweis:** Titel-Layout, PowerOn-Logo zentriert, keine Tabellen. Hintergrund clean, ggf. dezentes Grafik-Element.
|
||||
|
||||
---
|
||||
|
||||
## Folie 2 von 5 – Der Weg zur KI-gestützten Automatisierung
|
||||
|
||||
### Verschwenden Sie Ihre kostbare Kapazität nicht – steigern Sie Ihre Innovationskraft
|
||||
|
||||
**Von aufwendigen manuellen Prozessen zu KI-unterstützten automatisierten Prozessen**
|
||||
|
||||
| Schritt 1 | Schritt 2 | Schritt 3 | Schritt 4 |
|
||||
| --- | --- | --- | --- |
|
||||
| **Verstehen der spezifischen Anforderungen** | **Mögliche KI-Unterstützung identifizieren** | **Komplexität reduzieren** | **Vertrauenswürdige Informationen** |
|
||||
| Wir analysieren, welche Prozesse manuell, repetitiv oder fehleranfällig sind. | Wir prüfen, wo KI konkret unterstützen oder Aufgaben übernehmen kann. | Unnötige Schritte werden eliminiert und Schnittstellen vereinfacht. | Die KI arbeitet ausschliesslich mit geprüften, klar definierten Daten. |
|
||||
|
||||
**Manuell → Automatisiert**
|
||||
|
||||
### KI wird Ihr Assistent
|
||||
|
||||
| Daten-Extraktion | Fraud Detection | Compliance Check | Smarte Freigabe | Prozessführung |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Relevante Inhalte automatisch aus Dokumenten gewinnen | Auffälligkeiten frühzeitig erkennen | Regelwerke automatisiert prüfen | Freigabeprozesse mit KI-Empfehlung beschleunigen | Abläufe Schritt für Schritt begleiten |
|
||||
|
||||
**schnell – konkret**
|
||||
|
||||
> **Visual-Hinweis:** Vier Schritte als horizontaler Pfeil (links → rechts). Darunter die fünf KI-Outputs als Icon-Leiste. Claim „schnell – konkret" rechts unten.
|
||||
|
||||
---
|
||||
|
||||
## Folie 3 von 5 – Ihre Erfolgsstory – gezielt und fokussiert
|
||||
|
||||
| Ihre Herausforderung | Unser Vorgehen | Ihr Ergebnis |
|
||||
| --- | --- | --- |
|
||||
| Sie wissen, dass Digitalisierung und KI wichtig sind – aber nicht, wo Sie am wirkungsvollsten ansetzen. | **Fragebogen** – gezielte Vorerhebung Ihrer Ausgangslage | **Handlungsfelder mit Massnahmen** – Wo liegt der grösste Hebel? |
|
||||
| | **Interview** – vertiefte Analyse Ihrer Prozesse und Engpässe | **Kausalnetz mit Abhängigkeiten** – Welche Massnahmen bauen aufeinander auf? |
|
||||
| | **Initial-Workshop** – gemeinsame Erarbeitung mit Ihrem Team | **Priorisierte Umsetzungsroadmap** – In welcher Reihenfolge vorgehen? |
|
||||
| | **Analyse** – Synthese und Aufbereitung durch PowerOn | **Massnahmen-Steckbrief** – Jede Massnahme einzeln beschrieben und umsetzbar |
|
||||
| | | → **Digitalisierung** und **Einsatz von KI** |
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph vorgehen [Unser Vorgehen]
|
||||
Fragebogen --> Interview --> Workshop[Initial-Workshop] --> Analyse
|
||||
end
|
||||
subgraph ergebnis [Ihr Ergebnis]
|
||||
Analyse --> Handlungsfelder
|
||||
Handlungsfelder --> Kausalnetz
|
||||
Kausalnetz --> Roadmap[Priorisierte Roadmap]
|
||||
Roadmap --> Steckbrief[Massnahmen-Steckbrief]
|
||||
end
|
||||
```
|
||||
|
||||
> **Visual-Hinweis:** Drei-Spalten-Layout. Links: Fragezeichen-Symbolik für die Herausforderung. Mitte: Trichter von oben (Fragebogen) nach unten (Analyse). Rechts: Ergebnis-Artefakte als aufsteigende Liste.
|
||||
|
||||
---
|
||||
|
||||
## Folie 4 von 5 – Das halten Sie am Ende in der Hand
|
||||
|
||||
| Handlungsfelder mit Massnahmen | Kausalnetz – Massnahmen mit Abhängigkeiten |
|
||||
| --- | --- |
|
||||
| Identifizierte Bereiche mit konkreten Massnahmen, zugeordnet zu Ihren Geschäftszielen. | Visualisierung der Wechselwirkungen zwischen Massnahmen – inklusive Engpässe und Voraussetzungen. |
|
||||
|
||||
| Priorisierte Umsetzungsroadmap | Steckbrief je Massnahme |
|
||||
| --- | --- |
|
||||
| Zeitliche Abfolge mit klarer Priorisierung – von Quick Wins bis zu strategischen Initiativen. | Beschreibung, Ziel, Aufwand, Abhängigkeiten und nächste Schritte – pro Massnahme einzeln dokumentiert. |
|
||||
|
||||
> **Visual-Hinweis:** 2×2-Raster, vier gleichgrosse Kacheln. Jede Kachel mit Titel und einem Satz. Optional je ein abstraktes Icon.
|
||||
|
||||
---
|
||||
|
||||
## Folie 5 von 5 – Erfolgreicher Einsatz von KI
|
||||
|
||||
### Einsatz von KI
|
||||
|
||||
| Prinzip | Erklärung |
|
||||
| --- | --- |
|
||||
| **Datenschutz** | Keine sensitiven Daten gelangen nach aussen. Die Verarbeitung bleibt innerhalb klar definierter Grenzen. |
|
||||
| **Klar definierte Use-Cases** | KI wird nur dort eingesetzt, wo der Anwendungsfall geprüft und freigegeben ist. |
|
||||
| **Einfache Anbindung** | Bestehende Informationsquellen und Agentensysteme lassen sich ohne grossen Aufwand verbinden. |
|
||||
| **Vertrauensvoller, fairer Einsatz** | Die KI arbeitet nachvollziehbar. Ergebnisse sind überprüfbar, Entscheidungen bleiben beim Menschen. |
|
||||
| **Zugriff nur auf definierte Daten** | Die KI hat ausschliesslich Zugriff auf klar freigegebene Datenquellen – kein unkontrolliertes Training. |
|
||||
|
||||
> **Visual-Hinweis:** Zentrales Label „Einsatz von KI" in der Mitte. Die fünf Prinzipien als Kranz/Stern drumherum angeordnet – je mit Icon (Schloss, Zielscheibe, Stecker, Waage, Auge).
|
||||
347
docs/case-study-power-desktop.md
Normal file
347
docs/case-study-power-desktop.md
Normal file
|
|
@ -0,0 +1,347 @@
|
|||
# PowerOn Desktop
|
||||
*Der zentrale AI Workspace fuer Unternehmen, die produktiver, sicherer und schneller arbeiten wollen.*
|
||||
**Subline:** Ein Workspace. Alle Daten. Alle KI-Faehigkeiten.
|
||||
|
||||
---
|
||||
**1 von 16**
|
||||
|
||||
## Seite 1 - Cover
|
||||
*KI, Daten und Teamarbeit – ein gemeinsamer Arbeitsraum.*
|
||||
|
||||
PowerOn Desktop bringt KI, Daten und Teamarbeit in eine gemeinsame Arbeitsumgebung.
|
||||
Sie reduzieren Reibung im Alltag und schaffen messbaren Mehrwert ab dem ersten Use Case.
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erstelle eine moderne isometrische SaaS-Hero-Illustration eines digitalen Arbeitsplatzes. Zeige ein zentrales Dashboard mit verbundenen Modulen fuer Chat, Dokumente, Datenquellen und Automationen. Stil clean, hochwertig, C-Level-Praesentation. Farbpalette mit Primaerblau #1976d2, Tuerkis-Akzenten, Weiss und dezenten Grautoenen. Licht, Tiefe, klare Linien, keine Personenfotos. Kein Text im Bild. 16:9, hohe Aufloesung.
|
||||
|
||||
---
|
||||
**2 von 16**
|
||||
|
||||
## Seite 2 - Die Herausforderung
|
||||
*Wenn Wissen zerstreut ist, leidet die Wertschoepfung.*
|
||||
|
||||
In den meisten Unternehmen ist Wissen verteilt: Dateien, Mails, Fachsysteme und Meetings laufen nebeneinander.
|
||||
Teams springen zwischen Tools, verlieren Kontext und investieren zu viel Zeit in Suche statt in Entscheidungen.
|
||||
|
||||
**Typische Folgen:**
|
||||
- Lange Recherchezeiten bei jeder wichtigen Frage
|
||||
- Uneinheitliche Qualitaet in Ergebnissen
|
||||
- Hoehere Risiken bei Datenschutz und Compliance
|
||||
- KI bleibt auf einzelne Experimente begrenzt
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Visualisiere eine fragmentierte Unternehmenslandschaft mit vielen isolierten Dateninseln: Dokumente, E-Mail, CRM, Tabellen, Tickets. Verbinde sie nicht direkt, sondern zeige bewusst Brueche und Medienwechsel. Abstrakt, modern, minimalistisch, isometrischer Look. Farben: Grau fuer Fragmentierung, Akzente in Blau fuer Potenzial. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**3 von 16**
|
||||
|
||||
## Seite 3 - Die Loesung im Ueberblick
|
||||
*Vier Zugaenge, ein durchgaengiger Kontext.*
|
||||
|
||||
PowerOn Desktop schafft einen gemeinsamen Arbeitsraum fuer vier Kernaufgaben:
|
||||
- **Denken und abstimmen (AI Chat)** – Fragen, Entwuerfe, Abstimmung und Entscheidungsvorbereitung an einem Ort
|
||||
- **Inhalte umsetzen (Editor)** – Texte und Dokumente mit KI-Unterstuetzung bearbeiten, aber immer mit Ihrer Freigabe
|
||||
- **Wissen verbinden (Datenquellen)** – Dateien, Clouds und Fachsysteme als durchsuchbaren Kontext einbinden
|
||||
- **Prozesse beschleunigen (Workflows und Automation)** – Wiederkehrende Ablaeufe planbar ausfuehren und Ergebnisse wiederverwenden
|
||||
|
||||
**Warum das fuer Fuehrungsteams zaehlt:** Statt fuenf getrennte Tools entsteht ein durchgaengiger Arbeitsfluss. Der Kontext aus Chat, Dateien und Quellen bleibt erhalten. Teams sparen Such- und Abstimmungszeit, und Sie behalten die Steuerung darueber, welche Informationen ueberhaupt in die KI einfliessen.
|
||||
|
||||
**Typischer Ablauf im Alltag:** Information beschaffen (Quellen) – diskutieren und strukturieren (Chat) – Inhalt finalisieren (Editor) – bei Bedarf automatisieren (Workflows). Alles in derselben Instanz, ohne Export-Chaos und ohne Kontextverlust zwischen den Schritten.
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erstelle eine isometrische Uebersichtsillustration mit einem zentralen Hub und vier klar verbundenen Modulen: Chat, Editor, Data Sources, Automation. Datenstroeme sollen in beide Richtungen fliessen. Stil: enterprise SaaS, aufgeraeumt, premium, viel White Space. Farbsystem mit Blau #1976d2 als Leitfarbe, Tuerkis und Violett als Sekundaerfarben. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**4 von 16**
|
||||
|
||||
## Seite 4 - Arbeitsbereich 1: AI Chat
|
||||
*Strukturiert denken – mit nachvollziehbaren Antworten.*
|
||||
|
||||
Der AI Chat ist das Sprungbrett fuer den produktiven Einsatz von KI im Tagesgeschaeft. Teams nutzen ihn fuer Analyse, Formulierung, Zusammenfassungen und Entscheidungsvorbereitung – ohne dass Fachwissen in Prompt-Engineering ausarten muss.
|
||||
|
||||
**Was Entscheider schaetzen:** Antworten bleiben nachvollziehbar, weil Bezuege zu Quellen und Verarbeitungsschritten sichtbar werden. Das reduziert das Risiko von „halluzinierten“ Fakten und erleichtert interne Freigaben. Optional unterstuetzt Spracheingabe und Sprachausgabe – etwa fuer schnelle Notizen unterwegs oder barrierefreies Arbeiten.
|
||||
|
||||
**Konkrete Einsatzszenarien:** Erstentwurf fuer Kundenmail oder interne Mitteilung; Strukturierung eines Meetings oder eines Projektbriefings; Einordnung einer laengeren Unterlage mit klaren Bezugspunkten; Vorbereitung einer Praesentation aus gebundenem Kontext statt aus dem Gedaechtnis.
|
||||
|
||||
**Im Workspace sichtbar:** Verlauf der Unterhaltung, Anhaenge und Dateibezuege, nachvollziehbare Zwischenschritte bei komplexeren Anfragen – damit bleibt nachvollziehbar, *wie* ein Ergebnis zustande kam.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Schnellere Erstentwuerfe fuer Mails, Konzepte und Entscheidungen
|
||||
- Weniger Rueckfragen durch besser strukturierten Kontext
|
||||
- Hoehere Vertrauenswuerdigkeit durch nachpruefbare Herkunft von Inhalten
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Gestalte eine abstrakte Chat-UI-Illustration mit links-rechts angeordneten Nachrichtenblasen, Quellensymbolen und einem dezenten Sprachsymbol fuer Voice-Interaktion. Keine echten Markenlogos. Design modern, klar, professionell. Helle Flaechen mit blauen Akzenten (#1976d2), leichte Tiefenwirkung. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**5 von 16**
|
||||
|
||||
## Seite 5 - Arbeitsbereich 2: Editor
|
||||
*Schnelligkeit der KI – mit Ihrer letzten Freigabe.*
|
||||
|
||||
Im Editor werden KI-Vorschlaege nicht blind uebernommen, sondern kontrolliert geprueft. Aenderungen erscheinen im direkten Vergleich (Vorher und Nachher). Sie entscheiden pro Abschnitt oder gesamt: annehmen, ablehnen oder nachjustieren – analog zu professionellen Review-Prozessen in Recht, Compliance oder Technikredaktion.
|
||||
|
||||
**Warum das strategisch relevant ist:** Unternehmen wollen Tempo *und* Kontrolle. Der Editor verbindet beides: KI liefert Vorschlaege in grosser Geschwindigkeit, Ihre Organisation behaelt die letzte Instanz. Das senkt das Risiko ungewollter Formulierungen oder inhaltlicher Fehler in nach aussen gerichteten Dokumenten.
|
||||
|
||||
**Fuer wen besonders wertvoll:** Fachbereiche mit verbindlichen Texten (Vertraege, Richtlinien, Angebote), Projektleitungen mit Spezifikationen, Qualitaetssicherung und alle Teams, die wiederkehrend aehnliche Dokumente anpassen muessen.
|
||||
|
||||
**Mehrstufige Aufgaben:** Fuer umfangreichere Bearbeitungen kann die KI in einem gefuehrten Ablauf mehrere Schritte vorschlagen – stets mit der Moeglichkeit, vor der Uebernahme zu pruefen. So bleibt Effizienz mit Governance vereinbar.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Schnellere Bearbeitung von Dokumenten und Fachtexten bei gleichzeitiger Freigabe-Logik
|
||||
- Weniger Korrekturschleifen durch klare Sicht auf jede Aenderung
|
||||
- Skalierbare Qualitaet bei Standarddokumenten und Vorlagen
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erstelle eine elegante Side-by-Side-Editor-Illustration mit Vorher-Nachher-Ansicht, farblich markierten Aenderungen und klaren Aktionsflaechen fuer Accept/Reject. Stil: clean enterprise software concept art, isometrisch oder halb-isometrisch. Dunkles Editorpanel kombiniert mit hellem UI-Rahmen. Primaerblau #1976d2, Akzentgruen und Rot sehr dezent. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**6 von 16**
|
||||
|
||||
## Seite 6 - Arbeitsbereich 3: Datenquellen
|
||||
*Ihre Systeme werden zum nutzbaren Wissensraum.*
|
||||
|
||||
PowerOn Desktop verbindet bestehende Systeme mit dem Arbeitskontext Ihrer Teams. Typische Anbindungen umfassen etwa Microsoft 365 (SharePoint, OneDrive, Outlook, Teams), Google (Drive, Gmail), Ticketsysteme wie Jira oder ClickUp, sowie FTP und branchenspezifische Fachsysteme – jeweils dort, wo Ihre Organisation bereits arbeitet.
|
||||
|
||||
**Zwei praktische Ebenen:** Zum einen **persoenliche Quellen** des Nutzers (z. B. eigene Cloud-Bereiche), zum anderen **Quellen der konkreten Workspace-Instanz** und mandantenbezogene Daten – immer abgestimmt auf Ihre Rollen- und Freigaberegeln. Zusaetzlich koennen Dateien direkt im Workspace abgelegt, strukturiert und fuer die KI-Nutzung bereitgestellt werden (inkl. Drag-and-Drop).
|
||||
|
||||
**Der Effekt fuer den Alltag:** Statt Informationen manuell zu suchen, zusammenzukopieren und in einen Chat zu pasten, entsteht ein **durchsuchbarer Wissensraum**. Die KI bezieht sich auf Inhalte, die Sie bewusst freigegeben haben – nicht auf ein undurchsichtiges „Internet-Gedaechtnis“.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Entscheidungen und Antworten basieren auf *Ihren* Unterlagen, nicht auf Vermutungen
|
||||
- Deutlich weniger Medienbrueche und Copy-Paste zwischen Systemen
|
||||
- Schnellere Einarbeitung neuer Mitarbeitender durch einen klaren, gebundenen Wissenszugang
|
||||
- Weniger Risiko veralteter oder falscher Versionen, weil der Bezug zur Quelle erhalten bleibt
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Visualisiere mehrere Unternehmensdatenquellen als abstrahierte Knoten (Dokumente, Cloud, Tickets, Mail) die in einen zentralen AI-Workspace-Hub fliessen. Zeige Struktur und Ordnung statt Chaos. Stil modern, isometrisch, B2B-Marketing. Farben: Blau #1976d2, Gruen fuer externe Quellen, Violett fuer Feature-Daten, neutraler Hintergrund. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**7 von 16**
|
||||
|
||||
## Seite 7 - Arbeitsbereich 4: Workflows und Automation
|
||||
*Standardisierte Ablaeufe – transparent ausgefuehrt.*
|
||||
|
||||
Wiederkehrende Aufgaben werden als Workflows **einmal** sinnvoll definiert und danach **zuverlaessig** ausgefuehrt – manuell gestartet oder nach Plan. Das ist besonders relevant fuer wiederkehrende Reports, Datenaufbereitungen, Qualitaetschecks oder vorbereitende Schritte vor menschlicher Freigabe.
|
||||
|
||||
**Transparenz statt Blackbox:** Laufende und abgeschlossene Ausfuehrungen sind nachvollziehbar dokumentiert (Live-Logs und Status). Fuehrungskraefte sehen, *dass* und *wie* Automatisierung laeuft – wichtig fuer Vertrauen und interne Kontrolle.
|
||||
|
||||
**Rueckkopplung in den Workspace:** Ergebnisse aus Workflows werden nicht „irgendwo abgelegt“, sondern koennen als neuer Kontext fuer Chat, Editor und weitere Schritte dienen. So schliesst sich der Kreis von ad-hoc-Arbeit und standardisierten Ablaeufen.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Hoehere Prozessgeschwindigkeit bei gleichbleibender Qualitaet und weniger manuellen Fehlern
|
||||
- Entlastung von Teams bei Routinethemen; mehr Kapazitaet fuer Urteils- und Beziehungsarbeit
|
||||
- Bessere Skalierung ueber Teams, Standorte und Zeitzonen hinweg
|
||||
- Einheitliche Standards statt Inselloesungen („jeder macht es anders“)
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erstelle eine moderne Workflow-Illustration mit mehreren Prozessstufen, KI-Knoten und Rueckkopplung in ein zentrales Dashboard. Zeige klare Richtungspfeile, modulare Bausteine und Statusindikatoren. Stil: clean, enterprise, minimalistisch-isometrisch. Farbpalette mit Blau #1976d2 und Tuerkis-Akzenten. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**8 von 16**
|
||||
|
||||
## Seite 8 - USP: Intelligente Wissenssuche in drei Ebenen
|
||||
*Das passende Wissen zur richtigen Zeit – ohne Rauschen.*
|
||||
|
||||
Stellen Sie sich drei **Schubladen** vor, die Ihre Organisation ohnehin kennt – nur dass sie hier technisch sauber getrennt und fuer die KI nutzbar gemacht werden:
|
||||
|
||||
- **Persoenlich:** Notizen, Entwuerfe und Dateien, die dem einzelnen Nutzer zuordenbar sind und nicht automatisch das ganze Team exponieren.
|
||||
- **Team / Instanz:** Alles, was zu einem konkreten Projekt, einem Mandat-Workspace oder einer definierten Arbeitsgruppe gehoert – der gemeinsame Tisch fuer diesen Use Case.
|
||||
- **Mandat / Unternehmen:** Von der Organisation freigegebenes Wissen (Richtlinien, Vorlagen, Standards), das breiter – aber weiterhin regelkonform – genutzt werden darf.
|
||||
|
||||
**Warum das mehr ist als „eine grosse Datenbank“:** Bei jeder Anfrage wird der **sinnvolle Ausschnitt** aus diesen Ebenen zusammengefuehrt. Antworten werden relevanter, Rauschen sinkt, und Sie vermeiden das typische Problem generischer KI-Tools: zu viel oder zu wenig Kontext, falsch gemischt.
|
||||
|
||||
**Fuer die Geschaeftsfuehrung:** Das Modell spiegelt reale Verantwortlichkeiten wider (individuell, teambezogen, unternehmensweit). So laesst sich KI-Nutzung **governancetauglich** erklaeren und auditieren – statt als undifferenzierte „alles-in-einen-Topf“-Loesung.
|
||||
|
||||
**Das Ergebnis im Alltag:** Schnellere, treffsichere Antworten, weniger irrelevante Treffer, klarere Grenzen zwischen privatem Arbeitskontext und geteiltem Wissen.
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Gestalte eine abstrakte 3-Ebenen-Architektur als konzentrische Kreise oder gestapelte Ebenen: personal, team-instance, mandate-enterprise. Daten sollen von unten nach oben intelligent selektiert werden. Premium-SaaS-Look, klare Geometrie, moderne Schattierung. Blau #1976d2 als Hauptfarbe, Tuerkis und Violett fuer Ebenenunterscheidung. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**9 von 16**
|
||||
|
||||
## Seite 9 - USP: Privacy Shield
|
||||
*Sensibel bleibt sensibel – auch mit KI.*
|
||||
|
||||
Datenschutz wird nicht erst in der Rechtsabteilung „nachgebessert“, sondern direkt im Arbeitsprozess verankert. **Privacy Shield** steht fuer eine kontrollierte Vorverarbeitung: Personenbezogene und besonders sensible Angaben (z. B. Namen, Kontaktdaten, typische Identifikatoren) koennen **vor** der eigentlichen KI-Verarbeitung geschuetzt werden, sodass weniger Rohdaten nach aussen gelangen.
|
||||
|
||||
**Was das praktisch bedeutet:** Teams arbeiten weiter mit echten Inhalten im Workspace. Fuer die Verarbeitung durch externe oder interne Modelle werden nur die Teile genutzt, die Sie policykonform freigeben. Ergebnisse bleiben dennoch inhaltlich nutzbar, weil die Zuordnung im geschuetzten Umfeld wiederhergestellt werden kann – ohne dass der Nutzer jedes Mal manuell anonymisieren muss.
|
||||
|
||||
**Gespraech mit Datenschutz und Compliance:** Sie koennen zeigen, *welche* Kategorie von Daten geschuetzt wird, *wann* das greift und *wer* welche Freigaben hat. Das erhoeht die Akzeptanz bei Datenschutzbeauftragten, Arbeitnehmervertretungen und Kunden mit strengen Auflagen.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- KI-Einsatz auch dort moeglich, wo sensible Inhalte allgegenwaertig sind (HR, Kundenakten, Vertraege)
|
||||
- Geringeres regulatorisches und Reputationsrisiko bei schneller Pilotierung
|
||||
- Hoeheres Vertrauen von Vorstand, Aufsicht und externen Pruefern
|
||||
- Weniger „Schatten-KI“, weil der offizielle Weg sicher genug ist, um genutzt zu werden
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erzeuge eine abstrakte Cyber-Security-Illustration mit einem Schutzschild zwischen Datenstrom und KI-Kern. Zeige, dass sensible Daten vor Verarbeitung geschuetzt werden. Stil: clean, modern, enterprise trust visual. Keine Bedrohungs-Optik, sondern kontrollierte Sicherheit und Governance. Farben: Blau #1976d2, Tuerkis, dezentes Silber/Grau. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**10 von 16**
|
||||
|
||||
## Seite 10 - USP: Mandanten-Isolation
|
||||
*Klare Grenzen – technisch abgebildet, nicht nur organisatorisch gewuenscht.*
|
||||
|
||||
Jeder **Mandant** – sei es ein Kunde, eine Tochtergesellschaft oder eine klar abgegrenzte Organisationseinheit – arbeitet in einem **eigenen, logisch getrennten Datenraum**. Daten und Wissensbestaende vermischen sich nicht zwischen Mandanten, selbst wenn dieselbe Plattform genutzt wird.
|
||||
|
||||
**Typische Traeger dieser Anforderung:** Treuhand und Revision, Beratung mit mehreren Auftraggebern, Konzerne mit strikten Firewalls zwischen Sparten, sowie jede Organisation, die **Vertraulichkeit** als Verkaufsargument oder gesetzliche Pflicht versteht.
|
||||
|
||||
**Need-to-know auf Plattform-Ebene:** Nutzer sehen nur, was ihre Rolle und ihr Mandat erlauben. Das unterstuetzt interne Kontrollsysteme und erleichtert die Kommunikation mit externen Pruefern: Trennung ist nicht nur organisatorisch gewuenscht, sondern **technisch abgebildet**.
|
||||
|
||||
**Skalierung ohne Grenzverlust:** Neue Mandanten oder neue Projekte lassen sich hinzufuegen, ohne bestehende Sicherheits- und Vertraulichkeitsmodelle zu verwaessern. Das ist ein Wachstumshebel fuer Dienstleister und fuer Konzerne mit komplexer Struktur.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Eignung fuer Multi-Client- und Multi-Brand-Setups ohne Datenvermischung
|
||||
- Deutlich reduziertes Risiko von Vertraulichkeitsverletzungen und „falschen“ Zugriffen
|
||||
- Bessere Argumentationsgrundlage gegenueber Kunden, die Trennschaerfe verlangen
|
||||
- Kontrollierbares Wachstum: mehr Nutzung, nicht mehr Risiko pro Nutzer
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Visualisiere mehrere sauber getrennte Datenbereiche als leuchtende, voneinander isolierte Cluster oder Glas-Container, jeweils mit eigenem Zugangspfad. Zeige Ordnung, Trennung und Sicherheit in einer modernen Enterprise-Aesthetik. Farben: Blau #1976d2 als verbindendes System, unterschiedliche Akzentfarben pro Mandant. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**11 von 16**
|
||||
|
||||
## Seite 11 - USP: Datenkontrolle durch den Nutzer
|
||||
*Sie steuern, welcher Kontext zaehlt – ohne stillschweigende Weitergabe.*
|
||||
|
||||
Mit **klaren Sichtbarkeitsstufen** entscheiden Nutzer und Rolleninhaber aktiv, welche Inhalte in welchem Kontext fuer die KI nutzbar sind. Es gibt **keine stillschweigende** Weitergabe: Was geteilt wird, wird bewusst eingestellt – beim Einbinden von Dateien, Ordnern oder Quellen.
|
||||
|
||||
**Die vier Stufen in Klartext:**
|
||||
- **Persoenlich:** Nur fuer den anlegenden Nutzer sichtbar und nutzbar – ideal fuer Entwuerfe und persoenliche Arbeitsunterlagen.
|
||||
- **Instanzbezogen:** Fuer alle, die Zugriff auf genau diese Workspace-Instanz haben – typisch fuer Projekt- oder Teamarbeitsraeume.
|
||||
- **Mandatsweit:** Fuer die gesamte Mandantenorganisation freigegeben – etwa Richtlinien, die jeder mit Mandatszugang nutzen darf.
|
||||
- **Global (kontrolliert):** Plattformweite Referenzinhalte, typischerweise **stark reglementiert** und oft nur lesend – z. B. offizielle Standards, die zentral gepflegt werden.
|
||||
|
||||
**Zusaetzliche Hebel:** Inhalte koennen mit einer **Schutz-Option** markiert werden (Vorverarbeitung / Neutralisierung), bevor sie in die KI-Pipeline gehen. Aenderungen an Sichtbarkeit oder Schutz koennen eine Neu-Einordnung im Wissensindex erfordern – damit bleibt das System konsistent mit Ihren Regeln.
|
||||
|
||||
**Warum das Fuehrungskraefte interessiert:** Sie reduzieren **Fehlbedienung** und **Social Engineering** im weitesten Sinne – nicht jede Datei landet aus Versehen im falschen Kontext. Datenschutz und Informationsklassifikation werden **operationalisierbar**, nicht nur Policy-Papier.
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erstelle eine abstrakte Control-Panel-Illustration mit Scope-Umschaltern, Toggle-Elementen und klaren Zugriffsebenen. Fokus auf User-Kontrolle und Transparenz. Stil: reduziertes High-End SaaS Interface Concept, flach-isometrisch, aufgeraeumt. Primaerfarbe Blau #1976d2, Akzente in Tuerkis und Violett. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**12 von 16**
|
||||
|
||||
## Seite 12 - USP: Multi-Model AI Orchestrierung
|
||||
*Flexibilitaet im Modellmarkt – unter Ihren Freigaben und Richtlinien.*
|
||||
|
||||
PowerOn Desktop ist **nicht** an einen einzelnen KI-Anbieter gebunden. Hinter den Kulissen waehlt die Plattform passend zur Aufgabe: mal ein Modell, das besonders gut bei **langer Textarbeit** ist, mal eines fuer **schnelle Antworten**, mal Spezialfaehigkeiten fuer **Bildanalyse** oder **Strukturierung** – immer im Rahmen Ihrer Freigaben und Richtlinien.
|
||||
|
||||
**Was das fuer Einkauf und IT bedeutet:** Sie vermeiden **Single-Source-Abhaengigkeiten** und behalten Verhandlungsmacht. Wenn ein Anbieter Preise aendert, Qualitaet schwankt oder Verfuegbarkeit leidet, ist die Plattform darauf vorbereitet, **auszuweichen** – ohne dass Endanwender sofort umlernen muessen.
|
||||
|
||||
**Betrieb und Risiko:** Ausfallsicherheit steigt, weil kritische Pfade nicht von einem einzigen Dienst abhaengen. Gleichzeitig laesst sich **Kosten und Leistung** feiner steuern: teurere Modelle dort, wo der Mehrwert hoch ist; sparsamere Varianten bei einfachen Routinefragen.
|
||||
|
||||
**Governance bleibt obenauf:** Welche Modelle wer nutzen darf, bleibt **rollen- und mandantenbezogen** steuerbar – Innovation ohne Kontrollverlust.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Strategische Flexibilitaet in einem sich schnell veraendernden KI-Markt
|
||||
- Bessere Ergebnisqualitaet, weil Werkzeug und Aufgabe zusammenpassen
|
||||
- Hoehere Verfuegbarkeit und Resilienz im Tagesbetrieb
|
||||
- Transparente Kostenlogik statt undurchsichtiger Flatrates ohne Steuerung
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Visualisiere mehrere abstrakte KI-Modelle als unterschiedliche Rechenkerne, die in einen zentralen Orchestrator laufen. Zeige Lastverteilung, Routing und Ausfallsicherheit. Stil: futuristisch, aber business-tauglich, clean und nicht verspielt. Farbschema: Blau #1976d2, Cyan, Violett, dunkler Hintergrund mit sanften Highlights. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**13 von 16**
|
||||
|
||||
## Seite 13 - USP: Swiss Made, Governance und Compliance
|
||||
*Innovation mit Leitplanken – fuer Vorstand, Aufsicht und Pruefer nachvollziehbar.*
|
||||
|
||||
PowerOn Desktop verbindet **Innovationsgeschwindigkeit** mit **klaren Governance-Leitplanken**. Als Schweizer Anbieter adressieren wir den Erwartungsstandard vieler mittelstaendischer und grosser Organisationen: Qualitaet, Verlaesslichkeit und ein angemessener Umgang mit Datenschutz (DSG) und – wo relevant – DSGVO.
|
||||
|
||||
**Was „Governance“ hier konkret heisst:**
|
||||
- **Rollen und Rechte:** Wer darf welche Features, Datenquellen und KI-Modelle nutzen?
|
||||
- **Nachvollziehbarkeit:** Welche Schritte und Quellen haben zu einem Ergebnis beigetragen – zumindest dort, wo es fuer interne Kontrolle noetig ist?
|
||||
- **Mandanten- und Instanzlogik:** Klare Grenzen zwischen Organisationen, Projekten und persoenlichem Raum.
|
||||
- **Betriebsreife:** Kein reines „Labor-Tool“, sondern eine Struktur, mit der sich KI **breit** ausrollen laesst.
|
||||
|
||||
**Fuer Vorstand und Aufsicht:** Sie erhalten eine erzaehlbare Geschichte: KI ist eingebettet in Regeln, Trennungen und Freigaben – nicht eine anonyme Chat-Box aus dem Internet. Das erleichtert Freigaben, Versicherungs- und Partnerfragen sowie die Zusammenarbeit mit externen Pruefern.
|
||||
|
||||
**Business-Nutzen:**
|
||||
- Verlaessliche Grundlage fuer strategische KI-Programme und Budgetentscheide
|
||||
- Bessere Auditierbarkeit in sensiblen Bereichen (Finance, Legal, HR, Kundenprojekte)
|
||||
- Weniger Schatten-KI, weil der offizielle Weg attraktiv *und* sicher ist
|
||||
- Staerkere Positionierung gegenueber Kunden und Partnern, die Compliance explizit einfordern
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erstelle eine hochwertige Compliance-Illustration mit Schweizer Referenz (abstrakte Alpenlinie oder dezente Swiss-Form), Security-Symbolen, Audit-Pfaden und Governance-Elementen. Stil: premium corporate, clean, vertrauensvoll, modern. Farben: Blau #1976d2, Weiss, dezentes Rot als kleiner Akzent. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**14 von 16**
|
||||
|
||||
## Seite 14 - Business Impact
|
||||
*Zeit, Qualitaet, Skalierung, Compliance – messbar adressiert.*
|
||||
|
||||
PowerOn Desktop liefert Wirkung in vier strategischen Dimensionen:
|
||||
|
||||
**1) Zeitgewinn**
|
||||
- Schnellere Informationssuche und Entscheidungsvorbereitung
|
||||
- Weniger Tool-Wechsel und manuelle Zwischenschritte
|
||||
|
||||
**2) Qualitaet**
|
||||
- Konsistentere Ergebnisse durch gemeinsamen Kontext
|
||||
- Hoehere Nachvollziehbarkeit durch Quellen und Prozesssicht
|
||||
|
||||
**3) Skalierung**
|
||||
- Wiederverwendbare Workflows statt Einzelfallarbeit
|
||||
- Schnellere Uebertragung von Best Practices zwischen Teams
|
||||
|
||||
**4) Compliance**
|
||||
- Strukturierte Datenkontrolle und klare Rollenlogik
|
||||
- Bessere Grundlage fuer interne und externe Pruefungen
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Gestalte eine moderne Business-Impact-Illustration mit vier gleichwertigen Saeulen oder KPI-Kacheln: Geschwindigkeit, Qualitaet, Skalierung, Compliance. Zeige positive Dynamik, klare Struktur und Executive-Level-Aesthetik. Farben: Blau #1976d2 dominiert, Tuerkis und Violett als Sekundaerakzente, heller Hintergrund. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**15 von 16**
|
||||
|
||||
## Seite 15 - So starten Sie
|
||||
*Vom ersten Gespraech bis zum messbaren Ergebnis – in vier Schritten.*
|
||||
|
||||
Ein erfolgreicher Einstieg folgt einem klaren, risikoarmen Vorgehen:
|
||||
|
||||
1. **Discovery Call (30 Min.)**
|
||||
Ziele, Prioritaeten und kritische Use Cases abstimmen.
|
||||
2. **Workspace Blueprint**
|
||||
Datenquellen, Rollen und Governance-Rahmen definieren.
|
||||
3. **MVP in kurzer Zeit**
|
||||
Ein produktiver Kern-Use-Case mit messbarem Ergebnis.
|
||||
4. **Scale-Up**
|
||||
Weitere Teams, Prozesse und Automationen schrittweise ausrollen.
|
||||
|
||||
Dieser Ansatz schafft schnelle Erfolge ohne strategische Ueberdehnung.
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Erzeuge eine visuelle Roadmap mit vier klaren Etappen von links nach rechts: Discover, Blueprint, MVP, Scale. Nutze abstrakte Milestones, verbindende Linien und Fortschrittsdynamik. Stil: hochwertig, clean, enterprise consulting look. Farben: Blau #1976d2, Tuerkis-Akzente, viel Luft und Ordnung. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
**16 von 16**
|
||||
|
||||
## Seite 16 - Kontakt und Team
|
||||
*Ihr Einstieg in PowerOn Desktop – persoenlich und strukturiert.*
|
||||
|
||||
**PowerOn AG**
|
||||
Birmensdorferstrasse 94, 8003 Zuerich (CH)
|
||||
[www.poweron.swiss](https://www.poweron.swiss)
|
||||
|
||||
**Team**
|
||||
- Patrick Motsch - CEO/CTO
|
||||
- Ida Dittrich - Product Architect
|
||||
- Stephan Schellworth - Business Integration
|
||||
|
||||
Wenn Sie KI im Tagesgeschaeft produktiv und kontrolliert verankern wollen, starten wir mit einem klaren ersten Schritt.
|
||||
|
||||
> **BILD-PROMPT (Nano Banana Pro):**
|
||||
> Gestalte ein minimalistisches, professionelles Abschlussvisual fuer ein B2B-Pitchdeck: abstraktes Team-/Unternehmensmotiv mit einem zentralen Hub, verbundenen Punkten und vertrauensvoller Corporate-Atmosphaere. Stil clean, modern, hochwertig, nicht verspielt. Farbpalette: Blau #1976d2, Weiss, dezentes Grau, leichter Tuerkis-Akzent. Kein Text im Bild. 16:9.
|
||||
|
||||
---
|
||||
|
||||
## Keywords / Tags
|
||||
|
||||
PowerOn Desktop, AI Workspace, intelligente Wissenssuche, Datenschutz, Privacy Shield, Mandanten-Isolation, Datenkontrolle, Multi-Model AI, Workflow Automation, C-Level KI-Strategie, DSG, DSGVO, Swiss Made, Governance, Compliance, Datenquellen, Enterprise SaaS
|
||||
217
docs/case-study-poweron-48h-agent.md
Normal file
217
docs/case-study-poweron-48h-agent.md
Normal file
|
|
@ -0,0 +1,217 @@
|
|||
# Case Study (Illustration / Template): PowerOn Launch48
|
||||
|
||||
**Wichtig:** Das **primaere Kundenangebot** zum Weitergeben ist **[poweron-launch48-offer.md](./poweron-launch48-offer.md)** – verstaendlich fuer Management und Fachbereiche.
|
||||
**Dieses Dokument** dient **nicht** als erstes Verkaufs-PDF: Es ist ein **Beispiel-Verlauf / Pilot-Template** zur Vertiefung, sobald Sie Referenzgeschichten brauchen. Alle **Kundendaten, Branche und Kennzahlen** sind **fiktiv oder anonymisiert**, bis ein reales Projekt mit schriftlicher Freigabe vorliegt.
|
||||
**Referenz fuer Liefermethodik:** AI-augmented Engineering (vergleichbar der dokumentierten **Abraxas DATA Hub Migration** – Kundennennung in oeffentlichen Materialien nur mit Freigabe).
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Ausgangslage (Beispiel):** Ein **mittelstaendisches Dienstleistungsunternehmen** (anonymisiert) hatte wiederkehrende **Kundenanfragen zu Vertrags- und Leistungsinhalten**, die heute aus **PDF-Handbuechern, E-Mail-Templates und internen Notizen** manuell beantwortet werden. Die Bearbeitungszeit pro Anfrage war hoch, die Qualitaet von der Erfahrung der jeweiligen Person abhaengig.
|
||||
|
||||
**PowerOn** fuehrte mit dem Paket **Launch48** einen **48-Stunden-Block** auf der **PowerOn-Plattform** durch. Ergebnis (Zielbild des Templates): **ein produktiv einsetzbarer KI-Assistent** mit angebundenen **internen Quellen**, definierter **Pilotgruppe** und **vereinbarten Erfolgszielen** fuer die zweite Zahlungsstufe.
|
||||
|
||||
**Kernresultat (Illustration):** Von **Kickoff** bis **Uebergabe** **2 Arbeitstage** intensiver Umsetzung; schneller **Mehrwert im Pilot** statt monatelanger Vorlauf; laufende **Pruefung durch Ihre Fachexpertinnen und Experten** fuer Qualitaet und Compliance.
|
||||
|
||||
---
|
||||
|
||||
## Projekteckdaten
|
||||
|
||||
| Aspekt | Detail (Template / anonymisiert) |
|
||||
| --- | --- |
|
||||
| **Kunde** | Anonymisiertes Dienstleistungsunternehmen, deutschsprachige Schweiz |
|
||||
| **Plattform** | PowerOn (Power Desktop / AI Workspace, Datenquellen, Automation) |
|
||||
| **Use-Case** | Erstbeantwortung und Strukturierung von wiederkehrenden Fachanfragen aus freigegebenen internen Unterlagen |
|
||||
| **Sprint-Dauer** | 48 Stunden gebundene Umsetzung (plus Vorlauf fuer Gates) |
|
||||
| **Umfang** | 1 Agent/Workflow, 3 Wissensquellen (Beispiel), 1 Integration (Beispiel: internes Ticket-Read) |
|
||||
| **PowerOn Team** | Patrick Motsch (Technische Leitung), Ida Dittrich (Architektur), Stephan Schellworth (Projektsteuerung) |
|
||||
| **Kunde Team** | Fach-Owner, IT-Ansprechpartner, 10 Pilotnutzer (Beispiel) |
|
||||
|
||||
---
|
||||
|
||||
## Die Herausforderung
|
||||
|
||||
### Fachliche und technische Ausgangslage
|
||||
|
||||
- **Wissen verteilt** in PDFs, geteilten Ablagen und persoenlichen Entwuerfen.
|
||||
- **Kein einheitlicher Erstkontakt**: Mitarbeitende formulieren Antworten neu – Inkonsistenz und laengere Durchlaufzeiten.
|
||||
- **Datenschutz**: Kundenbezogene Details duerfen nicht in generische KI-Tools ohne Kontrolle.
|
||||
|
||||
### Business Impact der Ausgangslage
|
||||
|
||||
- Hoher **Zeitaufwand** pro Standardanfrage.
|
||||
- **Skalierungsbremse** bei Wachstum (Onboarding neuer Mitarbeitender).
|
||||
- **Risiko** unterschiedlicher Antwortqualitaet und laengerer Reaktionszeiten.
|
||||
|
||||
---
|
||||
|
||||
## Der PowerOn-Ansatz
|
||||
|
||||
### AI-Augmented Delivery auf der Plattform
|
||||
|
||||
PowerOn setzt auf **Human-in-the-Loop**: KI beschleunigt Aufbau und Iteration, **Architektur und Freigaben** bleiben beim erfahrenen Team und beim Kunden.
|
||||
|
||||
**Kernprinzip:** Schnelligkeit durch KI-gestuetzte Umsetzung, **Qualitaet** durch Reviews, **Governance** durch PowerOn-Faehigkeiten (Quellen, Rollen, nachvollziehbare Ablaeufe).
|
||||
|
||||
### Phase 1: Use-Case & Impact (Vorlauf + Sprint-Start)
|
||||
|
||||
**Aktivitaeten:**
|
||||
|
||||
- Priorisierung eines **einzigen** Kernprozesses.
|
||||
- Definition von **3 KPIs** (z. B. Zeit pro Vorgang, Pilot-Zufriedenheit, Fehlerindikator).
|
||||
- Scope-Freeze fuer den Fixpreis.
|
||||
|
||||
**Deliverables:**
|
||||
|
||||
- Schriftliche **Scope- und KPI-Spezifikation**.
|
||||
- **Go/No-Go** nach Compliance-Freigabe.
|
||||
|
||||
### Phase 2: Wissensbasis
|
||||
|
||||
**Aktivitaeten:**
|
||||
|
||||
- Anbindung von **Handbuch-PDFs**, **FAQ-Dokument** und **freigegebenem SharePoint-Ordner** (Beispiel).
|
||||
- Zuordnung zu **Instanz-/Mandantenlogik** gemaess Rollen.
|
||||
|
||||
**Deliverables:**
|
||||
|
||||
- Indexierte Quellen im PowerOn-Workspace.
|
||||
- Kurz-Dokumentation, welche Inhalte **nicht** im Agent-Kontext liegen (Grenzen).
|
||||
|
||||
### Phase 3: Tools & Anbindung
|
||||
|
||||
**Aktivitaeten:**
|
||||
|
||||
- **Eine** Integration im vereinbarten Umfang: z. B. **Lesen** von Ticket-Metadaten fuer Kontext (kein Schreiben in Produktion im Template-Beispiel).
|
||||
- Festlegung von **Freigaben** und Testfaellen.
|
||||
|
||||
**Deliverables:**
|
||||
|
||||
- Funktionsfaehiger Integrationspfad in der Pilotumgebung.
|
||||
- Testprotokoll (Grundfaelle).
|
||||
|
||||
### Phase 4: 48h Build-Sprint
|
||||
|
||||
**Aktivitaeten:**
|
||||
|
||||
- Gemeinsame Umsetzung mit **Pairing** (Kunde + PowerOn).
|
||||
- Iterative Tests mit **realistischen Anfragen**.
|
||||
- **Runbook** und **Handover**.
|
||||
|
||||
**Deliverables:**
|
||||
|
||||
- **Einsatzbereiter Agent/Workflow** im Pilot.
|
||||
- **Runbook** + Enablement-Session.
|
||||
|
||||
---
|
||||
|
||||
## Execution – Das Herzstueck
|
||||
|
||||
1. **Strukturierte Zielvorgaben** aus Phase 1–3.
|
||||
2. **Plattformnahe Umsetzung** (kein „einmaliger Skript-Hack“ ausserhalb des Betriebsmodells).
|
||||
3. **Validierung** durch Fach-Owner und Architektur-Review.
|
||||
4. **Test mit Pilotnutzern** vor KPI-Messfenster.
|
||||
|
||||
**Effizienzgewinn (Illustration):** Statt mehrwoechiger interner Experimentierphase entsteht in **48 Stunden** ein **abnahmefaehiger** Pilot mit klarer Messgroesse.
|
||||
|
||||
---
|
||||
|
||||
## Testing & Uebergabe
|
||||
|
||||
- **Pilotgruppe** (z. B. 10 Nutzer) fuer **10 Arbeitstage** nach Uebergabe.
|
||||
- **Sammelfeedback** und kleine Nachjustierungen im vereinbarten Rahmen (optional als Zusatzleistung klaeren).
|
||||
- **Auswertung der Erfolgsziele** zum vertraglichen Stichtag → Basis fuer die **CHF 7’000**-Komponente von **Launch48**.
|
||||
|
||||
**Enablement:** Das Ziel ist **Autonomie**: Internes Team versteht Grenzen, Bedienung und Eskalationspfad – analog zur **Enablement-Philosophie** bei groesseren PowerOn-Projekten (vgl. Wissenstransfer in der **Abraxas**-Methodendokumentation, sofern intern referenziert).
|
||||
|
||||
---
|
||||
|
||||
## Business Impact (Illustrationsbandbreiten)
|
||||
|
||||
*Hinweis: Zahlen erst mit echtem Projekt ersetzen.*
|
||||
|
||||
| Dimension | Illustrative Aussage |
|
||||
| --- | --- |
|
||||
| **Time-to-Value** | Produktiver Pilot in **Tagen** statt **Monaten** |
|
||||
| **Zeit pro Vorgang** | Ziel z. B. **25–40 %** Reduktion nach Baseline |
|
||||
| **Qualitaet** | Weniger Streuung durch einheitliche Wissensbasis |
|
||||
| **Risiko** | Weniger Shadow-AI durch **freigegebene** Plattform |
|
||||
|
||||
---
|
||||
|
||||
## Lessons Learned (generisch, aus Sprints dieser Art)
|
||||
|
||||
1. **Scope schlaegt Feature-Wunschliste** – ein scharfer Use-Case traegt KPIs.
|
||||
2. **Gates sparen Zeit** – Compliance und Zugang vor dem Sprint klaeren.
|
||||
3. **Human-in-the-Loop** – verhindert Halluzinationen im produktiven Kontext.
|
||||
4. **Runbook ist Produkt** – ohne Dokumentation sinkt Adoption.
|
||||
|
||||
| Herausforderung | Loesung |
|
||||
| --- | --- |
|
||||
| Unklare Verantwortung Fach/IT | Zwei benannte Owner von Tag 1 |
|
||||
| Zu grosse Wissensmenge | Priorisierte Quellen, spaetere Erweiterung |
|
||||
| Integration komplexer als gedacht | Frueh Spike oder Scope auf „read-only“ reduzieren |
|
||||
|
||||
---
|
||||
|
||||
## Technische Details (Beispiel-Stack)
|
||||
|
||||
**PowerOn:**
|
||||
|
||||
- Power Desktop / AI Workspace
|
||||
- Datenquellen (z. B. SharePoint, Uploads)
|
||||
- Automation / Workflow (je nach Use-Case)
|
||||
- Rollen und Sichtbarkeit gemaess Organisationsmodell
|
||||
|
||||
**Optional erwaehnt im echten Case:**
|
||||
|
||||
- Spezifische Modelle/Provider nur nach Kundenfreigabe dokumentieren.
|
||||
|
||||
---
|
||||
|
||||
## Projektorganisation
|
||||
|
||||
| Meilenstein | Zeit (Beispiel) |
|
||||
| --- | --- |
|
||||
| Kickoff & Gates | Woche -1 |
|
||||
| Sprint Tag 1 | z. B. Do |
|
||||
| Sprint Tag 2 | z. B. Fr |
|
||||
| Handover | Ende Tag 2 |
|
||||
| KPI-Messfenster | 10 Arbeitstage |
|
||||
| Auswertung | Stichtag laut Vertrag |
|
||||
|
||||
---
|
||||
|
||||
## Verbindung zur Abraxas-Methodik (interner Verweis)
|
||||
|
||||
Die **Abraxas DATA Hub Migration** zeigte: **strukturierte Analyse**, **Architekturentscheide mit Review**, **KI-gestuetzte Execution** und **Enablement** liefern **hohe Geschwindigkeit bei produktionsreifer Qualitaet**. **Launch48** uebertraegt diese Prinzipien auf **kleinere, scharf umrissene KI-Piloten** auf der **PowerOn-Plattform** – mit **Fixpreis** und **vereinbarten Erfolgszielen** fuer die zweite Zahlungsstufe.
|
||||
|
||||
*Oeffentliche Zitate oder Logos von Abraxas nur mit schriftlicher Freigabe.*
|
||||
|
||||
---
|
||||
|
||||
## Fazit
|
||||
|
||||
**Launch48** macht aus einem konkreten Alltags-Engpass einen **messbaren Piloten** auf **PowerOn** – schnell, mit klaren Leitplanken und ohne Monatsprojekt-Pflicht. Nach dem ersten echten Kundenprojekt: dieses Template durch **verifizierte Kennzahlen**, **Zitate** und **freigegebenen Namen** ersetzen.
|
||||
|
||||
---
|
||||
|
||||
## Freigaben (Checkliste – legal / kommerziell)
|
||||
|
||||
- [ ] Entscheid: Duerfen wir **Abraxas** als Referenz **namentlich** nennen?
|
||||
- [ ] Entscheid: Duerfen wir **diesen** Pilot-Kunden nennen?
|
||||
- [ ] Template-Kennzeichnung auf Website/PDF: **„Beispielszenario“** bis zur Finalversion.
|
||||
- [ ] KPI-Formulierungen von Recht/Finance geprueft.
|
||||
- [ ] Screenshots nur mit anonymisierten Daten.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- **Kundenangebot (primaer):** [poweron-launch48-offer.md](./poweron-launch48-offer.md)
|
||||
- Konzept (intern): [concept-poweron-48h-agent-offer.md](./concept-poweron-48h-agent-offer.md)
|
||||
- Flyer: [flyer-poweron-48h-agent.md](./flyer-poweron-48h-agent.md)
|
||||
- Plattform-Ueberblick: [product-teaser-poweron.md](./product-teaser-poweron.md)
|
||||
- PowerOn Desktop Story (Marketingtiefe): [case-study-power-desktop.md](./case-study-power-desktop.md)
|
||||
|
||||
246
docs/concept-poweron-48h-agent-offer.md
Normal file
246
docs/concept-poweron-48h-agent-offer.md
Normal file
|
|
@ -0,0 +1,246 @@
|
|||
# PowerOn Launch48 – Konzeptdokument (intern)
|
||||
*Produktisiertes Angebot: KI auf PowerOn in 48 Stunden (Fixpreis, Erfolgsziele gestaffelt)*
|
||||
|
||||
**Kundenfaehiges Angebot zum Teilen:** [poweron-launch48-offer.md](./poweron-launch48-offer.md)
|
||||
|
||||
**Version:** 1.1 (Entwurf zur internen Freigabe)
|
||||
**Bezug:** [product-teaser-poweron.md](./product-teaser-poweron.md), [case-study-power-desktop.md](./case-study-power-desktop.md)
|
||||
|
||||
---
|
||||
|
||||
## 1. Elevator Pitch
|
||||
|
||||
Viele Teams verlieren Kapazitaet an wiederkehrende Routine, waehrend KI-Piloten in Einzeltools haengen bleiben – ohne klare Datenhoheit und ohne messbaren Betriebsmehrwert. **Launch48** ist ein **48-Stunden-Sprint** auf der **PowerOn Enterprise-KI-Orchestrierungsplattform**: Gemeinsam mit Ihren und unseren Entwickler\*innen entsteht **ein konkreter, produktiv nutzbarer KI-Agent** (inkl. definierter Wissensbasis und Systemanbindung im vereinbarten Umfang). **Fixpreis CHF 9’000**, aufgeteilt in **CHF 2’000** bei Vertragsstart und **CHF 7’000** bei Erreichen **vorab definierter KPIs** – Ergebnis und Scope sind schriftlich fixiert, nicht „Stunden ohne Ende“.
|
||||
|
||||
---
|
||||
|
||||
## 2. Category-Zeile (Marketing)
|
||||
|
||||
**„Launch48: In 48 Stunden von Use-Case zu produktivem KI-Agenten auf PowerOn – mit messbarem Erfolg.“**
|
||||
|
||||
Alternativ techniknaeher (IT-Persona): **„Orchestrierter 48h-Sprint: Agent, Datenkontext und Integration – auf Ihrer PowerOn-Instanz.“**
|
||||
|
||||
---
|
||||
|
||||
## 3. Ideal Customer Profile (ICP) und Ausschluss
|
||||
|
||||
### 3.1 ICP
|
||||
|
||||
- **Organisationen** in der Schweiz / DACH: KMU, Mittelstand, Software-Haeuser, Dienstleister mit wiederkehrenden Wissens- oder Verarbeitungsprozessen.
|
||||
- **Ein klarer Kern-Use-Case** mit greifbarem Input/Output (z. B. Anfragebeantwortung aus internen Unterlagen, Vorbereitung standardisierter Antworten, erste Stufe Qualitaets-/Plausibilitaetschecks, strukturierte Extraktion aus definierten Dokumenten).
|
||||
- **Bereitschaft**, technische Ansprechpartner, Testdaten und **Zugang zu den vereinbarten Quellen/Systemen** waehrend des Sprints bereitzustellen.
|
||||
- **PowerOn** als Zielplattform akzeptiert (oder Pilot-Instanz wird fuer den Sprint bereitgestellt).
|
||||
|
||||
### 3.2 Ausschluss (kein Launch48 ohne Anpassung)
|
||||
|
||||
- Reine **Strategie-Workshops** ohne System- und Datenzugang.
|
||||
- **„KI fuer alles“** ohne priorisierten Use-Case.
|
||||
- Erwartung einer **vollstaendigen Unternehmens-Transformation** in 48 Stunden.
|
||||
- Use-Cases mit **hochreguliertem Alleingang** ohne vorherige Compliance-/Datenschutz-Freigaben (Sprint verschieben bis Gate erfuellt).
|
||||
|
||||
---
|
||||
|
||||
## 4. Differenzierung (Orientierung am Markt)
|
||||
|
||||
| Aspekt | Typischer „AI-Hackathon / One-Day-Agent“-Stil | **Launch48 (PowerOn)** |
|
||||
| --- | --- | --- |
|
||||
| **Dauer** | Oft 1 Tag vor Ort / komprimiert | **48 Stunden** gebuegelter Sprint inkl. Vorbereitung und Uebergabe |
|
||||
| **Traeger** | Oft generisch / tool-offen | **PowerOn-Plattform**: Workspace, Datenquellen, Automation, Governance |
|
||||
| **Daten & Privacy** | hauefig implizit | **Explizit**: Mandantenlogik, Sichtbarkeitsstufen, Privacy-Shield-Ansatz (siehe Desktop-Story) |
|
||||
| **Lieferobjekt** | „funktionale KI-Loesung“ (breit) | **Ein Agent/Workflow** im definierten Scope + Runbook + Enablement |
|
||||
| **Preislogik** | variabel | **Fixpreis CHF 9’000**, **CHF 7’000** an **messbare KPIs** gekoppelt |
|
||||
| **Beweis** | Referenzen variabel | **Methoden-Proof:** u. a. AI-augmented Delivery (z. B. Abraxas DATA Hub Migration – siehe separate Case Study; Nennung nur mit Kundenfreigabe) |
|
||||
|
||||
---
|
||||
|
||||
## 5. Vier Phasen (PowerOn-spezifisch)
|
||||
|
||||
Die Phasen sind inhaltlich mit gaengigen „Ideation → Data → Integration → Build“-Modellen vergleichbar, aber **konkret auf PowerOn** gebaut:
|
||||
|
||||
1. **Use-Case & Impact** – Priorisierung eines Szenarios mit hohem Business-Impact; Definition von **Erfolgskriterien und KPIs**; Abgrenzung In-/Out-of-Scope.
|
||||
2. **Wissensbasis** – Aufbau/Anbindung der vereinbarten **Dokumente und Datenquellen** im PowerOn-Kontext (persoenlich / Instanz / Mandat gemaess Rollenmodell).
|
||||
3. **Tools & Anbindung** – Auswahl und Umsetzung der **optimalen Integrationen** (z. B. APIs, konfigurierte Quellen, Automation-Trigger) im vereinbarten Rahmen; Freigaben und Berechtigungen.
|
||||
4. **Build-Sprint (48h)** – Gemeinsame Umsetzung mit **Pairing** zwischen Kunden- und PowerOn-Team; Reviews, Tests, Uebergabe.
|
||||
|
||||
---
|
||||
|
||||
## 6. Scope-Grenzen (Vorschlag zur internen Finalisierung)
|
||||
|
||||
*Die folgenden Groessen ermoeglichen einen verteidigbaren Fixpreis. Zahlen intern verbindlich festlegen und im Angebot/Vertrag ersetzen.*
|
||||
|
||||
### 6.1 Im Standard-Scope (empfohlen)
|
||||
|
||||
| Parameter | Vorschlag | Hinweis |
|
||||
| --- | --- | --- |
|
||||
| **Hauptlieferobjekt** | 1 **Agent bzw. 1 klar definierter Workflow/Automation** auf PowerOn | Erweiterung = Change Request |
|
||||
| **Workspace** | 1 **PowerOn-Instanz** bzw. 1 Mandanten-Workspace | Mehr Instanzen = Zusatz |
|
||||
| **Wissensquellen** | Bis **3 Quellen** (z. B. SharePoint-Bibliothek, definierter Ordner, CSV/FAQ-Dokumente) | „Quelle“ = fachlich abgegrenztes Bundle |
|
||||
| **Dokumentenvolumen (indikativ)** | Bis ca. **500 MB** indexierbarer Inhalt **oder** bis ca. **2’000** Seiten-Aequivalent | Grobmasstab; technische Validierung im Gate |
|
||||
| **Integrationen** | **1** zusaetzliche Systemanbindung im vereinbarten Umfang (z. B. ein REST-Webhook, ein definierter Connector) | Komplexe ERP-Tiefenintegration oft ausserhalb |
|
||||
| **Nutzer-Pilotgruppe** | Bis **15** aktive Testnutzer fuer KPI-Messung | Skalierung danach |
|
||||
| **Enablement** | **1** Live-Handover (60–90 Min.) **oder** Kurzvideo (30 Min.) + **Runbook** (Markdown/PDF) | |
|
||||
|
||||
### 6.2 Ausserhalb Standard-Scope (Zusatzangebot)
|
||||
|
||||
- Mehrere unabhaengige Use-Cases parallel.
|
||||
- Umfangreiche Individualentwicklung ausserhalb PowerOn-Standardfeatures.
|
||||
- Produktions-HA/DR, rechtliche Due-Diligence, vollstaendige Penetrationstests.
|
||||
- Schulung der gesamten Belegschaft.
|
||||
|
||||
### 6.3 Vor-Sprint-Gates (Go/No-Go)
|
||||
|
||||
Vor Start **CHF 2’000**-Phase muessen erfuellt sein:
|
||||
|
||||
- [ ] Geschaeftlicher **Use-Case Owner** benannt.
|
||||
- [ ] **Technischer Ansprechpartner** mit Berechtigung fuer Testsystem oder Pilot.
|
||||
- [ ] **Liste der Quellen** und Freigabe durch Datenschutz/Compliance (falls noetig).
|
||||
- [ ] **KPI-Set** schriftlich unterschrieben (siehe Kapitel 8).
|
||||
- [ ] Zugang zu PowerOn-Umgebung (Kunde oder PowerOn-Hosting laut Vereinbarung).
|
||||
|
||||
---
|
||||
|
||||
## 7. 48h-Ablauf (Kalender – Beispiel)
|
||||
|
||||
**Vorlauf (remote, typisch 3–5 Arbeitstage vor Sprint):** Kickoff 60 Min., Scope-Freeze, Zugriffe, Testdaten.
|
||||
|
||||
| Zeit | Tag 1 | Tag 2 |
|
||||
| --- | --- | --- |
|
||||
| Vormittag | Phase 1–2 Abschluss: Use-Case frozen, Quellen angebunden/indexiert | Phase 4: Integration finalisieren, End-to-End-Tests |
|
||||
| Nachmittag | Phase 3–4 Start: Tooling, erste Agent-/Workflow-Version | Pilotlauf mit Testnutzern, Runbook, Handover-Vorbereitung |
|
||||
|
||||
**Direkt nach Sprint:** Handover-Termin; **KPI-Messfenster** z. B. **10 Arbeitstage** nach Uebergabe (konfigurierbar).
|
||||
|
||||
---
|
||||
|
||||
## 8. KPI-Framework fuer CHF 7’000
|
||||
|
||||
*Im Vertrag: **3–5 KPIs** waehlen, je eine klare **Messmethode**, **Zielwert**, **Messzeitpunkt**.*
|
||||
|
||||
### 8.1 KPI-Katalog (Auswahl)
|
||||
|
||||
| ID | KPI (Beispiel) | Messidee | Beispiel-Zielwert |
|
||||
| --- | --- | --- | --- |
|
||||
| K1 | **Zeit pro Vorgang** | Zeitstempel Start/Ende in Pilot (oder Ticket-Stichprobe) | ≥ **30 %** Reduktion vs. Baseline (4-Wochen-Durchschnitt) |
|
||||
| K2 | **Anteil automatisierter Schritte** | Definierte Teilschritte ohne manuellen Eingriff | ≥ **70 %** der Schritte im definierten Prozess |
|
||||
| K3 | **Fehlerquote / Nacharbeit** | Anzahl Eskalationen oder Korrekturloops pro 100 Vorgaenge | ≤ **X** (Baseline + Schwelle) |
|
||||
| K4 | **Time-to-First-Answer** | Median bis erste brauchbare Agent-Antwort | ≤ **Y Minuten** |
|
||||
| K5 | **Pilot-Akzeptanz** | SUS oder interne 1–5-Befragung nach 2 Wochen | Mittelwert ≥ **4.0** |
|
||||
| K6 | **Verfuegbarkeit im Pilot** | Uptime der Agent-Instanz in Messfenster | ≥ **99 %** (ausser geplante Wartung) |
|
||||
|
||||
### 8.2 Regeln
|
||||
|
||||
- **Baseline** vor Sprint dokumentieren (Stichprobe oder Kennzahl aus Reporting).
|
||||
- Bei **Teilerreichung** optional interne Policy definieren (z. B. gestaffelte Zahlung oder Nachsprint-Paket – *nur wenn gewuenscht, rechtlich klaeren*).
|
||||
- **CHF 7’000** faellig bei **Erreichen aller vertraglich definierten KPI-Ziele** zum Messzeitpunkt.
|
||||
|
||||
---
|
||||
|
||||
## 9. Deliverables (Checkliste)
|
||||
|
||||
- [ ] Funktionsfaehiger **Agent/Workflow** im vereinbarten Scope auf PowerOn.
|
||||
- [ ] Konfigurierte **Wissensquellen** (laut Vertrag).
|
||||
- [ ] **Integration** (laut Vertrag) inkl. Testnachweis.
|
||||
- [ ] **Runbook**: Bedienung, Grenzen, Eskalation, bekannte Einschraenkungen.
|
||||
- [ ] **Enablement**: Session oder Video laut Vertrag.
|
||||
- [ ] **Uebergabeprotokoll** mit Link auf Testfaelle / Abnahme-Checkliste.
|
||||
|
||||
---
|
||||
|
||||
## 10. Commercials
|
||||
|
||||
| Position | Betrag | Faelligkeit |
|
||||
| --- | --- | --- |
|
||||
| **Gesamt Fixpreis** | **CHF 9’000** (exkl. MWSt. je nach Vereinbarung) | |
|
||||
| **Anzahlung** | **CHF 2’000** | Bei Vertragsunterzeichnung / Sprint-Freigabe |
|
||||
| **Erfolgszahlung** | **CHF 7’000** | Bei Nachweis der **vereinbarten KPIs** zum Messzeitpunkt |
|
||||
|
||||
Zusaetzliche Leistungen: nach **Stunden- oder Paketsatz** gemaess Preisliste.
|
||||
|
||||
---
|
||||
|
||||
## 11. Risiken und Mitigation
|
||||
|
||||
| Risiko | Mitigation |
|
||||
| --- | --- |
|
||||
| Schlechte Datenqualitaet | Gate vor Sprint: Stichprobe, Bereinigung, Scope reduzieren |
|
||||
| Fehlende API-Dokumentation | Frueh Integrations-Spike; sonst manueller Uebergabe-Modus im Scope |
|
||||
| Compliance verzoegert | Sprint startet erst nach Freigabe; keine parallele „Schatten-Produktion“ |
|
||||
| Scope Creep | Aenderungen nur per Change Request; Product Owner auf Kundenseite |
|
||||
| Erwartung „magische KI“ | KPIs und Grenzen im Runbook; Human-in-the-Loop explizit |
|
||||
|
||||
---
|
||||
|
||||
## 12. Sales Playbook
|
||||
|
||||
### 12.1 Discovery-Fragen (Auszug)
|
||||
|
||||
1. Welcher **konkrete Vorgang** kostet heute am meisten Zeit pro Woche?
|
||||
2. Wo liegen die **Quellen** (Systeme, Ordner, Tickets)?
|
||||
3. Wer ist **Owner** fuer Inhalt und fuer Technik?
|
||||
4. Welche **Compliance**-Grenzen gelten (DSG, Kundenvertraege)?
|
||||
5. Wie messen Sie heute **Qualitaet** (Fehlerquote, SLA)?
|
||||
6. Gibt es eine **Baseline-Zahl** fuer die letzten 4 Wochen?
|
||||
7. Wie viele **Pilotnutzer** sind realistisch in 2 Wochen?
|
||||
8. Ist **PowerOn** bereits im Einsatz oder kommt eine Pilot-Instanz?
|
||||
9. Was passiert bei **Erfolg** – Rollout-Plan?
|
||||
10. Was waere **nicht** im Scope (bewusst ausschliessen)?
|
||||
|
||||
### 12.2 Einwaende
|
||||
|
||||
- **„Zu schnell / zu guenstig.“** → Fixpreis gilt nur bei fixem Scope; Referenzmethodik AI-augmented Delivery; menschliche Validierung.
|
||||
- **„Wir haben keine Daten.“** → Mindestens FAQs oder interne Vorlagen reichen oft; sonst kein Launch48.
|
||||
- **„IT blockiert.“** → Gates und Pilot-Instanz-Option; kleinster sicherer Umfang.
|
||||
|
||||
### 12.3 Qualifikations-Scorecard (einfach)
|
||||
|
||||
| Kriterium | Punkte (0–2) |
|
||||
| --- | --- |
|
||||
| Klarer Use-Case | |
|
||||
| Zugang zu Daten bis Sprint-Start | |
|
||||
| Sponsor auf Fachseite | |
|
||||
| Tech-Ansprechpartner | |
|
||||
| KPI denkbar | |
|
||||
| **Summe ≥ 8** → hohe Prioritaet fuer Angebot |
|
||||
|
||||
---
|
||||
|
||||
## 13. Marketing-Kit (Verweise)
|
||||
|
||||
| Artefakt | Datei |
|
||||
| --- | --- |
|
||||
| **Kundenangebot (primaer, teilbar)** | [poweron-launch48-offer.md](./poweron-launch48-offer.md) |
|
||||
| **4-Folien-Deck (Praesentation)** | [launch48-deck-presentation.md](./launch48-deck-presentation.md) |
|
||||
| Flyer (2 Seiten, Kurzfassung) | [flyer-poweron-48h-agent.md](./flyer-poweron-48h-agent.md) |
|
||||
| Case Story (Illustration / Template, nicht Primaerverkauf) | [case-study-poweron-48h-agent.md](./case-study-poweron-48h-agent.md) |
|
||||
|
||||
### 13.1 LinkedIn-Posts (Kurzvarianten)
|
||||
|
||||
1. **Outcome:** „48 Stunden. Ein Agent. Messbarer Mehrwert. Launch48 auf PowerOn – Fixpreis, KPI-gestaffelt.“
|
||||
2. **IT/Governance:** „KI ohne Daten-Chaos: Launch48 verankert Ihren Agent auf PowerOn – mit Quellen, Rollen und klarer Integration.“
|
||||
3. **Social Proof (nur mit Freigabe):** „Wie bei komplexen Migrationen liefern wir **schnell und review-getrieben** – jetzt als 48h-Paket fuer Ihren ersten produktiven Agent.“
|
||||
|
||||
---
|
||||
|
||||
## 14. Rechtliches und Freigaben (Checkliste)
|
||||
|
||||
Siehe [case-study-poweron-48h-agent.md](./case-study-poweron-48h-agent.md) Abschnitt „Freigaben“. Insbesondere:
|
||||
|
||||
- [ ] Abraxas- und andere Kundennennung in Marketing freigegeben.
|
||||
- [ ] AGB/Vertrag fuer KPI-Zahl Klauseln geprueft.
|
||||
- [ ] Angebotsname **Launch48** Markenpruefung (intern).
|
||||
|
||||
---
|
||||
|
||||
## 15. Team (Ansprechpartner)
|
||||
|
||||
- **Patrick Motsch** – Technische Leitung, AI-Strategie
|
||||
- **Ida Dittrich** – Architektur, Plattform, Qualitaet
|
||||
- **Stephan Schellworth** – Projektsteuerung, Business Alignment
|
||||
|
||||
**PowerOn AG** – [www.poweron.swiss](https://www.poweron.swiss)
|
||||
|
||||
---
|
||||
|
||||
## Keywords
|
||||
|
||||
Launch48, PowerOn, KI-Agent, 48h Sprint, Fixpreis, KPI, Enterprise AI, Orchestrierung, Datenhoheit, Governance, produktisierte Dienstleistung, Schweiz, DACH
|
||||
BIN
docs/connections-ui-tests.xlsx
Normal file
BIN
docs/connections-ui-tests.xlsx
Normal file
Binary file not shown.
183
docs/feature-deck-ai-chat.md
Normal file
183
docs/feature-deck-ai-chat.md
Normal file
|
|
@ -0,0 +1,183 @@
|
|||
# PORTO AI Chat — Feature Slide Deck
|
||||
|
||||
Struktur analog zu «20260408 Local LLM.pdf» (6 Folien). Text für PowerPoint / Keynote / PDF-Export.
|
||||
|
||||
**Produktname:** PORTO (von PowerOn)
|
||||
**Feature:** AI Chat (Unified AI Workspace)
|
||||
|
||||
---
|
||||
|
||||
## Folie 1 — Titelfolie
|
||||
|
||||
**Hauptzeile (gross):**
|
||||
Ihr sicherer KI-Arbeitsplatz.
|
||||
Chatten, analysieren, automatisieren — in einer Oberfläche.
|
||||
|
||||
**Fliesstext:**
|
||||
PORTO gibt Ihrem Team einen KI-Agenten, der Dokumente versteht, Quellen verbindet und Ergebnisse liefert — ohne Datenabfluss ins Ausland.
|
||||
|
||||
**Kernnutzen (3 Bullets):**
|
||||
|
||||
- KI-Chat mit Dateizugriff und Dokumentenverständnis (RAG)
|
||||
- Verbindung zu SharePoint, OneDrive, Google Drive und weiteren Quellen
|
||||
- Schweizer Datenhaltung; Private LLM optional
|
||||
|
||||
**Fusszeile / Zielgruppe:**
|
||||
Für Treuhand, Legal, Finance und weitere vertrauenssensible Bereiche.
|
||||
|
||||
**Logo:** PORTO / PowerOn
|
||||
|
||||
---
|
||||
|
||||
## Folie 2 — Problem
|
||||
|
||||
**Hauptzeile:**
|
||||
Warum KI-Chat im Unternehmen heute oft an der Realität scheitert
|
||||
|
||||
**Fliesstext:**
|
||||
Viele Organisationen wollen produktiv mit KI chatten — aber sensible Prozesse und fehlender Systemkontext bremsen die Umsetzung:
|
||||
|
||||
**Schmerzpunkte (Bullets):**
|
||||
|
||||
- Vertrauliche Inhalte landen in öffentlichen Chat-Tools (Copy/Paste-Risiko)
|
||||
- Standard-Chats haben keinen sicheren Zugriff auf Unternehmensdokumente
|
||||
- Ergebnisse müssen manuell in Dateien, Mails und Reports übertragen werden
|
||||
- IT und Compliance verlangen Kontrolle über Modelle und Datenflüsse — Nutzer wollen Geschwindigkeit
|
||||
|
||||
**Zwischenüberschrift:**
|
||||
Die Folgen im Alltag:
|
||||
|
||||
**Folgen (kurze Liste):**
|
||||
|
||||
- Compliance- und Reputationsrisiko
|
||||
- Medienbrüche und Doppelarbeit
|
||||
- Langsame Bearbeitung
|
||||
- Verzögerte oder uneinheitliche KI-Nutzung
|
||||
|
||||
**Abschlusszeile:**
|
||||
Das Problem ist nicht der Wille zur Innovation. Das Problem ist der fehlende sichere Rahmen für produktiven KI-Chat mit echtem Dokumentenkontext.
|
||||
|
||||
---
|
||||
|
||||
## Folie 3 — Lösung
|
||||
|
||||
**Hauptzeile:**
|
||||
PORTO von PowerOn bringt sicheren KI-Chat in produktive Abläufe
|
||||
|
||||
**Fliesstext:**
|
||||
PORTO AI Chat verbindet Konversation mit Datenhoheit und Agentenfähigkeit.
|
||||
|
||||
**Vier Säulen:**
|
||||
|
||||
| Säule | Inhalt |
|
||||
|-------|--------|
|
||||
| **Kontextbewusst** | Semantische Wissensabfrage (RAG) über Ihre Dokumente — nicht nur «blind» chatten |
|
||||
| **Praktisch** | Eine Arbeitsfläche: Chats, Dateien, Datenquellen; Drag & Drop, Vorschau, klare Nachvollziehbarkeit |
|
||||
| **Aktiv** | KI-Agent mit Tools: lesen, zusammenfassen, strukturierte Inhalte erstellen, Dateien vorschlagen — mit Ihrer Freigabe |
|
||||
| **Kontrollierbar** | Modellwahl (z. B. OpenAI, Mistral, Private LLM), definierte Quellen, Daten in der Schweiz |
|
||||
|
||||
**Mit PORTO nutzen Teams KI so, wie sie gebraucht wird:**
|
||||
|
||||
- effizient
|
||||
- nachvollziehbar
|
||||
- geschützt
|
||||
- geeignet für vertrauliche Informationen
|
||||
|
||||
**Abschlusszeile:**
|
||||
So wird aus Zurückhaltung echte Umsetzung.
|
||||
|
||||
---
|
||||
|
||||
## Folie 4 — Typische Einsatzfelder
|
||||
|
||||
**Hauptzeile:**
|
||||
Typische Einsatzfelder für PORTO AI Chat
|
||||
|
||||
**Untertitel:**
|
||||
Wo PORTO im Alltag den grössten Nutzen bringt — schnell, verständlich, messbar.
|
||||
|
||||
**Vier Kacheln (je: Problem | Mit PORTO | Nutzen):**
|
||||
|
||||
### 1. Dokumentenanalyse & Prüfung
|
||||
|
||||
- **Problem:** PDFs, Verträge und Reports sind verteilt; manuelles Suchen und Quervergleiche kosten Zeit.
|
||||
- **Mit PORTO:** Dateien hochladen oder aus dem Workspace wählen; gezielt fragen — die KI nutzt Dokumentenkontext und Struktur.
|
||||
- **Nutzen:** Schnellere Einschätzung, weniger Suchaufwand, konsistente Antworten auf wiederkehrende Fragen.
|
||||
|
||||
### 2. Berichte & Ausarbeitungen
|
||||
|
||||
- **Problem:** Informationen aus mehreren Quellen zusammentragen und in saubere Dokumente bringen.
|
||||
- **Mit PORTO:** Agent unterstützt bei Recherche, Strukturierung und Erstellung — verbunden mit Dateien und Datenquellen.
|
||||
- **Nutzen:** Weniger manuelle Zusammenführung, höhere Durchsatzrate bei wiederkehrenden Deliverables.
|
||||
|
||||
### 3. Kommunikation & Übersetzung
|
||||
|
||||
- **Problem:** Entwürfe, Zusammenfassungen und Übersetzungen entstehen fragmentiert und ohne einheitlichen Leitfaden.
|
||||
- **Mit PORTO:** KI formuliert, fasst zusammen und übersetzt — im geschützten Umfeld; Anbindung an E-Mail- und Cloud-Kontext wo vorgesehen.
|
||||
- **Nutzen:** Schnellere, konsistentere Kommunikation bei gleichbleibender Governance.
|
||||
|
||||
### 4. Wissensabruf aus dem Unternehmen
|
||||
|
||||
- **Problem:** Wissen steckt in SharePoint, Drives, Ordnern und Alt-Dokumenten — Antworten dauern.
|
||||
- **Mit PORTO:** Semantische Suche und Kontext über angebundene Quellen und indexierte Inhalte.
|
||||
- **Nutzen:** Weniger «Wer hat das Dokument?» — mehr direkte, begründete Antworten.
|
||||
|
||||
**Fusszeile:**
|
||||
PORTO von PowerOn macht Wissensarbeit einfacher — für Fachbereiche, Führung und Operations, nicht nur für Tech-Teams.
|
||||
|
||||
---
|
||||
|
||||
## Folie 5 — Warum PORTO? (CTA)
|
||||
|
||||
**Hauptzeile (gross):**
|
||||
Warum PORTO?
|
||||
|
||||
**Kernbotschaften (3 Zeilen):**
|
||||
|
||||
- Ihre Daten bleiben in der Schweiz.
|
||||
- Ihre Chats und Dokumente bleiben unter Kontrolle.
|
||||
- Ihre Teams werden bei Wissensarbeit messbar schneller.
|
||||
|
||||
**Fliesstext:**
|
||||
Wir zeigen Ihnen in einem kostenlosen Erstgespräch, wie PORTO AI Chat in Ihrem sensibelsten Prozess sinnvoll eingesetzt und wertschöpfend integriert werden kann.
|
||||
|
||||
**Claim:**
|
||||
Ihr KI-Chat für sensible Daten und Dokumente — ohne Datenabfluss, ohne Kontrollverlust.
|
||||
|
||||
**Abschluss:**
|
||||
Weil sensible KI Vertrauen braucht.
|
||||
|
||||
---
|
||||
|
||||
## Folie 6 — Team (unverändert zur Master-Präsentation)
|
||||
|
||||
**Überschrift:**
|
||||
Wir kombinieren Strategie, Technologie und Umsetzungskraft.
|
||||
|
||||
**WER WIR SIND — Das PowerOn Team**
|
||||
|
||||
**Patrick Motsch** — Partner
|
||||
Leitet erfolgreich komplexe IT-Implementierungsprojekte; langjährige Erfahrung in innovativer Softwareentwicklung.
|
||||
*Mission: Nachhaltige KI-Integration für Schweizer KMUs.*
|
||||
|
||||
**Ida Dittrich** — Product Architect
|
||||
Verbindet wissenschaftliches Know-how mit praktischer IT-Erfahrung und bringt innovative Ansätze in technische Projekte ein.
|
||||
|
||||
**Stephan Schellworth** — Business Integration
|
||||
Verbindet strategisches Denken mit praxisnaher Projektsteuerung und gestaltet digitale Projekte erfolgreich.
|
||||
|
||||
**Rollen (kurz):**
|
||||
Patrick Motsch: CEO/CTO · Ida Dittrich: Product Architect · Stephan Schellworth: Business Integration
|
||||
|
||||
**Kontakt:**
|
||||
PowerOn AG
|
||||
Birmensdorferstrasse 94, 8003 Zürich
|
||||
www.poweron.swiss
|
||||
|
||||
---
|
||||
|
||||
## Hinweise für Design / PDF
|
||||
|
||||
- Typografie und Farben wie bei «Local LLM»-Deck übernehmen.
|
||||
- Folie 4: Vier gleich breite Spalten oder 2×2-Raster; «Problem / Mit PORTO / Nutzen» visuell trennen (z. B. kleine Labels).
|
||||
- Optional: Ein Screenshot der Workspace-Oberfläche (3-Spalten) als dezentes Hintergrund- oder Rand-Element auf Folie 3 — nur wenn markenkonform freigegeben.
|
||||
22
docs/feature-pitch-automation.md
Normal file
22
docs/feature-pitch-automation.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Automation — One-Pager
|
||||
|
||||
**Layout:** Links Screenshot (Flow-Editor oder Workflow-Uebersicht), rechts Text. PowerOn-Logo rechts oben.
|
||||
|
||||
---
|
||||
|
||||
## Automation
|
||||
|
||||
Wiederkehrende Aufgaben einmal einrichten — und nie wieder manuell erledigen.
|
||||
|
||||
Die Automation in PowerOn uebernimmt wiederkehrende Ablaeufe zuverlaessig fuer Sie. Stellen Sie Schritte visuell zusammen oder nutzen Sie fertige Vorlagen — die Plattform fuehrt sie auf Knopfdruck, nach Zeitplan oder ausgeloest durch eine E-Mail aus.
|
||||
|
||||
### Kernfunktionen
|
||||
|
||||
Ein Klick oder ein Zeitplan — der Ablauf erledigt den Rest.
|
||||
|
||||
- Ablaeufe visuell per Drag & Drop zusammenstellen und verbinden
|
||||
- Fertige Vorlagen fuer gaengige Geschaeftsprozesse sofort einsetzbar
|
||||
- Start per Zeitplan, Formular, E-Mail-Eingang oder manuell
|
||||
- Freigaben, Formulare und Uploads als menschliche Zwischenschritte einbinden
|
||||
|
||||
> **Screenshot:** Flow-Editor mit verbundenen Schritten (z. B. Zeitplan → KI-Zusammenfassung → E-Mail) oder Workflow-Liste mit Status und naechster Ausfuehrung.
|
||||
22
docs/feature-pitch-commcoach.md
Normal file
22
docs/feature-pitch-commcoach.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Kommunikations-Coach — One-Pager
|
||||
|
||||
**Layout:** Links Screenshot (Dashboard oder Coaching-Session), rechts Text. PowerOn-Logo rechts oben.
|
||||
|
||||
---
|
||||
|
||||
## Kommunikations-Coach
|
||||
|
||||
Besser kommunizieren — mit KI als persoenlichem Sparringspartner.
|
||||
|
||||
Der Kommunikations-Coach in PowerOn trainiert gezielt Gespraechssituationen aus dem Berufsalltag. Waehlen Sie ein Thema, ueben Sie per Chat oder Sprache mit der KI — und verfolgen Sie Ihren Fortschritt ueber Sessions hinweg.
|
||||
|
||||
### Kernfunktionen
|
||||
|
||||
Von der ersten Uebung bis zum messbaren Fortschritt — alles in einem Dossier.
|
||||
|
||||
- Coaching-Themen fuer typische Fuehrungssituationen (Feedback, Konflikte, Verhandlung u. a.)
|
||||
- Training per Chat oder Sprache — mit realistischen Rollenspielen
|
||||
- Bewertung nach jeder Session mit konkreten Verbesserungshinweisen
|
||||
- Fortschritt, Aufgaben und Erfolge (Streaks, Level, Auszeichnungen) auf einen Blick
|
||||
|
||||
> **Screenshot:** Dashboard mit Streak, Kompetenz-Score und aktiven Themen oder laufende Coaching-Session mit Chat-Verlauf und Sprachsteuerung.
|
||||
BIN
docs/files-ui-tests.xlsx
Normal file
BIN
docs/files-ui-tests.xlsx
Normal file
Binary file not shown.
105
docs/flyer-poweron-48h-agent.md
Normal file
105
docs/flyer-poweron-48h-agent.md
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
# Flyer: PowerOn Launch48
|
||||
*Zweiseitige Kurzfassung zum Drucken – verweist auf das Kundenangebot*
|
||||
|
||||
**Vollstaendiges, teilbares Angebot:** [poweron-launch48-offer.md](./poweron-launch48-offer.md)
|
||||
**4-Folien-Deck (Praesentation):** [launch48-deck-presentation.md](./launch48-deck-presentation.md)
|
||||
|
||||
---
|
||||
|
||||
## Layout-Briefing (fuer Designer / Canva)
|
||||
|
||||
| Element | Vorgabe |
|
||||
| --- | --- |
|
||||
| **Format** | DIN A4 oder US Letter, **zweiseitig**; alternativ **A5 hoch** fuer Events |
|
||||
| **Primaerfarbe** | Blau **#1976d2** |
|
||||
| **Sekundaer** | Tuerkis-Akzente, Violett dezent (wie [case-study-power-desktop.md](./case-study-power-desktop.md)) |
|
||||
| **Hintergrund** | Hell, viel Weissraum; Seite 1 „Hero“ |
|
||||
| **Typo** | Serioes, gut lesbar |
|
||||
| **Bilder** | Optional: abstrakte Workspace-Illustration |
|
||||
| **Logo** | PowerOn oben links Seite 1 |
|
||||
| **QR** | Seite 2: Link zum PDF/Web **Launch48** oder Kalender |
|
||||
|
||||
---
|
||||
|
||||
## Seite 1
|
||||
|
||||
### Headline
|
||||
|
||||
**PowerOn Launch48**
|
||||
**Ihre erste produktive KI-Loesung – in 48 Stunden.**
|
||||
|
||||
### Subline
|
||||
|
||||
**Ein klar abgegrenzter Anwendungsfall. Ihre Daten in geregeltem Rahmen. Ein Ergebnis, das sich im Pilot messen laesst.**
|
||||
|
||||
### Drei Kurz-Punkte (Problem)
|
||||
|
||||
- **Viel Routine** – Teams haengen in wiederkehrenden Schritten.
|
||||
- **Wissen verteilt** – Antworten dauern, Qualitaet schwankt.
|
||||
- **KI ohne Leitplanken** – unsichere Tools statt freigegebener Plattform.
|
||||
|
||||
### Vier Phasen (grafisch 1–4, wie Praesentation)
|
||||
|
||||
1. **Discovery** – Gemeinsame Analyse; Use-Case mit grossem Hebel, in 48h realistisch.
|
||||
2. **Design und Architektur** – Daten, Integration auf PowerOn; Erfolgsziele schriftlich vor Start.
|
||||
3. **Build und Integration** – Umsetzung, Tests; Fachseite prueft mit (parallel).
|
||||
4. **Deploy und Handover** – Go-Live in vereinbarter Umgebung, Doku, Einweisung.
|
||||
|
||||
*Volltext und Zeitrahmen:* [poweron-launch48-offer.md](./poweron-launch48-offer.md) Abschnitt „Der Ablauf“.
|
||||
|
||||
### Angebot (Box)
|
||||
|
||||
| | |
|
||||
| --- | --- |
|
||||
| **Paket** | **CHF 9’000** Fixpreis |
|
||||
| **Zu Beginn** | **CHF 2’000** |
|
||||
| **Bei Erfolg** | **CHF 7’000** (wenn die vereinbarten Erfolgsziele im Pilot erreicht sind) |
|
||||
|
||||
*Der Preis steht fuer Transparenz und einen klaren Rahmen: kein offenes Beratungsprojekt, sondern ein fokussiertes Paket auf PowerOn.*
|
||||
*Details und Grenzen: siehe Angebotsdokument Launch48.*
|
||||
|
||||
### Footer
|
||||
|
||||
**poweron.swiss** · PowerOn AG, Zuerich
|
||||
|
||||
---
|
||||
|
||||
## Seite 2
|
||||
|
||||
### Ueberschrift
|
||||
|
||||
**Was Sie bekommen · Was Sie mitbringen**
|
||||
|
||||
**Wir:**
|
||||
|
||||
- Funktionierende **KI-Loesung** auf PowerOn fuer **einen** definierten Fall
|
||||
- **Datenquellen** und **eine** Anbindung im Standardrahmen (wie vereinbart)
|
||||
- **Einweisung** und **kurze Dokumentation**
|
||||
|
||||
**Sie:**
|
||||
|
||||
- **Ansprechperson** Fach und IT
|
||||
- **Zugriffe** und **Freigaben** rechtzeitig
|
||||
- **kleine Pilotgruppe** fuer die Messung der Erfolgsziele
|
||||
|
||||
### Team
|
||||
|
||||
Patrick Motsch · Ida Dittrich · Stephan Schellworth
|
||||
Birmensdorferstrasse 94, 8003 Zuerich
|
||||
|
||||
### Call to Action
|
||||
|
||||
**15-Minuten-Gespraech:** Passt Launch48 zu Ihnen?
|
||||
→ QR / Link / E-Mail
|
||||
|
||||
---
|
||||
|
||||
## Druck-Hinweise
|
||||
|
||||
PDF **CMYK**, **3 mm Beschnitt**, Schriften einbetten.
|
||||
|
||||
---
|
||||
|
||||
## Keywords
|
||||
|
||||
Launch48, PowerOn, Flyer, KI, 48h, Fixpreis, Kundenangebot
|
||||
138
docs/landing-billing-transparenz-poweron.md
Normal file
138
docs/landing-billing-transparenz-poweron.md
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
# PowerOn – Kosten auf einen Blick (Landingpage)
|
||||
|
||||
Dieses Dokument fasst die **tatsächlich im Gateway implementierte** Abrechnungslogik in verständlicher Sprache zusammen – für transparente Darstellung auf der Website. Alle Zahlen und Regeln beziehen sich auf den Stand des Codes (siehe Abschnitt [Quellen im Repository](#quellen-im-repository)).
|
||||
|
||||
---
|
||||
|
||||
## Was kostet PowerOn? (Kurzfassung)
|
||||
|
||||
- **Abonnement (Standard):** Sie zahlen **pro Abrechnungszeitraum** für jeden **aktiven Benutzer** und jede **aktive Feature-Instanz** – wahlweise **monatlich** oder **jährlich** (Preise in **CHF**).
|
||||
- **Inkludiert im Abo:** Ein festes **KI-Budget in CHF pro Abrechnungsperiode** (z. B. monatlich 10 CHF bzw. jährlich 120 CHF beim Standard-Plan).
|
||||
- **Darüber hinaus:** KI-Nutzung wird **verbrauchsbasiert** vom Guthaben abgebucht; der Endbetrag ergibt sich aus den **Provider-Einstandskosten** plus einem **definierten Aufschlag** im Backend.
|
||||
- **Speicher:** Über dem im Plan enthaltenen Datenvolumen fällt **zusätzlicher Speicher** an (**CHF pro GB und Monat**).
|
||||
- **Aufladen:** Zusätzliches Guthaben ist per **Stripe Checkout** in festen Stufen möglich (**10–500 CHF**).
|
||||
|
||||
---
|
||||
|
||||
## So setzt sich der Preis zusammen
|
||||
|
||||
### 1) Fixe Abo-Komponente (Benutzer + Instanzen)
|
||||
|
||||
Die wählbaren Pläne sind im Backend als **fester Katalog** hinterlegt. Maßgeblich sind:
|
||||
|
||||
| Plan (Schlüssel) | Zeitraum | Preis pro aktivem User | Preis pro aktiver Feature-Instanz | Inkl. Datenvolumen (Plan) | Inkl. KI-Budget (pro Periode) |
|
||||
|------------------|----------|------------------------|-----------------------------------|---------------------------|-------------------------------|
|
||||
| **Standard (Monatlich)** `STANDARD_MONTHLY` | Monat | **90 CHF** | **150 CHF** | **1024 MB** (1 GB) | **10 CHF** |
|
||||
| **Standard (Jährlich)** `STANDARD_YEARLY` | Jahr | **1080 CHF** | **1800 CHF** | **1024 MB** (1 GB) | **120 CHF** |
|
||||
|
||||
**Hinweis:** Die Jahrespreise entsprechen **12 ×** den Monatsbeträgen (gleiche effektive Monatsrate).
|
||||
|
||||
**Hinweis zu Limits:** Bei den Standard-Plänen sind im Katalog **keine** `maxUsers` / `maxFeatureInstances` gesetzt (`None` = im Modell **keine Plan-Obergrenze**; nur das **Datenvolumen** ist mit 1024 MB pro Mandat als Plan-Limit hinterlegt). Der Trial-Plan hat explizit **1** User und **3** Instanzen max.
|
||||
|
||||
**Wichtig für das Verständnis:** Die Abrechnung erfolgt **nutzungsorientiert in dem Sinne**, dass sich die **Gesamtsumme** aus der **Anzahl aktiver User** und **aktiver Feature-Instanzen** ergibt. Änderungen (z. B. mehr Instanzen) können über Stripe mit **Proration** abgebildet werden (technische Umsetzung im Gateway).
|
||||
|
||||
### 2) Testphase (Trial)
|
||||
|
||||
Der Plan **7-Tage-Test** (`TRIAL_7D`) ist **kein kostenpflichtiges Abo** im Katalog-Sinne, sondern eine begrenzte Phase:
|
||||
|
||||
- **Dauer:** 7 Tage
|
||||
- **Limits:** max. **1** User, max. **3** Feature-Instanzen, **500 MB** Datenvolumen
|
||||
- **Inkl. KI-Budget:** **5 CHF**
|
||||
- Nach Ablauf ist laut Katalog ein Übergang zum **Standard (Monatlich)** vorgesehen (`successorPlanKey`).
|
||||
|
||||
---
|
||||
|
||||
## Variable Kosten (über das Abo hinaus)
|
||||
|
||||
### KI-Nutzung (Pay-per-Use aus dem Guthaben)
|
||||
|
||||
- Vor KI-Aufrufen prüft das System u. a., ob ein **aktives Abonnement** (oder Trial / begrenzt überfälliger Status) vorliegt und ob **ausreichend Guthaben** vorhanden ist.
|
||||
- Die bei einem Aufruf verbuchte Summe basiert auf einem **Basispreis** (vom KI-Provider / AICore geliefert) und wird im Gateway mit einem **Aufschlag** multipliziert.
|
||||
|
||||
**Implementierter Aufschlag:** Konstante `BILLING_MARKUP_PERCENT = 400` → Faktor **\(1 + 400\% = 5{,}0\)** auf den übergebenen Basisbetrag.
|
||||
|
||||
> **Transparenz-Hinweis:** Im Code-Kommentar neben der Konstante steht eine andere Erläuterung („Faktor 2.0“). **Maßgeblich für die Verrechnung ist die Implementierung** (`400` → Faktor 5). Bei Änderungen der Konstante bitte Landingpage-Text anpassen.
|
||||
|
||||
### Speicher über dem Plan-Inklusivvolumen
|
||||
|
||||
- **Preis überschüssigen Speichers:** **0,50 CHF pro GB und Monat** (`STORAGE_PRICE_PER_GB_CHF`), soweit das Volumen über dem im Plan enthaltenen **Soft-Limit** liegt (Standard-Pläne: **1024 MB**).
|
||||
|
||||
### Guthaben aufladen (optional)
|
||||
|
||||
Erlaubte **Einmal-Beträge** für Stripe-Top-up (serverseitig fix): **10, 25, 50, 100, 250, 500 CHF**.
|
||||
|
||||
---
|
||||
|
||||
## Abrechnung & Zahlung (ohne Technik-Jargon)
|
||||
|
||||
1. **Abo:** Aktivierung läuft über **Stripe** (wiederkehrende Abrechnung). Mengen (User/Instanzen) werden mit Stripe synchronisiert; Rechnungsstellung erfolgt über Stripe entsprechend der gewählten Periode.
|
||||
2. **Guthaben:** KI-Verbrauch und ggf. Speicher-Overage belasten das **Prepaid-Guthaben** des Mandats (bzw. die kontextabhängige Kontoführung im Billing-Modul).
|
||||
3. **Top-up:** Mandats-Admins können per **Stripe Checkout** Guthaben kaufen; die Gutschrift erfolgt über **Webhooks** / Bestätigung – serverseitig nur erlaubte Beträge.
|
||||
4. **Nachvollziehbarkeit:** Transaktionen und Auswertungen (z. B. nach Zeitraum, Provider, Modell, Feature) sind über die **Billing-API** abrufbar (für eingeloggte Nutzer je nach Rolle).
|
||||
|
||||
---
|
||||
|
||||
## Währung, Steuern, Laufzeit
|
||||
|
||||
- **Währung:** Durchgängig **CHF** (Plan-Katalog, Speicher-Overage, Top-up-Stufen).
|
||||
- **Intervalle:** **Monatlich** oder **jährlich** für die Standard-Pläne; Trial ohne Abo-Intervall.
|
||||
- **MwSt. / Steuerlogik:** Im Gateway-Code ist **keine** automatische Umsatzsteuerberechnung für Stripe-Checkout der Abos erkennbar; die **Unternehmens-/MwSt.-Angaben** des Betreibers können aus der Konfiguration für Kommunikation genutzt werden – **finanzrechtliche Texte** auf der Landingpage sollten mit Buchhaltung/Legal abgestimmt werden.
|
||||
|
||||
---
|
||||
|
||||
## FAQ (für die Website)
|
||||
|
||||
**Ist dies ein Abo?**
|
||||
Ja — die reguläre Nutzung von PowerOn ist ein Abonnement. Sie zahlen in einem festen Rhythmus (**monatlich oder jährlich**) für Ihre aktiven Benutzer und aktiven Funktionsbereiche (Feature-Instanzen). Die Zahlung verlängert sich automatisch, bis Sie kündigen oder Ihren Tarif anpassen. Im Abo-Preis ist bereits ein **KI-Budget** enthalten, das Sie jeden Monat bzw. jedes Jahr nutzen können. Für intensive KI-Nutzung oder zusätzlichen Speicher über dem inkludierten Volumen kann separat Guthaben aufgeladen werden — so bleibt das Basis-Abo planbar, während Mehrverbrauch fair nach tatsächlicher Nutzung abgerechnet wird. Die **kostenlose Testphase** (7 Tage) ist kein bezahltes Abo und endet automatisch; über den Wechsel zu einem Standard-Tarif werden Sie rechtzeitig informiert.
|
||||
|
||||
<!-- LEGAL-REVIEW: Formulierungen "verlängert sich automatisch, bis Sie kündigen" und
|
||||
"über den Wechsel zu einem Standard-Tarif werden Sie rechtzeitig informiert"
|
||||
vor Veröffentlichung mit Legal/AGB abstimmen (autoRenew=true im Gateway-Katalog,
|
||||
successorPlanKey=STANDARD_MONTHLY beim Trial). -->
|
||||
|
||||
**Zahle ich nur das Abo?**
|
||||
Nein. Das Abo deckt **Lizenzen** (User + Instanzen) und ein **inkludiertes KI-Budget** pro Periode. Darüber hinaus zählen **zusätzliche KI-Kosten** (verbrauchsbasiert mit Aufschlag) und ggf. **Speicher über dem Planlimit**.
|
||||
|
||||
**Wie transparent sind die KI-Kosten?**
|
||||
Jede belastbare Nutzung wird als **Transaktion** geführt (u. a. Provider, Modell, Feature-Kontext). Der Endbetrag enthält den im Code konfigurierten **Aufschlag** auf die Provider-Basis.
|
||||
|
||||
**Kann ich Guthaben nachladen?**
|
||||
Ja, in festen Paketen (**10–500 CHF**) über **Stripe**.
|
||||
|
||||
**Was passiert, wenn das Guthaben nicht reicht?**
|
||||
Die Plattform blockiert entsprechende **KI-Aufrufe**, sobald die Prüfung (Abo + Guthaben) nicht mehr erfüllt ist – Details siehe `BillingService.checkBalance` im Gateway.
|
||||
|
||||
**Gibt es eine Testphase?**
|
||||
Ja: **7 Tage** mit klaren Grenzen (User, Instanzen, Volumen, **5 CHF** KI-Budget).
|
||||
|
||||
**Wechseln sich die Preise ohne Ankündigung?**
|
||||
Die öffentlich kommunizierten Beträge sollten mit dem **Deploy-Stand** des Gateways übereinstimmen: Die Standardpreise liegen im **Python-Plan-Katalog** (`BUILTIN_PLANS`), nicht in einer Marketing-Datei.
|
||||
|
||||
---
|
||||
|
||||
## Quellen im Repository
|
||||
|
||||
| Thema | Datei (Gateway) |
|
||||
|--------|------------------|
|
||||
| Plan-Katalog, CHF-Preise, Limits, KI-Budget | `modules/datamodels/datamodelSubscription.py` (`BUILTIN_PLANS`) |
|
||||
| Speicher-Overage CHF/GB/Monat | `modules/datamodels/datamodelBilling.py` (`STORAGE_PRICE_PER_GB_CHF`) |
|
||||
| KI-Aufschlag / Verbrauchsbuchung | `modules/serviceCenter/services/serviceBilling/mainServiceBilling.py` (`BILLING_MARKUP_PERCENT`, `calculatePriceWithMarkup`, `recordUsage`, `checkBalance`) |
|
||||
| Top-up-Beträge, Stripe Checkout | `modules/serviceCenter/services/serviceBilling/stripeCheckout.py` (`ALLOWED_AMOUNTS_CHF`) |
|
||||
| Billing- & Abo-Routen (API) | `modules/routes/routeBilling.py`, `modules/routes/routeSubscription.py`, `modules/routes/routeStore.py` (`/api/store/subscription-info`) |
|
||||
|
||||
---
|
||||
|
||||
## Mini-Übersicht als Fluss (optional für Diagramm auf der Seite)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
visitor[Besucher] --> plans[Plan_User_und_Instanz_CHF]
|
||||
plans --> included[Inkl_KI_Budget_pro_Periode]
|
||||
included --> usage[Verbrauch_KI_und_Speicher]
|
||||
usage --> topup[Optional_Stripe_TopUp]
|
||||
topup --> insight[Transaktionen_und_Statistik_in_App]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*Letzte inhaltliche Abstimmung mit dem Gateway-Code: Dokument erzeugt für Landingpage-Transparenz; bei Code-Änderungen bitte Tabelle und FAQ aktualisieren.*
|
||||
233
docs/launch48-deck-presentation.md
Normal file
233
docs/launch48-deck-presentation.md
Normal file
|
|
@ -0,0 +1,233 @@
|
|||
# PowerOn 48h AI Sprint – Praesentationsdeck (4 Folien)
|
||||
*Fertiger Copy-Stand fuer Canva / PowerPoint / PDF-Export. Ersetzt die fruehere Arbeitsversion `20260320_AI_Hackathon.pdf` inhaltlich.*
|
||||
|
||||
**Kundenangebot (Fliesstext):** [poweron-launch48-offer.md](./poweron-launch48-offer.md)
|
||||
|
||||
**Schreibweise:** durchgaengig **PowerOn** (nicht PowerON). Produktname im Kundenfacing: **48h AI Sprint** (nicht mehr „Launch48“ als Markenname).
|
||||
|
||||
**Optional – Zusatzfolie Architektur (16:9, HTML):** [poweron-ki-betriebssystem-slide.html](./poweron-ki-betriebssystem-slide.html) – im Browser oeffnen, Ansicht **1920×1080** (z. B. DevTools-Geraetemodus), **Screenshot** oder Druck als PDF fuer PowerPoint/Keynote. Prompts fuer Bild-KI: [poweron-ki-betriebssystem-prompts.md](./poweron-ki-betriebssystem-prompts.md).
|
||||
|
||||
---
|
||||
|
||||
## Folie 1 von 4 – Einstieg (Hero)
|
||||
|
||||
### Haupttitel
|
||||
**48h AI Sprint**
|
||||
|
||||
### Nutzenversprechen (ein Satz, sales-stark)
|
||||
**Von der Idee zum pilotfaehigen MVP in 48 Stunden – gebaut mit KI-gestuetztem Engineering durch PowerOn, mit Fixpreis und Erfolgsanteil.**
|
||||
|
||||
### Outcome (ein Satz, greifbar – keine Wiederholung von „klar abgegrenzt“)
|
||||
**Sie erhalten einen funktionierenden Software-Piloten im vereinbarten Umfang – spezifiziert, umgesetzt, getestet und dokumentiert – plus schriftlich fixierte Erfolgsziele fuer Abnahme und die zweite Zahlungsstufe.**
|
||||
|
||||
### Badge / Meta
|
||||
**PowerOn · 48h AI Sprint · 2026**
|
||||
|
||||
### Drei Kurz-Pills (horizontal)
|
||||
| Pill 1 | Pill 2 | Pill 3 |
|
||||
| --- | --- | --- |
|
||||
| **48 Stunden** Umsetzungsblock | **Fixpreis CHF 9'000** | **CHF 7'000** erfolgsgebunden |
|
||||
|
||||
*Hinweis fuer Layout (optional, klein unter Pills):* `CHF 7'000` = **78%** des Paketpreises – faellig bei nachgewiesenen, vorab vereinbarten Erfolgszielen im Pilot.
|
||||
|
||||
### Zahlungslogik (eine Zeile, zentral)
|
||||
**CHF 2'000 zu Projektstart · CHF 7'000 bei erfuellten, schriftlich definierten Pilot-Zielen.**
|
||||
|
||||
### Vertrauen / Governance (eine Zeile)
|
||||
**Gemeinsame Entscheidungsbasis: fester Leistungsrahmen, keine offene Stundenhonorarspirale. Betrieb, Datenfluesse und Freigaben stimmen wir vor dem 48h-Block mit Ihrer IT und Compliance ab.**
|
||||
|
||||
### Micro-CTA
|
||||
**15-Minuten-Check: Passt Ihr Software-Vorhaben zum 48h AI Sprint?**
|
||||
|
||||
### CTA-Kanaele (konkret eintragen / im PDF verlinken)
|
||||
- **Web:** [www.poweron.swiss](https://www.poweron.swiss)
|
||||
- **E-Mail:** info@poweron.swiss *(Betreff-Vorschlag: „48h AI Sprint – 15-Minuten-Check“)*
|
||||
- **Kalender:** *(Link zum Buchungstool hier einfuegen, sobald vorhanden)*
|
||||
|
||||
---
|
||||
|
||||
### Was auf Folie 1 weg soll (Redundanzen aus alter Version)
|
||||
- Keine doppelte **FIXPREIS**-Box.
|
||||
- Kein paralleler Marken-Mix: durchgaengig **48h AI Sprint** als Produktname auf der Folie.
|
||||
- Kein Mix aus **CHF 9'000** und **CHF 9k** auf derselben Folie.
|
||||
- Pill 3 nicht nur **„78% bei Erfolg“** ohne Kontext – **CHF 7'000 erfolgsgebunden** plus optionaler Hinweis auf 78%.
|
||||
- **„messbarer ROI“** nur, wenn ihr ihn operationalisiert; sonst: **„messbare Erfolgsziele im Pilot“**.
|
||||
|
||||
---
|
||||
|
||||
## Folie 2 von 4 – Der Ablauf
|
||||
|
||||
### Titel
|
||||
**DER ABLAUF**
|
||||
|
||||
### Untertitel (korrigiert)
|
||||
**Vier Phasen · 48 Stunden · gemeinsam mit Ihrem Team**
|
||||
|
||||
### Subline
|
||||
**KI-gestuetztes Engineering durch erfahrene Architektinnen und Architekten – auf der PowerOn-Plattform, mit Ihren Daten und Systemen.**
|
||||
|
||||
### Phase 1 – Discovery
|
||||
Gemeinsame Analyse Ihres Vorhabens. Wir identifizieren den Scope mit dem groessten Nutzen – **messbar** und in **48 Stunden** realistisch umsetzbar.
|
||||
|
||||
### Phase 2 – Design und Architektur
|
||||
Software-Architektur, Datenmodell und Integration auf der **PowerOn**-Plattform. Definition der **Erfolgsziele**, die **vor dem Start schriftlich fixiert** werden und ueber die **Erfolgszahlung** (CHF 7'000) entscheiden.
|
||||
|
||||
### Phase 3 – Build und Integration
|
||||
Umsetzung der Loesung, Anbindung an Ihre Systeme **im Vereinbarten**, Testing. **Mensch prueft mit:** Validierung durch Ihre Fachanwenderinnen und -anwender – parallel zum Build.
|
||||
|
||||
### Phase 4 – Deploy und Handover
|
||||
**Go-Live in Ihrer vereinbarten PowerOn-Umgebung** (Pilot oder Produktion je nach Vereinbarung), Wissenstransfer, Dokumentation. Ihr Team kann die Loesung **im vereinbarten Rahmen** vom ersten Tag an **selbststaendig weiterbetreiben und ausbauen**.
|
||||
|
||||
### Optional: Zeit-Splits (Beispiel-Verteilung, nicht vertraglich)
|
||||
*Hinweis intern: Anpassen, wenn euer echtes Modell anders ist.*
|
||||
|
||||
| Block | Dauer (Beispiel) |
|
||||
| --- | --- |
|
||||
| Discovery / Vorbereitung | 4 h |
|
||||
| Design / Architektur | 8 h |
|
||||
| Build / Integration | 28 h |
|
||||
| Deploy / Handover | 8 h |
|
||||
|
||||
### Fussbereich Folie 2
|
||||
**Gebaut auf PowerOn – Ihrer AI-Augmented-Engineering-Plattform.**
|
||||
|
||||
PowerOn ist nicht nur ein Projektrahmen: Hier entsteht Ihre Loesung mit **KI als Produktivitaetshebel** des Teams – mit Monitoring, Auditierbarkeit, Rollen- und Rechteverwaltung und Skalierbarkeit.
|
||||
|
||||
**Stichwoerter (Tags):** AI-augmented Engineering · Hosting nach Vorgabe · Software-Qualitaet · Nachvollziehbarkeit
|
||||
|
||||
---
|
||||
|
||||
## Folie 3 von 4 – Warum PowerOn
|
||||
|
||||
### Kennzahl-Band (qualifiziert, nicht als Garantie)
|
||||
**Deutlich schneller als klassische Monatsprojekte** – je nach Ausgangslage und Vorhaben.
|
||||
|
||||
*(Die fruehere Formulierung „10x“ nur verwenden, wenn ihr sie pro Kunde belegen koennt.)*
|
||||
|
||||
### Titel
|
||||
**WARUM POWERON**
|
||||
|
||||
### Untertitel
|
||||
**Nicht nur schnell – strukturell besser.**
|
||||
|
||||
### Kurzzeile
|
||||
KI-gestuetzt bauen – mit nachvollziehbaren Ergebnissen und klarem Scope.
|
||||
|
||||
### Block 1 – AI-Augmented-Engineering-Plattform
|
||||
PowerOn ist keine Ad-hoc-Einzelloesung: eine **Plattform fuer AI-augmented Engineering**. Ihre **Software-Loesung** laeuft in einer Umgebung, die fuer **Skalierung** und **Sicherheit** ausgelegt ist; die KI steigert die **Liefergeschwindigkeit** des Teams, nicht das Chat-Erlebnis allein.
|
||||
|
||||
### Block 2 – Erfolgsgebundene Verguetung
|
||||
**CHF 7'000** (78% von CHF 9'000) zahlen Sie bei **nachgewiesenen, vorab schriftlich vereinbarten Erfolgszielen** im Pilot. So teilen wir das Ergebnisrisiko transparent.
|
||||
|
||||
### Block 3 – Sicherheit und Compliance fuer Ihr Projekt
|
||||
**Datenhaltung nach Vorgabe:** Schweizer Hosting, Cloud nach Wahl oder andere Modelle – wir stimmen das **im Erstgespraech** mit Ihrer IT und Compliance ab.
|
||||
|
||||
### Block 4 – Enablement statt Abhaengigkeit
|
||||
Wissenstransfer ist **fester Bestandteil**. Ihr Team versteht Bedienung, Grenzen und Weiterentwicklung **im vereinbarten Rahmen**.
|
||||
|
||||
### Messbare Ergebnisse (als Zielgroessen, nicht als Versprechen)
|
||||
*Formulierung fuer Folie:*
|
||||
|
||||
**Im Pilot messen wir gemeinsam – typische Zielgroessen (je nach Vorhaben):**
|
||||
- Funktionalitaet und Stabilitaet der Loesung im Alltag
|
||||
- Zeit bis zur **ersten pilotfaehigen** Nutzung: **48 Stunden** Umsetzungsblock (plus vereinbarter Pilot)
|
||||
- Wirtschaftlichkeit: Break-even haengt von internem Aufwand und Volumen ab – **kein fixer Monatswert ohne Daten**
|
||||
|
||||
*(Die frueheren harten Zahlen **-70%** und **<6 Monate** nur nutzen, wenn ihr sie durch Pilotdaten oder Rechnungsbeispiele stuetzt; sonst weglassen oder als „Illustration“ kennzeichnen.)*
|
||||
|
||||
### Proof-Box – Abraxas *(nur bei schriftlicher Kundenfreigabe nennen)*
|
||||
|
||||
**Variante A – mit Namensnennung (bei Freigabe durch Abraxas):**
|
||||
|
||||
> **Referenz (Methodik):** PowerOn hat die **DATA-Hub-Backend-Migration** fuer die **Abraxas Informatik AG** in **11 Tagen** umgesetzt (Node.js/TypeScript zu .NET/C#) – mit klaren Phasen, Reviews und Wissenstransfer.
|
||||
> **Botschaft:** Dieselbe **Lieferdisziplin** nutzen wir, um Ihren **Software-Piloten** im Rahmen des **48h AI Sprint** schnell und kontrolliert zu bringen.
|
||||
> **Details:** Case Study auf Anfrage.
|
||||
|
||||
**Variante B – ohne Namen (wenn keine Freigabe), ausfuehrlich fuer Proof-Folie / HTML:**
|
||||
|
||||
**Referenzcase (anonymisiert) – Backend-Migration unter Zeitdruck**
|
||||
|
||||
*Folie / Layout: optional zwei Spalten „Ausgangslage | Vorgehen“ oder vier Zeilen unten als Timeline.*
|
||||
|
||||
- **Ausgangslage**
|
||||
- Fuehrendes **Schweizer Softwarehaus**; **geschaeftskritisches** Plattform-Backend (DATA-Hub-Umfeld)
|
||||
- Jahre gewachsen, mehrere fruehere Partner, **hohe technische Schulden** und **Pentest-relevante Security-Themen**
|
||||
- **Wissensluecken:** **10** Themenbereiche, **49** Klaerungsfragen vor Migration (strukturiert beantwortet)
|
||||
- Klassische Groessenordnung: **3–6 Monate** statt Wochen
|
||||
|
||||
- **Vorgehen (4 Phasen, KI-gestuetzt, Human-in-the-Loop)**
|
||||
1. **Analyse & Dokumentation** (ca. 2–3 Tage): **47** TypeScript-Dateien inventarisiert und dokumentiert
|
||||
2. **Technische Spezifikation** (ca. 2–3 Tage): Ziel **.NET/C#**, Architekturentscheide, **Reviews** mit Kundenteam, **Acceptance Criteria**
|
||||
3. **Execution** (ca. **1 Tag** Migration): **Node.js/TypeScript → .NET/C#**, Modul fuer Modul **architektonisch validiert**, Tests parallel
|
||||
4. **Testing & Uebergabe** (ca. 2–3 Tage): Validierung, automatisierte Tests, **Wissenstransfer** (Training on the Job, Video)
|
||||
|
||||
- **Ergebnis**
|
||||
- **11 Kalendertage** Gesamt (Kickoff bis uebergabefaehige Basis)
|
||||
- **~1 Tag** fuer eigentliche Code-Migration; Tech Debt und Security-Punkte **adressiert**; Team **befaehigt**
|
||||
- Relativ zu klassisch **mehrmonatiger** Migration: **ca. 10x schneller** in diesem Fall *(Indikator, keine Garantie fuer andere Vorhaben)*
|
||||
|
||||
- **Transfer zum 48h AI Sprint**
|
||||
- Gleiche Logik: **fester Scope**, Phasen, messbare Abnahme, **Enablement** als Kern – nicht als Zusatz
|
||||
|
||||
*Hinweis:* Kein Garantieversprechen pro Use Case. **Vollstaendige Case Study / namentliche Referenz** nur auf Anfrage und mit **schriftlicher Kundenfreigabe**.
|
||||
|
||||
---
|
||||
|
||||
### Geeignet fuer (Software-Vorhaben im Paketrahmen)
|
||||
- **MVP-** und Pilotbau, Prototyping
|
||||
- **Backend-Migration** und Stack-Wechsel
|
||||
- **Systemintegration** (APIs, Daten, Identity)
|
||||
- **Prozessautomatisierung** und interne Tools
|
||||
- **Legacy-Modernisierung** in abgegrenztem Schnitt
|
||||
- Dokumentenverarbeitung, Reporting, Freigabe-Workflows – im vereinbarten Umfang
|
||||
|
||||
---
|
||||
|
||||
## Folie 4 von 4 – Wer wir sind
|
||||
|
||||
### Titelzeile
|
||||
**Wir kombinieren Strategie, Technologie und Umsetzungskraft.**
|
||||
|
||||
### Ueberschrift
|
||||
**WER WIR SIND – Das PowerOn-Team**
|
||||
|
||||
### Lieferfaehigkeit 48h AI Sprint (eine Zeile, fuer Erstleser)
|
||||
**Dieses Team fuehrt Discovery, Architektur, Build und Handover im 48h AI Sprint – End-to-End, mit klaren Meilensteinen.**
|
||||
|
||||
### Patrick Motsch
|
||||
**CEO/CTO** – Steuert technische Umsetzung und komplexe IT-Projekte; sorgt dafuer, dass Ihr Software-Pilot in PowerOn produktiv wird und betreibbar bleibt.
|
||||
**Mission:** Schneller, nachvollziehbarer **Softwarebau** fuer Schweizer Unternehmen – mit KI als Engineering-Hebel.
|
||||
|
||||
### Ida Dittrich
|
||||
**Product Architect** – Verantwortet Architektur, Qualitaet und Machbarkeit auf der PowerOn-Plattform – damit Scope, Daten und Integration im 48h-Rahmen stimmig bleiben.
|
||||
|
||||
### Stephan Schellworth
|
||||
**Business Integration** – Verbindet Vorhaben, Stakeholder und Projektsteuerung – damit Erfolgsziele vor dem Start klar sind und der Pilot messbar bleibt.
|
||||
|
||||
### Rollen (einzeilig, Fusszeile / Karten)
|
||||
- **Patrick Motsch** – CEO/CTO
|
||||
- **Ida Dittrich** – Product Architect
|
||||
- **Stephan Schellworth** – Business Integration
|
||||
|
||||
### Kontakt und naechster Schritt
|
||||
**PowerOn AG**
|
||||
Birmensdorferstrasse 94, 8003 Zuerich
|
||||
|
||||
**15-Minuten-Check buchen:** [www.poweron.swiss](https://www.poweron.swiss) · **E-Mail:** info@poweron.swiss
|
||||
*(Betreff: „48h AI Sprint – 15-Minuten-Check“; Kalenderlink ergaenzen, sobald verfuegbar.)*
|
||||
|
||||
---
|
||||
|
||||
## Checkliste vor PDF-Export
|
||||
|
||||
- [ ] Referenz: **Variante A (Abraxas namentlich)** oder **Variante B (anonym, ausfuehrlich)** gewaehlt; Freigabe fuer Namensnennung liegt vor?
|
||||
- [ ] Alle **PowerOn**-Schreibweisen vereinheitlicht; Produktname **48h AI Sprint** konsistent
|
||||
- [ ] Keine **doppelten** Preisboxen auf Folie 1
|
||||
- [ ] **Kennzahlen** nur in der gewaehlten Strenge (hart vs. qualifiziert)
|
||||
- [ ] **CTA** mit realem Kalenderlink oder zentraler E-Mail belegt
|
||||
|
||||
---
|
||||
|
||||
## Hinweis zur Datei in Downloads
|
||||
|
||||
Die bisherige Datei `20260320_AI_Hackathon.pdf` bitte **inhaltlich** an dieses Dokument anpassen (Design kann gleich bleiben). Diese Markdown-Datei ist die **autoritative Textfassung**.
|
||||
494
docs/launch48-offer-page.html
Normal file
494
docs/launch48-offer-page.html
Normal file
|
|
@ -0,0 +1,494 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="de-CH">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="description" content="PowerOn 48h AI Sprint: pilotfaehiger MVP oder Software-Pilot in 48 Stunden, KI-gestuetztes Engineering, Fixpreis CHF 9'000, CHF 7'000 erfolgsgebunden.">
|
||||
<title>PowerOn 48h AI Sprint | MVP in 48 Stunden</title>
|
||||
<style>
|
||||
:root {
|
||||
--po-blue: #1976d2;
|
||||
--po-blue-dark: #12579b;
|
||||
--po-teal: #00897b;
|
||||
--text: #1a1a2e;
|
||||
--text-muted: #5c5c6f;
|
||||
--bg: #f8fafc;
|
||||
--card: #ffffff;
|
||||
--border: #e2e8f0;
|
||||
--radius: 12px;
|
||||
--shadow: 0 4px 24px rgba(25, 118, 210, 0.08);
|
||||
--max: 1080px;
|
||||
}
|
||||
*, *::before, *::after { box-sizing: border-box; }
|
||||
body {
|
||||
margin: 0;
|
||||
font-family: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
|
||||
font-size: 1.0625rem;
|
||||
line-height: 1.55;
|
||||
color: var(--text);
|
||||
background: var(--bg);
|
||||
}
|
||||
a { color: var(--po-blue); text-decoration: none; }
|
||||
a:hover { text-decoration: underline; }
|
||||
.wrap { max-width: var(--max); margin: 0 auto; padding: 0 1.25rem; }
|
||||
/* Header */
|
||||
header.site {
|
||||
background: linear-gradient(135deg, var(--po-blue-dark) 0%, var(--po-blue) 48%, #1565c0 100%);
|
||||
color: #fff;
|
||||
padding: 2.5rem 0 3.25rem;
|
||||
}
|
||||
.badge {
|
||||
display: inline-block;
|
||||
font-size: 0.75rem;
|
||||
font-weight: 600;
|
||||
letter-spacing: 0.06em;
|
||||
text-transform: uppercase;
|
||||
opacity: 0.92;
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
header h1 {
|
||||
margin: 0 0 0.75rem;
|
||||
font-size: clamp(1.85rem, 4.5vw, 2.5rem);
|
||||
font-weight: 700;
|
||||
line-height: 1.15;
|
||||
letter-spacing: -0.02em;
|
||||
}
|
||||
.hero-lead {
|
||||
font-size: 1.2rem;
|
||||
max-width: 38rem;
|
||||
opacity: 0.96;
|
||||
margin: 0 0 0.5rem;
|
||||
}
|
||||
.hero-outcome {
|
||||
font-size: 1.02rem;
|
||||
font-weight: 600;
|
||||
line-height: 1.45;
|
||||
max-width: 40rem;
|
||||
opacity: 0.98;
|
||||
margin: 0 0 1.35rem;
|
||||
}
|
||||
.pills {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 0.65rem;
|
||||
margin-bottom: 1.25rem;
|
||||
}
|
||||
.pill {
|
||||
background: rgba(255,255,255,0.14);
|
||||
border: 1px solid rgba(255,255,255,0.28);
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 999px;
|
||||
font-size: 0.9rem;
|
||||
font-weight: 600;
|
||||
}
|
||||
.pill strong { font-weight: 700; }
|
||||
.payment-line {
|
||||
font-size: 0.95rem;
|
||||
opacity: 0.95;
|
||||
margin-bottom: 1rem;
|
||||
max-width: 40rem;
|
||||
}
|
||||
.trust-line {
|
||||
font-size: 0.88rem;
|
||||
opacity: 0.85;
|
||||
max-width: 42rem;
|
||||
margin-bottom: 1.75rem;
|
||||
}
|
||||
header.site .pill-hint {
|
||||
font-size: 0.8rem;
|
||||
opacity: 0.82;
|
||||
max-width: 42rem;
|
||||
margin: 0.5rem 0 1rem;
|
||||
}
|
||||
.btn {
|
||||
display: inline-block;
|
||||
background: #fff;
|
||||
color: var(--po-blue-dark);
|
||||
font-weight: 600;
|
||||
padding: 0.85rem 1.5rem;
|
||||
border-radius: var(--radius);
|
||||
box-shadow: 0 2px 12px rgba(0,0,0,0.12);
|
||||
border: none;
|
||||
cursor: pointer;
|
||||
font-size: 1rem;
|
||||
}
|
||||
.btn:hover { text-decoration: none; opacity: 0.95; }
|
||||
.btn-secondary {
|
||||
background: transparent;
|
||||
color: #fff;
|
||||
border: 2px solid rgba(255,255,255,0.55);
|
||||
box-shadow: none;
|
||||
margin-left: 0.5rem;
|
||||
}
|
||||
@media (max-width: 560px) {
|
||||
.btn-secondary { margin-left: 0; margin-top: 0.65rem; display: inline-block; }
|
||||
}
|
||||
/* Sections */
|
||||
section {
|
||||
padding: 3rem 0;
|
||||
}
|
||||
section.alt { background: #fff; }
|
||||
h2 {
|
||||
margin: 0 0 0.35rem;
|
||||
font-size: clamp(1.35rem, 3vw, 1.65rem);
|
||||
font-weight: 700;
|
||||
color: var(--text);
|
||||
}
|
||||
.section-intro {
|
||||
color: var(--text-muted);
|
||||
margin: 0 0 1.75rem;
|
||||
max-width: 38rem;
|
||||
}
|
||||
/* Pain grid */
|
||||
.grid-3 {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
|
||||
gap: 1.25rem;
|
||||
}
|
||||
.card {
|
||||
background: var(--card);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
padding: 1.35rem 1.5rem;
|
||||
box-shadow: var(--shadow);
|
||||
}
|
||||
.card h3 {
|
||||
margin: 0 0 0.5rem;
|
||||
font-size: 1.05rem;
|
||||
color: var(--po-blue);
|
||||
}
|
||||
.card p { margin: 0; color: var(--text-muted); font-size: 0.98rem; }
|
||||
/* Phases */
|
||||
.phases-head { text-align: center; margin-bottom: 2rem; }
|
||||
.phases-head h2 { margin-bottom: 0.35rem; }
|
||||
.phases-head .sub { color: var(--text-muted); margin: 0; font-size: 1rem; }
|
||||
.steps {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
|
||||
gap: 1rem;
|
||||
counter-reset: step;
|
||||
}
|
||||
.step {
|
||||
position: relative;
|
||||
background: var(--card);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
padding: 1.35rem 1.25rem 1.25rem 1.35rem;
|
||||
border-top: 4px solid var(--po-blue);
|
||||
}
|
||||
.step:nth-child(2) { border-top-color: #e65100; }
|
||||
.step:nth-child(3) { border-top-color: #7b1fa2; }
|
||||
.step:nth-child(4) { border-top-color: #c2185b; }
|
||||
.step-num {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 700;
|
||||
color: var(--po-blue);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.04em;
|
||||
margin-bottom: 0.35rem;
|
||||
}
|
||||
.step:nth-child(2) .step-num { color: #e65100; }
|
||||
.step:nth-child(3) .step-num { color: #7b1fa2; }
|
||||
.step:nth-child(4) .step-num { color: #c2185b; }
|
||||
.step h3 { margin: 0 0 0.5rem; font-size: 1.05rem; }
|
||||
.step p { margin: 0; font-size: 0.92rem; color: var(--text-muted); line-height: 1.5; }
|
||||
/* Why */
|
||||
.why-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(260px, 1fr));
|
||||
gap: 1.25rem;
|
||||
}
|
||||
.why-card h3 { margin: 0 0 0.5rem; font-size: 1.05rem; }
|
||||
.why-card p { margin: 0; color: var(--text-muted); font-size: 0.95rem; }
|
||||
/* Proof */
|
||||
.proof {
|
||||
background: linear-gradient(180deg, #f0f7fc 0%, #fff 100%);
|
||||
border: 1px solid #cfe8fc;
|
||||
border-radius: var(--radius);
|
||||
padding: 1.5rem 1.75rem;
|
||||
margin-top: 2rem;
|
||||
}
|
||||
.proof h3 { margin: 0 0 0.5rem; font-size: 1.05rem; color: var(--po-blue-dark); }
|
||||
.proof h4 {
|
||||
margin: 1.1rem 0 0.4rem;
|
||||
font-size: 0.82rem;
|
||||
font-weight: 700;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.04em;
|
||||
color: var(--po-blue);
|
||||
}
|
||||
.proof h4:first-of-type { margin-top: 0; }
|
||||
.proof p { margin: 0 0 0.55rem; font-size: 0.95rem; color: var(--text); line-height: 1.55; }
|
||||
.proof .fine { font-size: 0.8rem; color: var(--text-muted); margin-top: 0.85rem; margin-bottom: 0; }
|
||||
.deliverables-strip {
|
||||
margin-top: 1.75rem;
|
||||
padding: 1.25rem 1.5rem;
|
||||
background: #f1f5f9;
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
}
|
||||
.deliverables-strip h3 {
|
||||
margin: 0 0 0.65rem;
|
||||
font-size: 0.95rem;
|
||||
color: var(--text);
|
||||
}
|
||||
.deliverables-strip ul {
|
||||
margin: 0;
|
||||
padding-left: 1.2rem;
|
||||
color: var(--text-muted);
|
||||
font-size: 0.92rem;
|
||||
line-height: 1.5;
|
||||
}
|
||||
.deliverables-strip li { margin-bottom: 0.35rem; }
|
||||
/* Use cases */
|
||||
ul.check {
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(260px, 1fr));
|
||||
gap: 0.5rem 1.5rem;
|
||||
}
|
||||
ul.check li {
|
||||
padding-left: 1.35rem;
|
||||
position: relative;
|
||||
font-size: 0.95rem;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
ul.check li::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 0;
|
||||
top: 0.45rem;
|
||||
width: 0.5rem;
|
||||
height: 0.5rem;
|
||||
background: var(--po-teal);
|
||||
border-radius: 2px;
|
||||
}
|
||||
/* CTA footer */
|
||||
.cta-band {
|
||||
background: var(--po-blue);
|
||||
color: #fff;
|
||||
text-align: center;
|
||||
padding: 2.75rem 1.25rem;
|
||||
}
|
||||
.cta-band h2 { color: #fff; margin-bottom: 0.5rem; }
|
||||
.cta-band p { opacity: 0.92; margin: 0 0 1.25rem; }
|
||||
.cta-band .btn { color: var(--po-blue); }
|
||||
.cta-band .btn.btn-secondary {
|
||||
color: #fff;
|
||||
border-color: rgba(255, 255, 255, 0.55);
|
||||
}
|
||||
footer.legal {
|
||||
padding: 1.5rem 1.25rem;
|
||||
text-align: center;
|
||||
font-size: 0.85rem;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.skip-link {
|
||||
position: absolute;
|
||||
left: -9999px;
|
||||
}
|
||||
.skip-link:focus { left: 1rem; top: 1rem; z-index: 100; background: #fff; padding: 0.5rem; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<a class="skip-link" href="#main">Zum Inhalt</a>
|
||||
|
||||
<header class="site">
|
||||
<div class="wrap">
|
||||
<p class="badge">PowerOn · 48h AI Sprint · 2026</p>
|
||||
<h1>48h AI Sprint</h1>
|
||||
<p class="hero-lead">Von der Idee zum <strong>pilotfaehigen MVP</strong> in <strong>48 Stunden</strong> – gebaut mit <strong>KI-gestuetztem Engineering</strong> durch das PowerOn-Team, zum <strong>Fixpreis</strong> und mit Erfolgsanteil. Die KI ist unser Produktivitaetshebel – Ihr Lieferobjekt ist <strong>funktionierende Software</strong>.</p>
|
||||
<p class="hero-outcome">Sie erhalten einen <strong>funktionierenden Software-Piloten</strong> im vereinbarten Umfang: spezifiziert, umgesetzt, getestet, dokumentiert – plus <strong>schriftlich fixierte Erfolgsziele</strong> fuer Abnahme und die zweite Zahlungsstufe.</p>
|
||||
<div class="pills" role="list">
|
||||
<span class="pill" role="listitem"><strong>48 Stunden</strong> Umsetzungsblock</span>
|
||||
<span class="pill" role="listitem"><strong>Fixpreis CHF 9’000</strong></span>
|
||||
<span class="pill" role="listitem"><strong>CHF 7’000</strong> erfolgsgebunden</span>
|
||||
</div>
|
||||
<p class="pill-hint">CHF 7’000 entspricht 78% des Pakets – wird faellig, sobald die <strong>vorab vereinbarten Erfolgsziele</strong> im Pilot nachgewiesen sind.</p>
|
||||
<p class="payment-line"><strong>Zahlungslogik:</strong> CHF 2’000 zu Projektstart · CHF 7’000 bei erfuellten, schriftlich definierten Pilot-Zielen.</p>
|
||||
<p class="trust-line"><strong>Gemeinsame Entscheidungsbasis:</strong> fester Leistungsrahmen, keine offene Stundenhonorarspirale. Betrieb, Datenfluesse und Freigaben stimmen wir <strong>vor</strong> dem 48h-Block mit Ihrer IT und Compliance ab.</p>
|
||||
<p>
|
||||
<a class="btn" href="https://www.poweron.swiss" target="_blank" rel="noopener">15-Minuten-Check – passt Ihr Vorhaben?</a>
|
||||
<a class="btn btn-secondary" href="mailto:info@poweron.swiss?subject=48h%20AI%20Sprint%20%E2%80%93%2015-Minuten-Check">E-Mail</a>
|
||||
</p>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<main id="main">
|
||||
<section class="alt" aria-labelledby="pain-title">
|
||||
<div class="wrap">
|
||||
<h2 id="pain-title">Warum viele bei Software-Vorhaben zoegern</h2>
|
||||
<p class="section-intro">MVPs und Piloten rutschen oft in lange Vorlaufphasen – Scope wabert, Budget bleibt offen, der erste echte Nutzen kommt zu spaet. Der <strong>48h AI Sprint</strong> verbindet <strong>Tempo im Umsetzungsblock</strong>, einen <strong>festen Leistungsrahmen</strong> und eine <strong>messbare Pilot-Abnahme</strong>.</p>
|
||||
<div class="grid-3">
|
||||
<div class="card">
|
||||
<h3>Scope ohne Schärfe</h3>
|
||||
<p>Ohne klare Grenzen wächst das Vorhaben ständig – und Ende offen statt Lieferdatum. Sie brauchen einen <strong>abgeschlossenen Pilot-Schnitt</strong>, der sich bewerten lässt.</p>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Budget ohne Plan</h3>
|
||||
<p>Stundensätze und offene Schätzungen machen Einkauf und Führung nervös. <strong>Fixpreis plus erfolgsgebundener Anteil</strong> schafft eine gemeinsame Entscheidungsbasis.</p>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Zu lange bis zum MVP</h3>
|
||||
<p>Klassische Monatsprojekte versanden leicht zwischen Workshops und Spezifikationen. Sie wollen <strong>schnell sehen</strong>, ob Architektur, Integration und Nutzen im Alltag tragen.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section aria-labelledby="outcome-title">
|
||||
<div class="wrap">
|
||||
<h2 id="outcome-title">Was Sie am Ende haben</h2>
|
||||
<p class="section-intro">Konkrete Software-Lieferobjekte statt Folienstapel: alles, was Sie brauchen, um im Alltag zu testen, zu messen und intern zu entscheiden – ob und wie Sie skalieren.</p>
|
||||
<div class="grid-3">
|
||||
<div class="card">
|
||||
<h3>Funktionierender Software-Pilot</h3>
|
||||
<p>Eine <strong>pilotfaehige Loesung</strong> im vereinbarten Umfang – z. B. MVP, Integrations-Schnittstelle, Automatisierung oder Migrationsschritt – mit realistischen Testfaellen aus Ihrem Alltag, nicht als reines Konzeptpapier.</p>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Daten, Integration, Abnahme</h3>
|
||||
<p><strong>Freigegebene</strong> Datenquellen und <strong>eine</strong> Systemanbindung wie vereinbart. <strong>Erfolgsziele und Abnahmekriterien</strong> sind vor dem 48h-Block schriftlich fixiert – dieselbe Sprache fuer Fachbereich, IT und Einkauf.</p>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Betrieb & Wissenstransfer</h3>
|
||||
<p>Kurze Dokumentation, Einweisung und Uebergabe, damit Ihr Team die Loesung im Paketrahmen <strong>selbststaendig weiterbetreiben oder ausbauen</strong> kann – inklusive Grenzen, Rollen und naechster sinnvoller Schritte.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deliverables-strip">
|
||||
<h3>Zeitlicher Rahmen (Orientierung)</h3>
|
||||
<ul>
|
||||
<li><strong>Vorbereitung</strong> vor dem Block: Discovery, Architektur, Freigaben – typischerweise einige Arbeitstage.</li>
|
||||
<li><strong>48 Stunden</strong> intensiver Umsetzungsblock gemeinsam mit Ihrem Team.</li>
|
||||
<li><strong>Pilotphase</strong> danach: Messfenster fuer die vereinbarten Erfolgsziele (Dauer wie im Angebot festgelegt).</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="alt" aria-labelledby="flow-title">
|
||||
<div class="wrap">
|
||||
<div class="phases-head">
|
||||
<h2 id="flow-title">Der Ablauf</h2>
|
||||
<p class="sub"><strong>Vier Phasen</strong> · <strong>48 Stunden</strong> Umsetzung · <strong>gemeinsam</strong> mit Ihrem Team</p>
|
||||
<p class="sub" style="margin-top:0.5rem">Ihre freigegebenen Systeme und Daten – umgesetzt durch <strong>KI-gestuetztes Engineering</strong> erfahrener Architektinnen und Architekten auf der PowerOn-Plattform, mit nachvollziehbaren Abläufen und wachsender Skalierbarkeit.</p>
|
||||
</div>
|
||||
<div class="steps">
|
||||
<article class="step">
|
||||
<div class="step-num">Phase 1</div>
|
||||
<h3>Discovery</h3>
|
||||
<p>Gemeinsame Analyse: Wir waehlen den Use-Case mit dem groessten Hebel – messbar und in 48 Stunden realistisch umsetzbar.</p>
|
||||
</article>
|
||||
<article class="step">
|
||||
<div class="step-num">Phase 2</div>
|
||||
<h3>Design & Architektur</h3>
|
||||
<p>Software-Architektur, Datenmodell und Integration auf PowerOn. <strong>Erfolgsziele</strong> werden vor dem Start schriftlich fixiert – sie steuern die Erfolgszahlung.</p>
|
||||
</article>
|
||||
<article class="step">
|
||||
<div class="step-num">Phase 3</div>
|
||||
<h3>Build & Integration</h3>
|
||||
<p>Build der Loesung, Anbindung im Vereinbarten, Tests. Ihre Fachseite prueft mit – parallel zum Build, mit Alltags-Beispielen.</p>
|
||||
</article>
|
||||
<article class="step">
|
||||
<div class="step-num">Phase 4</div>
|
||||
<h3>Deploy & Handover</h3>
|
||||
<p>Go-Live in Ihrer <strong>vereinbarten PowerOn-Umgebung</strong>, Wissenstransfer und Dokumentation für den laufenden Betrieb.</p>
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section aria-labelledby="why-title">
|
||||
<div class="wrap">
|
||||
<h2 id="why-title">Warum PowerOn</h2>
|
||||
<p class="section-intro">Nicht nur schnell – strukturell besser: <strong>AI-augmented Engineering</strong> auf einer Plattform mit klaren Rollen und nachvollziehbaren Ergebnissen.</p>
|
||||
<div class="why-grid">
|
||||
<div class="card why-card">
|
||||
<h3>AI-Augmented-Engineering-Plattform</h3>
|
||||
<p>PowerOn ist keine Ad-hoc-Einzelloesung. Wir bauen Ihre Loesung auf einer Umgebung, auf der <strong>KI-gestuetzte Produktivitaet</strong> und klassische Softwarequalitaet zusammenkommen – Skalierung, Rechte, Nachvollziehbarkeit inbegriffen.</p>
|
||||
</div>
|
||||
<div class="card why-card">
|
||||
<h3>Erfolg teilen</h3>
|
||||
<p><strong>CHF 7’000</strong> (78% von CHF 9’000) werden erst faellig, wenn die <strong>vorab schriftlich vereinbarten Erfolgsziele</strong> im Pilot nachgewiesen sind.</p>
|
||||
</div>
|
||||
<div class="card why-card">
|
||||
<h3>Daten nach Vorgabe</h3>
|
||||
<p>Sicherheit und Compliance fuer Ihr Softwareprojekt: Hosting- und Verarbeitungsmodell stimmen wir mit Ihrer IT ab – vom Schweizer Rechenzentrum bis zu definierten Cloud-Szenarien.</p>
|
||||
</div>
|
||||
<div class="card why-card">
|
||||
<h3>Enablement</h3>
|
||||
<p>Wissenstransfer ist fester Bestandteil. Ihr Team versteht Bedienung, Grenzen und naechste Schritte im vereinbarten Rahmen.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<aside class="proof" aria-labelledby="proof-title">
|
||||
<h3 id="proof-title">Referenzcase (anonymisiert) – Backend-Migration unter Zeitdruck</h3>
|
||||
<!-- Anonym: keine Kundennamen. Variante mit Namensnennung: siehe launch48-deck-presentation.md Variante A. -->
|
||||
<h4>Ausgangslage</h4>
|
||||
<p>Ein fuehrendes <strong>Schweizer Softwarehaus</strong> modernisierte ein <strong>geschaeftskritisches Plattform-Backend</strong> (DATA-Hub-Umfeld): ueber Jahre gewachsen, mehrere fruehere Partner, <strong>erhebliche technische Schulden</strong> und <strong>Sicherheitsbefunde</strong> (u.a. aus Pentests). Zusaetzlich <strong>Wissensluecken</strong> im Bestand – strukturiert geklaert in <strong>10 Themenbereichen</strong> mit <strong>49 Detailfragen</strong> vor der Umsetzung. Ein vergleichbares Vorhaben waere klassisch oft mit <strong>3–6 Monaten</strong> und hohem internen Aufwand geplant worden.</p>
|
||||
<h4>Vorgehen (4 Phasen, KI-gestuetzt, Human-in-the-Loop)</h4>
|
||||
<p><strong>1. Analyse & Dokumentation</strong> (ca. 2–3 Tage): Inventur und strukturierte Analyse von <strong>47 TypeScript-Dateien</strong>, Geschaeftslogik und Abhaengigkeiten; Ergebnis in dokumentierter Form fuer Entscheid und Migration.</p>
|
||||
<p><strong>2. Technische Spezifikation</strong> (ca. 2–3 Tage): Zielarchitektur <strong>.NET / C#</strong> (u.a. ORM, APIs, Anbindungen an Messaging, Object Storage, Identity); <strong>Review-Sessions</strong> mit dem Kundenteam; feste <strong>Acceptance Criteria</strong>.</p>
|
||||
<p><strong>3. Execution</strong> (ca. <strong>1 Tag</strong> fuer die eigentliche Code-Migration): KI unterstuetzt die Uebersetzung <strong>Node.js/TypeScript → .NET/C#</strong>; erfahrene Architektinnen und Architekten <strong>validieren jedes Modul</strong>; Tests und Integration laufen parallel.</p>
|
||||
<p><strong>4. Testing & Uebergabe</strong> (ca. 2–3 Tage): Mock- und End-to-End-Validierung, Testdaten, automatisierte Tests; <strong>Wissenstransfer</strong> (Training on the Job, aufgezeichnete Session) – damit das interne Team den Ansatz <strong>eigenstaendig fortsetzen</strong> kann.</p>
|
||||
<h4>Ergebnis</h4>
|
||||
<p>Gesamtprojekt <strong>11 Kalendertage</strong> vom Kickoff bis zur uebergabefaehigen .NET/C#-Basis – bei gleichzeitiger <strong>Bereinigung von Tech Debt</strong>, Adressierung relevanter <strong>Security-Punkte</strong> und <strong>vollstaendigem Enablement</strong> des Kundenteams. Relativ zur typischen Planungsgroessenordnung <strong>mehrmonatiger</strong> klassischer Migration: <strong>ca. 10x schnellere</strong> Time-to-Result in diesem Fall (kein Uebertragungsversprechen fuer jedes Projekt).</p>
|
||||
<h4>Transfer zum 48h AI Sprint</h4>
|
||||
<p>Dieselbe Lieferdisziplin nutzen wir fuer Ihren <strong>Software-Piloten</strong>: <strong>klarer Scope</strong>, feste Phasen, nachvollziehbare Zwischenresultate, messbare Abnahme – plus <strong>Wissenstransfer</strong> als fester Bestandteil, nicht als Zusatz.</p>
|
||||
<p class="fine">Kein Garantieversprechen pro Use Case; Dauer und Aufwand haengen von Ausgangslage und Freigaben ab. <strong>Vollstaendige Case Study und namentliche Referenz</strong> auf Anfrage und nur mit Kundenfreigabe.</p>
|
||||
</aside>
|
||||
|
||||
<h2 style="margin-top:2.5rem;">Geeignet fuer</h2>
|
||||
<p class="section-intro">Typische Einstiege – immer im vereinbarten Paketrahmen:</p>
|
||||
<ul class="check">
|
||||
<li><strong>MVP-</strong> und Pilotbau (neue Produkte, Schnittstellen, Prozesse)</li>
|
||||
<li><strong>Backend-Migration</strong> und Stack-Wechsel (wie im Referenzcase)</li>
|
||||
<li><strong>Systemintegration</strong> (APIs, Messaging, Identity, Datenpipelines)</li>
|
||||
<li><strong>Prozessautomatisierung</strong> und interne Tools</li>
|
||||
<li><strong>Prototyping</strong> und Machbarkeitsnachweis vor groesserem Budget</li>
|
||||
<li><strong>Legacy-Modernisierung</strong> in abgegrenztem Schnitt</li>
|
||||
<li>Dokumentenverarbeitung, Reporting, Freigabe-Workflows – im vereinbarten Umfang</li>
|
||||
</ul>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="alt" aria-labelledby="team-title">
|
||||
<div class="wrap">
|
||||
<h2 id="team-title">Das PowerOn-Team</h2>
|
||||
<p class="section-intro">Wir kombinieren Strategie, Technologie und Umsetzungskraft. Dieses Team fuehrt Discovery, Architektur, Build und Handover im <strong>48h AI Sprint</strong> – End-to-End, mit klaren Meilensteinen.</p>
|
||||
<div class="grid-3">
|
||||
<div class="card">
|
||||
<h3>Patrick Motsch</h3>
|
||||
<p><strong>CEO/CTO</strong> – Steuert technische Umsetzung und komplexe IT-Projekte; sorgt dafuer, dass Ihr Software-Pilot in PowerOn produktiv wird und betreibbar bleibt.</p>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Ida Dittrich</h3>
|
||||
<p><strong>Product Architect</strong> – Verantwortet Architektur, Qualitaet und Machbarkeit auf der PowerOn-Plattform – damit Scope, Daten und Integration im 48h-Rahmen stimmig bleiben.</p>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Stephan Schellworth</h3>
|
||||
<p><strong>Business Integration</strong> – Verbindet Use Case, Stakeholder und Projektsteuerung – damit Erfolgsziele vor dem Start klar sind und der Pilot messbar bleibt.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<div class="cta-band">
|
||||
<div class="wrap">
|
||||
<h2>Bereit fuer den 15-Minuten-Check?</h2>
|
||||
<p>Wir sagen ehrlich, ob Ihr Vorhaben zum <strong>48h AI Sprint</strong> passt – ohne Druck.</p>
|
||||
<a class="btn" href="https://www.poweron.swiss" target="_blank" rel="noopener">15-Minuten-Check – poweron.swiss</a>
|
||||
<a class="btn btn-secondary" href="mailto:info@poweron.swiss?subject=48h%20AI%20Sprint%20%E2%80%93%2015-Minuten-Check">E-Mail</a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<footer class="legal">
|
||||
<div class="wrap">
|
||||
<p><strong>PowerOn AG</strong> · Birmensdorferstrasse 94, 8003 Zuerich · <a href="https://www.poweron.swiss">www.poweron.swiss</a></p>
|
||||
<p>Fliesstext und Vertragsdetails: siehe <a href="./poweron-launch48-offer.md">poweron-launch48-offer.md</a> (Markdown).</p>
|
||||
</div>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
52
docs/poweron-ki-betriebssystem-prompts.md
Normal file
52
docs/poweron-ki-betriebssystem-prompts.md
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
# Prompts: KI-Betriebssystem-Infografik (Google Bild-KI / Gemini)
|
||||
|
||||
Für die Generierung einer alternativen oder verfeinerten Visualisierung in **Google AI Studio**, der **Gemini-App** (Bildfunktion) oder einem vergleichbaren Angebot (z. B. Imagen). Modell im UI wählen (intern manchmal anders benannt).
|
||||
|
||||
**Zugehörige Code-Folie (HTML, 1920×1080):** [poweron-ki-betriebssystem-slide.html](./poweron-ki-betriebssystem-slide.html)
|
||||
|
||||
---
|
||||
|
||||
## Master-Prompt (ein Bild, gesamte Folie)
|
||||
|
||||
```
|
||||
Professional German B2B infographic slide, 16:9 landscape, 1920x1080. Title at top: "Das moderne KI-Betriebssystem" with subtitle "PowerOn". Light grey background (#f8fafc).
|
||||
|
||||
Left: flat-design rocket pointing up, five horizontal colored segments from top to bottom: dark blue, medium blue, light blue-grey, cream, orange flame at bottom; small dark fins on sides of cream section. White line icons centered in each segment: dashboard gauge; server with nodes; hand holding gear; crossed wrench and screwdriver; document with magnifying glass. Labels on rocket segments in German: Interface, Orchestrierung, Skills, Modelle, Daten.
|
||||
|
||||
Center: five stacked white rounded cards with left color tabs matching rocket segments. Each card: bold German title, subtitle, two bullet lines with arrow symbols. Content exactly:
|
||||
(1) Interface Layer (Interaktion) — Einstiegspunkt für User & Systeme — Chat, Spracheingabe, Oberflächen; API & Webhooks
|
||||
(2) Orchestrierung & Agenten — Entscheiden & Abläufe planen — Aufgaben delegieren; Skills & Tools koordinieren
|
||||
(3) Skill- & Tool-Layer — Ausführung konkreter Aufgaben — Prozesse, Aktionen, Integration; API-Aufrufe, Funktionen & Automationen
|
||||
(4) KI-Modelle — Spezialisierte Modelle — Generierung, Analyse & Klassifikation; Ausführung einzelner Denkschritte
|
||||
(5) Daten- & Kontextschicht — Dokumente & Wissen — Vektordatenbanken; Retrieval & Historien
|
||||
|
||||
Ribbon connectors between rocket segments and cards with subtle folded ribbon 3D effect.
|
||||
|
||||
Far left vertical bar: vertical text "Regeln & Steuerung", subtext horizontal small: Zugriffsrechte & Rollen, Entscheidungsgrenzen, Validierung & Freigaben. Far right vertical bar: vertical text "Transparenz & Kontrolle", subtext: Nachvollziehbarkeit, Qualitätssicherung, Kosten- und Nutzungsübersicht. Dark blue caps on bars.
|
||||
|
||||
Typography: clean geometric sans-serif, high legibility, no watermark, no stock photo people, no clutter.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Kurz-Prompt (Iteration / Stil-Fix)
|
||||
|
||||
```
|
||||
Same layout as a McKinsey-style architecture infographic: rocket left, five layered segments, five matching explanation cards center, two slim governance columns with vertical German labels. Colors: corporate blues #12579b and #1976d2, light grey background, orange accent only for data layer flame. Flat vector, crisp edges, presentation-ready.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Negativ / Vermeiden (an den Bild-Prompt anhängen)
|
||||
|
||||
```
|
||||
Avoid: 3D photorealistic rocket, cartoon style, low resolution, illegible micro-text, English-only text, logos of OpenAI/Google/Microsoft, busy backgrounds, isometric clutter, more than five main layers.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Text-Prompt für Gemini (Copy-Feinschliff, kein Bild)
|
||||
|
||||
```
|
||||
Du bist Redakteur für ein deutschsprachiges Enterprise-Pitchdeck. Überprüfe die fünf Schichten eines "KI-Betriebssystems" (Interface, Orchestrierung/Agenten, Skills/Tools, Modelle, Daten/Kontext) plus die beiden Querschnittsthemen Regeln & Steuerung und Transparenz & Kontrolle. Schlage je Schicht maximal zwei prägnante Bulletpoints vor (jeweils unter 90 Zeichen), konsistent mit PowerOn-Messaging (Plattform, Governance, schnelle Lieferung, Auditierbarkeit). Gib nur die optimierte Liste aus, keine Einleitung.
|
||||
```
|
||||
467
docs/poweron-ki-betriebssystem-slide.html
Normal file
467
docs/poweron-ki-betriebssystem-slide.html
Normal file
|
|
@ -0,0 +1,467 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="de-CH">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=1920">
|
||||
<title>PowerOn – Das moderne KI-Betriebssystem (16:9)</title>
|
||||
<style>
|
||||
:root {
|
||||
--po-blue: #1976d2;
|
||||
--po-blue-dark: #12579b;
|
||||
--po-seg-light: #b8d4f0;
|
||||
--po-seg-cream: #f0ebe3;
|
||||
--po-flame: #f57c00;
|
||||
--po-flame-light: #ff9800;
|
||||
--text: #1a1a2e;
|
||||
--text-muted: #5c5c6f;
|
||||
--bg: #f8fafc;
|
||||
--card: #ffffff;
|
||||
--icon: rgba(255, 255, 255, 0.95);
|
||||
--icon-dark: #12579b;
|
||||
}
|
||||
*, *::before, *::after { box-sizing: border-box; }
|
||||
body {
|
||||
margin: 0;
|
||||
min-height: 100vh;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
background: #e2e8f0;
|
||||
font-family: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
|
||||
color: var(--text);
|
||||
}
|
||||
.stage {
|
||||
width: 1920px;
|
||||
height: 1080px;
|
||||
background: var(--bg);
|
||||
overflow: hidden;
|
||||
flex-shrink: 0;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
padding: 28px 36px 32px;
|
||||
box-shadow: 0 8px 40px rgba(0, 0, 0, 0.12);
|
||||
}
|
||||
.slide-header {
|
||||
text-align: center;
|
||||
margin-bottom: 18px;
|
||||
}
|
||||
.slide-header h1 {
|
||||
margin: 0;
|
||||
font-size: 2.05rem;
|
||||
font-weight: 700;
|
||||
letter-spacing: -0.02em;
|
||||
color: var(--po-blue-dark);
|
||||
}
|
||||
.slide-header p {
|
||||
margin: 6px 0 0;
|
||||
font-size: 1.15rem;
|
||||
font-weight: 600;
|
||||
color: var(--po-blue);
|
||||
}
|
||||
.slide-grid {
|
||||
flex: 1;
|
||||
min-height: 0;
|
||||
display: grid;
|
||||
grid-template-columns: 78px 210px 46px minmax(0, 1fr) 78px;
|
||||
grid-template-rows: repeat(5, minmax(0, 1fr));
|
||||
gap: 0 0;
|
||||
column-gap: 0;
|
||||
}
|
||||
/* Governance columns */
|
||||
.gov {
|
||||
grid-row: 1 / -1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
background: var(--card);
|
||||
border-radius: 10px;
|
||||
border: 1px solid #e2e8f0;
|
||||
box-shadow: 0 2px 12px rgba(18, 87, 155, 0.06);
|
||||
padding: 12px 8px;
|
||||
position: relative;
|
||||
}
|
||||
.gov::before,
|
||||
.gov::after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 4px;
|
||||
right: 4px;
|
||||
height: 10px;
|
||||
background: var(--po-blue-dark);
|
||||
border-radius: 3px;
|
||||
}
|
||||
.gov::before { top: 8px; }
|
||||
.gov::after { bottom: 8px; }
|
||||
.gov-left { grid-column: 1; }
|
||||
.gov-right { grid-column: 5; }
|
||||
.gov-title {
|
||||
writing-mode: vertical-rl;
|
||||
transform: rotate(180deg);
|
||||
font-size: 0.95rem;
|
||||
font-weight: 700;
|
||||
color: var(--po-blue-dark);
|
||||
letter-spacing: 0.04em;
|
||||
text-align: center;
|
||||
flex: 0 0 auto;
|
||||
max-height: 62%;
|
||||
}
|
||||
.gov-sub {
|
||||
font-size: 0.62rem;
|
||||
line-height: 1.35;
|
||||
color: var(--text-muted);
|
||||
text-align: center;
|
||||
padding: 10px 2px 0;
|
||||
writing-mode: horizontal-tb;
|
||||
max-width: 100%;
|
||||
}
|
||||
/* Per-row cells: col 2 = rocket tier, col 3 = ribbon, col 4 = card */
|
||||
.rocket-tier {
|
||||
grid-column: 2;
|
||||
position: relative;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
margin: 0 8px;
|
||||
min-height: 0;
|
||||
}
|
||||
.rocket-tier .tier-body {
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
min-height: 72px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
position: relative;
|
||||
}
|
||||
.rocket-tier.t-interface .tier-body {
|
||||
background: var(--po-blue-dark);
|
||||
border-radius: 14px 14px 0 0;
|
||||
margin-top: 38px;
|
||||
}
|
||||
.rocket-nose {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-left: 52px solid transparent;
|
||||
border-right: 52px solid transparent;
|
||||
border-bottom: 42px solid var(--po-blue-dark);
|
||||
z-index: 1;
|
||||
}
|
||||
.rocket-tier.t-interface { align-items: flex-end; padding-top: 0; }
|
||||
.rocket-tier.t-interface .wrap { position: relative; width: 100%; height: 100%; display: flex; flex-direction: column; align-items: center; }
|
||||
.rocket-tier.t-orch .tier-body { background: var(--po-blue); }
|
||||
.rocket-tier.t-skills .tier-body { background: var(--po-seg-light); }
|
||||
.rocket-tier.t-skills .tier-label { color: var(--po-blue-dark); text-shadow: none; }
|
||||
.rocket-tier.t-models .tier-body {
|
||||
background: var(--po-seg-cream);
|
||||
border-radius: 0 0 6px 6px;
|
||||
}
|
||||
.rocket-tier.t-models .fin {
|
||||
position: absolute;
|
||||
bottom: 8px;
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-style: solid;
|
||||
z-index: 0;
|
||||
}
|
||||
.rocket-tier.t-models .fin-l {
|
||||
left: -20px;
|
||||
border-width: 0 22px 56px 0;
|
||||
border-color: transparent var(--po-blue-dark) transparent transparent;
|
||||
}
|
||||
.rocket-tier.t-models .fin-r {
|
||||
right: -20px;
|
||||
border-width: 0 0 56px 22px;
|
||||
border-color: transparent transparent transparent var(--po-blue-dark);
|
||||
}
|
||||
.rocket-tier.t-data .tier-body {
|
||||
background: linear-gradient(180deg, var(--po-flame-light) 0%, var(--po-flame) 100%);
|
||||
clip-path: polygon(15% 0%, 85% 0%, 100% 100%, 50% 85%, 0% 100%);
|
||||
min-height: 64px;
|
||||
margin-top: 2px;
|
||||
}
|
||||
.tier-label {
|
||||
position: absolute;
|
||||
bottom: 6px;
|
||||
left: 0;
|
||||
right: 0;
|
||||
text-align: center;
|
||||
font-size: 0.65rem;
|
||||
font-weight: 700;
|
||||
color: rgba(255, 255, 255, 0.92);
|
||||
text-shadow: 0 1px 2px rgba(0, 0, 0, 0.2);
|
||||
pointer-events: none;
|
||||
}
|
||||
.rocket-tier.t-models .tier-label,
|
||||
.rocket-tier.t-data .tier-label { color: var(--po-blue-dark); text-shadow: none; }
|
||||
.rocket-tier.t-data .tier-label { color: #fff; bottom: 10px; }
|
||||
/* Ribbons */
|
||||
.ribbon {
|
||||
grid-column: 3;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: flex-start;
|
||||
padding-left: 2px;
|
||||
}
|
||||
.ribbon-inner {
|
||||
width: 100%;
|
||||
height: 72%;
|
||||
min-height: 48px;
|
||||
position: relative;
|
||||
background: linear-gradient(180deg, rgba(255, 255, 255, 0.5) 0%, rgba(0, 0, 0, 0.04) 100%);
|
||||
transform: skewY(-2deg);
|
||||
border-radius: 0 4px 4px 0;
|
||||
box-shadow: inset -2px 0 4px rgba(0, 0, 0, 0.06), 2px 2px 6px rgba(18, 87, 155, 0.08);
|
||||
}
|
||||
.ribbon-inner::after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 0;
|
||||
top: 0;
|
||||
bottom: 0;
|
||||
width: 6px;
|
||||
border-radius: 2px;
|
||||
}
|
||||
.ribbon.row-1 .ribbon-inner::after { background: var(--po-blue-dark); }
|
||||
.ribbon.row-2 .ribbon-inner::after { background: var(--po-blue); }
|
||||
.ribbon.row-3 .ribbon-inner::after { background: var(--po-seg-light); }
|
||||
.ribbon.row-4 .ribbon-inner::after { background: #c4b8a8; }
|
||||
.ribbon.row-5 .ribbon-inner::after { background: var(--po-flame); }
|
||||
/* Cards */
|
||||
.layer-card {
|
||||
display: flex;
|
||||
align-items: stretch;
|
||||
margin: 4px 0 4px 10px;
|
||||
min-height: 0;
|
||||
}
|
||||
.layer-card .card-shell {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
background: var(--card);
|
||||
border-radius: 12px;
|
||||
border: 1px solid #e2e8f0;
|
||||
box-shadow: 0 2px 14px rgba(25, 118, 210, 0.07);
|
||||
overflow: hidden;
|
||||
min-height: 0;
|
||||
}
|
||||
.layer-card .tab {
|
||||
width: 14px;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
.layer-card.row-1 .tab { background: var(--po-blue-dark); }
|
||||
.layer-card.row-2 .tab { background: var(--po-blue); }
|
||||
.layer-card.row-3 .tab { background: var(--po-seg-light); }
|
||||
.layer-card.row-4 .tab { background: #c4b8a8; }
|
||||
.layer-card.row-5 .tab { background: linear-gradient(180deg, var(--po-flame-light), var(--po-flame)); }
|
||||
.layer-card .card-body {
|
||||
padding: 10px 16px 10px 14px;
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
}
|
||||
.layer-card h3 {
|
||||
margin: 0 0 2px;
|
||||
font-size: 0.98rem;
|
||||
font-weight: 700;
|
||||
color: var(--po-blue-dark);
|
||||
line-height: 1.2;
|
||||
}
|
||||
.layer-card .sub {
|
||||
margin: 0 0 6px;
|
||||
font-size: 0.78rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.layer-card ul {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
list-style: none;
|
||||
}
|
||||
.layer-card li {
|
||||
font-size: 0.76rem;
|
||||
line-height: 1.4;
|
||||
color: var(--text);
|
||||
padding-left: 0.85em;
|
||||
text-indent: -0.85em;
|
||||
}
|
||||
.layer-card li + li { margin-top: 2px; }
|
||||
/* Row placement (row-N on same element as component) */
|
||||
.rocket-tier.row-1, .ribbon.row-1, .layer-card.row-1 { grid-row: 1; }
|
||||
.rocket-tier.row-2, .ribbon.row-2, .layer-card.row-2 { grid-row: 2; }
|
||||
.rocket-tier.row-3, .ribbon.row-3, .layer-card.row-3 { grid-row: 3; }
|
||||
.rocket-tier.row-4, .ribbon.row-4, .layer-card.row-4 { grid-row: 4; }
|
||||
.rocket-tier.row-5, .ribbon.row-5, .layer-card.row-5 { grid-row: 5; }
|
||||
.rocket-tier { grid-column: 2; }
|
||||
.ribbon { grid-column: 3; }
|
||||
.layer-card { grid-column: 4; }
|
||||
/* SVG icons */
|
||||
.tier-icon { width: 44px; height: 44px; color: var(--icon); }
|
||||
.rocket-tier.t-models .tier-icon,
|
||||
.rocket-tier.t-skills .tier-icon { color: var(--icon-dark); }
|
||||
.rocket-tier.t-data .tier-icon { color: #fff; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="stage" role="img" aria-label="Infografik: Das moderne KI-Betriebssystem PowerOn mit fünf Schichten und Governance-Säulen">
|
||||
<header class="slide-header">
|
||||
<h1>Das moderne KI-Betriebssystem</h1>
|
||||
<p>PowerOn</p>
|
||||
</header>
|
||||
|
||||
<div class="slide-grid">
|
||||
<aside class="gov gov-left">
|
||||
<div class="gov-title">Regeln & Steuerung</div>
|
||||
<div class="gov-sub">Zugriffsrechte & Rollen, Entscheidungsgrenzen, Validierung & Freigaben</div>
|
||||
</aside>
|
||||
|
||||
<!-- Row 1: Interface -->
|
||||
<div class="row-1 rocket-tier t-interface">
|
||||
<div class="wrap" style="width:100%;height:100%;">
|
||||
<div class="rocket-nose" aria-hidden="true"></div>
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<circle cx="24" cy="24" r="16" stroke-opacity="0.35"/>
|
||||
<path d="M24 12 v8 M24 28 v8 M12 24 h8 M28 24 h8"/>
|
||||
<circle cx="24" cy="24" r="6"/>
|
||||
</svg>
|
||||
<span class="tier-label">Interface</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-1 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-1 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Interface Layer (Interaktion)</h3>
|
||||
<p class="sub">Einstiegspunkt für User & Systeme</p>
|
||||
<ul>
|
||||
<li>➔ Chat, Spracheingabe, Oberflächen</li>
|
||||
<li>➔ API & Webhooks</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 2: Orchestrierung -->
|
||||
<div class="row-2 rocket-tier t-orch">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<rect x="8" y="22" width="18" height="16" rx="2"/>
|
||||
<path d="M26 26 h10 M26 30 h10 M26 34 h10"/>
|
||||
<circle cx="38" cy="18" r="5"/>
|
||||
<path d="M33 22 L36 20 M26 22 L22 18"/>
|
||||
</svg>
|
||||
<span class="tier-label">Orchestrierung</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-2 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-2 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Orchestrierung & Agenten</h3>
|
||||
<p class="sub">Entscheiden & Abläufe planen</p>
|
||||
<ul>
|
||||
<li>➔ Aufgaben delegieren</li>
|
||||
<li>➔ Skills & Tools koordinieren</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 3: Skills -->
|
||||
<div class="row-3 rocket-tier t-skills">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<path d="M14 32 c8 -4 12 -12 12 -20 c0 -4 -2 -6 -5 -6 c-4 0 -7 4 -7 10 c0 6 4 10 10 10 z"/>
|
||||
<circle cx="30" cy="22" r="9"/>
|
||||
<path d="M30 16 v12 M24 22 h12"/>
|
||||
</svg>
|
||||
<span class="tier-label">Skills</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-3 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-3 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Skill- & Tool-Layer</h3>
|
||||
<p class="sub">Ausführung konkreter Aufgaben</p>
|
||||
<ul>
|
||||
<li>➔ Prozesse, Aktionen, Integration</li>
|
||||
<li>➔ API-Aufrufe, Funktionen & Automationen</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 4: Modelle -->
|
||||
<div class="row-4 rocket-tier t-models">
|
||||
<span class="fin fin-l" aria-hidden="true"></span>
|
||||
<span class="fin fin-r" aria-hidden="true"></span>
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<path d="M12 38 L22 10 L38 38 Z M18 28 h14"/>
|
||||
<line x1="26" y1="18" x2="32" y2="32"/>
|
||||
</svg>
|
||||
<span class="tier-label">Modelle</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-4 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-4 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>KI-Modelle</h3>
|
||||
<p class="sub">Spezialisierte Modelle</p>
|
||||
<ul>
|
||||
<li>➔ Generierung, Analyse & Klassifikation</li>
|
||||
<li>➔ Ausführung einzelner „Denkschritte“</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 5: Daten -->
|
||||
<div class="row-5 rocket-tier t-data">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<rect x="10" y="8" width="22" height="28" rx="2"/>
|
||||
<line x1="14" y1="16" x2="28" y2="16"/>
|
||||
<line x1="14" y1="22" x2="26" y2="22"/>
|
||||
<circle cx="34" cy="30" r="9"/>
|
||||
<line x1="40" y1="36" x2="44" y2="40" stroke-linecap="round"/>
|
||||
</svg>
|
||||
<span class="tier-label">Daten</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-5 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-5 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Daten- & Kontextschicht</h3>
|
||||
<p class="sub">Dokumente & Wissen</p>
|
||||
<ul>
|
||||
<li>➔ Vektordatenbanken</li>
|
||||
<li>➔ Retrieval & Historien</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<aside class="gov gov-right">
|
||||
<div class="gov-title">Transparenz & Kontrolle</div>
|
||||
<div class="gov-sub">Nachvollziehbarkeit, Qualitätssicherung, Kosten- und Nutzungsübersicht</div>
|
||||
</aside>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
176
docs/poweron-launch48-offer.md
Normal file
176
docs/poweron-launch48-offer.md
Normal file
|
|
@ -0,0 +1,176 @@
|
|||
# PowerOn Launch48
|
||||
**Ihre erste produktive KI-Loesung auf der PowerOn-Plattform – in 48 Stunden.**
|
||||
|
||||
*Zum Weitergeben an Kundinnen und Kunden. Verstaendlich fuer Geschaeftsfuehrung, Fachbereiche und IT.*
|
||||
|
||||
---
|
||||
|
||||
## Warum viele Unternehmen bei KI noch zoegern
|
||||
|
||||
Daten liegen heute oft **verteilt**: in Ordnern, Mails, Ticketsystemen und Fachapplikationen. Gleichzeitig wuenschen sich Teams **schnellere Antworten** und **weniger manuelle Routine**.
|
||||
|
||||
Viele erste KI-Versuche scheitern nicht an der Technik allein, sondern daran, dass
|
||||
|
||||
- **kein klarer Anwendungsfall** im Fokus steht,
|
||||
- **wichtige Unterlagen** nicht sicher und gezielt genutzt werden,
|
||||
- **generische Chat-Tools** ohne Freigaben genutzt werden – mit Risiko fuer Datenschutz und Qualitaet,
|
||||
- **lange Vorprojekte** geplant werden, bevor ueberhaupt etwas Greifbares entsteht.
|
||||
|
||||
**PowerOn Launch48** ist das Gegenteil davon: ein **fokussiertes Paket** mit klarem Ablauf, **Fixpreis** und einem **konkreten Ergebnis** auf **Ihrer** PowerOn-Umgebung.
|
||||
|
||||
---
|
||||
|
||||
## Was PowerOn ist – in einem Satz
|
||||
|
||||
**PowerOn** ist eine **Unternehmensplattform fuer kuenstliche Intelligenz**: Teams arbeiten mit KI **dort, wo Ihre Informationen und Prozesse ohnehin sind** – mit klaren Rollen, nachvollziehbaren Ablaeufen und ohne dass Sie die Kontrolle ueber sensible Inhalte verlieren.
|
||||
|
||||
Mehr zur Plattform: [product-teaser-poweron.md](./product-teaser-poweron.md) (interne Vertiefung).
|
||||
|
||||
---
|
||||
|
||||
## Was Sie mit Launch48 bekommen
|
||||
|
||||
**Am Ende steht keine Theorie, sondern etwas Greifbares:** eine **einsatznahe KI-Loesung** auf der **PowerOn-Plattform** – typischerweise Ihr erster **KI-Assistent** fuer **einen** klar abgegrenzten Prozess, mit **Ihren freigegebenen Daten** und – im vereinbarten Rahmen – einer **Systemanbindung**. Details zum Ablauf folgen im naechsten Abschnitt.
|
||||
|
||||
Damit koennen Sie **realistisch einschaetzen**, welchen Nutzen KI in **Ihrem** Unternehmen bringt – und darauf aufbauen.
|
||||
|
||||
---
|
||||
|
||||
## Der Ablauf: vier Phasen, 48 Stunden, ein gemeinsames Team
|
||||
|
||||
**Kopfzeile (z. B. fuer Praesentation / Folie):** *Vier Phasen · 48 Stunden · gemeinsam mit Ihrem Team*
|
||||
|
||||
**Subline:** *Ein Workspace. Ihre Daten. Die passenden KI-Faehigkeiten. Gebündelt auf PowerOn.*
|
||||
|
||||
Die **48 Stunden** sind der **konzentrierte Umsetzungsblock**. Davor liegt eine **kurze Vorbereitung** (Discovery, Architektur, Freigaben); danach ein **Pilot** mit ausgewaehlten Nutzerinnen und Nutzern, in dem wir die **vereinbarten Erfolgsziele** messen.
|
||||
|
||||
### Phase 1: Discovery
|
||||
|
||||
**Gemeinsame Analyse Ihrer Prozesse.** Wir identifizieren den Anwendungsfall mit dem groessten **Automatisierungs- bzw. Entlastungspotenzial** – so, dass er **messbar** und **in 48 Stunden realistisch** umsetzbar ist (z. B. wiederkehrende Anfragen, Erstbearbeitungen, standardisierte Pruefschritte).
|
||||
|
||||
**Ergebnis:** Ein **scharf umrissener Use-Case** und klare Erwartungen.
|
||||
|
||||
### Phase 2: Design und Architektur
|
||||
|
||||
**KI-Architektur, Datenmodell und Integration auf der PowerOn-Plattform.** Wir legen fest, **welche Datenquellen** und **welche Anbindung** im Paketrahmen vorgesehen sind. Zentral: die **messbaren Erfolgsziele**, die **vor dem Start schriftlich fixiert** werden und ueber die **zweite Zahlungsstufe** (CHF 7’000) entscheiden – damit Einkauf, Fachbereich und IT dieselbe Sprache sprechen.
|
||||
|
||||
**Ergebnis:** **Fester Plan** fuer Umsetzung und Abnahme.
|
||||
|
||||
### Phase 3: Build und Integration
|
||||
|
||||
**Entwicklung des KI-Assistenten, Anbindung an Ihre Systeme (im Vereinbarten), Testing.** Ihre **Fachanwenderinnen und -anwender** pruefen parallel zum Build mit (**„Mensch prueft mit“** statt reiner Black-Box) – mit realistischen **Testfaellen aus dem Alltag**.
|
||||
|
||||
**Ergebnis:** Stabile, einsatznahe Loesung vor dem Go-Live.
|
||||
|
||||
### Phase 4: Deploy und Handover
|
||||
|
||||
**Go-Live in Ihrer vereinbarten PowerOn-Umgebung** (Pilot- oder Produktions-Instanz je nach Vereinbarung – kein generisches „Internet-KI-Experiment“), **Wissenstransfer** und **Dokumentation**, damit Ihr Team den Assistenten **vom ersten Tag an** im vereinbarten Rahmen **selbst betreiben** kann.
|
||||
|
||||
**Ergebnis:** Uebergabe mit kurzer **Einweisung** und **Nachschlagewerk** fuer den Betrieb.
|
||||
|
||||
### Zeitlicher Ablauf auf einen Blick
|
||||
|
||||
| Phase | Inhalt |
|
||||
| --- | --- |
|
||||
| **Vorbereitung** | Discovery, Design/Architektur, Freigaben – in der Regel **einige Arbeitstage** vor dem 48h-Block |
|
||||
| **Umsetzung** | **48 Stunden** intensiv gemeinsam |
|
||||
| **Pilot** | z. B. **ca. 10 Arbeitstage** Messfenster fuer die vereinbarten Erfolgsziele (wie im Angebot festgelegt) |
|
||||
|
||||
### Am Ende liegen fuer Sie vor (Kernlieferobjekte)
|
||||
|
||||
- eine **funktionierende KI-Loesung** auf PowerOn fuer den **definierten** Anwendungsfall,
|
||||
- **konfigurierte Datenquellen** und **eine** Systemanbindung **im vereinbarten Umfang**,
|
||||
- **kurze Dokumentation** und **Einweisung** fuer Ihr Team.
|
||||
|
||||
### Rollen: Sie und wir
|
||||
|
||||
| | **Sie** | **Wir** |
|
||||
| --- | --- | --- |
|
||||
| **Verantwortung** | Fach-Owner, IT-Zugang, Freigaben (Datenschutz/Compliance nach Bedarf), **Pilotgruppe** | Architektur, Umsetzung, Qualitaet, Begleitung im 48h-Block |
|
||||
|
||||
**Vertrauen in einem Satz:** Kein undurchsichtiges Einzel-Tool im Browser – sondern **PowerOn** mit **Ihren freigegebenen Daten** und **klaren Grenzen**.
|
||||
|
||||
---
|
||||
|
||||
## Fuer wen ist Launch48 gedacht?
|
||||
|
||||
Launch48 richtet sich an Organisationen, die **wissen, dass KI relevant ist**, aber **noch keinen einfachen Weg** gefunden haben, **schnell und kontrolliert** zu starten – oder die **bereits eine Idee** haben und diese **in Wochen, nicht Monaten** greifbar machen wollen.
|
||||
|
||||
**Typische Situationen:**
|
||||
|
||||
- Viele **wiederkehrende Anfragen** (Kundenservice, interne Support-Themen, Fachfragen).
|
||||
- **Wissen in Dokumenten**, das immer wieder neu gesucht und zusammengefasst wird.
|
||||
- **Bedarf an Geschwindigkeit** ohne monatelange Evaluationsprojekte.
|
||||
- **Wuensche nach Kontrolle** ueber Daten und Rollen statt „KI irgendwo im Browser“.
|
||||
|
||||
---
|
||||
|
||||
## Investition – einfach und planbar
|
||||
|
||||
| | Betrag | Wann |
|
||||
| --- | --- | --- |
|
||||
| **Gesamtpaket** | **CHF 9’000** (zzgl. MWSt. falls anwendbar) | Fixpreis fuer das vereinbarte Paket |
|
||||
| **Zu Beginn** | **CHF 2’000** | Wenn Sie starten und wir die Umsetzung freigeben |
|
||||
| **Nach dem Pilot** | **CHF 7’000** | Wenn die **gemeinsam festgelegten Erfolgsziele** im vereinbarten Messzeitraum erreicht sind |
|
||||
|
||||
**Was bedeutet das fuer Sie?** Der Preis ist bewusst **frueh transparent**, weil Launch48 kein offenes Beratungsprojekt ist, sondern ein **klar abgegrenztes Paket**. Sie investieren zu Beginn einen **kleineren Teil**. Der groessere Teil ist an **messbare, vorab beschriebene Ziele** geknuepft – z. B. Zeitersparnis pro typischem Vorgang, Zufriedenheit der Pilotgruppe oder Fehlerquote. **Genau diese Ziele** legen wir **vor dem Start** schriftlich fest, damit alle dasselbe verstehen.
|
||||
|
||||
So wird aus der Zahl kein Risikozeichen, sondern ein **Vertrauenssignal**: klarer Rahmen, klares Ergebnis, klare Abnahme. Details und Grenzen des Pakets besprechen wir **transparent** im Erstgespraech (Umfang der Datenquellen, eine Systemanbindung im Standardrahmen, Groesse der Pilotgruppe).
|
||||
|
||||
---
|
||||
|
||||
## Was Sie von uns erwarten koennen
|
||||
|
||||
- **Erfahrene Begleitung** von Anfang bis Pilotende
|
||||
- **Klare Kommunikation** – wenig Buzzwords, viel Nutzen
|
||||
- **PowerOn als Plattform** – skalierbar, wenn Sie verlaengern moechten
|
||||
- **Respekt vor Ihren Freigaben** – Datenschutz und IT-Security ernst nehmen
|
||||
|
||||
---
|
||||
|
||||
## Ihr naechster Schritt
|
||||
|
||||
**Kurzes Erstgespraech (ca. 15–30 Minuten):** Passt Ihr Thema zu Launch48? Wir sagen Ihnen ehrlich **ja, nein oder noch nicht**.
|
||||
|
||||
**Kontakt**
|
||||
|
||||
- **Web:** [www.poweron.swiss](https://www.poweron.swiss)
|
||||
- **Adresse:** PowerOn AG, Birmensdorferstrasse 94, 8003 Zuerich, Schweiz
|
||||
|
||||
**Ansprechpartner**
|
||||
|
||||
- Patrick Motsch
|
||||
- Ida Dittrich
|
||||
- Stephan Schellworth
|
||||
|
||||
*Bitte ersetzen Sie bei Bedarf durch eine zentrale E-Mail-Adresse oder Buchungslink fuer Ihr Vertriebsteam.*
|
||||
|
||||
---
|
||||
|
||||
## Hauefige Fragen (kurz)
|
||||
|
||||
**Brauchen wir schon PowerOn?**
|
||||
Wir klaeren mit Ihnen, ob eine **Pilot-Umgebung** oder Ihre bestehende Instanz passt.
|
||||
|
||||
**Ist das nur ein Prototyp?**
|
||||
Nein – Ziel ist eine **einsatznahe Loesung** fuer einen **definierten** Anwendungsfall. Was **nicht** im Paket liegt (z. B. Rollout auf die ganze Firma), sagen wir klar dazu.
|
||||
|
||||
**Was, wenn unsere IT Zeit braucht?**
|
||||
Dann verschieben wir den Start – **Zugang und Freigaben** muessen passen, sonst wird niemand gluecklich.
|
||||
|
||||
**Duerfen wir das Dokument weitergeben?**
|
||||
Ja. Es ist dafuer gedacht, intern weiterzureichen (Geschaeftsfuehrung, Fachbereich, IT).
|
||||
|
||||
---
|
||||
|
||||
## Weitere Unterlagen (optional)
|
||||
|
||||
- **Onepager im Browser (HTML, teilbar):** [launch48-offer-page.html](./launch48-offer-page.html)
|
||||
- **4-Folien-Deck (Copy fuer PDF/Canva/PPT):** [launch48-deck-presentation.md](./launch48-deck-presentation.md)
|
||||
- **Kurzfassung zum Drucken:** [flyer-poweron-48h-agent.md](./flyer-poweron-48h-agent.md)
|
||||
- **Technisches Vertiefungs- und Lieferkonzept (intern):** [concept-poweron-48h-agent-offer.md](./concept-poweron-48h-agent-offer.md)
|
||||
- **Beispiel-Verlauf (Illustration, kein Echt-Kunde):** [case-study-poweron-48h-agent.md](./case-study-poweron-48h-agent.md)
|
||||
|
||||
---
|
||||
|
||||
*PowerOn Launch48 – strukturiert vorbereitet, in 48 Stunden umgesetzt, messbar abgeschlossen.*
|
||||
529
docs/poweron-plattform-layer-schaubild.html
Normal file
529
docs/poweron-plattform-layer-schaubild.html
Normal file
|
|
@ -0,0 +1,529 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="de-CH">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=1920">
|
||||
<title>PowerOn – Die KI-Plattform (Layer-Schaubild, 16:9)</title>
|
||||
<style>
|
||||
:root {
|
||||
--po-blue: #1976d2;
|
||||
--po-blue-dark: #12579b;
|
||||
--po-industry: #4a8ec8;
|
||||
--po-seg-light: #b8d4f0;
|
||||
--po-seg-cream: #f0ebe3;
|
||||
--po-flame: #f57c00;
|
||||
--po-flame-light: #ff9800;
|
||||
--text: #1a1a2e;
|
||||
--text-muted: #5c5c6f;
|
||||
--bg: #f8fafc;
|
||||
--card: #ffffff;
|
||||
--icon: rgba(255, 255, 255, 0.95);
|
||||
--icon-dark: #12579b;
|
||||
}
|
||||
*, *::before, *::after { box-sizing: border-box; }
|
||||
body {
|
||||
margin: 0;
|
||||
min-height: 100vh;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
background: #e2e8f0;
|
||||
font-family: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
|
||||
color: var(--text);
|
||||
}
|
||||
.stage {
|
||||
width: 1920px;
|
||||
height: 1080px;
|
||||
background: var(--bg);
|
||||
overflow: hidden;
|
||||
flex-shrink: 0;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
padding: 20px 32px 24px;
|
||||
box-shadow: 0 8px 40px rgba(0, 0, 0, 0.12);
|
||||
}
|
||||
.slide-header {
|
||||
text-align: center;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
.brand-row {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
gap: 16px;
|
||||
margin-bottom: 4px;
|
||||
}
|
||||
.brand-mark {
|
||||
font-size: 0.95rem;
|
||||
font-weight: 800;
|
||||
letter-spacing: 0.22em;
|
||||
color: var(--po-blue-dark);
|
||||
text-transform: uppercase;
|
||||
border: 2px solid var(--po-blue-dark);
|
||||
padding: 6px 14px 6px 18px;
|
||||
border-radius: 4px;
|
||||
line-height: 1;
|
||||
}
|
||||
.slide-header h1 {
|
||||
margin: 0;
|
||||
font-size: 1.85rem;
|
||||
font-weight: 700;
|
||||
letter-spacing: -0.02em;
|
||||
color: var(--po-blue-dark);
|
||||
}
|
||||
.slide-header .tagline {
|
||||
margin: 4px 0 0;
|
||||
font-size: 0.98rem;
|
||||
font-weight: 600;
|
||||
color: var(--po-blue);
|
||||
max-width: 920px;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
line-height: 1.35;
|
||||
}
|
||||
.slide-grid {
|
||||
flex: 1;
|
||||
min-height: 0;
|
||||
display: grid;
|
||||
grid-template-columns: 82px 200px 42px minmax(0, 1fr) 82px;
|
||||
grid-template-rows: repeat(6, minmax(0, 1fr));
|
||||
gap: 0;
|
||||
}
|
||||
.gov {
|
||||
grid-row: 1 / -1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
background: var(--card);
|
||||
border-radius: 10px;
|
||||
border: 1px solid #e2e8f0;
|
||||
box-shadow: 0 2px 12px rgba(18, 87, 155, 0.06);
|
||||
padding: 10px 6px;
|
||||
position: relative;
|
||||
}
|
||||
.gov::before,
|
||||
.gov::after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 4px;
|
||||
right: 4px;
|
||||
height: 10px;
|
||||
background: var(--po-blue-dark);
|
||||
border-radius: 3px;
|
||||
}
|
||||
.gov::before { top: 8px; }
|
||||
.gov::after { bottom: 8px; }
|
||||
.gov-left { grid-column: 1; }
|
||||
.gov-right { grid-column: 5; }
|
||||
.gov-title {
|
||||
writing-mode: vertical-rl;
|
||||
transform: rotate(180deg);
|
||||
font-size: 0.88rem;
|
||||
font-weight: 700;
|
||||
color: var(--po-blue-dark);
|
||||
letter-spacing: 0.04em;
|
||||
text-align: center;
|
||||
flex: 0 0 auto;
|
||||
max-height: 58%;
|
||||
}
|
||||
.gov-sub {
|
||||
font-size: 0.6rem;
|
||||
line-height: 1.34;
|
||||
color: var(--text-muted);
|
||||
text-align: center;
|
||||
padding: 8px 2px 0;
|
||||
writing-mode: horizontal-tb;
|
||||
max-width: 100%;
|
||||
}
|
||||
.rocket-tier {
|
||||
grid-column: 2;
|
||||
position: relative;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
margin: 0 6px;
|
||||
min-height: 0;
|
||||
}
|
||||
.rocket-tier .tier-body {
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
min-height: 52px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
position: relative;
|
||||
}
|
||||
.rocket-tier.t-interface .tier-body {
|
||||
background: var(--po-blue-dark);
|
||||
border-radius: 12px 12px 0 0;
|
||||
margin-top: 32px;
|
||||
}
|
||||
.rocket-nose {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-left: 48px solid transparent;
|
||||
border-right: 48px solid transparent;
|
||||
border-bottom: 36px solid var(--po-blue-dark);
|
||||
z-index: 1;
|
||||
}
|
||||
.rocket-tier.t-interface { align-items: flex-end; padding-top: 0; }
|
||||
.rocket-tier.t-interface .wrap {
|
||||
position: relative;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
}
|
||||
.rocket-tier.t-orch .tier-body { background: var(--po-blue); }
|
||||
.rocket-tier.t-industry .tier-body { background: var(--po-industry); }
|
||||
.rocket-tier.t-skills .tier-body { background: var(--po-seg-light); }
|
||||
.rocket-tier.t-skills .tier-label { color: var(--po-blue-dark); text-shadow: none; }
|
||||
.rocket-tier.t-models .tier-body {
|
||||
background: var(--po-seg-cream);
|
||||
border-radius: 0 0 6px 6px;
|
||||
}
|
||||
.rocket-tier.t-models .fin {
|
||||
position: absolute;
|
||||
bottom: 6px;
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-style: solid;
|
||||
z-index: 0;
|
||||
}
|
||||
.rocket-tier.t-models .fin-l {
|
||||
left: -18px;
|
||||
border-width: 0 20px 48px 0;
|
||||
border-color: transparent var(--po-blue-dark) transparent transparent;
|
||||
}
|
||||
.rocket-tier.t-models .fin-r {
|
||||
right: -18px;
|
||||
border-width: 0 0 48px 20px;
|
||||
border-color: transparent transparent transparent var(--po-blue-dark);
|
||||
}
|
||||
.rocket-tier.t-data .tier-body {
|
||||
background: linear-gradient(180deg, var(--po-flame-light) 0%, var(--po-flame) 100%);
|
||||
clip-path: polygon(15% 0%, 85% 0%, 100% 100%, 50% 85%, 0% 100%);
|
||||
min-height: 52px;
|
||||
margin-top: 2px;
|
||||
}
|
||||
.tier-label {
|
||||
position: absolute;
|
||||
bottom: 4px;
|
||||
left: 0;
|
||||
right: 0;
|
||||
text-align: center;
|
||||
font-size: 0.58rem;
|
||||
font-weight: 700;
|
||||
color: rgba(255, 255, 255, 0.92);
|
||||
text-shadow: 0 1px 2px rgba(0, 0, 0, 0.2);
|
||||
pointer-events: none;
|
||||
line-height: 1.1;
|
||||
padding: 0 2px;
|
||||
}
|
||||
.rocket-tier.t-skills .tier-label,
|
||||
.rocket-tier.t-models .tier-label { color: var(--po-blue-dark); text-shadow: none; }
|
||||
.rocket-tier.t-data .tier-label { color: #fff; bottom: 8px; }
|
||||
.ribbon {
|
||||
grid-column: 3;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: flex-start;
|
||||
padding-left: 2px;
|
||||
}
|
||||
.ribbon-inner {
|
||||
width: 100%;
|
||||
height: 70%;
|
||||
min-height: 40px;
|
||||
position: relative;
|
||||
background: linear-gradient(180deg, rgba(255, 255, 255, 0.5) 0%, rgba(0, 0, 0, 0.04) 100%);
|
||||
transform: skewY(-2deg);
|
||||
border-radius: 0 4px 4px 0;
|
||||
box-shadow: inset -2px 0 4px rgba(0, 0, 0, 0.06), 2px 2px 6px rgba(18, 87, 155, 0.08);
|
||||
}
|
||||
.ribbon-inner::after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 0;
|
||||
top: 0;
|
||||
bottom: 0;
|
||||
width: 6px;
|
||||
border-radius: 2px;
|
||||
}
|
||||
.ribbon.row-1 .ribbon-inner::after { background: var(--po-blue-dark); }
|
||||
.ribbon.row-2 .ribbon-inner::after { background: var(--po-blue); }
|
||||
.ribbon.row-3 .ribbon-inner::after { background: var(--po-industry); }
|
||||
.ribbon.row-4 .ribbon-inner::after { background: var(--po-seg-light); }
|
||||
.ribbon.row-5 .ribbon-inner::after { background: #c4b8a8; }
|
||||
.ribbon.row-6 .ribbon-inner::after { background: var(--po-flame); }
|
||||
.layer-card {
|
||||
display: flex;
|
||||
align-items: stretch;
|
||||
margin: 2px 0 2px 8px;
|
||||
min-height: 0;
|
||||
}
|
||||
.layer-card .card-shell {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
background: var(--card);
|
||||
border-radius: 10px;
|
||||
border: 1px solid #e2e8f0;
|
||||
box-shadow: 0 2px 12px rgba(25, 118, 210, 0.07);
|
||||
overflow: hidden;
|
||||
min-height: 0;
|
||||
}
|
||||
.layer-card .tab {
|
||||
width: 12px;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
.layer-card.row-1 .tab { background: var(--po-blue-dark); }
|
||||
.layer-card.row-2 .tab { background: var(--po-blue); }
|
||||
.layer-card.row-3 .tab { background: var(--po-industry); }
|
||||
.layer-card.row-4 .tab { background: var(--po-seg-light); }
|
||||
.layer-card.row-5 .tab { background: #c4b8a8; }
|
||||
.layer-card.row-6 .tab { background: linear-gradient(180deg, var(--po-flame-light), var(--po-flame)); }
|
||||
.layer-card .card-body {
|
||||
padding: 6px 12px 6px 10px;
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
}
|
||||
.layer-card h3 {
|
||||
margin: 0 0 1px;
|
||||
font-size: 0.92rem;
|
||||
font-weight: 700;
|
||||
color: var(--po-blue-dark);
|
||||
line-height: 1.2;
|
||||
}
|
||||
.layer-card .sub {
|
||||
margin: 0 0 4px;
|
||||
font-size: 0.72rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-muted);
|
||||
line-height: 1.25;
|
||||
}
|
||||
.layer-card ul {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
list-style: none;
|
||||
}
|
||||
.layer-card li {
|
||||
font-size: 0.71rem;
|
||||
line-height: 1.35;
|
||||
color: var(--text);
|
||||
padding-left: 0.85em;
|
||||
text-indent: -0.85em;
|
||||
}
|
||||
.layer-card li + li { margin-top: 1px; }
|
||||
.rocket-tier.row-1, .ribbon.row-1, .layer-card.row-1 { grid-row: 1; }
|
||||
.rocket-tier.row-2, .ribbon.row-2, .layer-card.row-2 { grid-row: 2; }
|
||||
.rocket-tier.row-3, .ribbon.row-3, .layer-card.row-3 { grid-row: 3; }
|
||||
.rocket-tier.row-4, .ribbon.row-4, .layer-card.row-4 { grid-row: 4; }
|
||||
.rocket-tier.row-5, .ribbon.row-5, .layer-card.row-5 { grid-row: 5; }
|
||||
.rocket-tier.row-6, .ribbon.row-6, .layer-card.row-6 { grid-row: 6; }
|
||||
.rocket-tier { grid-column: 2; }
|
||||
.ribbon { grid-column: 3; }
|
||||
.layer-card { grid-column: 4; }
|
||||
.tier-icon { width: 36px; height: 36px; color: var(--icon); }
|
||||
.rocket-tier.t-industry .tier-icon { color: var(--icon); }
|
||||
.rocket-tier.t-skills .tier-icon,
|
||||
.rocket-tier.t-models .tier-icon { color: var(--icon-dark); }
|
||||
.rocket-tier.t-data .tier-icon { color: #fff; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="stage" role="img" aria-label="Infografik: PowerOn KI-Plattform in sechs verständlichen Schichten für Entscheider">
|
||||
<header class="slide-header">
|
||||
<div class="brand-row">
|
||||
<span class="brand-mark" aria-hidden="true">PowerOn</span>
|
||||
</div>
|
||||
<h1>Die PowerOn KI-Plattform</h1>
|
||||
<p class="tagline">Eine Plattform für KI im Unternehmen – mit Kontrolle, klaren Kosten und Lösungen für echte Fachfragen.</p>
|
||||
</header>
|
||||
|
||||
<div class="slide-grid">
|
||||
<aside class="gov gov-left">
|
||||
<div class="gov-title">Sicherheit & Regeln</div>
|
||||
<div class="gov-sub">Wer darf was?<br>Getrennt pro Kunde / Mandant<br>Sensible Daten schützen<br>DSGVO: Auskunft & Löschen</div>
|
||||
</aside>
|
||||
|
||||
<!-- Row 1: Interface -->
|
||||
<div class="row-1 rocket-tier t-interface">
|
||||
<div class="wrap" style="width:100%;height:100%;">
|
||||
<div class="rocket-nose" aria-hidden="true"></div>
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<circle cx="24" cy="24" r="16" stroke-opacity="0.35"/>
|
||||
<path d="M24 12 v8 M24 28 v8 M12 24 h8 M28 24 h8"/>
|
||||
<circle cx="24" cy="24" r="6"/>
|
||||
</svg>
|
||||
<span class="tier-label">Zugang</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-1 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-1 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Zugang & Bedienung</h3>
|
||||
<p class="sub">So arbeiten Menschen und Systeme mit PowerOn</p>
|
||||
<ul>
|
||||
<li>➔ Chat, Arbeitsfläche, Sprache</li>
|
||||
<li>➔ Im Browser, als App, Anbindung an Ihre IT</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 2: Orchestrierung -->
|
||||
<div class="row-2 rocket-tier t-orch">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<rect x="8" y="22" width="18" height="16" rx="2"/>
|
||||
<path d="M26 26 h10 M26 30 h10 M26 34 h10"/>
|
||||
<circle cx="38" cy="18" r="5"/>
|
||||
<path d="M33 22 L36 20 M26 22 L22 18"/>
|
||||
</svg>
|
||||
<span class="tier-label">Steuerung</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-2 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-2 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Steuerung & KI-Helfer</h3>
|
||||
<p class="sub">Die KI plant Schritte und koordiniert das Weitere</p>
|
||||
<ul>
|
||||
<li>➔ Gespräche, Aufgaben und Abläufe im Griff</li>
|
||||
<li>➔ Übergibt Arbeit an Programme und Schnittstellen</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 3: Branchen -->
|
||||
<div class="row-3 rocket-tier t-industry">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<rect x="10" y="12" width="28" height="26" rx="2"/>
|
||||
<path d="M10 20 h28 M18 12 v8 M30 12 v8"/>
|
||||
<circle cx="18" cy="30" r="3"/>
|
||||
<circle cx="30" cy="30" r="3"/>
|
||||
</svg>
|
||||
<span class="tier-label">Branchen</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-3 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-3 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Fachlösungen</h3>
|
||||
<p class="sub">Vorgefertigt für konkrete Berufsfelder</p>
|
||||
<ul>
|
||||
<li>➔ Treuhand & Buchhaltung, Immobilien & Grundstücke</li>
|
||||
<li>➔ Coaching, Schulung, Unterstützung in Microsoft Teams</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 4: Skills & Automation -->
|
||||
<div class="row-4 rocket-tier t-skills">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<path d="M14 32 c8 -4 12 -12 12 -20 c0 -4 -2 -6 -5 -6 c-4 0 -7 4 -7 10 c0 6 4 10 10 10 z"/>
|
||||
<circle cx="30" cy="22" r="9"/>
|
||||
<path d="M30 16 v12 M24 22 h12"/>
|
||||
</svg>
|
||||
<span class="tier-label">Aktionen</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-4 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-4 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Automatisierung & Aktionen</h3>
|
||||
<p class="sub">Routine läuft, ohne dass alles manuell geklickt wird</p>
|
||||
<ul>
|
||||
<li>➔ Abläufe starten nach Zeitplan oder Ereignis (z. B. E-Mail)</li>
|
||||
<li>➔ Verbindet Microsoft, Google und weitere Tools</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 5: KI-Modelle -->
|
||||
<div class="row-5 rocket-tier t-models">
|
||||
<span class="fin fin-l" aria-hidden="true"></span>
|
||||
<span class="fin fin-r" aria-hidden="true"></span>
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<path d="M12 38 L22 10 L38 38 Z M18 28 h14"/>
|
||||
<line x1="26" y1="18" x2="32" y2="32"/>
|
||||
</svg>
|
||||
<span class="tier-label">Modelle</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-5 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-5 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>KI-Modelle</h3>
|
||||
<p class="sub">Sie wählen – nicht an einen einzigen Anbieter gebunden</p>
|
||||
<ul>
|
||||
<li>➔ Einsatz führender KI-Anbieter nach Bedarf</li>
|
||||
<li>➔ Eigene KI im eigenen Rechenzentrum möglich</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<!-- Row 6: Unified Data Bar -->
|
||||
<div class="row-6 rocket-tier t-data">
|
||||
<div class="tier-body">
|
||||
<svg class="tier-icon" viewBox="0 0 48 48" fill="none" stroke="currentColor" stroke-width="1.8" aria-hidden="true">
|
||||
<rect x="8" y="14" width="32" height="22" rx="2"/>
|
||||
<line x1="12" y1="20" x2="36" y2="20"/>
|
||||
<line x1="12" y1="25" x2="28" y2="25"/>
|
||||
<line x1="12" y1="30" x2="32" y2="30"/>
|
||||
<circle cx="38" cy="10" r="6"/>
|
||||
<path d="M40 12 l4 4" stroke-linecap="round"/>
|
||||
</svg>
|
||||
<span class="tier-label">Daten</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row-6 ribbon"><div class="ribbon-inner"></div></div>
|
||||
<article class="row-6 layer-card">
|
||||
<div class="card-shell">
|
||||
<div class="tab" aria-hidden="true"></div>
|
||||
<div class="card-body">
|
||||
<h3>Datenleiste & Wissen</h3>
|
||||
<p class="sub">Alle wichtigen Quellen an einem Ort für die KI</p>
|
||||
<ul>
|
||||
<li>➔ Dateien und Ablagen – sichtbar wie eine gemeinsame Leiste</li>
|
||||
<li>➔ Antworten mit Bezug zu Ihren Unterlagen & Gesprächen</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<aside class="gov gov-right">
|
||||
<div class="gov-title">Kosten & Nachvollziehbarkeit</div>
|
||||
<div class="gov-sub">Zahlen nach tatsächlicher Nutzung<br>Wer hat was gemacht?<br>Kosten pro Kunde / Mandant<br>Nachvollziehbare Entscheidungen</div>
|
||||
</aside>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
174
docs/product-teaser-billing-poweron.md
Normal file
174
docs/product-teaser-billing-poweron.md
Normal file
|
|
@ -0,0 +1,174 @@
|
|||
# PowerOn Billing Product Teaser - Recherche & Analyse
|
||||
|
||||
## Zusammenfassung der Recherche-Ergebnisse
|
||||
|
||||
### Abrechnungsmodelle
|
||||
PowerOn bietet **4 flexible Abrechnungsmodelle**, die auf unterschiedliche Unternehmensanforderungen zugeschnitten sind:
|
||||
|
||||
1. **PREPAY_MANDATE** - Gemeinsames Prepaid-Guthaben fuer das gesamte Mandat
|
||||
2. **PREPAY_USER** - Individuelles Prepaid-Guthaben pro Benutzer (Standard-Startguthaben: 10 CHF)
|
||||
3. **CREDIT_POSTPAY** - Kreditrahmen mit monatlicher Abrechnung (erfordert Rechnungsadresse)
|
||||
4. **UNLIMITED** - Unbegrenzt (nur fuer interne Mandate)
|
||||
|
||||
### Preisstruktur
|
||||
- **Pay-per-Use**: Abrechnung nach tatsaechlicher KI-Nutzung
|
||||
- **Transparente Aufschlaege**: 100% Markup auf Provider-Kosten (Faktor 2.0)
|
||||
- 50% fuer Infrastruktur und Platform Service
|
||||
- 50% fuer Waehrungsrisiko
|
||||
- **Waehrung**: Schweizer Franken (CHF)
|
||||
- **Aufladungsbetraege**: 10, 25, 50, 100, 250, 500 CHF
|
||||
- **Zahlungsmethode**: Stripe Checkout (Kreditkarte)
|
||||
|
||||
### Kernmerkmale
|
||||
- **Mandanten-basierte Abrechnung**: Isolierte Konten pro Mandat
|
||||
- **Echtzeit-Transparenz**: Sofortige Kostenzuordnung nach jedem KI-Aufruf
|
||||
- **Detaillierte Statistiken**: Nach Provider, Modell, Feature, Zeitraum
|
||||
- **Warnungen**: Konfigurierbare Schwellenwerte (Standard: 10%)
|
||||
- **Flexible Kontrolle**: Blockierung bei Nullsaldo optional
|
||||
- **RBAC-Integration**: Feingranulare Zugriffskontrolle auf AI-Provider
|
||||
|
||||
### Technische Details
|
||||
- **Keine Abonnements**: One-time Payments, keine wiederkehrenden Gebuehren
|
||||
- **Webhook-Integration**: Automatische Gutschrift nach Zahlung
|
||||
- **API-First**: Vollstaendige REST-API fuer Billing-Operationen
|
||||
- **Audit-Trail**: Vollstaendige Transaktionshistorie
|
||||
|
||||
## Product Teaser fuer Homepage
|
||||
|
||||
Der folgende Text ist **Copy & Paste ready** und fuer die Homepage optimiert.
|
||||
|
||||
---
|
||||
|
||||
# Transparente Abrechnung. Volle Kostenkontrolle.
|
||||
|
||||
## Bezahlen Sie nur, was Sie nutzen - fair, transparent und flexibel
|
||||
|
||||
PowerOn bietet ein modernes, nutzungsbasiertes Abrechnungssystem, das sich Ihren Geschaeftsanforderungen anpasst. Keine versteckten Kosten, keine ueberraschenden Rechnungen - nur klare, nachvollziehbare Preise fuer die KI-Leistungen, die Sie tatsaechlich nutzen.
|
||||
|
||||
---
|
||||
|
||||
## Unsere Abrechnungsmodelle
|
||||
|
||||
### Prepaid fuer volle Kontrolle
|
||||
**Prepaid Mandant** - Gemeinsames Guthaben fuer Ihr gesamtes Team. Ideal fuer Organisationen, die zentrale Budgetkontrolle bevorzugen.
|
||||
|
||||
**Prepaid Benutzer** - Individuelles Guthaben pro Mitarbeiter. Perfekt fuer dezentrale Teams mit eigenstaendiger Kostenverwaltung.
|
||||
|
||||
- Startguthaben von 10 CHF fuer neue Benutzer
|
||||
- Flexible Aufladung: 10, 25, 50, 100, 250 oder 500 CHF
|
||||
- Einfache Zahlung per Kreditkarte
|
||||
- Sofortige Gutschrift nach Zahlung
|
||||
|
||||
### Kreditrahmen fuer etablierte Kunden
|
||||
**Credit Postpay** - Arbeiten Sie mit einem Kreditrahmen und erhalten Sie monatliche Rechnungen. Ideal fuer Unternehmen mit etablierten Prozessen und hoeherem Nutzungsvolumen.
|
||||
|
||||
- Individuell vereinbarter Kreditrahmen
|
||||
- Monatliche Abrechnung
|
||||
- Rechnungsstellung an Ihre Firmenadresse
|
||||
- Keine Vorauszahlung erforderlich
|
||||
|
||||
---
|
||||
|
||||
## So funktioniert die Preisgestaltung
|
||||
|
||||
### Pay-per-Use - Fair und transparent
|
||||
Sie bezahlen ausschliesslich fuer die tatsaechlich genutzten KI-Leistungen. Jeder Aufruf wird praezise erfasst und Ihrem Konto zugeordnet.
|
||||
|
||||
### Klare Preisstruktur
|
||||
Unsere Preise basieren auf den Kosten der fuehrenden KI-Provider (OpenAI, Anthropic, etc.) mit einem transparenten Aufschlag fuer:
|
||||
- Infrastruktur und Platform Services
|
||||
- Waehrungsabsicherung und Stabilitaet
|
||||
- Support und Betrieb
|
||||
|
||||
**Alle Preise in Schweizer Franken (CHF)** - keine Waehrungsrisiken fuer Sie.
|
||||
|
||||
---
|
||||
|
||||
## Ihre Vorteile auf einen Blick
|
||||
|
||||
### Volle Transparenz
|
||||
- **Echtzeit-Uebersicht**: Sehen Sie Ihr aktuelles Guthaben jederzeit ein
|
||||
- **Detaillierte Statistiken**: Kosten nach Provider, Modell, Feature und Zeitraum
|
||||
- **Vollstaendige Historie**: Jede Transaktion nachvollziehbar dokumentiert
|
||||
|
||||
### Intelligente Kontrolle
|
||||
- **Warnungen**: Automatische Benachrichtigung bei niedrigem Guthaben
|
||||
- **Flexible Limits**: Optionale Blockierung bei Nullsaldo
|
||||
- **Budget-Management**: Individuelle Schwellenwerte pro Mandat
|
||||
|
||||
### Sicherheit und Compliance
|
||||
- **Mandanten-Isolation**: Strikte Trennung zwischen Organisationen
|
||||
- **Audit-Trail**: Vollstaendige Nachverfolgbarkeit aller Transaktionen
|
||||
- **DSGVO-konform**: Schweizer Datenschutzstandards
|
||||
|
||||
### Einfache Verwaltung
|
||||
- **Self-Service**: Guthaben jederzeit selbst aufladen
|
||||
- **Keine Vertraege**: Keine Mindestlaufzeiten oder Kuendigungsfristen
|
||||
- **Sofortige Aktivierung**: Nach Zahlung direkt einsatzbereit
|
||||
|
||||
---
|
||||
|
||||
## Fuer wen ist welches Modell geeignet?
|
||||
|
||||
| Ihr Bedarf | Empfohlenes Modell | Vorteil |
|
||||
|------------|-------------------|---------|
|
||||
| Kleine Teams, erste Schritte mit KI | **Prepaid Benutzer** | Jeder verwaltet sein eigenes Budget |
|
||||
| Zentrale Kostenkontrolle | **Prepaid Mandant** | Ein gemeinsames Budget fuer alle |
|
||||
| Etablierte Prozesse, hoeheres Volumen | **Credit Postpay** | Arbeiten ohne Vorauszahlung, monatliche Rechnung |
|
||||
| Pilotprojekte, flexible Nutzung | **Prepaid Mandant** | Schneller Start, volle Flexibilitaet |
|
||||
|
||||
---
|
||||
|
||||
## Haeufig gestellte Fragen
|
||||
|
||||
**Gibt es versteckte Kosten?**
|
||||
Nein. Sie bezahlen ausschliesslich fuer die tatsaechlich genutzten KI-Leistungen. Keine Setup-Gebuehren, keine Grundgebuehren, keine versteckten Zuschlaege.
|
||||
|
||||
**Wie schnell wird mein Guthaben gutgeschrieben?**
|
||||
Sofort nach erfolgreicher Zahlung. Sie koennen direkt weiterarbeiten.
|
||||
|
||||
**Kann ich zwischen Modellen wechseln?**
|
||||
Ja, Ihr Administrator kann das Abrechnungsmodell jederzeit anpassen - je nach Entwicklung Ihrer Anforderungen.
|
||||
|
||||
**Welche Zahlungsmethoden werden akzeptiert?**
|
||||
Aktuell: Kreditkarte ueber Stripe Checkout. Fuer Credit Postpay: Rechnung per E-Mail.
|
||||
|
||||
**Wie detailliert ist die Kostenaufschluesselung?**
|
||||
Sehr detailliert. Sie sehen fuer jede Transaktion: Provider, Modell, Feature, Benutzer, Zeitpunkt und Kosten.
|
||||
|
||||
**Was passiert, wenn mein Guthaben aufgebraucht ist?**
|
||||
Je nach Konfiguration erhalten Sie eine Warnung oder KI-Funktionen werden blockiert. Sie koennen jederzeit selbst Guthaben aufladen.
|
||||
|
||||
---
|
||||
|
||||
## Jetzt starten
|
||||
|
||||
Beginnen Sie mit einem Prepaid-Modell und 10 CHF Startguthaben pro Benutzer. Keine Kreditkarte erforderlich fuer den ersten Test.
|
||||
|
||||
**Bereit fuer den naechsten Schritt?**
|
||||
Kontaktieren Sie uns fuer eine persoenliche Demo oder starten Sie direkt mit Ihrem Team.
|
||||
|
||||
---
|
||||
|
||||
## Technische Details fuer IT-Verantwortliche
|
||||
|
||||
- **API-First**: Vollstaendige REST-API fuer Billing-Operationen
|
||||
- **Webhook-Integration**: Automatische Verarbeitung von Zahlungsereignissen
|
||||
- **RBAC-Integration**: Feingranulare Zugriffskontrolle auf AI-Provider
|
||||
- **Stripe-Integration**: Sichere Zahlungsabwicklung nach PCI-DSS
|
||||
- **Echtzeit-Abrechnung**: Sofortige Kostenzuordnung nach jedem AI-Call
|
||||
- **Statistik-Aggregation**: Nach Tag, Monat, Jahr mit Breakdown nach Provider/Feature
|
||||
|
||||
---
|
||||
|
||||
## Kontakt
|
||||
|
||||
**PowerOn AG**
|
||||
Zuerich, Schweiz
|
||||
|
||||
Haben Sie Fragen zu unseren Abrechnungsmodellen?
|
||||
Unser Team beraet Sie gerne persoenlich.
|
||||
|
||||
---
|
||||
|
||||
*Stand: Maerz 2026*
|
||||
245
docs/product-teaser-poweron.md
Normal file
245
docs/product-teaser-poweron.md
Normal file
|
|
@ -0,0 +1,245 @@
|
|||
# PowerOn Product Teaser
|
||||
*Ihre KI-Plattform. Ein Arbeitsplatz. Alle Moeglichkeiten.*
|
||||
|
||||
## Die KI-Plattform fuer produktivere Teams
|
||||
*Weniger Aufwand, bessere Ergebnisse -- ab dem ersten Tag.*
|
||||
|
||||
PowerOn ist die zentrale Arbeitsplattform fuer Unternehmen, die Prozesse vereinfachen, Wissen skalieren und wiederkehrende Aufgaben intelligent automatisieren wollen.
|
||||
Auch ohne technisches Vorwissen starten Teams schnell: klare Oberflaechen, gefuehrte Workflows und direkt nutzbare KI-Funktionen helfen ab dem ersten Tag.
|
||||
|
||||
> **Screenshot-Platzhalter:** `HERO_SCREENSHOT`
|
||||
> **Empfohlener Inhalt:** Startseite oder Dashboard mit PowerOn Branding und klarer Hauptnavigation
|
||||
|
||||
---
|
||||
|
||||
## Was ist PowerOn?
|
||||
*KI, Zusammenarbeit und Automatisierung -- vereint in einer Plattform.*
|
||||
|
||||
PowerOn verbindet KI-Assistenten, teamweite Zusammenarbeit und Automatisierung in einer Plattform. Unternehmen erhalten damit einen digitalen Arbeitsplatz, in dem Beratung, Meetings, Prozesse und Fachdaten in einem einheitlichen Erlebnis zusammenkommen.
|
||||
|
||||
### Ihr Nutzen auf einen Blick
|
||||
*Fuenf Gruende, warum Unternehmen auf PowerOn setzen.*
|
||||
|
||||
- Schnellere Entscheidungen durch kontextbezogene KI-Unterstuetzung
|
||||
- Weniger manuelle Arbeit durch wiederverwendbare Automationen
|
||||
- Hoehere Qualitaet durch standardisierte Ablaufe und transparente Ergebnisse
|
||||
- Bessere Zusammenarbeit, weil Teams in vertrauten Umgebungen arbeiten koennen
|
||||
- Skalierbarkeit fuer wachsende Organisationen und unterschiedliche Mandate
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_DASHBOARD`
|
||||
> **Empfohlener Inhalt:** Uebersichtsseite mit zentralen Kacheln, Kennzahlen oder Einstiegen in Features
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_NAVIGATION`
|
||||
> **Empfohlener Inhalt:** Linke Navigation mit den Bereichen Power Desktop, Test Coach, Teams Bot, Automation und Machbarkeitsstudie
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_FEATURE_STORE`
|
||||
> **Empfohlener Inhalt:** Feature-Store mit aktivierbaren Modulen
|
||||
|
||||
---
|
||||
|
||||
## Feature 1: Power Desktop (AI Workspace)
|
||||
*Ihr digitaler Schreibtisch -- alles an einem Ort.*
|
||||
|
||||
Power Desktop ist der zentrale Arbeitsbereich fuer produktives, KI-gestuetztes Arbeiten. Teams finden dort die wichtigsten Werkzeuge in einer durchgaengigen Umgebung: Chat, Editor und experimentelle KI-Arbeitsflaechen.
|
||||
|
||||
### Was neue Kunden daran schaetzen
|
||||
*Der Mehrwert, der sofort spuerbar ist.*
|
||||
|
||||
- Ein Ort fuer Ideen, Inhalte und Umsetzung
|
||||
- Weniger Tool-Wechsel, mehr Fokus im Tagesgeschaeft
|
||||
- Schneller Einstieg auch fuer Nicht-Techniker durch klare Bedienlogik
|
||||
|
||||
### Kernfunktionen
|
||||
*Chat, Editor und Playground in einer Umgebung.*
|
||||
|
||||
- KI-Chat fuer Fragen, Entwuerfe und iterative Verbesserungen
|
||||
- Editor-Arbeitsbereich fuer strukturierte Inhalte und Dokumentation
|
||||
- Playground-Bereich zum Testen und Verfeinern von KI-gestuetzten Loesungen
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_WORKSPACE_OVERVIEW`
|
||||
> **Empfohlener Inhalt:** Gesamtansicht des Workspaces mit mehreren Bereichen
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_WORKSPACE_CHAT`
|
||||
> **Empfohlener Inhalt:** Konkrete Chat-Interaktion mit verwertbarer Antwort
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_WORKSPACE_CODE`
|
||||
> **Empfohlener Inhalt:** Editor-Ansicht mit klaren Arbeitsflaechen
|
||||
|
||||
---
|
||||
|
||||
## Feature 2: Test Coach (Kommunikations-Coach)
|
||||
*Besser kommunizieren -- mit KI als persoenlichem Sparringspartner.*
|
||||
|
||||
Der Test Coach unterstuetzt Mitarbeitende und Fuehrungskraefte dabei, Kommunikationssituationen gezielt zu trainieren. Statt abstrakter Theorie liefert die KI konkrete, direkt anwendbare Impulse fuer den Berufsalltag.
|
||||
|
||||
### Was neue Kunden daran schaetzen
|
||||
*Persoenliches Wachstum, messbar und alltagsnah.*
|
||||
|
||||
- Sichereres Auftreten in schwierigen Gespraechen
|
||||
- Kontinuierliche Weiterentwicklung mit messbarem Fortschritt
|
||||
- Individuelle Unterstuetzung passend zum persoenlichen Kommunikationsstil
|
||||
|
||||
### Kernfunktionen
|
||||
*Von Themenauswahl bis Gamification -- alles in einem Dossier.*
|
||||
|
||||
- Coaching-Kontexte fuer Themen, Ziele und Herausforderungen
|
||||
- Session-basiertes Training mit KI-Dialogen
|
||||
- Aufgaben, Fortschritt und Verlauf in einem Dossier gebuendelt
|
||||
- Sprachunterstuetzung fuer natuerlichere Lernsituationen
|
||||
- Motivierende Elemente wie Streaks, Scores und Badges
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_COACH_DASHBOARD`
|
||||
> **Empfohlener Inhalt:** Dashboard mit KPIs (z. B. Streak, Score, Badges)
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_COACH_SESSION`
|
||||
> **Empfohlener Inhalt:** Laufende Coaching-Session mit Chat-Verlauf
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_COACH_DOSSIER`
|
||||
> **Empfohlener Inhalt:** Dossier mit Tabs fuer Aufgaben, Sessions und Dokumente
|
||||
|
||||
---
|
||||
|
||||
## Feature 3: Teams Bot
|
||||
*KI-Unterstuetzung dort, wo Ihr Team bereits arbeitet -- in Microsoft Teams.*
|
||||
|
||||
Der Teams Bot bringt KI-Unterstuetzung direkt in Microsoft Teams Meetings. Er kann Sitzungen begleiten, Inhalte erfassen und kontextbezogene Antworten bereitstellen.
|
||||
|
||||
### Was neue Kunden daran schaetzen
|
||||
*Meetings produktiver machen, ohne Gewohnheiten zu aendern.*
|
||||
|
||||
- Sofortiger Mehrwert in bereits etablierten Meeting-Prozessen
|
||||
- Besseres Informationsmanagement durch strukturierte Protokollierung
|
||||
- Schnellere Nachbereitung durch KI-gestuetzte Unterstuetzung
|
||||
|
||||
### Kernfunktionen
|
||||
*Ein Link genuegt -- der Bot uebernimmt den Rest.*
|
||||
|
||||
- Start einer Session ueber Meeting-Link
|
||||
- Unterstuetzung verschiedener Join-Modi (z. B. Bot oder Benutzerkonto)
|
||||
- Laufende Verarbeitung von Meeting-Inhalten
|
||||
- KI-Antworten als Chat, Audio oder kombiniert
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_TEAMSBOT_START`
|
||||
> **Empfohlener Inhalt:** Formular/Ansicht zum Start einer Teams-Bot-Session
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_TEAMSBOT_LIVE`
|
||||
> **Empfohlener Inhalt:** Aktive Session mit Status und Live-Interaktion
|
||||
|
||||
---
|
||||
|
||||
## Feature 4: Automation
|
||||
*Einmal definieren, immer wieder zuverlaessig ausfuehren.*
|
||||
|
||||
Automation in PowerOn macht wiederkehrende Aufgaben planbar und zuverlaessig. Unternehmen definieren Vorlagen einmal und fuehren Prozesse danach manuell oder zeitgesteuert aus.
|
||||
|
||||
### Was neue Kunden daran schaetzen
|
||||
*Weniger Routine, mehr Raum fuer das Wesentliche.*
|
||||
|
||||
- Spuerbare Entlastung bei repetitiven Aufgaben
|
||||
- Konstante Prozessqualitaet ueber Teams hinweg
|
||||
- Mehr Zeit fuer wertschaffende Arbeit
|
||||
|
||||
### Kernfunktionen
|
||||
*Templates, Zeitplanung und Echtzeit-Transparenz.*
|
||||
|
||||
- Verwaltung von Automations-Definitionen
|
||||
- Wiederverwendbare Templates fuer typische Geschaeftsprozesse
|
||||
- Geplante oder sofortige Ausfuehrung
|
||||
- Transparente Rueckmeldungen ueber Live-Logs
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_AUTOMATION_LIST`
|
||||
> **Empfohlener Inhalt:** Uebersicht der vorhandenen Automationen
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_AUTOMATION_EDIT`
|
||||
> **Empfohlener Inhalt:** Erstellungs- oder Bearbeitungsmaske mit Template-Auswahl
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_AUTOMATION_LOGS`
|
||||
> **Empfohlener Inhalt:** Laufende oder abgeschlossene Ausfuehrung mit Log-Anzeige
|
||||
|
||||
---
|
||||
|
||||
## Feature 5: Machbarkeitsstudie (Real Estate)
|
||||
*Immobilienpotenziale in Minuten statt Tagen bewerten.*
|
||||
|
||||
Die Machbarkeitsstudie unterstuetzt bei der schnellen Erstbewertung von Immobilienpotenzialen. Relevante Informationen aus Regelwerken werden strukturiert extrahiert und als verwertbare Entscheidungsgrundlage aufbereitet.
|
||||
|
||||
### Was neue Kunden daran schaetzen
|
||||
*Fundierte Entscheidungen frueher im Projektverlauf.*
|
||||
|
||||
- Schnellere Vorpruefung von Immobilienprojekten
|
||||
- Bessere Entscheidungsgrundlagen in fruehen Projektphasen
|
||||
- Klar strukturierte Ergebnisse statt unuebersichtlicher Rohdaten
|
||||
|
||||
### Kernfunktionen
|
||||
*Automatische Analyse von Regelwerken und Parzellendaten.*
|
||||
|
||||
- KI-gestuetzte Extraktion von BZO-Inhalten
|
||||
- Aufbereitung zentraler Fakten
|
||||
- Konkrete Vorschlaege zur Einschaetzung von Potenzialen
|
||||
- Zusatzinformationen fuer vertiefte Pruefungen
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_REALESTATE_MAP`
|
||||
> **Empfohlener Inhalt:** Karten-/Parzellenansicht im Real-Estate-Bereich
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_REALESTATE_MACHBARKEIT`
|
||||
> **Empfohlener Inhalt:** Ergebnisbereich mit Fakten und Vorschlaegen
|
||||
|
||||
> **Screenshot-Platzhalter:** `SCREENSHOT_REALESTATE_BZO`
|
||||
> **Empfohlener Inhalt:** Detailansicht der BZO-Extraktion
|
||||
|
||||
---
|
||||
|
||||
## Warum PowerOn fuer neue Kunden?
|
||||
*Eine Plattform, die mit Ihren Anforderungen waechst.*
|
||||
|
||||
PowerOn ist darauf ausgelegt, den Einstieg in KI-gestuetztes Arbeiten einfach zu machen und zugleich professionellen Mehrwert zu liefern. Statt isolierter Einzelloesungen erhalten Unternehmen eine skalierbare Plattform, die Menschen, Prozesse und KI wirkungsvoll verbindet.
|
||||
|
||||
### Besonders relevant fuer Nicht-Techies
|
||||
*Kein Vorwissen noetig -- einfach loslegen.*
|
||||
|
||||
- Intuitive Bedienung statt technischer Komplexitaet
|
||||
- Klare, gefuehrte Workflows
|
||||
- Sofort sichtbarer Nutzen in Alltagsszenarien
|
||||
- Schrittweise Erweiterung je nach Bedarf
|
||||
|
||||
### Call to Action
|
||||
*Jetzt den naechsten Schritt machen.*
|
||||
|
||||
Starten Sie mit den wichtigsten Anwendungsfaellen in Ihrem Team und bauen Sie Ihre KI-gestuetzten Prozesse mit PowerOn systematisch aus.
|
||||
|
||||
---
|
||||
|
||||
## Benoetigte Screenshots (Uebersicht)
|
||||
*Alle visuellen Platzhalter auf einen Blick.*
|
||||
|
||||
| Platzhalter | Benoetigter Screenshot | Empfohlene Perspektive |
|
||||
| --- | --- | --- |
|
||||
| `HERO_SCREENSHOT` | PowerOn Startseite mit Branding | Vollansicht mit Logo, Claim, Einstieg |
|
||||
| `SCREENSHOT_DASHBOARD` | Hauptdashboard nach Login | Uebersicht mit wichtigsten Einstiegen |
|
||||
| `SCREENSHOT_NAVIGATION` | Seitennavigation mit Feature-Liste | Fokus auf Feature-Namen und Struktur |
|
||||
| `SCREENSHOT_FEATURE_STORE` | Feature-Store | Sichtbare Feature-Kacheln/Module |
|
||||
| `SCREENSHOT_WORKSPACE_OVERVIEW` | Power Desktop Gesamtansicht | Mehrere Arbeitsbereiche gleichzeitig |
|
||||
| `SCREENSHOT_WORKSPACE_CHAT` | Chat-Bereich | Konkrete Konversation mit KI-Antwort |
|
||||
| `SCREENSHOT_WORKSPACE_CODE` | Editor-Bereich | Klar lesbare Arbeitsumgebung |
|
||||
| `SCREENSHOT_COACH_DASHBOARD` | Coach Dashboard | KPIs wie Streak, Score, Badges |
|
||||
| `SCREENSHOT_COACH_SESSION` | Aktive Coach Session | Laufender Dialog und Session-Kontext |
|
||||
| `SCREENSHOT_COACH_DOSSIER` | Coach Dossier | Tabs/Abschnitte mit Aufgaben und Verlauf |
|
||||
| `SCREENSHOT_TEAMSBOT_START` | Teams Bot Start | Meeting-Link und Session-Einstellungen |
|
||||
| `SCREENSHOT_TEAMSBOT_LIVE` | Teams Bot Live Session | Session-Status und Interaktion |
|
||||
| `SCREENSHOT_AUTOMATION_LIST` | Automation-Liste | Definitions-Uebersicht |
|
||||
| `SCREENSHOT_AUTOMATION_EDIT` | Automation bearbeiten | Template + Parameter sichtbar |
|
||||
| `SCREENSHOT_AUTOMATION_LOGS` | Automation-Logs | Live- oder Abschlussprotokolle |
|
||||
| `SCREENSHOT_REALESTATE_MAP` | Real-Estate Kartenansicht | Parzellen und Kontext sichtbar |
|
||||
| `SCREENSHOT_REALESTATE_MACHBARKEIT` | Machbarkeitsstudie Ergebnis | Fakten, Vorschlaege, strukturierte Ausgabe |
|
||||
| `SCREENSHOT_REALESTATE_BZO` | BZO-Extraktionsdetails | Ausgelesene Regel-/Detailinformationen |
|
||||
|
||||
---
|
||||
|
||||
## Hinweis zur Verwendung
|
||||
*So werden aus Platzhaltern fertige Bilder.*
|
||||
|
||||
Alle Platzhalter koennen spaeter im selben Dokument durch finale Bilder ersetzt werden, z. B. als direkte Markdown-Bilder:
|
||||
|
||||
```md
|
||||

|
||||
```
|
||||
BIN
docs/prompts-ui-tests.xlsx
Normal file
BIN
docs/prompts-ui-tests.xlsx
Normal file
Binary file not shown.
168
docs/screen-recording-script-ai-chat.md
Normal file
168
docs/screen-recording-script-ai-chat.md
Normal file
|
|
@ -0,0 +1,168 @@
|
|||
# PORTO AI Chat — Screen-Recording-Skript (Werbeclip)
|
||||
|
||||
**Zielgruppe:** Entscheider, C-Level, Investoren
|
||||
**Ton:** sachlich, vertrauensbildend, ohne Tech-Slang
|
||||
**Gesamtlänge:** ca. 90–120 Sekunden
|
||||
**Auflösung:** mindestens 1920×1080; UI zoomed / Browser auf 125–150 % falls nötig für Lesbarkeit
|
||||
|
||||
---
|
||||
|
||||
## Vorbereitung (nicht aufnehmen)
|
||||
|
||||
1. **Testdaten:** Eine anonymisierte PDF (z. B. «Muster-Vertrag») und ein kurzes internes Memo — keine echten Kundendaten.
|
||||
2. **Workspace:** Bereits eingeloggt; eine leere oder neue Konversation wählen.
|
||||
3. **Datenquelle (optional):** SharePoint- oder OneDrive-Testsite verbunden *oder* vorbereiteten Screen mit bereits verbundener Quelle (ohne sensible Namen).
|
||||
4. **Provider:** Für eine Szene «Private LLM» sichtbar wählen — nur wenn in Ihrer Umgebung freigeschaltet; sonst Szene 7 weglassen oder durch «Mistral» ersetzen.
|
||||
5. **Browser:** Tabs schliessen; keine persönlichen Lesezeichenleisten im Bild.
|
||||
|
||||
---
|
||||
|
||||
## Struktur Overview
|
||||
|
||||
| Block | Dauer | Inhalt |
|
||||
|-------------|---------|----------------------------------|
|
||||
| Hook | ~5 s | Eine Zeile, die Aufmerksamkeit holt |
|
||||
| Problem | ~15 s | Risiko + Lücke öffentlicher Chats |
|
||||
| Demo | ~60 s | Walkthrough mit konkreten Prompts |
|
||||
| CTA | ~15 s | Schweiz, Kontrolle, Erstgespräch |
|
||||
|
||||
---
|
||||
|
||||
## Szene A — Hook (0:00–0:05)
|
||||
|
||||
**Bild:** Start auf PORTO Workspace (zentrale Chat-Ansicht, ruhig, keine Bewegung).
|
||||
|
||||
**Voice-over:**
|
||||
«Was wäre, wenn Ihre Teams mit KI chatten könnten — mit echtem Zugriff auf Ihre Dokumente, aber ohne dass sensible Daten das Unternehmen verlassen?»
|
||||
|
||||
**Action:** Keine Klicks; 1–2 Sekunden Pause, dann sanft zur linken Sidebar zoomen oder leicht scrollen (optional).
|
||||
|
||||
---
|
||||
|
||||
## Szene B — Problem (0:05–0:20)
|
||||
|
||||
**Bild:** Kurz Browser-Tab oder Grafik weglassen — bleiben Sie in PORTO oder wechseln Sie zu einer neutralen Titelfolie «Das Problem» (optional).
|
||||
|
||||
**Voice-over:**
|
||||
«Öffentliche Chat-Tools sind schnell — aber sie kennen Ihre Verträge, Ihre SharePoint-Ordner und Ihre Compliance-Regeln nicht. Das Ergebnis: Copy-Paste, Medienbrüche und ein Risiko, das Audit und Vorstand nicht tragen wollen. PORTO AI Chat schliesst diese Lücke.»
|
||||
|
||||
**Action:** Zurück zum Workspace wechseln.
|
||||
|
||||
---
|
||||
|
||||
## Szene C — Demo Teil 1: Dokument hochladen (0:20–0:30)
|
||||
|
||||
**Bild:** Workspace mit leerem oder neuem Chat; linke Leiste mit Dateien sichtbar.
|
||||
|
||||
**Action:** PDF per **Drag & Drop** in den Chat-Bereich ziehen *oder* über Datei-Upload anhängen. Warten, bis die Datei in der Konversation / Anhänge erscheint.
|
||||
|
||||
**Voice-over:**
|
||||
«Hier arbeiten Ihre Mitarbeitenden in einer geschützten Oberfläche. Sie ziehen ein Dokument hinein — und der KI-Agent kann es im Kontext nutzen.»
|
||||
|
||||
---
|
||||
|
||||
## Szene D — Demo Teil 2: Analyse-Prompt (0:30–0:45)
|
||||
|
||||
**Bild:** Cursor im Eingabefeld; dann Senden.
|
||||
|
||||
**Eingabetext (exakt oder leicht angepasst):**
|
||||
|
||||
```text
|
||||
Fasse die wichtigsten Klauseln dieses Dokuments in maximal fünf Bulletpoints zusammen.
|
||||
Hebe Haftung, Kündigung und Vertraulichkeit hervor. Antworte auf Deutsch.
|
||||
```
|
||||
|
||||
**Action:** Nach dem Senden **nicht** unterbrechen: kurz die **Streaming-Antwort** laufen lassen; wenn sichtbar, **Tool-Aktivität** oder Fortschritt in der rechten Spalte («Activity» / Tool-Log) mitfilmen.
|
||||
|
||||
**Voice-over:**
|
||||
«Statt manuell zu lesen und zu kopieren, stellt man eine präzise Frage. Die KI arbeitet mit dem Dokument — und Sie sehen, was im Hintergrund passiert. Transparenz statt Blackbox.»
|
||||
|
||||
---
|
||||
|
||||
## Szene E — Demo Teil 3: Datenquelle (0:45–1:00)
|
||||
|
||||
**Bild:** Linke Sidebar → Tab **Quellen / Datenquellen** (SharePoint, OneDrive o. Ä., je nach UI-Label).
|
||||
|
||||
**Action:** Bereits verbundene Quelle anzeigen *oder* kurz durch Ordner browsen (nur Testinhalte). Dann zurück in den Chat.
|
||||
|
||||
**Eingabetext (Prompt):**
|
||||
|
||||
```text
|
||||
Suche in meiner verbundenen Datenquelle nach dem neuesten Dokument zum Thema "Onboarding"
|
||||
und gib mir eine einzeilige Inhaltszusammenfassung. Wenn nichts passt, sag es klar.
|
||||
```
|
||||
|
||||
**Voice-over:**
|
||||
«PORTO verbindet sich mit Ihren Systemen — SharePoint, OneDrive, Google Drive und mehr. Die KI beantwortet Fragen über Ihr Unternehmenswissen, nicht nur über das offene Internet.»
|
||||
|
||||
*Hinweis:* Wenn die Suche in der Demo leer zurückkommt, Voice-over anpassen: «Auch dann liefert das System eine klare Antwort — ohne zu halluzinieren.»
|
||||
|
||||
---
|
||||
|
||||
## Szene F — Demo Teil 4: Ergebnis als Datei (1:00–1:15)
|
||||
|
||||
**Bild:** Neuer Follow-up im selben Chat.
|
||||
|
||||
**Eingabetext (Prompt):**
|
||||
|
||||
```text
|
||||
Erstelle auf Basis deiner letzten Antwort eine strukturierte Markdown-Datei
|
||||
"Executive_Summary.md" mit Überschriften: Kontext, Kernpunkte, offene Fragen.
|
||||
Schlage die Datei zur Freigabe vor, falls dein Workflow das vorsieht.
|
||||
```
|
||||
|
||||
**Action:** Wenn **Datei-Änderungsvorschlag** / Vorschau erscheint: kurz **Akzeptieren** oder Vorschau zeigen (je nach Produktverhalten). Optional rechte Spalte **Vorschau** einblenden.
|
||||
|
||||
**Voice-over:**
|
||||
«Der Agent liefert nicht nur Text im Chat — er kann Arbeitsergebnisse vorbereiten und zur Freigabe einreichen. Kontrolle bleibt beim Menschen.»
|
||||
|
||||
---
|
||||
|
||||
## Szene G — Demo Teil 5: Modellwahl (1:15–1:25)
|
||||
|
||||
**Bild:** Eingabebereich unten; **Provider-Auswahl** / Modell-Multiselect sichtbar machen.
|
||||
|
||||
**Action:** Dropdown öffnen; **Private LLM** (oder «Mistral» / konfigurierte Option) auswählen — ohne erneut zu senden, es sei denn Sie wollen eine kurze «Ping»-Antwort zeigen.
|
||||
|
||||
**Voice-over:**
|
||||
«Entscheider interessiert: Welches Modell läuft? Hier wählen Sie es — bis hin zu Private LLM auf Schweizer Infrastruktur. Governance wird zur Einstellung, nicht zur Ausrede.»
|
||||
|
||||
---
|
||||
|
||||
## Szene H — CTA (1:25–1:40)
|
||||
|
||||
**Bild:** Ruhiger Vollbild-Workspace oder Ihre PORTO-/PowerOn-Schlussfolie mit Kontakt.
|
||||
|
||||
**Voice-over:**
|
||||
«PORTO AI Chat macht produktive KI-Nutzung vereinbar mit Datenschutz und Kontrolle. PowerOn zeigt Ihnen im Erstgespräch, wie das in Ihrem konkreten Prozess funktioniert — von Treuhand bis Legal. Kontakt: poweron.swiss.»
|
||||
|
||||
**On-Screen-Text (optional, 3–4 Sekunden):**
|
||||
`poweron.swiss` · `Erstgespräch vereinbaren`
|
||||
|
||||
---
|
||||
|
||||
## Prompts — Schnellkopie (alle Demo-Eingaben)
|
||||
|
||||
```
|
||||
1) Analyse:
|
||||
Fasse die wichtigsten Klauseln dieses Dokuments in maximal fünf Bulletpoints zusammen.
|
||||
Hebe Haftung, Kündigung und Vertraulichkeit hervor. Antworte auf Deutsch.
|
||||
|
||||
2) Datenquelle:
|
||||
Suche in meiner verbundenen Datenquelle nach dem neuesten Dokument zum Thema "Onboarding"
|
||||
und gib mir eine einzeilige Inhaltszusammenfassung. Wenn nichts passt, sag es klar.
|
||||
|
||||
3) Datei:
|
||||
Erstelle auf Basis deiner letzten Antwort eine strukturierte Markdown-Datei
|
||||
"Executive_Summary.md" mit Überschriften: Kontext, Kernpunkte, offene Fragen.
|
||||
Schlage die Datei zur Freigabe vor, falls dein Workflow das vorsieht.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Technische Checkliste nach der Aufnahme
|
||||
|
||||
- [ ] Keine echten Kundennamen, E-Mails oder Vertragsnummern sichtbar
|
||||
- [ ] Töne: optional dezente Hintergrundmusik (royalty-free), Voice-over dominant
|
||||
- [ ] Untertitel (DE) für LinkedIn / stummes Abspielen empfohlen
|
||||
- [ ] Endcard: Logo + URL + «Schweizer Datenhaltung»
|
||||
BIN
docs/settings-ui-tests.xlsx
Normal file
BIN
docs/settings-ui-tests.xlsx
Normal file
Binary file not shown.
137
docs/slide-erfolgreicher-einsatz-von-ki.md
Normal file
137
docs/slide-erfolgreicher-einsatz-von-ki.md
Normal file
|
|
@ -0,0 +1,137 @@
|
|||
# Erfolgreicher Einsatz von KI
|
||||
|
||||
*PowerPoint-Vorlage. Ersetzt die Ring-Grafik durch eine klar lesbare 5-Säulen-Darstellung. Jede Säule: Titel, ein Leitsatz (aus Originalgrafik), 2–3 konkrete Belege aus der PowerOn-Doku.*
|
||||
|
||||
**Quellenbasis:** Originalbild „Erfolgreicher Einsatz von KI" sowie `wiki/a-strategy/product-vision.md`, `wiki/b-reference/platform/rbac.md`, `wiki/b-reference/platform/neutralization.md`, `wiki/b-reference/gateway/ai-agent.md`, `wiki/e-compliance/security-overview.md`.
|
||||
|
||||
---
|
||||
|
||||
## Folie 0 – Intro (Titelfolie)
|
||||
|
||||
### Von der KI-Idee zur Roadmap, die trägt.
|
||||
|
||||
**Ihre Daten bleiben in der Schweiz. Ergebnisse in Wochen, nicht Monaten.**
|
||||
|
||||
Was Sie in der Hand halten: Handlungsfelder · Kausalnetz · Umsetzungsroadmap · Steckbriefe.
|
||||
|
||||
**Kicker (oben, klein, grau, uppercase):** PRÄSENTATION · ERFOLGREICHER EINSATZ VON KI
|
||||
**Footer (unten, dezent):** PowerOn · www.poweron.swiss
|
||||
|
||||
**Textbausteine in Reihenfolge:**
|
||||
|
||||
| Ebene | Inhalt | Stil |
|
||||
|---|---|---|
|
||||
| Kicker | `PRÄSENTATION · ERFOLGREICHER EINSATZ VON KI` | klein, uppercase, grau |
|
||||
| Headline | `Von der KI-Idee zur Roadmap, die trägt.` | XXL, schwarz, 2 Zeilen (Umbruch nach „KI-Idee") |
|
||||
| Subline | `Ihre Daten bleiben in der Schweiz. Ergebnisse in Wochen, nicht Monaten.` | mittel, dunkelgrau |
|
||||
| Deck-Teaser | `Was Sie in der Hand halten: Handlungsfelder · Kausalnetz · Umsetzungsroadmap · Steckbriefe.` | klein, grau, eine Zeile |
|
||||
| Footer | `PowerOn · www.poweron.swiss` | klein, grau |
|
||||
|
||||
**Begründung der Wortwahl:**
|
||||
|
||||
- „Von der KI-Idee zur Roadmap, die trägt" — verknüpft explizit mit Folie 4 („Das halten Sie am Ende in der Hand") und schafft eine Deck-Klammer. „die trägt" setzt den selbstbewussten Ton, ohne marktschreierisch zu wirken.
|
||||
- „Ihre Daten bleiben in der Schweiz" — deckt Compliance (CISO), Differenzierung (CEO) und Risiko-Argument (CFO) in einem Satz ab.
|
||||
- „Ergebnisse in Wochen, nicht Monaten" — bewusst ohne harte Zahl (Time-to-Value steht noch nicht verbindlich fest), aber mit klarem Erwartungsmanagement.
|
||||
- „Was Sie in der Hand halten" — identischer Wording-Anker wie Folie 4. Konsistenz schafft Vertrauen.
|
||||
|
||||
> **Visual-Hinweis:** 16:9, weißer Hintergrund, keine Hintergrund-Textur. Links 55 %: Kicker → Headline → Subline → Teaser, alles linksbündig. Rechts 45 %: die 5-Säulen-Grafik auf dezentem hellgrauen Panel mit abgerundeten Ecken, **mit Labels unter jedem Balken** (Use-Cases / Datenschutz / Berechtigungen / Verbindungen / Regeln / Ethik) in kleiner grauer Schrift. Dünne Trennlinie über dem Footer. Nur zwei Schriftgrößen-Stufen: Headline XXL + alles andere. Keine dekorativen Icons, keine Badges, keine Fülltextur.
|
||||
|
||||
> **C-Level-Logik:** EIN visueller Anker (Headline) statt fünf konkurrierender Hierarchieebenen. Ergebnis-Framing („Roadmap") spricht CEO, Subline fängt CFO („Wochen") und Compliance („Schweiz") gleichzeitig mit. Teaser baut inhaltliche Brücke zu Folie 4 – Leser versteht sofort, worauf das Deck hinausläuft. Generisches Wording hält die Zielgruppe offen; Branchen-Personalisierung bleibt dem Cover-Letter vorbehalten.
|
||||
|
||||
---
|
||||
|
||||
## Folie 1 – Übersicht: Die 5 Erfolgsfaktoren
|
||||
|
||||
### Erfolgreicher Einsatz von KI
|
||||
|
||||
**Fünf Säulen, die KI im Unternehmen sicher und wirksam machen.**
|
||||
|
||||
| # | Säule | Leitsatz (aus Originalgrafik) |
|
||||
|---|---|---|
|
||||
| 1 | **Use-Cases** | Der Einsatz basiert auf klar definierten Use-Cases. |
|
||||
| 2 | **Datenschutz** | Keine sensitiven Daten gelangen nach aussen. |
|
||||
| 3 | **Berechtigungen** | Die KI hat nur Zugriff auf klar definierte Daten. |
|
||||
| 4 | **Verbindungen** | Einfache Anbindung von Informationsquellen und Agentensystemen. |
|
||||
| 5 | **Regeln / Ethik** | Vertrauensvoller und fairer Einsatz der KI. |
|
||||
|
||||
> **Visual-Hinweis:** 5 gleich grosse Karten nebeneinander (Icons oben, Titel fett, Leitsatz darunter). Kein Kreis, keine schräg gestellten Labels. Reihenfolge links → rechts von „Voraussetzung" (Use-Case) über „Schutz" (Datenschutz, Berechtigungen) und „Integration" (Verbindungen) bis „Leitplanken" (Regeln / Ethik).
|
||||
|
||||
---
|
||||
|
||||
## Folie 2 – Use-Cases
|
||||
|
||||
### Der Einsatz basiert auf klar definierten Use-Cases
|
||||
|
||||
- **Schrittweise Einführung** statt Big-Bang: „Schrittweise Integration, beginnend mit einfachen Use Cases." (product-vision.md)
|
||||
- **Feature-Store-Architektur:** Mandanten aktivieren modular nur die Features, die sie brauchen (Workspace, Automation, CommCoach, Trustee …). Skaliert von Einzelanwendung bis Full-Suite. (product-vision.md)
|
||||
- **Spezialisierte Agenten pro Aufgabe:** Chat, Workflow, Voice, RAG, Automation – jeder Agent auf seinen Use-Case zugeschnitten, koordiniert durch eine zentrale Engine. (product-vision.md)
|
||||
|
||||
> **Visual-Hinweis:** Drei Stufen-Icons (klein → mittel → gross), um die schrittweise Einführung zu zeigen.
|
||||
|
||||
---
|
||||
|
||||
## Folie 3 – Datenschutz
|
||||
|
||||
### Keine sensitiven Daten gelangen nach aussen
|
||||
|
||||
- **Datenschutz-Neutralisierer:** Sensitive Inhalte werden durch stabile Platzhalter ersetzt, bevor Text an externe KI-Modelle geht oder dauerhaft im RAG landet. Ein zentrales AI-Gate prüft jeden Modell-Call. (neutralization.md)
|
||||
- **Hard-Mode:** Ist Neutralisierung erforderlich und scheitert, wird der Call blockiert – Inhalte gelangen nie im Klartext zum Modell. (neutralization.md)
|
||||
- **Private-LLM-Option:** Für höchste Anforderungen kann ein lokal betriebenes Sprachmodell genutzt werden. In diesem Fall verlassen keine Daten die eigene Infrastruktur. (security-overview.md § 7.5)
|
||||
- **Kein Training mit Kundendaten:** Über Enterprise-APIs der Anbieter vertraglich ausgeschlossen. (security-overview.md § 7.4)
|
||||
|
||||
> **Visual-Hinweis:** Symbol „Schild" mit einem ausgehenden Pfeil, der auf einen Filter trifft.
|
||||
|
||||
---
|
||||
|
||||
## Folie 4 – Berechtigungen
|
||||
|
||||
### Die KI hat nur Zugriff auf klar definierte Daten
|
||||
|
||||
- **Rollenbasierte Zugriffskontrolle (RBAC)** auf vier Stufen: System, Mandant, Feature und Feature-Instanz. (rbac.md)
|
||||
- **Feingliedrige Zugriffsstufen** pro Aktion (Lesen, Erstellen, Bearbeiten, Löschen):
|
||||
|
||||
| Stufe | Zugriff |
|
||||
|---|---|
|
||||
| Kein Zugriff | Funktion nicht verfügbar |
|
||||
| Eigene Daten | Nur selbst erstellte Einträge |
|
||||
| Mandantendaten | Alle Daten des eigenen Mandanten |
|
||||
| Alle Daten | Vollzugriff (Administratoren) |
|
||||
|
||||
*(security-overview.md § 4.1 / rbac.md)*
|
||||
- **Vollständige Mandantentrennung:** Zugehörigkeitsprüfung bei jedem Zugriff serverseitig – keine mandantenübergreifenden Datenflüsse. (security-overview.md § 3)
|
||||
|
||||
> **Visual-Hinweis:** Schlüssel-Icon + vier abgestufte Balken (kein / eigene / Mandant / alle).
|
||||
|
||||
---
|
||||
|
||||
## Folie 5 – Verbindungen
|
||||
|
||||
### Einfache Anbindung von Informationsquellen und Agentensystemen
|
||||
|
||||
- **Toolbox-Registry:** Der Agent verfügt über thematische Tool-Gruppen (`core`, `ai`, `datasources`, `email`, `sharepoint`, `clickup`, `jira`, `workflow`, `trustee`) und kann bei Bedarf weitere zur Laufzeit nachfordern. (ai-agent.md)
|
||||
- **Connection-abhängige Aktivierung:** External-Toolboxes werden nur freigeschaltet, wenn der Nutzer eine passende Connection hat (z. B. Microsoft, ClickUp, Jira). (ai-agent.md)
|
||||
- **Modellunabhängigkeit:** Integration mit Anthropic, OpenAI, Mistral, Perplexity, Tavily und Private LLM – kein Vendor-Lock-in, das jeweils beste Modell pro Aufgabe. (product-vision.md)
|
||||
|
||||
> **Visual-Hinweis:** Hub-and-Spoke-Grafik: PowerOn in der Mitte, Connectoren nach aussen (SharePoint, ClickUp, Jira, Mail, Private LLM, externe Modelle).
|
||||
|
||||
---
|
||||
|
||||
## Folie 6 – Regeln / Ethik
|
||||
|
||||
### Vertrauensvoller und fairer Einsatz der KI
|
||||
|
||||
- **Transparente KI-Datenverarbeitung:** Die Plattform legt offen, welche Daten an welche KI-Dienste übermittelt werden. (security-overview.md § 7)
|
||||
- **Lückenloser Audit-Trail:** Alle sicherheitsrelevanten Aktionen (Zugriffe, Administratoraktionen, Berechtigungsänderungen, KI-Nutzung) werden automatisch protokolliert und sind für Compliance-Nachweise verfügbar. (security-overview.md § 8)
|
||||
- **DSGVO-Betroffenenrechte als Self-Service:** Auskunft, Löschung, Datenübertragbarkeit und Berichtigung sind direkt in der Plattform implementiert. (security-overview.md § 2)
|
||||
- **Kein unkontrolliertes Superuser-Konto:** Auch Administratoren unterliegen dem RBAC-System; jede Aktion ist nachvollziehbar. (security-overview.md § 4.3)
|
||||
|
||||
> **Visual-Hinweis:** Waage-Icon (Balance) plus ein Logbuch-Symbol für den Audit-Trail.
|
||||
|
||||
---
|
||||
|
||||
## Übergeordneter Visual-Hinweis für PowerPoint
|
||||
|
||||
- **Statt Kreis → Zeile:** 5 gleich grosse Karten nebeneinander auf der Übersichts-Folie.
|
||||
- **Farblogik konsistent halten:** pro Säule eine Farbe (z. B. wie im Original: Use-Cases grün, Datenschutz rosa, Berechtigungen blau, Verbindungen grau, Regeln/Ethik orange) und diese Farbe auch auf der jeweiligen Detail-Folie als Akzent verwenden.
|
||||
- **Lesbarkeit:** Keine schräg gestellten Labels. Titel horizontal, Leitsatz in 1–2 Zeilen, Belege als Bullet-Liste mit max. 3–4 Einträgen pro Folie.
|
||||
- **Quellen-Footer (optional):** klein am Folienrand: „Quelle: PowerOn Wiki – a-strategy / b-reference / e-compliance".
|
||||
266
docs/social-clip-poweron-ai-desktop.md
Normal file
266
docs/social-clip-poweron-ai-desktop.md
Normal file
|
|
@ -0,0 +1,266 @@
|
|||
# Social-Media-Werbeclip: PowerOn Desktop (AI Workspace)
|
||||
|
||||
Handbuch fuer einen **Stufen-Clip**: Funktionen und Vorteile **der Reihe nach** — aehnlich wie bei eurem **Treuhand- / Trustee-Beispiel** (Canva-Folie: grosse Schrittnummer, klare Headline, kurzer Erklaertext, zentrale Screenshot-Flaeche, optionaler Footer-Hinweis mit Pfeil).
|
||||
|
||||
**Medien:** Mockups, **selbst aufgezeichnete Screen Recordings**, optional Motion-Transitions zwischen den Stufen.
|
||||
**Laenge:** ca. **30–60 s**, je nach Anzahl Stufen (pro Stufe typisch **3–5 s**).
|
||||
**Plattformen:** Reels, Shorts, TikTok (**9:16**), LinkedIn (**1:1** oder **4:5**).
|
||||
|
||||
---
|
||||
|
||||
## Dieses Format vs. „Problem–Loesung–Montage“
|
||||
|
||||
| Ansatz | Eignung |
|
||||
|--------|---------|
|
||||
| **Stufen-Clip (dieses Dokument)** | Zuschauer sollen **einzelne Staerken** nacheinander **merken** — wie eine Kurz-Praesentation. Ideal, wenn ihr **mehrere Funktionen** fair abhaengen wollt. |
|
||||
| Reiner Hook–Pain–Solution-Clip | Ein emotionaler Bogen in 20–30 s; weniger Platz fuer **5+ konkrete Features**. |
|
||||
|
||||
Beides laesst sich kombinieren: **Stufe 0** = 2 s Hook, dann **Stufe 1 ff.** = Features.
|
||||
|
||||
---
|
||||
|
||||
## Slide-/Card-Vorlage (orientiert am Trustee-Beispiel)
|
||||
|
||||
Pro **Stufe** eine visuelle Einheit (Canva-Slide, After-Effects-Comp oder Schnitt-Szene mit festem Layout):
|
||||
|
||||
| Bereich | Inhalt | Hinweis |
|
||||
|---------|--------|---------|
|
||||
| **Badge** (oben links, optional) | z. B. `Neu`, `PowerOn Desktop`, Kampagnen-Tag | Kurz; nicht jede Stufe muss ein Badge haben |
|
||||
| **Schrittnummer** | Grosse Zahl `1`, `2`, `3` … | Sofort klar: „wir sind bei Schritt X“ |
|
||||
| **Headline** | **Ein Nutzenversprechen** (nicht Techniklabel) | z. B. „Einfache Bedienung“, „Alles im Blick“ |
|
||||
| **Fliesstext** (1–2 Saetze) | **Was die Funktion tut** + **warum es dem Nutzer hilft** | Verstaendlich fuer Nicht-Techies |
|
||||
| **Akzentzeile** (optional, unten mit Pfeil) | Micro-CTA oder Feature-Kern | z. B. „Einfacher Drag and Drop“ — analog zu eurem Trustee-Slide |
|
||||
| **Mittelband / Label** ueber dem Screenshot | **Name der gezeigten Funktion** | z. B. „Dokumenten-Upload“ bei Trustee; bei Desktop z. B. „KI-Chat im Workspace“ |
|
||||
| **Hauptbild** | **Screen Recording** oder Mockup | Echte UI bevorzugt; Demo-Mandat, anonymisiert |
|
||||
| **Seitenleiste** (optional) | `www.poweron.swiss` vertikal | Wiedererkennung wie auf eurer Referenzfolie |
|
||||
|
||||
**Social-Best-Practice dazu:** Pro Stufe **nur eine Kernaussage** lesbar halten; bei **Sound off** muessen **Nummer + Headline** allein schon den Nutzen transportieren.
|
||||
|
||||
---
|
||||
|
||||
## Namensfuehrung
|
||||
|
||||
| Kontext | Bezeichnung |
|
||||
|---------|-------------|
|
||||
| Stufen-Headlines / Voiceover (Kunde) | **PowerOn Desktop**, „**Ihr KI-Arbeitsplatz**“ |
|
||||
| Screenshot (Navigation in der App) | **AI Workspace** (ggf. Voice: „PowerOn Desktop – der AI Workspace“) |
|
||||
| Marke | **PowerOn** |
|
||||
|
||||
---
|
||||
|
||||
## Empfohlene Stufenfolge (PowerOn Desktop)
|
||||
|
||||
Die Reihenfolge ist fuer **Verstaendnis** optimiert: erst **Gesamtbild**, dann **Arbeiten mit KI**, dann **Daten**, dann **Kontextsteuerung**, dann **Quellen**, dann **Kontrolle**, dann **Transparenz**, zuletzt **CTA**.
|
||||
|
||||
---
|
||||
|
||||
### Stufe 0 — Einstieg (optional, 2–3 s)
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Badge | `PowerOn` oder `Neu` |
|
||||
| Nummer | — oder kleines `Start` |
|
||||
| Headline | **Ihr KI-Arbeitsplatz in einem Workspace** |
|
||||
| Text | Chat, Dateien und Quellen zusammen — statt staendig zwischen Tools zu wechseln. |
|
||||
| Screenshot | Sehr kurze **Gesamtansicht** AI Workspace (drei Spalten andeuten) oder nur Logo + Farbflaeche |
|
||||
| Footer (optional) | **Mehr Ueberblick. Weniger Medienbruch.** |
|
||||
|
||||
**Voiceover (optional):**
|
||||
> „PowerOn Desktop: alles, was Sie fuer produktives Arbeiten mit KI brauchen — an einem Ort.“
|
||||
|
||||
---
|
||||
|
||||
### Stufe 1 — Ein Workspace, alles verbunden
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **1** |
|
||||
| Headline | **Alles im Blick** |
|
||||
| Text | Chats, Dateien und Datenquellen in **einer** Oberflaeche. Sie behalten den Faden vom ersten Satz bis zur fertigen Ausarbeitung. |
|
||||
| Mittelband | `AI Workspace` |
|
||||
| Screenshot | **Workspace Gesamtansicht:** links Tabs **Chats / Files / Sources**, Mitte Chat, rechts **Activity** oder **Preview** |
|
||||
| Footer (optional) | **Ein Ort statt fuenf Fenster** |
|
||||
|
||||
**Was im Recording zeigen:** 2–3 s ruhig auf Layout verweilen; Cursor einmal links ueber die drei Tabs fuehren (ohne Hektik).
|
||||
|
||||
---
|
||||
|
||||
### Stufe 2 — Mit KI arbeiten, mit Kontext
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **2** |
|
||||
| Headline | **Fragen. Antworten. Nachvollziehbar.** |
|
||||
| Text | Der **KI-Chat** nutzt Ihre gebundenen Inhalte — Antworten lassen sich an **Quellen** und Schritten nachvollziehen, nicht nur „aus dem Bauch“ der KI. |
|
||||
| Mittelband | `KI-Chat` |
|
||||
| Screenshot | Aktive Konversation mit **sichtbarer** Antwort; wenn moeglich **Quellen** oder Anhaenge andeuten |
|
||||
| Footer (optional) | **Weniger Raetselraten** |
|
||||
|
||||
**Hinweis:** Demo-Frage so waehlen, dass die Antwort in 2–3 s lesbar ist (kurzer Absatz).
|
||||
|
||||
---
|
||||
|
||||
### Stufe 3 — Dateien ablegen und mitnehmen
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **3** |
|
||||
| Headline | **Einfach ablegen** |
|
||||
| Text | **Dateien** im Workspace ablegen, sortieren und direkt als Kontext fuer die KI nutzen — analog zu eurem Trustee-Beispiel mit klarer **Drag-and-Drop**-Botschaft. |
|
||||
| Mittelband | `Dateien` / `Files` |
|
||||
| Screenshot | Tab **Files**: Ordnerliste oder **Drag-and-Drop**-Zone kurz zeigen (Datei markieren oder in Zone ziehen) |
|
||||
| Footer (optional) | **Einfacher Drag and Drop** |
|
||||
|
||||
---
|
||||
|
||||
### Stufe 4 — Wer sieht was? Kontextsteuerung pro Datei
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **4** |
|
||||
| Headline | **Wer sieht was?** |
|
||||
| Text | Fuer jede Datei bestimmen Sie mit **einem Klick**, ob sie **persoenlich** bleibt, im **Team** (Instanz) sichtbar wird oder dem ganzen **Mandanten** zur Verfuegung steht. Die KI nutzt genau diesen Kontext. |
|
||||
| Mittelband | `Kontextsteuerung` / `Scope` |
|
||||
| Screenshot | Tab **Files** mit sichtbaren **Scope-Icons** neben den Dateinamen: 👤 Persoenlich, 👥 Instanz, 🏢 Mandant; Cursor klickt ein Icon — es wechselt zur naechsten Stufe |
|
||||
| Footer (optional) | **Ein Klick. Drei Stufen.** |
|
||||
|
||||
**Was im Recording zeigen:** Files-Tab mit mind. 3 Dateien, jede mit sichtbarem Scope-Icon. Klick auf ein Icon — Wechsel von 👤 (Persoenlich) zu 👥 (Instanz). Kurz verweilen, damit die **Legende** unten sichtbar ist (Persoenlich / Instanz / Mandant).
|
||||
|
||||
---
|
||||
|
||||
### Stufe 5 — Eigene Systeme einbinden
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **5** |
|
||||
| Headline | **Ihre Datenquellen, Ihr Kontext** |
|
||||
| Text | Cloud und Fachsysteme als **Quellen** anbinden — die KI arbeitet mit dem, was Sie **freigeben**, nicht mit beliebigem Internetwissen. |
|
||||
| Mittelband | `Datenquellen` / `Sources` |
|
||||
| Screenshot | Tab **Sources**: mind. eine verbundene Quelle sichtbar (farbcodierte Eintraege); keine echten Mandantendaten |
|
||||
| Footer (optional) | **Gebunden statt raten** |
|
||||
|
||||
---
|
||||
|
||||
### Stufe 6 — Aenderungen pruefen, dann freigeben
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **6** |
|
||||
| Headline | **Sie entscheiden** |
|
||||
| Text | Im **Editor** sehen Sie Aenderungen im **Vergleich** — **annehmen** oder **ablehnen**. Tempo von KI, Kontrolle bei Ihnen. |
|
||||
| Mittelband | `Aenderungen pruefen` / `File Edit Review` |
|
||||
| Screenshot | **Editor** mit Diff / Vorher–Nachher oder Aktionsleiste **Accept / Reject** |
|
||||
| Footer (optional) | **Freigabe bleibt bei Ihnen** |
|
||||
|
||||
---
|
||||
|
||||
### Stufe 7 — Transparenz bei der Arbeit
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **7** |
|
||||
| Headline | **Nachvollziehbar fuer Teams** |
|
||||
| Text | Die **Aktivitaets**-Ansicht zeigt, was im Hintergrund laeuft — gut fuer Vertrauen im Team und fuer Fuehrungskraefte, die Steuerung wollen. |
|
||||
| Mittelband | `Aktivitaet` / `Activity` |
|
||||
| Screenshot | Rechte Spalte **Activity** mit Eintraegen / Status |
|
||||
| Footer (optional) | **Keine Blackbox** |
|
||||
|
||||
---
|
||||
|
||||
### Stufe 8 — Abschluss + CTA (3–5 s)
|
||||
|
||||
| Feld | Vorschlag |
|
||||
|------|-----------|
|
||||
| Nummer | **8** oder weglassen |
|
||||
| Headline | **PowerOn Desktop** |
|
||||
| Text | Produktiv mit KI arbeiten — mit Struktur, Daten und Kontrolle. |
|
||||
| Screenshot | Wieder **Gesamtansicht** oder nur Markenflaeche |
|
||||
| Footer | **Demo auf poweron.swiss** — URL nach Freigabe |
|
||||
|
||||
| Element | Wert |
|
||||
|---------|------|
|
||||
| Primaer-Link | `https://____________` |
|
||||
| UTM (optional) | `?utm_source=___&utm_medium=paid_social&utm_campaign=ai_desktop` |
|
||||
|
||||
---
|
||||
|
||||
## Kurzvariante (ca. 30 s)
|
||||
|
||||
Nur **Stufen 0 → 1 → 2 → 6 → 8** (Ueberblick, Chat, Editor-Kontrolle, CTA).
|
||||
Pro Stufe **~4 s**.
|
||||
Optional **Stufe 4** (Kontextsteuerung) ergaenzen, wenn die Datei-Sichtbarkeit betont werden soll (+4 s).
|
||||
|
||||
---
|
||||
|
||||
## Schnitt-Timeline (Referenz, alle 8 inkl. 0)
|
||||
|
||||
| Stufe | ca. Sekunden |
|
||||
|-------|----------------|
|
||||
| 0 Einstieg | 2–3 |
|
||||
| 1 Workspace | 4–5 |
|
||||
| 2 KI-Chat | 4–5 |
|
||||
| 3 Dateien | 3–4 |
|
||||
| 4 Kontextsteuerung | 3–4 |
|
||||
| 5 Quellen | 3–4 |
|
||||
| 6 Editor | 4–5 |
|
||||
| 7 Aktivitaet | 3–4 |
|
||||
| 8 CTA | 3–5 |
|
||||
|
||||
**Summe:** etwa **48–65 s** — kuerzbar durch Weglassen von 3, 4, 5 oder 7.
|
||||
|
||||
---
|
||||
|
||||
## Mockups vs. Screen Recordings
|
||||
|
||||
| Stufe | Empfehlung |
|
||||
|-------|------------|
|
||||
| 0, 8 | Mockup oder reduzierte UI + starke Typo erlaubt |
|
||||
| 1–7 | **Echtes Screen Recording** aus Demo-Instanz (Zoom 100–125 %, ruhiger Cursor) |
|
||||
|
||||
Uebergaenge: kurzer **Push** oder **Match-Cut** auf die naechste Schrittnummer — konsistent mit eurem Trustee-Stil (Farbe, Schrift, www.poweron.swiss).
|
||||
|
||||
---
|
||||
|
||||
## Social-Media-Best Practices (kompakt)
|
||||
|
||||
- **Erste Sekunde:** Bewegung oder klare Schritt-`1`-Flaeche — sonst Swipe weg.
|
||||
- **Ein Gedanke pro Stufe:** Headline + ein Satz Text reichen.
|
||||
- **Ohne Ton:** alles Wichtige als **grossen Text** im Bild; Untertitel zusaetzlich.
|
||||
- **9:16:** Text nicht in die untere Drittel-Social-UI legen; **sichere Zone** einplanen.
|
||||
- **Keine Echtdaten** in Screens; Demo-Mandat, anonymisierte Namen/Dateien.
|
||||
|
||||
---
|
||||
|
||||
## Untertitel-Zeile pro Stufe (Sprechertext)
|
||||
|
||||
1. „PowerOn Desktop — Ihr KI-Arbeitsplatz.“
|
||||
2. „Alles verbunden: Chat, Dateien, Quellen.“
|
||||
3. „Der Chat nutzt Ihren Kontext — nachvollziehbar.“
|
||||
4. „Dateien ablegen — per Drag and Drop.“
|
||||
5. „Persoenlich, Team oder Mandant — Sie bestimmen, wer was sieht.“
|
||||
6. „Ihre Systeme als Quellen — bewusst freigegeben.“
|
||||
7. „Aenderungen pruefen — annehmen oder ablehnen.“
|
||||
8. „Aktivitaet sichtbar — keine Blackbox.“
|
||||
9. „Demo: poweron.swiss.“
|
||||
|
||||
---
|
||||
|
||||
## Marken- und Rechts-Checkliste
|
||||
|
||||
- [ ] **PowerOn** Schreibweise
|
||||
- [ ] Feature in UI: **AI Workspace**; Werbetext: **PowerOn Desktop**
|
||||
- [ ] Keine personenbezogenen / Kundenechtdaten in Aufnahmen
|
||||
- [ ] Musik lizenziert
|
||||
- [ ] Starke Datenschutz-Aussagen nur nach Legal-Abstimmung
|
||||
|
||||
---
|
||||
|
||||
## Verwandte interne Doku
|
||||
|
||||
- [case-study-power-desktop.md](case-study-power-desktop.md) — Argumente und Tiefe
|
||||
- [product-teaser-poweron.md](product-teaser-poweron.md) — Plattform
|
||||
- [social-clip-poweron-treuhand.md](social-clip-poweron-treuhand.md) — anderes Feature, gleiches **Stufen-Prinzip** mit Screens
|
||||
|
||||
---
|
||||
|
||||
*Stand: April 2026*
|
||||
160
docs/social-clip-poweron-treuhand.md
Normal file
160
docs/social-clip-poweron-treuhand.md
Normal file
|
|
@ -0,0 +1,160 @@
|
|||
# Social-Media-Kurzclip: PowerOn Treuhand
|
||||
|
||||
Produktionshandbuch fuer **reine Screen-Aufnahmen**: On-Screen-Texte, Screen-Storyboard und Freigaben. Ziel: **20-40 s** (Reels, Shorts, LinkedIn). Ton: sachlich-treuhaenderisch.
|
||||
|
||||
---
|
||||
|
||||
## Grundsetup fuer Screen-Only
|
||||
|
||||
- Kein Interview-Footage einplanen, nur UI-Aufnahmen aus PowerOn.
|
||||
- On-Screen-Texte kurz halten (max. 6-8 Woerter pro Karte).
|
||||
- 9:16 schneiden (1080x1920) oder aus 16:9 sauber croppen.
|
||||
- Alle Daten in Demo-Instanz anonymisieren.
|
||||
|
||||
---
|
||||
|
||||
## Shot 1: Customer Story (3-5 s)
|
||||
|
||||
### On-Screen — Variante A (generisch)
|
||||
|
||||
| Karte | Text |ca. Zeichen |
|
||||
|-------|------|------------|
|
||||
| 1 | Treuhand im Alltag | kurz |
|
||||
| 2 | Ein Team. Viele Mandate. | kurz |
|
||||
|
||||
### On-Screen — Variante B (persona)
|
||||
|
||||
| Karte | Text |
|
||||
|-------|------|
|
||||
| 1 | Fiduciary / Treuhänder:in |
|
||||
| 2 | Belege. Buchhaltung. Verantwortung. |
|
||||
|
||||
### Screen-Aufnahme (statt Interview)
|
||||
|
||||
- Navigiere zu **Treuhand > Uebersicht (Dashboard)**.
|
||||
- Zeige 1-2 Sekunden die gesamte Seite, dann kurzer Fokus auf Kacheln.
|
||||
- Sichtbar: `Positionen`, `Dokumente`, `Buchhaltung`.
|
||||
|
||||
### Optionales Voiceover
|
||||
|
||||
> „Treuhand im Alltag: viele Mandate, viele Belege, hohe Verantwortung.“
|
||||
|
||||
---
|
||||
|
||||
## Shot 2: Pain — Before (4-8 s)
|
||||
|
||||
### On-Screen — Standard (4 Karten, schneller Wechsel)
|
||||
|
||||
1. `Before:`
|
||||
2. `Belege überall`
|
||||
3. `manuell abtippen`
|
||||
4. `keine klare Zuordnung`
|
||||
|
||||
### On-Screen — Schnitt-Variante (3 Karten)
|
||||
|
||||
1. `Before: Chaos in Postfach & Ordnern`
|
||||
2. `Excel & Copy-Paste`
|
||||
3. `Prüfung? Lücken in der Akte`
|
||||
|
||||
### Voiceover (optional)
|
||||
|
||||
> „Vorher: verteilte Belege, manuelle Schritte und wenig Transparenz.“
|
||||
|
||||
### Screen-Aufnahme (Pain visuell zeigen)
|
||||
|
||||
- In **Dokumente** kurz eine unstrukturierte Liste zeigen.
|
||||
- Dann in **Positionen** kurz eine manuelle Erfassung andeuten (z. B. Tabelle ohne Zuordnung).
|
||||
- Optional 0.5-1 s auf fehlende Zuordnung wechseln (noch nicht `Zuordnungen` zeigen).
|
||||
|
||||
---
|
||||
|
||||
## Shot 3: After — PowerOn Treuhand (10-18 s)
|
||||
|
||||
### On-Screen (4 Karten, über den Screen gelegt)
|
||||
|
||||
1. `After:`
|
||||
2. `PowerOn Treuhand`
|
||||
3. `eine Instanz · klare Akte`
|
||||
4. `bis zur Buchhaltung`
|
||||
|
||||
### Voiceover (optional)
|
||||
|
||||
> „Mit PowerOn Treuhand ist alles pro Mandat gebuendelt: Positionen, Dokumente, Zuordnungen und Sync.“
|
||||
|
||||
### Screen-Aufnahmen — Storyboard (Reihenfolge)
|
||||
|
||||
**Technik:** Demo- oder Schulungsmandat; **keine realen Mandantennamen**; Cursor ruhig; ideal **9:16** (1080x1920) oder Ausschnitt.
|
||||
|
||||
| Nr. | Dauer | Navigation | Sichtbar machen |
|
||||
|-----|-------|------------|------------------|
|
||||
| 1 | 3-4 s | Treuhand -> **Uebersicht** (Dashboard) | Kacheln: Positionen, Dokumente, Buchhaltung; Bereich **Instanz-Details** (Instanz, Mandant) |
|
||||
| 2 | 2-3 s | **Positionen** | Tabelle mit mind. einer Zeile; optional **Sync-Status-Spalte**; kurz Zeile anklicken oder markieren |
|
||||
| 3 | 2-3 s | **Positionen** (optional) | **Mehrfachauswahl** einer Zeile -> Aktion **Sync zur Buchhaltung** (nur wenn Demo OK); sonst Nr. 2 verlaengern |
|
||||
| 4 | 2-3 s | **Dokumente** | Liste; **Download** auf eine Zeile oder Upload-Dialog starten (ohne sensible Dateinamen) |
|
||||
| 5 | 2-3 s | **Zuordnungen** | Mind. eine Zeile: Verknuepfung **Position <-> Dokument** lesbar |
|
||||
| 6 | 2-4 s | *Entweder* **Scannen / Hochladen** *oder* **Spesen Import** | **Scannen:** PDF/JPG per Drag-and-Drop -> **Pipeline-Status** (laeuft/fertig). **Spesen:** verbundene Microsoft-/Ordner-Ansicht + Automation sichtbar aktiv |
|
||||
|
||||
**Kürzestes Set (wenn Zeit knapp):** nur **1 → 2 → 5** (Dashboard, Positionen, Zuordnungen).
|
||||
|
||||
**Nicht noetig im Kurzclip:** lange Passagen **Buchhaltungseinstellungen** oder **Rollen & Rechte**; hoechstens der Hinweis „Buchhaltung konfiguriert“ auf dem Dashboard.
|
||||
|
||||
---
|
||||
|
||||
## Shot 4: Closing (3-5 s)
|
||||
|
||||
### On-Screen — Englisch
|
||||
|
||||
- `Real business.`
|
||||
- `Real wins.`
|
||||
|
||||
### On-Screen — Deutsch (Alternative)
|
||||
|
||||
- `Echtes Geschäft.`
|
||||
- `Messbarer Gewinn.`
|
||||
|
||||
### On-Screen — Ultra-kurz
|
||||
|
||||
- `Weniger Handarbeit. Mehr Nachweis.`
|
||||
|
||||
### CTA (letzte Karte)
|
||||
|
||||
Setzen Sie die **verbindliche URL** nach Freigabe ein:
|
||||
|
||||
| Element | Wert |
|
||||
|---------|------|
|
||||
| Primär-Link | `https://____________` |
|
||||
| Tracking (UTM) | optional `?utm_source=___&utm_medium=social` |
|
||||
|
||||
### Voiceover (optional)
|
||||
|
||||
> „Real business. Real wins.“
|
||||
|
||||
---
|
||||
|
||||
## Marken- und Rechts-Checkliste
|
||||
|
||||
- [ ] Schreibweise **PowerOn** (nicht Power On / poweron außerhalb der Domain)
|
||||
- [ ] Feature-Bezeichnung konsistent mit Navigation: **Treuhand** bzw. interner Label „Trustee“
|
||||
- [ ] Bei reinem Screen-Clip: keine Personen/Gesichter sichtbar
|
||||
- [ ] Keine **geschützten Kundendaten** in Screens (Demo-Mandat)
|
||||
- [ ] Musik: Lizenz / Ton über Plattform-Library
|
||||
- [ ] Falls Mitarbeitende sichtbar: **Bildrechte** oder Silhouette/Blur
|
||||
|
||||
---
|
||||
|
||||
## Schnitt-Timeline (Referenz)
|
||||
|
||||
| Block | Ziel-Länge |
|
||||
|-------|------------|
|
||||
| Customer Story | 3-5 s |
|
||||
| Before | 4-8 s |
|
||||
| After (Screen-Only) | 10-18 s |
|
||||
| Closing + CTA | 3-5 s |
|
||||
|
||||
**Gesamt:** ca. 20–35 s; bei längerer Musik + Logo-Stinger bis 40 s.
|
||||
|
||||
---
|
||||
|
||||
## Verwandte interne Doku
|
||||
|
||||
- [product-teaser-billing-poweron.md](product-teaser-billing-poweron.md) — Markenkontext PowerOn
|
||||
Loading…
Reference in a new issue