feat: restructure dHive knowledge into OKF layout
This commit is contained in:
@@ -0,0 +1,122 @@
|
||||
# AGENTS.md
|
||||
|
||||
---
|
||||
|
||||
## Coding rules
|
||||
|
||||
1. Read `SPEC.md` first and treat it as source of truth ("the spec"). If `SPEC.md` does not exist, **stop and ask**.
|
||||
2. Follow the user prompt exactly; do not omit explicitly requested steps.
|
||||
3. **Avoid over-engineering.** Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused:
|
||||
- Scope: Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.
|
||||
- Documentation: Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.
|
||||
- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs).
|
||||
- Abstractions: Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task.
|
||||
- Custom coding: Don't reinvent the wheel, use the functions the framework provides you with. If you think that using framework is not possible, consult the relevant online or MCP docs to make sure. If you still cannot find a solution within the framework, **stop and ask**.
|
||||
4. Do not hard-code values or create solutions that only work for specific test inputs; implement the actual logic that solves the problem generally.
|
||||
5. The resulting code must be robust, maintainable, and extendable.
|
||||
6. The resulting code must not contradict the spec.
|
||||
7. **Before writing code**, post a short and concise "Plan + spec mapping" summary and **ask for approval to proceed**. Do not implement until you receive the go-ahead.
|
||||
8. Documentation Rules:
|
||||
- filenames are always capitalized.
|
||||
- describes the **current state only**. Do not include change/history phrasing.
|
||||
- must always be coherent end-to-end never have stale or conflicting info.
|
||||
9. Always use repo virtual environment (unless there is none).
|
||||
|
||||
---
|
||||
|
||||
## Documentation MCP policy
|
||||
|
||||
- We run ONE docs MCP server: `docs` (multi-library).
|
||||
|
||||
### Library selection
|
||||
- For any docs query call (everything except `list_libraries`), you MUST set `library`.
|
||||
- If the prompt or repo context involves a specific product/project unambiguously, use that as `library` (e.g. `library="haystack"`).
|
||||
- If more than one library could plausibly match, call `list_libraries` and select the best match (do not invent/guess library ids).
|
||||
- If the task spans multiple products, run separate docs calls per library and label results by library.
|
||||
|
||||
### Version selection
|
||||
- If the prompt or repo context involves a version or range (e.g. `2.25`, `2.x`), call `find_version(library=..., targetVersion=...)` and record the returned `version`.
|
||||
- Use that resolved `version` for all subsequent calls for that library.
|
||||
- If `find_version` cannot resolve unambiguously, **stop and ask**.
|
||||
- If no version is mentioned, omit `version` (defaults to latest indexed for that library).
|
||||
|
||||
- We also run the `github` MCP server. Consult it always for code that is in public github instead of searching at the disk or cloning the repos locally.
|
||||
|
||||
---
|
||||
## Base branch rule
|
||||
|
||||
**BASE_BRANCH = the branch that new work branches are created from and PRs target.**
|
||||
|
||||
Default:
|
||||
- If the user did not explicitly specify a base/target branch, set:
|
||||
- `BASE_BRANCH=$(git branch --show-current)` (from the user's main checkout at session start)
|
||||
|
||||
Override:
|
||||
- If the user explicitly specifies a base/target branch in the prompt, use that as `BASE_BRANCH`.
|
||||
|
||||
Remote base ref:
|
||||
- If `origin/$BASE_BRANCH` exists, use that as `BASE_REF`, else use `$BASE_BRANCH`:
|
||||
- `git show-ref --verify --quiet "refs/remotes/origin/$BASE_BRANCH" && BASE_REF="origin/$BASE_BRANCH" || BASE_REF="$BASE_BRANCH"`
|
||||
|
||||
Notes:
|
||||
- This supports long-lived feature integration branches and stacked PRs.
|
||||
- The base branch may itself be another PR branch (for stacking); set BASE_BRANCH accordingly.
|
||||
|
||||
---
|
||||
|
||||
## Before work
|
||||
1. Determine base branch (unless user specified it explicitly):
|
||||
- `BASE_BRANCH=$(git branch --show-current)`
|
||||
2. Fetch latest refs:
|
||||
- `git fetch origin --prune`
|
||||
3. Update base branch (fast-forward only) if it has an `origin/` tracking ref:
|
||||
- `git switch "$BASE_BRANCH"`
|
||||
- `if git show-ref --verify --quiet "refs/remotes/origin/$BASE_BRANCH"; then git pull --ff-only origin "$BASE_BRANCH"; fi`
|
||||
- If the pull fails for any reason, stop and ask.
|
||||
4. Read `SPEC.md` + `README.md` once per session. Re-read only if changed/unsure:
|
||||
- `git log -1 --oneline -- SPEC.md README.md`
|
||||
5. If deviating from `SPEC.md`: **stop and ask**.
|
||||
6. Create a new local work branch (once per session) **from BASE_BRANCH**. **ALWAYS push to the branch you created.**
|
||||
- `git switch -c "agent/<topic>-YYYYMMDD-<shortid>"`
|
||||
|
||||
## Tests
|
||||
- Run tests only if the prompt requests or `SPEC.md` requires them; run all requested tests.
|
||||
- If any cannot be run: **stop and ask**.
|
||||
|
||||
## After work
|
||||
1. Make sure you did not miss requested tests.
|
||||
2. If you are addressing a **remote github issue** with
|
||||
- "to-do" checklist: for **each** item, make sure your implementation is **fully complete** and:
|
||||
- if yes, check it off
|
||||
- if not, finish implementation and recheck.
|
||||
- "acceptance" checklist: for **each** item, make the acceptance criterion is **completely fulfilled** and:
|
||||
- if yes, check it off
|
||||
- if not, implement missing code and recheck.
|
||||
3. Update all relevant documentation appropriately.
|
||||
4. **Before making a commit**: Stop and ask user to `/review` → `Review uncommited changes`.
|
||||
5. Commit **only after** user confirms code review passed.
|
||||
6. Open a PR or use already opened PR
|
||||
- **use your created branch**.
|
||||
- **Target `BASE_BRANCH`**.
|
||||
- PR text requirements:
|
||||
- commands in backticks
|
||||
- real newlines (ANSI-C quoting/heredoc)
|
||||
- if addressing a **remote github issue**, reference it so that github can close automatically after merging.
|
||||
7. **Only after** PR is merged:
|
||||
- switch back to base branch and sync it
|
||||
- `git switch "$BASE_BRANCH"`
|
||||
- `git fetch origin --prune`
|
||||
- `if git show-ref --verify --quiet "refs/remotes/origin/$BASE_BRANCH"; then git reset --hard "origin/$BASE_BRANCH"; fi`
|
||||
- If the reset fails, **stop and ask**.
|
||||
- delete the local merged work branch
|
||||
|
||||
---
|
||||
|
||||
## Required completion checklist (final response)
|
||||
- [ ] Base/target branch used correctly (BASE_BRANCH)
|
||||
- [ ] **all** Coding rules followed
|
||||
- [ ] All requested tests run (commands + results), or blocked → asked
|
||||
- [ ] Documentation updated appropriately: **list updated files**
|
||||
- [ ] PR opened (summary + command log) targeting BASE_BRANCH
|
||||
- [ ] After merge (if applicable): base branch synced; merged branch deleted
|
||||
---
|
||||
@@ -0,0 +1,16 @@
|
||||
# Component: Projekt-KIQ-HP
|
||||
|
||||
## Description
|
||||
KIQ project homepage - static React/Vite landing page for d-hive KI-Qualifizierung
|
||||
|
||||
## Metadata
|
||||
- **Deployment Target:** vps-docker
|
||||
- **Upstream URL:** https://github.com/DoctoDre/Projekt-KIQ-HP
|
||||
- **Status:** active
|
||||
|
||||
## Interconnections
|
||||
- (to be documented)
|
||||
|
||||
## Notes
|
||||
- Part of dhive context in the Orchestrator monorepo
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
# GitHub Issues - Next Steps
|
||||
|
||||
Da das GitHub CLI lokal nicht installiert war, sind hier die Issues, die wir im Repository als nächstes abarbeiten (oder in GitHub übertragen) sollten, um das Projekt abzuschließen:
|
||||
|
||||
## 1. High-Res Partner Logos einpflegen
|
||||
**Titel:** Hochauflösende Partnerlogos einpflegen
|
||||
**Beschreibung:** Die aktuellen Logos der Partnergesellschaften (Arvos Group, eoda, Viessmann, Science Park Kassel) sind in der Marquee-Komponente als Text-Platzhalter implementiert. Um den Nickle.ai-Look im Marquee perfekt umzusetzen, benötigen wir transparente PNGs oder SVGs der Logos, idealerweise in Weiß oder Grau für den Dark Mode.
|
||||
|
||||
## 2. Kontaktformular / E-Mail Anbindung
|
||||
**Titel:** CTA Footer Button mit echtem Kontakt-Routing verbinden
|
||||
**Beschreibung:** Der Button "Jetzt Kontakt aufnehmen" im Footer ist momentan als `mailto:` Link konfiguriert. Wir sollten ein kleines Kontaktformular-Modal implementieren oder ein Service wie EmailJS / Formspree anbinden, damit der Nutzer die Seite nicht verlassen muss.
|
||||
|
||||
## 3. SEO- und Performance-Optimierung
|
||||
**Titel:** Meta-Tags und SEO in index.html ergänzen
|
||||
**Beschreibung:** Für eine perfekte Performance und Auffindbarkeit müssen wir noch finale Meta-Descriptions, Social-Media-Tags (OpenGraph Image) und das Favicon im `public`-Ordner und in der `index.html` einstellen.
|
||||
|
||||
## 4. CI/CD Pipeline einrichten
|
||||
**Titel:** GitHub Actions Workflow für Deployment
|
||||
**Beschreibung:** Einrichtung einer GitHub Action, die das Vite/React-Projekt bei einem Push in den `main`-Branch automatisch baut (`npm run build`) und das Resultat auf dem Ziel-Server (z.B. GitHub Pages, Vercel, Netlify oder eigener Webserver) bereitstellt.
|
||||
@@ -0,0 +1,7 @@
|
||||
# PLAN.md — Projekt KIQ Homepage
|
||||
|
||||
## Open Tasks
|
||||
- [ ] Hochauflösende Partnerlogos einpflegen (transparente PNGs/SVGs)
|
||||
- [ ] Kontaktformular / E-Mail Anbindung (CTA Footer Button)
|
||||
- [ ] SEO- und Performance-Optimierung (Meta-Tags, OpenGraph, Favicon)
|
||||
- [ ] CI/CD Pipeline einrichten (GitHub Actions → Deployment)
|
||||
@@ -0,0 +1,37 @@
|
||||
# D-Hive Website Redesign: Projekt-Status & Zusammenfassung
|
||||
|
||||
Dieses Dokument dient als Gedächtnisstütze und Übersicht über alle vollendeten Phasen des d-hive Website-Redesigns, falls an dem Projekt zu einem späteren Zeitpunkt weitergearbeitet wird.
|
||||
|
||||
## 🚀 Abgeschlossene Meilensteine
|
||||
|
||||
### Phase 1 & 2: Design-System & Logo-Integration
|
||||
* **Aesthetic Upgrade:** Die Seite wurde auf ein komplett dunkles "Sci-Fi" Theme (`#0a0a0a` / `rgba(20,20,20)`) mit Neon-Green (`#00FF00`) Akzenten umgebaut.
|
||||
* **Kunden-Logos (`Customers.jsx`):** Es läuft nun eine endlose, sanfte Marquee-Animation. Die Logos (wie Uni Kassel, Science Park Kassel) sind im un-hoverten Zustand grau und werden bei Mausberührung farbig. Verlinkungen auf die Originalseiten wurden eingefügt.
|
||||
* **Mitgliedschaften (`Memberships.jsx`):** Diese sind als Raster/Grid umgesetzt. Die Logos sind dauerhaft in ihren Originalfarben (bzw. für dunkle Hintergründe optimiert) zu sehen und machen einen eleganten Zoom-Effekt, wenn man mit der Maus darüber fährt.
|
||||
* **Gefördert durch (`Gefoerdert.jsx`):** Das Distr@l Logo wurde integriert und mit einem weißen `background` ausgestattet, um auf dem dunklen Theme extrem scharf lesbar zu bleiben. Es zoomt beim Hovering und verlinkt direkt auf das Förderprogramm des Landes Hessen.
|
||||
|
||||
### Phase 3 & 4: Inhaltsseiten & Floating Menu
|
||||
* **Rechtliches (`Impressum.jsx` & `Datenschutz.jsx`):** Sämtliche übergebenen AGB- und Datenschutz-Texte von d-hive wurden exakt eingepflegt.
|
||||
* **Inhalte aus d-hive.de:** Inhalte für die Services "Automatisierung" und "KI" wurden durch eine Web-Scraping-KI nativ extrahiert und als Landingpages formatiert.
|
||||
* **Die `UseCases` & `Newsletter` Sektionen:**
|
||||
* **Use Cases:** Ein responsives Raster für zukünftige Portfolio-Einträge.
|
||||
* **Newsletter:** Enthält aktuell drei Platzhalter/Mockup-Beiträge deines LinkedIn-Feeds in einem strukturierten Code-Array, in das du später leicht neue reinkopieren kannst.
|
||||
* **Das "Über uns" (`About.jsx`):** Die Teamprofile von Alexander Schrodt (Struktur-Schaffer) und André Knie (Mensch-Maschine-Moderator) wurden samt Architektur-Ansätzen, Zitaten, Philosophie ("Wir hassen Verschwendung und lieben den Wandel") eingebaut.
|
||||
* **Floating Dock (`BottomDock.jsx`):** Die alte Navigationsleiste oben wurde abgelöst. Nun gibt es in Anlehnung an `nickle.ai` eine moderne Pille, die mittig unten über allem schwebt. Dieses Dock besitzt extrem weiche Mikto-Interaktionen (Tooltips beim Hover) und **wichtiger Zusatz**: Einen leuchtenden, neon-grünen Rahmen (`conic-gradient`), der permanent und flüssig drumherum rotiert.
|
||||
|
||||
### Phase 5: High-End Visuals: 3D-Cube & Seamless Background
|
||||
* **3D Stats-Cube (`Stats.jsx`):** Die vier Erfolgskacheln ("Gründung 2021", "Projekte 50+", "Kunden 15+", "ROI > 2x") wurden in ein tatsächliches CSS-3D-Objekt verwandelt. Der Würfel hält pro Ansicht kurz inne und reißt sich dann um 90 Grad weiter, sodass der Nutzer gebannt auf den nächsten Wert warten muss.
|
||||
* **Infinite Background (`BackgroundPattern.jsx`):** Die d-hive Vektorlinien (`d_-hive-lines_1-1.svg`) wurden in einem dedizierten CSS-Container verarbeitet. Weil die Kanten des Logos sonst hart abschneiden würden, wird das Bild im Code sofort vierzehnfach gespiegelt (Oben, Unten, Links, Rechts), um einen gigantischen, perfekt nahtlos übergehenden ("seamless") Block zu erzeugen. Dieser driftet für das "Big Data"-Feeling unendlich langsam durch den Hintergrund.
|
||||
* **Service-Bilder (`Services.jsx`):** Alle vier Leistungen (Workshops anstelle der normalen Softwareentwicklung) wurden mit futuristischen, von einer KI generierten Matrix-/Cyberpunk-Bildern hinterlegt.
|
||||
|
||||
---
|
||||
|
||||
## 📅 Offene Punkte für die nächste Session
|
||||
|
||||
Wenn ihr wieder startet, stehen vermutlich noch folgende Features aus:
|
||||
1. **Kontakt-Formular Scharfschalten:** Die Maske an ein tatsächliches Backend klemmen (z. B. `EmailJS` oder `Web3Forms`), damit dir Leute direkt in dein Postfach schreiben.
|
||||
2. **Use Cases aufstocken:** Wirkliche Texte zu Case-Studies (z. B. wie wurde die Sensorik implementiert, was hat es gekostet, was gespart) ausfüllen.
|
||||
3. **Newsletter-Logik:** Entscheidung abnehmen, ob die LinkedIn-Posts händisch (wie jetzt im Code als Liste) verbleiben sollen, oder ob wir eine API einbauen, sobald es Content-Systeme gibt.
|
||||
|
||||
---
|
||||
> Alle Code-Änderungen aus unserer Session sind auf dem `main` Branch eures GitHub-Repositories gesichert!
|
||||
@@ -0,0 +1,65 @@
|
||||
# Projekt-KIQ HP
|
||||
|
||||
React + Vite single-page application for Projekt-KIQ, with an Express backend for auth and access request management.
|
||||
|
||||
## Local Development
|
||||
|
||||
Copy the `.env.example` file to create your local environment configuration:
|
||||
|
||||
```bash
|
||||
cp .env.example .env.local
|
||||
```
|
||||
|
||||
Fill in the backend credentials (`ADMIN_USER`, `ADMIN_PASSWORD`, `SESSION_SECRET`).
|
||||
|
||||
### Running locally
|
||||
|
||||
```bash
|
||||
npm install
|
||||
|
||||
# Start the Express backend (port 3003)
|
||||
npm run start:server
|
||||
|
||||
# In another terminal, start the Vite dev server
|
||||
npm run dev
|
||||
```
|
||||
|
||||
The frontend dev server proxies API requests to `http://localhost:3003` (configured via `VITE_API_URL` in `.env.local`).
|
||||
|
||||
## Architecture
|
||||
|
||||
- **Frontend**: React + Vite SPA (static build)
|
||||
- **Backend**: Express.js (session-based auth, JSON file storage for access requests, Nodemailer for email alerts)
|
||||
- **Auth**: Cookie-based sessions (`kiq_session`), single admin user configured via env vars
|
||||
- **Access Requests**: Stored in `server/data/access-requests.json`, email alerts sent via SMTP
|
||||
|
||||
## Production Build
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
## Deployment
|
||||
|
||||
This repository deploys to `projekt-kiq.d-hive.de` via GitHub Actions.
|
||||
|
||||
- The built frontend is deployed to `/opt/projekt-kiq/site`
|
||||
- The Express backend runs as a systemd service (`projekt-kiq.service`) on port 3003
|
||||
- Caddy reverse-proxies `/api/*` to the backend and serves the SPA for all other routes
|
||||
- The [`Caddyfile`](./Caddyfile) handles TLS termination, security headers, and routing
|
||||
- The workflow in [`.github/workflows/deploy.yml`](./.github/workflows/deploy.yml) builds, deploys frontend + backend, and restarts services
|
||||
|
||||
### One-time server setup
|
||||
|
||||
- Install the SSH public key for the `github-deploy` user in `/home/github-deploy/.ssh/authorized_keys`
|
||||
- Ensure `/opt/projekt-kiq/` is writable by `github-deploy`
|
||||
- Create `/opt/projekt-kiq/.env` with production credentials (see `.env.example`)
|
||||
- Allow `github-deploy` to run the required sudo commands (see deploy workflow)
|
||||
|
||||
### Required GitHub secrets
|
||||
|
||||
- `DEPLOY_SSH_KEY`: private key for the `github-deploy` user
|
||||
|
||||
## Environment Variables
|
||||
|
||||
See [`.env.example`](./.env.example) for all available configuration options.
|
||||
@@ -0,0 +1,252 @@
|
||||
1. Executive Summary
|
||||
|
||||
Product / initiative name: Projekt-KIQ-HP
|
||||
Interviewed stakeholder role: Project lead, founder, future provider
|
||||
Product type: New product, with existing source materials and a possible template homepage as input
|
||||
Goal in one sentence: Create a homepage that presents Projekt-KIQ in a compelling and trustworthy way so that relevant funding bodies and selected company partners can quickly understand the opportunity and move into their funding or evaluation process.
|
||||
Short business context: Projekt-KIQ currently relies on scattered presentations, meetings, chats, and confidential concept material. The new homepage should consolidate relevant information into a structured public and restricted experience.
|
||||
Primary target users: MBGs (Mittelständische Beteiligungsgesellschaften), startup funding programs, similar funding stakeholders
|
||||
Secondary target users: Medium-sized companies that may participate as customers and investors
|
||||
Core functional scope summary: A modern homepage with a public information area, an access-request process, a restricted investor/funder area for approved users, downloadable documents for approved users only, and an admin view for managing interested parties and monitoring usage.
|
||||
In scope: Public landing experience, restricted information area, access request, human approval/rejection, document access for approved users, optional appointment selection after request, admin oversight, creation of initial content from existing source materials
|
||||
Out of scope: Developer landing pages, customer landing pages, separate restricted experiences for MBGs and companies in version 1, multilingual support, press/news area, community/application functions, ongoing content production beyond initial setup
|
||||
Main open questions: Whether optional interviews will be needed after the first draft to close content gaps; whether all approved users see the same restricted content in version 1; whether appointment selection is offered immediately to every requester or selectively; what “content request” means in the admin area
|
||||
Main acceptance indicators: MBGs understand the project quickly and provide positive feedback; qualified access requests are submitted; meetings are requested; the content appears professional, trustworthy, and complete
|
||||
|
||||
2. Goal
|
||||
|
||||
One-sentence goal
|
||||
The homepage should present Projekt-KIQ in a way that excites relevant funding bodies and selected company partners and enables them to directly proceed with funding-related next steps.
|
||||
|
||||
Detailed goal
|
||||
The product should replace fragmented, manual communication of project information with a structured digital experience that supports trust-building, early evaluation, and movement toward funding conversations. It should give target audiences a clear first understanding in the public area and provide deeper investment-relevant material in a restricted area after invitation or approval.
|
||||
|
||||
Business value
|
||||
The homepage reduces manual explanation effort, creates a more consistent external presentation, improves readiness for funding discussions, and supports lead qualification for serious and relevant interested parties.
|
||||
|
||||
Intended outcome for users and organization
|
||||
Users should understand the problem, solution, USP, product, team, and business potential quickly. The organization should receive better-qualified requests, more efficient follow-up conversations, and a stronger basis for funding discussions.
|
||||
|
||||
3. Stakeholder Context
|
||||
|
||||
Respondent role
|
||||
Project lead, founder, and future provider of the project
|
||||
|
||||
Perspective represented
|
||||
Business owner / initiator perspective
|
||||
|
||||
Relevant organizational or customer context
|
||||
The homepage is intended first for funding bodies such as MBGs and startup funding programs, and later also for medium-sized companies that may become both customers and investors.
|
||||
|
||||
Whether this spec reflects one interview only
|
||||
Yes. This specification reflects one interview only.
|
||||
|
||||
4. Target Users
|
||||
|
||||
User groups
|
||||
|
||||
MBGs and similar funding organizations
|
||||
Startup funding programs and comparable funding stakeholders
|
||||
Medium-sized companies interested in participating as customers and investors
|
||||
|
||||
Their context
|
||||
These users need enough confidence and structured information to decide whether Projekt-KIQ is relevant and whether they should continue with evaluation, document review, and follow-up discussions.
|
||||
|
||||
Their needs
|
||||
They need a quick understanding of the project, its value proposition, current status, team credibility, market opportunity, investment need, and expected upside.
|
||||
|
||||
Their pain points
|
||||
Today, information is scattered across presentations, meetings, chats, and confidential concept materials. This makes evaluation slow, inconsistent, and dependent on manual explanation.
|
||||
|
||||
Important differences between groups
|
||||
Funding bodies are the first priority in version 1. Medium-sized companies are a secondary audience. VCs and classical financial investors are explicitly not current target users.
|
||||
|
||||
5. Current Situation / Current Process
|
||||
|
||||
How the process works today
|
||||
Information is currently assembled and communicated through presentations and meetings. Relevant material is spread across confidential concept ideas, PowerPoint decks, PDFs, and chats.
|
||||
|
||||
Existing workaround or manual steps
|
||||
Project information must be manually gathered and consolidated for each conversation or presentation. This appears to depend heavily on direct involvement from the project team.
|
||||
|
||||
Main gaps, bottlenecks, and failure points
|
||||
There is no single structured external presentation of the project.
|
||||
Investment-relevant information is fragmented.
|
||||
Confidential and public information are not clearly separated in a reusable format.
|
||||
The current process is inefficient and may not provide a consistent basis for evaluation.
|
||||
|
||||
What should remain unchanged, if applicable
|
||||
Existing materials remain important as source inputs for the first version of the homepage content.
|
||||
|
||||
6. Functional Scope
|
||||
|
||||
The product must provide a modern homepage for Projekt-KIQ with two core areas: a public area and a restricted area.
|
||||
|
||||
Main capabilities
|
||||
The public area should present the project clearly and persuasively for first-time evaluation.
|
||||
The restricted area should provide deeper investment- and funding-relevant information for approved users.
|
||||
Visitors should be able to request access to the restricted area.
|
||||
The project team should be able to invite selected users or approve access requests.
|
||||
Approved users should be able to download restricted documents.
|
||||
The process should support movement from interest to conversation, including a possible appointment-selection step after request submission.
|
||||
An admin perspective should provide oversight of interested parties, users, registrations, access metrics, and content requests.
|
||||
|
||||
Key user interactions
|
||||
A public visitor lands on the homepage and reviews the core project information.
|
||||
A relevant visitor requests access by providing required business information.
|
||||
The project team reviews the request and either approves or rejects it.
|
||||
An approved user accesses restricted content and downloads documents.
|
||||
A user may request or select a meeting after expressing interest.
|
||||
An admin monitors requests, users, registrations, and usage indicators.
|
||||
|
||||
Major functional areas
|
||||
Public homepage content
|
||||
Access request flow
|
||||
Restricted content area
|
||||
Document download for approved users
|
||||
Admin oversight
|
||||
|
||||
Role-based differences in usage
|
||||
Public visitors can only view public content.
|
||||
Interested requesters can view public content and submit their own access request information.
|
||||
Approved users can access the restricted area in addition to public content.
|
||||
Admins have oversight and management visibility.
|
||||
|
||||
Relevant triggers, inputs, outputs, and outcomes
|
||||
Trigger: A funding body or company partner wants to assess Projekt-KIQ.
|
||||
Input: Public browsing or access request submission with required business details.
|
||||
Output: Public understanding, access request, access decision, document access, possible meeting request.
|
||||
Outcome: Qualified leads progress into evaluation and discussion.
|
||||
|
||||
7. Business Rules
|
||||
|
||||
Access to the restricted area is only possible through personal invitation or approval after a request.
|
||||
Confidential content must never be visible in the public area.
|
||||
Restricted documents must only be downloadable by approved users.
|
||||
If a requester is not part of a relevant target group, the request must be rejected by a human, with a reason.
|
||||
If access is denied, communication must be clear and polite, and handled by a human.
|
||||
Incomplete or unsuitable requests lead to rejection.
|
||||
The intended progression is: user becomes interested, requests or receives access, reviews documents, and then requests or schedules a conversation.
|
||||
Version 1 does not require separate restricted experiences for MBGs and companies, although this may be added later.
|
||||
The homepage must prioritize MBGs and similar funding bodies before other audiences.
|
||||
|
||||
8. Business Objects / Functional Data Objects
|
||||
|
||||
Projekt-KIQ public presentation
|
||||
Represents the core public-facing information needed for first understanding and interest generation.
|
||||
|
||||
Restricted investment/funding content
|
||||
Represents the deeper information needed for serious evaluation, such as investment need, market potential, and business case.
|
||||
|
||||
Access request
|
||||
Represents a user’s formal request to enter the restricted area. It includes identifying and business-relevant information for manual evaluation.
|
||||
|
||||
Interested party
|
||||
Represents a visitor who has expressed formal interest through a request.
|
||||
|
||||
Approved user
|
||||
Represents a requester who has been invited or approved and can access restricted content.
|
||||
|
||||
Access decision
|
||||
Represents the business outcome of reviewing a request: approval or rejection.
|
||||
|
||||
Restricted document
|
||||
Represents downloadable materials intended only for approved users.
|
||||
|
||||
Meeting request / appointment selection
|
||||
Represents the next-step interaction after interest has been established.
|
||||
|
||||
Admin overview data
|
||||
Represents operational visibility into interested parties, users, registrations, access metrics, and content requests.
|
||||
|
||||
Source materials
|
||||
Represents the existing business content used to produce the homepage content: PowerPoints, PDFs, chats/concept notes, and a template homepage.
|
||||
|
||||
9. In Scope
|
||||
Public homepage for Projekt-KIQ
|
||||
Public communication of problem and solution
|
||||
Public communication of USP
|
||||
Public communication of product
|
||||
Public communication of team
|
||||
Public communication of customer/market benefit
|
||||
Public call-to-action for requesting access
|
||||
Public display of references, partners, materials, and project status
|
||||
Access request process for interested parties
|
||||
Collection of requester business details
|
||||
Invitation- or approval-based access to restricted content
|
||||
Restricted area for approved users
|
||||
Restricted presentation of investment need
|
||||
Restricted presentation of market size and potential
|
||||
Restricted presentation of return opportunities
|
||||
Restricted presentation of use of funds
|
||||
Restricted presentation of competitive analysis
|
||||
Restricted presentation of business case
|
||||
Restricted presentation of strategy
|
||||
Download of restricted materials by approved users only
|
||||
Human review and response to unsuitable, incomplete, or denied requests
|
||||
Admin overview for interested parties, users, registrations, access metrics, and content requests
|
||||
Initial content creation from existing materials
|
||||
Optional appointment-selection step after request submission
|
||||
10. Out of Scope
|
||||
Dedicated landing pages for developers in version 1
|
||||
Dedicated landing pages for customers in version 1
|
||||
Separate restricted areas for MBGs and companies in version 1
|
||||
Multilingual support in version 1
|
||||
Press or news section
|
||||
Community features
|
||||
Application or recruitment-style functions
|
||||
Ongoing content production beyond the initial setup
|
||||
11. Requirements
|
||||
The product must provide a public homepage for Projekt-KIQ targeted primarily at MBGs and similar funding stakeholders.
|
||||
The public homepage must present the following information in this priority order: problem and solution, USP, product, team, customer/market benefit, call-to-action for access request, references/partners/materials/project status.
|
||||
The product must provide a restricted area for approved users containing funding- and investment-relevant information.
|
||||
The restricted area must present the following information in this priority order: investment need, market size/potential, return opportunities, use of funds, competitive analysis, business case, strategy.
|
||||
The product must allow a visitor to request access to the restricted area.
|
||||
The access request must collect at least the following information: name, company/organization, role, business email address, phone number for follow-up questions, reason for interest, and desired conversation purpose.
|
||||
The product must support access to the restricted area only through personal invitation or approval after request.
|
||||
The product must prevent confidential content from being visible in the public area.
|
||||
The product must allow only approved users to download restricted documents.
|
||||
The product must support a business process in which unsuitable or incomplete requests are rejected by a human, with a clear and polite response.
|
||||
The product must support a business process in which a requester may be offered a next-step meeting request or appointment-selection option after submitting interest.
|
||||
The product must provide an admin view that shows interested parties, users, registrations, access metrics, and content requests.
|
||||
The product must support the use of existing PowerPoints, PDFs, chats/concept notes, and an existing template homepage as source material for the initial content.
|
||||
The product must support a user journey in which relevant visitors can move from first interest to access request, document review, and conversation request.
|
||||
The first version must focus on a shared core experience for the current target audiences and does not require separate landing pages or separate restricted experiences for additional audiences.
|
||||
12. Open Questions / Items to Clarify
|
||||
Are the existing source materials sufficient for the first version, or will optional short interviews be required to close content gaps after the first draft?
|
||||
Should every requester be offered appointment selection immediately after submitting a request, or only selected requesters?
|
||||
Do all approved users see the same restricted content in version 1, or is some level of differentiation already needed?
|
||||
What exactly is meant by “content request” in the admin area?
|
||||
What specific references, partners, and project-status elements are already confirmed and suitable for public display?
|
||||
What exact wording or positioning should be used to communicate return opportunities in a way that matches the intended audience and business context?
|
||||
In a later phase, how should dedicated landing pages for developers and customers differ from the investor/funder experience?
|
||||
13. Risks and Ambiguities
|
||||
Because source information is fragmented across presentations, chats, PDFs, and confidential concept material, important content may be inconsistent, incomplete, or difficult to validate.
|
||||
Optional interviews being deferred to a later step may leave gaps in the first version’s messaging or factual completeness.
|
||||
The public display of references, partners, and project status is not yet concretely defined, which may lead to overstatement or underuse of credibility signals.
|
||||
The concept of return opportunities may be interpreted differently by different stakeholders unless the intended framing is aligned carefully.
|
||||
The admin requirement includes “content requests,” but this object is not yet defined, which may create implementation ambiguity.
|
||||
Not differentiating between MBGs and company partners in version 1 simplifies scope but may reduce relevance for secondary audiences.
|
||||
The current acceptance vision depends partly on subjective perception, such as whether content feels professional, trustworthy, and complete.
|
||||
14. Acceptance Perspective
|
||||
|
||||
From a business point of view, the product is successful when relevant MBGs and comparable funding stakeholders can quickly understand what Projekt-KIQ is, why it matters, and why it is worth evaluating further.
|
||||
The public area must create confidence and interest rather than requiring immediate manual explanation.
|
||||
The restricted area must provide enough depth for serious review once access has been approved.
|
||||
Qualified access requests must start coming in from relevant target groups.
|
||||
Users must begin requesting meetings or other follow-up conversations.
|
||||
The overall content and presentation must be perceived as professional, trustworthy, and complete enough to support funding-related next steps.
|
||||
|
||||
15. Glossary
|
||||
Original term English explanation Notes / context
|
||||
Projekt-KIQ Project-KIQ homepage initiative Name of the homepage/product initiative
|
||||
MBG Medium-sized business investment company Refers to Mittelständische Beteiligungsgesellschaften as a key target audience
|
||||
Mittelständische Beteiligungsgesellschaften Regional or specialized investment/funding bodies for SMEs Important primary target group
|
||||
Fördermittelgeber Funding bodies / funders Includes MBGs, startup funding programs, and similar entities
|
||||
Start-up Förderprogramme Startup funding programs Part of the primary target audience
|
||||
Mittelverwendung Use of funds How requested investment capital will be allocated
|
||||
Wettbewerbsanalyse Competitive analysis Comparison of Projekt-KIQ against alternatives or competitors
|
||||
Business Case Commercial viability case Business-oriented rationale for value and investment relevance
|
||||
USP Unique selling proposition Distinctive value proposition that differentiates the project
|
||||
geschützter Bereich Restricted area Area accessible only after invitation or approval
|
||||
öffentliche Bereich Public area Public-facing homepage content visible without approval
|
||||
@@ -0,0 +1,150 @@
|
||||
Regionale KI-Infrastruktur für
|
||||
Nordhessen
|
||||
DSGVO & AI Act-konforme KI-Lösungen für Unternehmen und
|
||||
Wissenschaft
|
||||
Von Testphase bis Produktionsumgebung
|
||||
AK von André Knie
|
||||
Nutzen & Vorteile
|
||||
Datenschutz
|
||||
DSGVO und AI-Act konform
|
||||
Netzwerk
|
||||
Partnerschaft zwischen Unternehmen und Universität
|
||||
Transparenz
|
||||
Implementierung nachvollziehbarer "Business KI"
|
||||
Forschung
|
||||
Wissenschaftliche Begleitung durch Uni Kassel
|
||||
Projektphasen
|
||||
Phase 1: Pretotyping & MVP
|
||||
Schnelle Entwicklung eines minimal testbaren Produkts
|
||||
3-5 Pilotpartner pro KMU je bis zu 6 TEUR Förderung
|
||||
Phase 2: Produktionsumgebung
|
||||
Skalierbare KI-Infrastruktur
|
||||
Landesförderung und laufende Kostenbeteiligung
|
||||
Hosting
|
||||
Initial: Hessen.AI, Ionos, gridscale
|
||||
Perspektivisch: Eigene Hardware
|
||||
Vorteile für Projektpartner
|
||||
Early-Access
|
||||
Sonderkonditionen für Pilotpartner
|
||||
Einflussnahme
|
||||
Direkte Mitgestaltung bei Anforderungen
|
||||
Risikominimierung
|
||||
Gemeinschaftliche Finanzierung und Förderung
|
||||
Wissenschaftliche Begleitung
|
||||
Evaluierte Ergebnisse und Expertise
|
||||
KI für Kassel
|
||||
DSGVO & AI Act-konforme KI-Lösungen für Unternehmen und
|
||||
Wissenschaft
|
||||
Von Testphase bis Produktionsumgebung
|
||||
AK von André Knie
|
||||
Projektablauf & Finanzierung
|
||||
Projektstart
|
||||
KMUs: 3.000€ + 3.000€ Förderung
|
||||
Große Unternehmen:
|
||||
6.000€ Eigenanteil
|
||||
Alle Partner treten in Vorleistung
|
||||
Use-Case Workshop (2+2h)
|
||||
Gemeinsame Auswahl von
|
||||
mindestens 2 Use-Cases
|
||||
Festlegung der Cloud-Infrastruktur
|
||||
Parallel-Aktivitäten
|
||||
Umsetzung der Use-Cases
|
||||
Entwicklung eines Businessmodells
|
||||
Erstellung eines Förderantrags
|
||||
Phase 1.5 (Oktober)
|
||||
Nur bei erfolgreicher Phase 1
|
||||
• KMUs: 1.995€ + 1.995€ Förderung
|
||||
• Große Unternehmen: 3.990€
|
||||
Nächste Schritte
|
||||
• Bilaterale NDAs unterzeichnen
|
||||
• Zugriff auf echte Daten ermöglichen
|
||||
• Konsortialvertrag in Phase 1 entwickeln
|
||||
|
||||
Ergebnisse aus dem Projekt
|
||||
Algorithmus identifiziert Bauteile auf
|
||||
einem Foto und ermittelt automatisch
|
||||
Teilenummer und Lagerplatz.
|
||||
Teileerkennung
|
||||
System erzeugt aus Auftrag &
|
||||
Zeichnungen automatisch vollständige
|
||||
Prüfprotokolle für die Qualitätssicherung.
|
||||
Prüfprotokolle
|
||||
KI-Agent überwacht Wettbewerber, erkennt
|
||||
neue Produkte/Entwicklungen & erstellt
|
||||
automatisiert Wettbewerbsanalysen.
|
||||
Marktanalyse
|
||||
KI-Agent erstellt unter Berücksichtigung
|
||||
rechtlicher & fachlicher Vorgaben innerhalb
|
||||
weniger Minuten umfangreiche Angebote.
|
||||
Angebotsunterstützung
|
||||
Monatliche Berichterstattung an
|
||||
Muttergesellschaft wird weitgehend
|
||||
automatisiert und reduziert den Aufwand von
|
||||
einer Woche auf wenige Minuten.
|
||||
Berichtserzeugung
|
||||
Wissensmanagement
|
||||
Einfacher Zugang zu verteiltem Wissen in
|
||||
Unterordnern und Sharepointseiten.
|
||||
Ready for test
|
||||
Ready for test
|
||||
Test ongoing
|
||||
Next in lineblocked
|
||||
On hold
|
||||
Lessons learned
|
||||
12 Extrem interessante Use-Cases Terminabsprache schwierig
|
||||
Fixe regelmäßige Termine?
|
||||
Höhere Priorität = Kosten!
|
||||
Skalierung benötigt Kapazität Umsetzung der Phase 2 bereits begonnen
|
||||
Wie geht es weiter?
|
||||
Zusätzliche Mitarbeiter und Planungsressourcen,
|
||||
Aufbau Plattform für vertrauenswürdige externe Kapazität
|
||||
Identity provider, IDM, Rollen und Rechte
|
||||
Tennant Struktur und Datenbank pipeline
|
||||
Security und Onboarding
|
||||
Skalierfähigkeit / Umzug komplett auf Ionos
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Das ideale Leistungsprofil
|
||||
12
|
||||
Informieren/ÖA (organisieren)
|
||||
• Grundlageninfo zu KI auf Fremdveranstaltungen; ggf. Sprechtage
|
||||
• Use-Case Report
|
||||
• Fachtagung p.a.
|
||||
Qualifizieren (anbieten & vermitteln)
|
||||
• E-Learning/Blended-Learning/Präsenz (z. B. AI-Act,
|
||||
Mitarbeitenden-Sensibilisierung)
|
||||
Vernetzen (organisieren)
|
||||
• mtl. "KI-Frühstück„
|
||||
• quartalsweise offene Themen-Workshops anbieten
|
||||
Leisten (vermitteln)
|
||||
• Coaching (z. B. Potenziale, Integration, Nutzung)
|
||||
• Use-Cases, Ready for copy
|
||||
• Individual-Nutzung (Exklusive-Nutzung)
|
||||
Ermöglichen (vermieten & vermitteln)
|
||||
• Bereitstellung von Technologie & Support
|
||||
Fördern (organisieren)
|
||||
• Start-up-Support
|
||||
• Kontakt UNI, WFG, RKW, WiBank …
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Organe der Gesellschaft/Funktionsweise (QS)
|
||||
GmbH Geschäftsführung
|
||||
Beratende Funktion, Einbindung
|
||||
bei ÖA, Vernetzung
|
||||
& Förderung
|
||||
Wirtschaftsbeirat
|
||||
Beratende Funktion, Einbindung
|
||||
bei ÖA & Vernetzung
|
||||
AnwenderbeiratRegion
|
||||
Wirtschaftsförderung
|
||||
Entscheidet, von welchen
|
||||
Umsetzungspartnern (Anbietern)
|
||||
welche Leistungen vermittelt/verkauft
|
||||
werden dürfen.
|
||||
Akkreditierungsausschuss
|
||||
Umsetzungspartner aus Wirtschaft, Forschung etc.
|
||||
VereinLeitung
|
||||
SitzSitz
|
||||
QS
|
||||
Entscheidungsprozess
|
||||
ist digital gestützt!
|
||||
Praxis-Partner/
|
||||
Anwender
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
Businessplan & Wachstumsstrategie (v0.1)
|
||||
Initiative KI4KS
|
||||
|
||||
1. Ausgangslage & Initiales Setup
|
||||
Die Initiative startet aus einer Position der Stärke: Das Produkt ist durch 6 Pilotkunden validiert.
|
||||
Initiales Kapital: 90.000 € (60.000 € Kundenumsatz + 30.000 € Gründer-Investment).
|
||||
Proof of Concept: Die 6 Kunden haben jeweils 10.000 € investiert (75% für Use-Case-Entwicklung, 25% für geteilte Infrastruktur).
|
||||
Kernteam: 1 Geschäftsführer (Sales/Admin), 1 Vollzeit-Plattformentwickler, 1 Solution Customer Expert (Integration), flankiert von 2 externen Use-Case-Entwicklern.
|
||||
|
||||
2. Das Geschäftsmodell (Revenue Streams)
|
||||
Das Preismodell ist dreistufig aufgebaut, um operative Kosten sofort zu decken und Skalierungseffekte zu nutzen:
|
||||
Setup-Fee (Einmalig): Deckt den Ressourcenaufwand für das Onboarding und die Anbindung spezifischer Schnittstellen ab. Diese Gebühr ist variabel und skaliert mit der Komplexität des Kunden-Setups.
|
||||
Pay-per-Token / Pay-per-Use (Wiederkehrend): Ein nutzungsbasiertes Modell, das die variablen Infrastrukturkosten (aktuell ca. 30 € pro Test-Kunde) plus eine feste Marge abdeckt.
|
||||
Value-Based Pricing (Upside / Profit-Sharing): Perspektivisch: Eine Beteiligung (z.B. 20%) an den durch den Use Case nachweislich eingesparten Kosten beim Kunden.
|
||||
|
||||
3. Personal & Kostenstruktur
|
||||
Um die in der Verfassung verankerten Werte ("Gemeinwohl & Teamfokus") zu leben, wird ein solidarisches Gehaltsmodell angewandt:
|
||||
Solidarische Basisentlohnung: 2.000 € Netto-Grundgehalt plus 500 € Netto-Zuschlag pro unterhaltsberechtigtem Kind. (Dies entspricht ca. 4.000 - 4.500 € Arbeitgeberkosten).
|
||||
Overhead: Der monatliche Grundbetrieb (Lizenzen, Steuern, Tools) startet bei 1.500 € und skaliert prozentual zum Umsatz.
|
||||
Die Differenz zum Marktwert der Entwickler wird über das "Wertpunkte-System" (Gewinn- und Projektbeteiligung) kompensiert.
|
||||
|
||||
4. Wachstums-Szenarien
|
||||
Um das Ziel von 100-200 Kunden in 24 Monaten zu erreichen, stehen zwei strategische Pfade zur Diskussion, die den Kapitalbedarf definieren.
|
||||
Szenario A: Moderates Wachstum (Bootstrapped / Cashflow-Fokus)
|
||||
Ziel: Schnellstmögliche Profitabilität ("Cashflow positive"). Fokus auf organisches Wachstum im DACH-Raum über das Netzwerk der Pilotkunden und öffentliche Träger.
|
||||
Finanzierung: Verzicht auf VC-Geld. Nutzung der Piloten als wiederkehrende Auftraggeber. Ggf. Aufnahme von Bankkrediten (Ziel-Verzinsung 5%) oder Einbindung Stiller Teilhaber aus dem Kunden-Beirat (Ziel-Rendite max. 10% p.a.).
|
||||
Team-Strategie: Vorsichtiger Aufbau des Sales-Teams. Externe Entwickler werden entweder durch Setup-Fees der Kunden 1:1 durchgereicht oder in das Wertpunkte-System konvertiert, um die Burn-Rate zu senken.
|
||||
Szenario B: Aggressives Wachstum (Investor-Driven)
|
||||
Ziel: Maximale Geschwindigkeit und Marktanteile. Erreichen der 200-Kunden-Marke durch massiven Aufbau eines dedizierten Sales- und Marketing-Teams ab Monat 1.
|
||||
Finanzierung: Aufnahme von Wagniskapital (Venture Capital / Business Angels). Die Investoren erwarten einen Exit oder eine Gewinnausschüttung, die einem Faktor 10x auf ihr Kapital nach 5 Jahren entspricht.
|
||||
Team-Strategie: Die Burn-Rate wird bewusst hochgehalten. Entwickler, Customer-Experts und Sales-Mitarbeiter werden aggressiv eingestellt, um die Use-Case-Bibliothek und das Onboarding exponentiell zu skalieren.
|
||||
@@ -0,0 +1,144 @@
|
||||
Project KIQ
|
||||
Das souveräne KI-Betriebssystem für den europäischen Mittelstand.
|
||||
Confidential Pitch Deck
|
||||
Tranche 1: 150.000 ¬ (Stille Beteiligung - Zielrendite 10%)
|
||||
Das Problem: Der
|
||||
Mittelstand und die Cloud
|
||||
Sicherheitsrisiko:
|
||||
Unternehmen vertrauen ihre
|
||||
Geschäftsgeheimnisse
|
||||
keinen US-Hyperscalern
|
||||
(OpenAI, Google) an.
|
||||
Ressourcenmangel: Eigene
|
||||
KI-Use-Cases scheitern am
|
||||
fehlenden Entwickler-
|
||||
Personal und komplexer
|
||||
Infrastruktur.
|
||||
Lock-in & Blackbox:
|
||||
Bestehende SaaS-Lösungen
|
||||
sind starr, unflexibel und
|
||||
bieten keine
|
||||
Datensouveränität.
|
||||
Es fehlt eine sichere,
|
||||
europäische Basis-
|
||||
Infrastruktur für Plug-and-
|
||||
Play KI-Anwendungen.
|
||||
Die Lösung: Datensouveränität
|
||||
trifft Plug & Play
|
||||
Project KIQ liefert die
|
||||
gesamte KI-Infrastruktur
|
||||
out-of-the-box.
|
||||
100% europäisches
|
||||
Hosting, 100% DSGVO-
|
||||
konform.
|
||||
Ein sicherer Hafen für
|
||||
Unternehmensdaten ohne
|
||||
IT-Overhead.
|
||||
Radikaler Fokus auf den
|
||||
Use Case: Entwickler bauen
|
||||
"Custom GPTs" für B2B, wir
|
||||
stellen Server, API und
|
||||
V ertrieb.
|
||||
Traction: Der Proof of Concept
|
||||
6
|
||||
Pilotkunden
|
||||
6 zahlende Pilotkunden erfolgreich ongeboardet.
|
||||
60.000¬
|
||||
Initialumsatz
|
||||
60.000 ¬ Initialumsatz sind bereits geflossen.
|
||||
Der Markt wartet nicht. Wir sind
|
||||
bereits profitabel im Testbetrieb.
|
||||
~2.500 ¬ Setup-Fee pro neuem Use-
|
||||
Case-Rollout am Markt etabliert.
|
||||
Das Modell ist validiert, die Architektur
|
||||
steht. Jetzt folgt die Skalierung.
|
||||
Das Entwickler-Ökosystem
|
||||
(Unser unfairer V orteil)
|
||||
Externe Top-Entwickler bauen auf unserer Plattform, weil wir
|
||||
das fairste Modell am Markt bieten.
|
||||
80/20 Profit-Split: Entwickler behalten 80% des generierten
|
||||
Gewinns, 20% fließen in die Infrastruktur.
|
||||
Quasi-Open-Source: Internes Teilen von Code beschleunigt
|
||||
die Entwicklung exponentiell.
|
||||
Maximale Geschwindigkeit: Use Cases werden einmal gebaut
|
||||
und an Dutzende Kunden skaliert.
|
||||
Das Geschäftsmodell
|
||||
Setup-Fee (Einmalig): ca. 2.500 ¬ für das Onboarding und die Schnittstellen-Anbindung. Deckt sofort unsere
|
||||
V ertriebsaufwände.
|
||||
Token-Marge (MRR): Monatliche nutzungsbasierte Abrechnung ("on demand"). Wir schlagen 20-50% Marge auf die reinen
|
||||
Server/Token-Kosten auf.
|
||||
Plattform-Abgabe: 20% aller laufenden Umsätze finanzieren den dauerhaften Plattform-Betrieb. Hoch skalierbar durch extrem niedrige Einstiegshürden für die Kunden.
|
||||
Simple
|
||||
Money Flow
|
||||
Monthly usage
|
||||
Ongoing token-based
|
||||
MRR
|
||||
Developers
|
||||
Revenue share /
|
||||
payouts
|
||||
Platform
|
||||
operations
|
||||
Operational costs and
|
||||
margin
|
||||
Setup fee
|
||||
One-time onboarding
|
||||
charge
|
||||
Customer payment
|
||||
Setup fee + monthly
|
||||
usage
|
||||
Go-to-Market Strategie
|
||||
Ziel: Skalierung auf 200 Kunden innerhalb von 24 Monaten.
|
||||
Phase 1: Netzwerk-Expansion über die 6 Pilotkunden (Referenzmarketing).
|
||||
Phase 2: Öffentliche Träger & Wirtschaftsförderungen als Multiplikatoren für den DACH-Mittelstand.
|
||||
Phase 3: Aufbau eines dedizierten B2B-Sales-Teams zur direkten Marktdurchdringung.
|
||||
Flexibilität vs. Souveränität
|
||||
|
||||
|
||||
|
||||
Wettbewerbsvorteil
|
||||
(Positionierung)
|
||||
Governance & Fundamentale
|
||||
Werte
|
||||
Wir bauen ein modernes, krisenfestes Unternehmen für Top-
|
||||
Talente.
|
||||
Null-V eto-Politik: Psychologische Sicherheit und Werte-Schutz bei
|
||||
der Aufnahme von Kunden und Teammitgliedern.
|
||||
Solidarisches Entlohnungsmodell: Existenzsicherndes Basisgehalt
|
||||
(mit Sozialkomponente) plus massive Gewinnbeteiligung.
|
||||
Pragmatismus: "Robust > fancy" und "Keep it simple & stupid"
|
||||
sind unsere technologischen Leitlinien.
|
||||
Financials: Der Weg in die Profitabilität
|
||||
Wir haben 18 Monate operativen Betrieb mathematisch simuliert.
|
||||
Durch den gezielten Team-Aufbau auf 7 Personen steigern wir die Neukundengewinnung auf bis zu 6 pro Monat.
|
||||
Break-Even Point: Durch die kumulierten MRR-Margen erreichen wir den operativen Cashflow-Turnaround exakt in Monat 15.
|
||||
Das Modell vereint Bootstrapping-Effizienz mit VC-Skalierbarkeit.
|
||||
6k
|
||||
8k
|
||||
5k
|
||||
12k
|
||||
14k
|
||||
10k
|
||||
Operativer Cashflow
|
||||
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.5 16 16.5 17 17.5 18
|
||||
Monat
|
||||
Profitabilität: 0
|
||||
The Ask: Tranche 1
|
||||
Gesuchtes Kapital: 150.000 ¬ (Präferiert als Stille Beteiligung, Zielrendite 10%).
|
||||
V erwendung der Mittel:
|
||||
70.000 ¬: Runway & Liquiditätspuffer zur Absicherung der simulierten Skalierungsphase.
|
||||
50.000 ¬: Go-to-Market (Sales, Messen, Multiplikatoren).
|
||||
30.000 ¬: Legal & Zertifizierungen (ISO 27001/DSGVO) zur Erfüllung höchster B2B-Standards.
|
||||
Runway & Liquiditätspuffer · 46.67%
|
||||
Go-to-Market · 33.33%
|
||||
Legal & Zertifizierungen · 20%
|
||||
70k
|
||||
50k
|
||||
30k
|
||||
Vision & Kontakt
|
||||
Technologie für den Menschen, Daten beim Kunden.
|
||||
Lasst uns die sichere KI-Plattform bauen, die Europas Wirtschaft dringend braucht.
|
||||
E-Mail:
|
||||
founder@project-kiq.com
|
||||
Website: www.project-KIQ.com
|
||||
Ansprechpartner: Gründer & Geschäftsführung
|
||||
Visual: Ein starkes, optimistisches Abschlussbild. Europäischer Fokus, aufstrebend. Ein QR Code Platzhalter für Kontaktdaten.
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
Regionale KI-
|
||||
Infrastruktur für
|
||||
Nordhessen
|
||||
DSGVO & AI Act-konforme KI-Lösungen für Unternehmen und
|
||||
Wissenschaft
|
||||
Von Testphase bis Produktionsumgebung
|
||||
von André Knie
|
||||
AK
|
||||
Nutzen & Vorteile
|
||||
Datenschutz
|
||||
DSGVO und AI-Act konform
|
||||
Netzwerk
|
||||
Partnerschaft zwischen Unternehmen und Universität
|
||||
Transparenz
|
||||
Implementierung nachvollziehbarer "Business KI"
|
||||
Forschung
|
||||
Wissenschaftliche Begleitung durch Uni Kassel
|
||||
Anwendungsfälle
|
||||
Dokumenten-
|
||||
verarbeitung
|
||||
Verarbeitung geschützter Inhalte
|
||||
Analyse
|
||||
Vertrauliche Lasten- und Pflichtenhefte
|
||||
Predictive
|
||||
Maintenance
|
||||
Vorausschauende Wartung
|
||||
Computer Vision
|
||||
Qualitätskontrolle und 2D-zu-3D-
|
||||
Umwandlung
|
||||
Projektphasen
|
||||
Phase 1: Pretotyping & MVP
|
||||
Schnelle Entwicklung eines minimal testbaren Produkts
|
||||
3-5 Pilotpartner pro KMU je bis zu 6 TEUR Förderung
|
||||
Phase 2: Produktionsumgebung
|
||||
Skalierbare KI-Infrastruktur
|
||||
Landesförderung und laufende Kostenbeteiligung
|
||||
Hosting
|
||||
Initial: Hessen.AI, Ionos, gridscale
|
||||
Perspektivisch: Eigene Hardware
|
||||
Vorteile für
|
||||
Projektpartner
|
||||
Early-Access
|
||||
Sonderkonditionen für Pilotpartner
|
||||
Einflussnahme
|
||||
Direkte Mitgestaltung bei Anforderungen
|
||||
Risikominimierung
|
||||
Gemeinschaftliche Finanzierung und Förderung
|
||||
Wissenschaftliche Begleitung
|
||||
Evaluierte Ergebnisse und Expertise
|
||||
Zahlen Daten Fakten
|
||||
Überblick zu Ressourcen und Zeitaufwand für die Pilotphase.
|
||||
60 TEUR
|
||||
Projektbudget
|
||||
Gesamtinvestition für den Prototypen
|
||||
4-8h
|
||||
Monatlicher Zeitaufwand
|
||||
Idealer Zeiteinsatz pro Partnerunternehmen
|
||||
1-2h
|
||||
Minimalaufwand
|
||||
Minimal erforderliche Beteiligung pro Monat
|
||||
3 Monate
|
||||
Projektlaufzeit
|
||||
Maximale Dauer in Monaten für die Pilotphase
|
||||
Fokussierte Workshops finden alle zwei Wochen online statt. Der Aufwand ist auch für kleine Teams gut zu bewältigen.
|
||||
KI für Kassel
|
||||
DSGVO & AI Act-konforme KI-Lösungen für Unternehmen und
|
||||
Wissenschaft
|
||||
Von Testphase bis Produktionsumgebung
|
||||
von André Knie
|
||||
AK
|
||||
Projektablauf & Finanzierung
|
||||
Projektstart
|
||||
KMUs: 3.000¬ + 3.000¬ Förderung
|
||||
Große Unternehmen:
|
||||
6.000¬ Eigenanteil
|
||||
Alle Partner treten in Vorleistung
|
||||
Use-Case Workshop
|
||||
(2+2h)
|
||||
Gemeinsame Auswahl von
|
||||
mindestens 2 Use-Cases
|
||||
Festlegung der Cloud-Infrastruktur
|
||||
Parallel-Aktivitäten
|
||||
Umsetzung der Use-Cases
|
||||
Entwicklung eines Businessmodells
|
||||
Erstellung eines Förderantrags
|
||||
Phase 1.5 (Oktober)
|
||||
Nur bei erfolgreicher Phase 1
|
||||
KMUs: 1.995¬ + 1.995¬ Förderung
|
||||
Große Unternehmen: 3.990¬
|
||||
Nächste Schritte
|
||||
Bilaterale NDAs unterzeichnen
|
||||
Zugriff auf echte Daten ermöglichen
|
||||
Konsortialvertrag in Phase 1 entwickeln
|
||||
Use Case Workshop
|
||||
In Vorgesprächen wurden bereits zwei vielversprechende Anwendungsfälle identifiziert:
|
||||
Ressourcenplanung
|
||||
Intelligente Planung von Maschinen und Arbeitseinsätzen für
|
||||
optimierte Betriebsabläufe.
|
||||
Dokumentautomatisierung
|
||||
Automatisierte Erstellung von Pflichtenheften und
|
||||
Angeboten aus bestehenden Lastenheften.
|
||||
Im Workshop wählen wir gemeinsam mindestens zwei Use-Cases aus. Bringt gerne weitere Ideen ein!
|
||||
Die Auswahl folgt den häufigsten Problemen, so dass wir möglichst schnell allen Partnern einen Mehrwert liefern
|
||||
mit leichter Priorisierung schnell umsetzbarer Anwendungsfälle.
|
||||
@@ -0,0 +1,119 @@
|
||||
Strategie
|
||||
|
||||
Verfassung & Strategische Vision (v0.2)
|
||||
Dieses Dokument führt die strategischen Kernprinzipien zusammen und dient als Grundlage für die spätere rechtliche Verfassung.
|
||||
|
||||
1. Präambel & Fundamentale Werte
|
||||
Die Werte dieser Initiative bilden das unumstößliche Fundament für alle strategischen, technischen und zwischenmenschlichen Entscheidungen. Sie stehen über dem reinen Profitstreben und definieren die Kultur der Zusammenarbeit.
|
||||
Da diese Werte durch die tägliche Arbeit wachsen und durch reale Beispiele aus der Praxis (z.B. in Code-Reviews oder bei Kunden-Entscheidungen) kontinuierlich konkretisiert werden, sind sie in einem separaten, begleitenden Leitdokument ("Werte & Handlungsmaximen") ausgelagert.
|
||||
Dieses Werte-Dokument ist integraler Bestandteil der Verfassung. Die darin festgehaltenen Prioritäten (wie Datensouveränität, Gemeinwohl, Pragmatismus vor Overengineering) sind für alle Teammitglieder und die Geschäftsführung bindend.
|
||||
|
||||
2. Vision und Kernmission
|
||||
Die Initiative schafft eine hochmoderne Plattform für KI-Anwendungen. Ziel ist es, ein Ökosystem zu etablieren, das Entwicklern ermöglicht, sich kompromisslos auf ihre individuellen Stärken zu fokussieren: die Entwicklung der Plattform, die Kreation von Use Cases oder die Etablierung dieser Use Cases beim Kunden. Die Plattform garantiert eine maximale Geschwindigkeit bei der Entwicklung (analog zu "Custom GPTs") und dem Rollout durch die Bereitstellung der gesamten notwendigen Infrastruktur.
|
||||
|
||||
3. Infrastruktur & Datensouveränität
|
||||
* Europäischer Fokus: Keine Datenspeicherung außerhalb der EU. Kein Hosting außerhalb der EU. Infrastrukturanbieter sind primär europäische Unternehmen.
|
||||
* Hyperscaler-Ausnahme: US-Hyperscaler werden ausschließlich auf expliziten Kundenwunsch eingesetzt.
|
||||
|
||||
4. Das Entwickler-Ökosystem & Geistiges Eigentum
|
||||
* Progressives Open-Source-Modell: Sämtlicher Code ist initial für alle Teammitglieder innerhalb der Initiative frei verfügbar ("internes Open Source"). Das strategische Ziel ist die vollständige Open-Source-Veröffentlichung nach außen. Dabei müssen jedoch Lizenzmodelle gewählt werden, die eine unregulierte Ausbeutung durch externe KI-Systeme verhindern.
|
||||
* Vergütung & Beteiligung: Urheber werden für ihre Code-Beiträge entlohnt und erhalten je nach Aufwand eine Gewinnbeteiligung pro Kundenprojekt und Geschäftsjahr. (Details zum System folgen).
|
||||
* Gehaltstransparenz: Intern herrscht absolute Transparenz über alle Gehälter und Beteiligungen. Eine vollständige, öffentliche Transparenz (als Instrument für radikales Marketing und Vertrauensbildung) ist das langfristige Ziel, wird aber erst nach ausführlicher Diskussion und Beschluss durch das Team umgesetzt, um gesellschaftliche Akzeptanzrisiken zu minimieren.
|
||||
|
||||
5. Governance & Entscheidungsstrukturen (Das Betriebssystem der Initiative)
|
||||
Die Verfassung definiert die bindenden Handlungsleitlinien für das Team und die Geschäftsführung. Die detaillierten methodischen Abläufe der Entscheidungsfindung (z. B. Ablauf der Widerstandsabfrage) sind in einem separaten, begleitenden Erklärdokument ("Entscheidungsprozesse & Governance-Praxis") detailliert geregelt.
|
||||
5.1 Null-Veto-Politik und Schutz persönlicher Werte
|
||||
Die Aufnahme neuer Kunden und neuer Teammitglieder erfordert grundsätzlich die Zustimmung oder Enthaltung aller bestehenden Teammitglieder. Ein Veto ist zulässig, muss jedoch durch ein "echtes Argument" begründet werden.
|
||||
Definition "Echtes Argument": Ein Argument kann fachlicher, moralischer, werteorientierter oder emotionaler Natur sein. Zwingende Voraussetzung ist, dass es klar kommuniziert werden kann. Der Grund für die Ablehnung muss durch das Argument direkt ersichtlich sein und dient als exemplarischer Präzedenzfall für zukünftige Entscheidungen der Initiative.
|
||||
5.2 Aufnahme von Kunden & Zweistufiges Veto-System
|
||||
Der Schutz der persönlichen Werte der Teammitglieder steht an oberster Stelle. Niemand muss für einen Kunden arbeiten, der seinen moralischen oder wertebasierten Grundsätzen widerspricht. Das Veto-Recht bei Kunden ist zweistufig aufgebaut:
|
||||
Stufe 1: Das Persönliche Veto (Arbeitsbefreiung): Ein Teammitglied kann aus wertebasierten oder emotionalen Gründen die persönliche Arbeit an Use Cases oder dem Support für einen spezifischen Kunden ablehnen. Der Kunde darf die Plattform weiterhin nutzen, aber das betroffene Teammitglied wird ohne negative Konsequenzen (weder finanziell bezüglich der Basisentlohnung noch disziplinarisch) vollständig von allen Berührungspunkten mit diesem Kunden freigestellt.
|
||||
Stufe 2: Das Globale Veto (No-Go-Kundenliste): Steht ein potenzieller Kunde im fundamentalen Widerspruch zu den Kernwerten der gesamten Initiative (z.B. Waffenproduktion, Verletzung von Menschenrechten, massive Umweltschäden), kann ein globales Veto eingelegt werden.
|
||||
Wird dieses Veto durch ein "echtes Argument" gestützt und im Team bestätigt, wird der Kunde vollständig abgelehnt.
|
||||
Der abgelehnte Kunde sowie der spezifische, argumentbasierte Grund werden transparent in der "No-Go-Kundenliste" dokumentiert. Diese Liste dient als Präzedenz-Katalog und wird regelmäßig vom Team geprüft.
|
||||
5.3 Aufnahme von Teammitgliedern (Bewerberprozess & Emotionale Sicherheit)
|
||||
Das Team entscheidet gemeinsam über Zuwachs. Ein Veto gegen eine:n Bewerber:in verliert jedoch seine Gültigkeit, wenn zwischen der einsprechenden Person und der/dem Bewerber:in im Arbeitsalltag keinerlei Berührungspunkte absehbar sind.
|
||||
Kennenlernen: Es werden strukturelle Formate geschaffen, die es jedem Teammitglied bei Bedarf ermöglichen, Bewerber:innen kennenzulernen, bevor eine Entscheidung getroffen wird.
|
||||
Umgang mit emotionalen Ablehnungsgründen: Ist ein Ablehnungsgrund emotional stark belastend, wird intern und extern lediglich ein abstrakter Grund kommuniziert.
|
||||
Um die emotionale Belastung zu kanalisieren und die Validität des Vetos zu prüfen, muss dieses vorab in mindestens zwei 4-Augen-Gesprächen diskutiert werden.
|
||||
Diese Gespräche werden wahlweise mit der Geschäftsführung oder mit speziell aus dem Team delegierten Vertrauenspersonen geführt.
|
||||
|
||||
5.4 Letztentscheid & Eskalation
|
||||
Bleibt bei strategisch kritischen Personal- oder Kundenentscheidungen ein unauflösbarer Widerstand bestehen, liegt der Letztentscheid bei der Geschäftsführung ("Patt-Breaker").
|
||||
Die Geschäftsführung darf nur in Ausnahmefällen gegen hohe Widerstände im Team handeln.
|
||||
Bedingungen für ein "Overruling": Entscheidet sich die Geschäftsführung gegen ein Veto aus dem Team, müssen die Gründe für diese Entscheidung dem Team gegenüber komplett transparent gemacht werden.
|
||||
Onboarding-Pflicht: Handelt es sich um die Aufnahme eines neuen Teammitglieds gegen hohe Widerstände, verpflichtet sich die Geschäftsführung persönlich dazu, das Onboarding der neuen Person über volle 6 Monate intensiv und engmaschig zu begleiten.
|
||||
|
||||
|
||||
6. Kunden, Partner & Unternehmensstruktur
|
||||
* Kunden-Beirat: Die wichtigsten Kunden (initial die 6 Pilotkunden) bilden ein Beratungsgremium. Um pragmatisch und schnell zu starten, wird dies zunächst als einfaches "Advisory Board" (Gremium ohne eigene Rechtsform) strukturiert. Das langfristige Ziel ist die Überführung in eine institutionalisierte Form (z.B. ein Verein / e.V.), über den Delegierte als Teil des Teams Mitspracherecht erhalten.
|
||||
* Öffentliche Träger & Wirtschaftsförderung: Diese Akteure nehmen eine strategische Rolle als Türöffner, Berater und Netzwerk-Multiplikatoren ein. Sie fungieren primär als Vermittler von Fördermöglichkeiten und Kontakten in die Wirtschaft, nicht als direkte Geldgeber.
|
||||
* Rechtsform & Investoren: Zielstruktur ist eine GmbH & Co. KG zur Trennung von operativem Geschäft und Investitionskapital. Investoren (Stille Teilhaber) werden aus dem Gewinn bedient, haben jedoch keine Entscheidungsgewalt über die Verfassungsprinzipien.
|
||||
|
||||
7. Vergütungs- und Beteiligungssystem (Das Wertpunkte-Modell)
|
||||
Das System zur Entlohnung und Beteiligung trennt bewusst die Deckung der existenziellen Lebenshaltungskosten von der erfolgsbasierten Gewinnbeteiligung. Es basiert auf dem Grundsatz der Solidarität und der Leistungsgerechtigkeit.
|
||||
Säule A: Solidarische Basis-Entlohnung (Existenzsicherung)
|
||||
Um das Lebensrisiko der Teammitglieder abzufedern und gleiche Augenhöhe zu garantieren, wird eine Basisentlohnung gezahlt. Diese besteht aus zwei Komponenten und eliminiert klassische Gehaltsverhandlungen:
|
||||
Einheitlicher Basis-Satz: Jedes aktive Teammitglied erhält unabhängig von seiner Rolle (Entwicklung, Sales, Admin) denselben monetären Grundsatz für seine investierte Zeit.
|
||||
Individuelle Bedarfskomponente (Sozial-Modifikator): Da die realen Lebenshaltungskosten variieren, wird der Basis-Satz durch persönliche, nachweisbare Faktoren aufgestockt. Hierzu zählen insbesondere familiäre Verpflichtungen (z.B. Kinder, pflegebedürftige Angehörige).
|
||||
Risk-Reward-Option: Es steht jedem Teammitglied frei, ganz oder teilweise auf die Basis-Entlohnung zu verzichten, um im Gegenzug einen Multiplikator auf die eigenen Beteiligungs-Wertpunkte (Säule B) zu erhalten.
|
||||
Säule B: Das Wertpunkte-System (Value Points) & Rollen
|
||||
Wertpunkte spiegeln den geschaffenen Wert wider. Das System berücksichtigt nun alle kritischen Säulen des Geschäftsbetriebs:
|
||||
Plattform & Infrastruktur: Entwickler des Kernsystems.
|
||||
Use-Case-Entwicklung: Schöpfer der spezifischen KI-Anwendungen.
|
||||
Sales & Kunden-Integration: Akquise, Rollout und Kundenbetreuung.
|
||||
Administration & Operations: Management, Finanzen und rechtliche Struktur.
|
||||
Säule C: Projektbeteiligung & Verteilungsschlüssel
|
||||
Der generierte Umsatz eines Kundenprojekts wird nach einem im Businessplan zu definierenden Schlüssel aufgeteilt. Dieser Schlüssel speist Töpfe für:
|
||||
Plattform-Weiterentwicklung & Infrastrukturkosten
|
||||
Use-Case-Urheber
|
||||
Sales & Integration
|
||||
Administration & Overhead
|
||||
Säule D: Innovations-Lebenszyklus & "Patent-System" (Fade-out)
|
||||
Um Innovationen zu fördern und passives Einkommen ohne Gegenleistung langfristig zu minimieren, unterliegen die projektbezogenen Anteile für Use Cases einem Lebenszyklus:
|
||||
Haltephase (Monate 1-6): Der Entwickler erhält 100% seines festgelegten Anteils am Use Case.
|
||||
Degradationsphase (Monate 7-30): Der Anteil sinkt über 24 Monate kontinuierlich ab ("Fade-out").
|
||||
Wiederbelebung: Werden signifikante neue Features entwickelt und vom Team positiv bewertet, wird der Zyklus ganz oder teilweise zurückgesetzt.
|
||||
Das "Code-Patent-System" (Recycling): Lösen neue, bessere Use Cases bestehende Lösungen ab, ist dies ausdrücklich erwünscht. Wird dabei jedoch Code der Ursprungslösung recycelt, erhält der ursprüngliche Urheber einen dauerhaften, vordefinierten "Patent-Anteil" (Micro-Share) an der neuen Lösung.
|
||||
|
||||
8. Geistiges Eigentum (IP), Code-Souveränität & Wettbewerb
|
||||
Der Schutz des kollektiven Wissens der Initiative ist essenziell für den gemeinsamen Erfolg und die Sicherstellung der Investitionen.
|
||||
Rechteübergang: Die Initiative (als juristische Person) erhält die vollumfänglichen, zeitlich und räumlich unbeschränkten Nutzungs- und Verwertungsrechte an jedem entwickelten Code.
|
||||
Rechte der Entwickler: Entwickler behalten das uneingeschränkte Recht, ihren eigenen, selbst geschriebenen Code privat oder beruflich weiter zu nutzen, sofern dies nicht in direkter Konkurrenz zur Initiative oder zu den bestehenden Use Cases der Kunden geschieht.
|
||||
Nutzungsbeschränkung der Codebasis: Die kollektive Codebasis, die Plattform-Architektur sowie die Infrastruktur dürfen von den Entwicklern ausschließlich für offizielle Projekte der Initiative genutzt werden.
|
||||
Post-Exit-Regelung: Scheidet ein Entwickler aus der Initiative aus, erlischt sein Zugriffs- und Nutzungsrecht auf die kollektive Codebasis und Plattform-Infrastruktur sofort. Er darf ab diesem Zeitpunkt ausschließlich seinen eigenen, isolierten Code (unter Beachtung des Wettbewerbsverbots) weiterverwenden.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Verfassung & Strategische Vision (v0.1)
|
||||
Dieses Dokument dient als Fundament für die strategische Ausrichtung der Initiative und wird kontinuierlich zur verbindlichen Verfassung weiterentwickelt.
|
||||
1. Vision und Kernmission
|
||||
Die Initiative schafft eine hochmoderne Plattform für KI-Anwendungen. Ziel ist es, ein Ökosystem zu etablieren, das Entwicklern ermöglicht, sich kompromisslos auf ihre individuellen Stärken zu fokussieren: die Entwicklung der Plattform, die Kreation von Use Cases oder die Etablierung dieser Use Cases beim Kunden. Die Plattform garantiert eine maximale Geschwindigkeit bei der Entwicklung (analog zu "Custom GPTs") und dem Rollout, indem sie die gesamte notwendige Infrastruktur bereitstellt.
|
||||
2. Fundamentale Werte
|
||||
Die Handlungen und Architekturen der Initiative unterliegen den folgenden priorisierten Werten:
|
||||
* Souveränität: Die Datensouveränität der Kunden ist das höchste Gut.
|
||||
* Gemeinwohl & Teamfokus: Das System dient immer dem Team und dem Gemeinwohl, niemals primär den Investoren. Kundenfokus steht im Zentrum der operativen Arbeit.
|
||||
* Pragmatismus & Qualität: Die besten verfügbaren Methoden kommen zum Einsatz. Dabei gilt: Robustheit schlägt "fancy" Features. Es herrscht eine "Keep it simple & stupid"-Mentalität, die Overengineering strikt ablehnt und minimale Verschwendung anstrebt.
|
||||
* Transparenz & Lernkultur: Feedback ist ein zentraler Pfeiler, Wissen wird "open source" geteilt.
|
||||
3. Infrastruktur & Datensouveränität
|
||||
* Europäischer Fokus: Es werden keine Daten auf Servern außerhalb der Europäischen Union gespeichert. Kein Service wird außerhalb der EU gehostet. Anbieter der Infrastruktur müssen weitestgehend europäische Unternehmen sein.
|
||||
* Hyperscaler-Ausnahme: Amerikanische Hyperscaler werden ausschließlich dann genutzt, wenn ein Kunde dies explizit verlangt.
|
||||
4. Das Entwickler-Ökosystem & Geistiges Eigentum
|
||||
* Kollaborationsmodell ("Quasi Open Source"): Jeder entwickelte Code wird innerhalb der Initiative allen Mitgliedern zur Verfügung gestellt.
|
||||
* Vergütung & Beteiligung: Urheber werden für ihre Code-Beiträge entlohnt. Abhängig vom Aufwand erhalten sie eine prozentuale Beteiligung pro Kundenprojekt und pro Geschäftsjahr.
|
||||
* Transparenz: Die Gehälter aller Teammitglieder sind öffentlich einsehbar und an den nachweisbaren Beitrag zur Initiative gekoppelt.
|
||||
5. Governance & Entscheidungsstrukturen
|
||||
Die Verfassung ist bindend und stellt die Handlungsleitlinien für die Geschäftsführung dar.
|
||||
* Entwickler als Kern & Aufsichtsrat: Das Entwickler-Team ist das Herzstück und fungiert als eine Art Aufsichtsrat. Neue Teammitglieder werden ausschließlich vom bestehenden Team ausgewählt und ongeboarded.
|
||||
* Null-Veto-Politik: Für die Aufnahme neuer Mitglieder bedarf es der Zustimmung oder Enthaltung aller. Eine Ablehnung (Veto) muss durch ein echtes, sachliches Argument begründet werden.
|
||||
* Kunden-Beirat: Ein Beirat wird in einer vereinsähnlichen Struktur organisiert, bestehend aus den wichtigsten Kunden. Die 6 Pilotkunden, die erste Use Cases finanziert und erprobt haben, bilden das Initiale Kundenteam. Über Delegierte (initial 1 Person) wird der Beirat Teil des Teams und hat Mitspracherecht (z. B. bei neuen Kunden oder Entwicklern).
|
||||
* Geschäftsführung: Wird initial durch den Gründer gestellt und spätestens alle 3 Jahre vom gesamten Team demokratisch neu gewählt.
|
||||
* Agile Entscheidungsfindung: Um Geschwindigkeit zu garantieren, gelten harte Deadlines für Entscheidungen (automatische Enthaltung bei Fristablauf):
|
||||
* Kleinigkeiten: 2 Stunden.
|
||||
* Personalentscheidungen: bis zu 1 Woche.
|
||||
6. Unternehmensstruktur & Investoren
|
||||
* Rechtsform (Zielstruktur): Eine GmbH & Co. KG wird angestrebt, um operatives Geschäft sauber von Investitionskapital zu trennen.
|
||||
* Investoren-Rolle: Investoren sind als Stille Teilhaber erwünscht. Ihre finanziellen Ansprüche werden ausschließlich aus dem Gewinn der Initiative bedient. Sie haben keine Entscheidungsgewalt über die in der Verfassung festgelegten Prinzipien.
|
||||
@@ -0,0 +1,454 @@
|
||||
www.team-mueller.net
|
||||
Vom Projektergebnis zum
|
||||
Geschäftsmodell für die Region
|
||||
„KI für KMU“
|
||||
Stand der Arbeitsergebnisse
|
||||
Vellmar, 14.01.2026
|
||||
Dipl. Ökonom Frank Müller
|
||||
www.team-mueller.net
|
||||
Ausgangslage
|
||||
Im Rahmen des Projektes Transformationsnetzwerk Region Kassel (tregks) wurden gemeinsam mit der
|
||||
Wirtschaftsförderung, dem fachlichen Kompetenzträger Dr. André Knie (Data Hive Cassel GmbH) und
|
||||
Praxis-Partnern das Thema KI in KMU bearbeitet, auf das Thema sensibilisiert und insbesondere
|
||||
KI-Agenten für den praktischen Einsatz zur Optimierung administrativer Prozesse entwickelt.
|
||||
Die Erkenntnisse und Ergebnisse aus dem Projekt sollen nun in ein eigenständiges Geschäftsmodell überführt
|
||||
werden, um mit dem Wissen aus der Region, Zukunftsfähigkeit und Wertschöpfung für die Region herzustellen.
|
||||
Folgende Parteien sind an der Geschäftsmodellentwicklung beteiligt:
|
||||
2
|
||||
Praxis-Partner/
|
||||
Anwender
|
||||
|
||||
www.team-mueller.net
|
||||
Inhalte
|
||||
• Erkenntnisse
|
||||
• Ergebnisse aus dem Projekt
|
||||
• Geschäftsmodell – eine Ideenskizze
|
||||
• Das ideale Leistungsprofil
|
||||
• Tragende Akteure und Gesellschaftsform
|
||||
• Organe der Gesellschaft/Funktionsweise (QS)
|
||||
• Ausrichtung & Nutzen
|
||||
• Zielgruppen & Eckpunkte des strategischen Marketings
|
||||
• Unterscheidungsmerkmale im Wettbewerbskontext
|
||||
• Wertschöpfung, Aufbauorganisation & Investitionsbedarf
|
||||
• Vor- und „Nachteile“ des Modells
|
||||
• Abstimmung nächster Schritte
|
||||
3
|
||||
|
||||
www.team-mueller.net
|
||||
4
|
||||
Erkenntnisse
|
||||
|
||||
www.team-mueller.net
|
||||
Erkenntnisse
|
||||
• Künstliche Intelligenz (KI) entwickelt sich rasant zum entscheidenden
|
||||
Wettbewerbsfaktor für Unternehmen aller Branchen.
|
||||
• Gleichzeitig fehlt es in vielen Unternehmen an klaren „Leitplanken“ für den Einsatz
|
||||
von KI. Die daraus resultierende Unsicherheit mündet häufig in widersprüchlichen
|
||||
oder isolierten Maßnahmen, wie etwa:
|
||||
• Teils generelle interne Verbote im Unternehmen
|
||||
• Teils unkoordinierte „Gehversuche“ mit internationalen (insb. US-basierten) SaaS*-Lösungen
|
||||
• Teils Nutzung vermeintlich „sicherer“ ChatGPT-Alternativen mit weiterhin bestehenden rechtlichen,
|
||||
sicherheitsrelevanten und strategischen Risiken
|
||||
Die Folge: Intransparente Nutzung, Schatten-KI und hohe Schadensrisiken
|
||||
5
|
||||
*Software as a Service - cloudbasierte Anwendung
|
||||
|
||||
www.team-mueller.net
|
||||
Erkenntnisse
|
||||
Schadensrisiken (aus Anwendung, fehlerhafter und fehlender Anwendung)
|
||||
• Haftungs- und Reputationsrisiken aus nicht sachgerechter
|
||||
Nutzung/Anwendung von KI-Lösungen
|
||||
(AI-Act, DSGVO und Daten-Sicherheit)
|
||||
• Verlust der Wettbewerbsfähigkeit im/der Unternehmen (in der Region)
|
||||
• Verlust von Arbeitsplätzen in der Region
|
||||
• Verlust von Wertschöpfung in der Region
|
||||
6
|
||||
|
||||
www.team-mueller.net
|
||||
Erkenntnisse - Herausforderungen
|
||||
Seit Februar 2025 besteht die formale Pflicht
|
||||
zur Schulung von Mitarbeitenden, die mit KI arbeiten.
|
||||
• Auch wenn Verstöße aktuell noch nicht sanktioniert werden,
|
||||
stellt dies für viele Unternehmen bereits heute
|
||||
eine reale Herausforderung dar.
|
||||
• Mitarbeitende haben einen hohen Bedarf an KI-Unterstützung,
|
||||
wissen jedoch häufig nicht, was erlaubt, sicher und sinnvoll ist.
|
||||
7
|
||||
|
||||
www.team-mueller.net
|
||||
Erkenntnisse - Herausforderungen
|
||||
Insgesamt ist klar:
|
||||
Unternehmen werden KI einsetzen müssen.
|
||||
Es gilt, ihnen dies zu ermöglichen,
|
||||
kontrolliert, sicher und regelkonform
|
||||
sowie zugleich wirtschaftlich erfolgreich.
|
||||
8
|
||||
|
||||
www.team-mueller.net
|
||||
9
|
||||
Ergebnisse aus dem Projekt
|
||||
|
||||
www.team-mueller.net
|
||||
Ergebnisse aus dem Projekt
|
||||
In kleiner Runde Sensibilisierung und erste Umsetzungserfolge erreicht.
|
||||
10
|
||||
Algorithmus identifiziert Bauteile auf
|
||||
einem Foto und ermittelt automatisch
|
||||
Teilenummer und Lagerplatz.
|
||||
Teileerkennung
|
||||
System erzeugt aus Auftrag &
|
||||
Zeichnungen automatisch vollständige
|
||||
Prüfprotokolle für die
|
||||
Qualitätssicherung.
|
||||
Prüfprotokolle
|
||||
KI-Agent überwacht Wettbewerber, erkennt
|
||||
neue Produkte/Entwicklungen & erstellt
|
||||
automatisiert Wettbewerbsanalysen.
|
||||
Marktanalyse
|
||||
KI-Agent erstellt unter Berücksichtigung
|
||||
rechtlicher & fachlicher Vorgaben
|
||||
innerhalb weniger Minuten
|
||||
umfangreiche Angebote.
|
||||
Angebotsunterstützung
|
||||
Monatliche Berichterstattung an
|
||||
Muttergesellschaft wird weitgehend
|
||||
automatisiert und reduziert den
|
||||
Aufwand von einer Woche auf wenige
|
||||
Minuten.
|
||||
Berichtserzeugung
|
||||
.
|
||||
Hexagon Plus
|
||||
|
||||
www.team-mueller.net
|
||||
Ergebnisse aus dem Projekt
|
||||
Learning
|
||||
• Das große Interesse und die aktive Beteiligung am Projekt zeigen die klare
|
||||
Bereitschaft zum Einsatz von KI in Unternehmen.
|
||||
• Die realisierten Use-Cases zeigen anschaulich Machbarkeit und Mehrwert von
|
||||
attraktiven KI-Lösungen/Werkzeugen zur Effizienzsteigerung Made in Germany.
|
||||
• Das Projekt zeigt/belegt, wie einfach und schnell man Unternehmen dazu
|
||||
verhelfen kann, grundlegende Sicherheit im Umgang mit KI zu erlangen
|
||||
UND für ihren eigenen Wertschöpfungsprozess geeignete und sichere
|
||||
KI-Lösungen entwickeln und integrieren zu können.
|
||||
Das angestrebte Geschäftsmodell soll diese Möglichkeiten und Nutzen
|
||||
skalierbar der Wirtschaft zur Verfügung stellen und damit die Region stärken.
|
||||
11
|
||||
|
||||
www.team-mueller.net
|
||||
12
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
|
||||
www.team-mueller.net
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Das ideale Leistungsprofil
|
||||
13
|
||||
Informieren/ÖA (organisieren)
|
||||
• Grundlageninfo zu KI auf Fremdveranstaltungen; ggf. Sprechtage
|
||||
• Use-Case Report
|
||||
• Fachtagung p.a.
|
||||
Qualifizieren (anbieten & vermitteln)
|
||||
• E-Learning/Blended-Learning/Präsenz (z. B. AI-Act,
|
||||
Mitarbeitenden-Sensibilisierung)
|
||||
Vernetzen (organisieren)
|
||||
• mtl. "KI-Frühstück„
|
||||
• quartalsweise offene Themen-Workshops anbieten
|
||||
Leisten (vermitteln)
|
||||
• Coaching (z. B. Potenziale, Integration, Nutzung)
|
||||
• Use-Cases, Ready for copy
|
||||
• Individual-Nutzung (Exklusive-Nutzung)
|
||||
Ermöglichen (vermieten & vermitteln)
|
||||
• Bereitstellung von Technologie & Support
|
||||
Fördern (organisieren)
|
||||
• Start-up-Support
|
||||
• Kontakt UNI, WFG, RKW , WiBank …
|
||||
Wie nun diese positiven Erfahrungen in ein Geschäftsmodell
|
||||
zu Gunsten der Region und der Pioniere weiterentwickeln?
|
||||
www.team-mueller.net
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Das ideale Leistungsprofil
|
||||
14
|
||||
Informieren/ÖA (organisieren)
|
||||
• Grundlageninfo zu KI auf Fremdveranstaltungen; ggf. Sprechtage
|
||||
• Use-Case Report
|
||||
• Fachtagung p.a.
|
||||
Qualifizieren (anbieten & vermitteln)
|
||||
• E-Learning/Blended-Learning/Präsenz (z. B. AI-Act,
|
||||
Mitarbeitenden-Sensibilisierung)
|
||||
Vernetzen (organisieren)
|
||||
• mtl. "KI-Frühstück„
|
||||
• quartalsweise offene Themen-Workshops anbieten
|
||||
Leisten (vermitteln)
|
||||
• Coaching (z. B. Potenziale, Integration, Nutzung)
|
||||
• Use-Cases, Ready for copy
|
||||
• Individual-Nutzung (Exklusive-Nutzung)
|
||||
Ermöglichen (vermieten & vermitteln)
|
||||
• Bereitstellung von Technologie & Support
|
||||
Fördern (organisieren)
|
||||
• Start-up-Support
|
||||
• Kontakt UNI, WFG, RKW , WiBank …
|
||||
www.team-mueller.net
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Tragende Akteure und Gesellschaftsform
|
||||
15
|
||||
Geschäftsführende
|
||||
GmbH
|
||||
Fachlicher Kompetenzträger
|
||||
Data Hive Cassel GmbH /Dr. André Knie
|
||||
Region
|
||||
Wirtschaftsförderung
|
||||
Verein
|
||||
Quoten-Fixierung (min. 12,6 %)
|
||||
Quoten-Fixierung (min. 12,6 %)
|
||||
Mitglieder aus Verein
|
||||
MBG etc.
|
||||
Data Hive Cassel GmbH /Dr. André Knie
|
||||
Praxis-Partner Verein
|
||||
Kommanditisten
|
||||
Kapital
|
||||
GmbH & Co. KG
|
||||
Wirtschaftliche Träger
|
||||
1/3
|
||||
1/3
|
||||
1/3
|
||||
KG
|
||||
Wirtschaft
|
||||
Praxis-Partner/Anwender
|
||||
Option
|
||||
www.team-mueller.net
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Organe der Gesellschaft/Funktionsweise (QS)
|
||||
16
|
||||
GmbH Geschäftsführung
|
||||
Beratende Funktion, Einbindung
|
||||
bei ÖA, Vernetzung
|
||||
& Förderung
|
||||
Wirtschaftsbeirat
|
||||
Beratende Funktion, Einbindung
|
||||
bei ÖA & Vernetzung
|
||||
AnwenderbeiratRegion
|
||||
Wirtschaftsförderung
|
||||
Entscheidet, von welchen
|
||||
Umsetzungspartnern (Anbietern) welche
|
||||
Leistungen vermittelt/verkauft werden
|
||||
dürfen.
|
||||
Akkreditierungsausschuss
|
||||
Umsetzungspartner aus Wirtschaft, Forschung etc.
|
||||
VereinLeitung
|
||||
SitzSitz
|
||||
QS
|
||||
Entscheidungsprozess
|
||||
ist digital gestützt!
|
||||
Praxis-Partner/
|
||||
Anwender
|
||||
www.team-mueller.net
|
||||
Geschäftsmodell – eine Ideenskizze
|
||||
Ausrichtung & Nutzen
|
||||
• Wir bieten über das Geschäftsmodell qualitätsgesichert skalierbare
|
||||
Möglichkeiten und nehmen gemeinsam nach unseren
|
||||
Ausrichtungen/Möglichkeiten risikoarm an der Wertschöpfung teil.
|
||||
• Das Geschäftsmodell ist daher strategischer Möglichmacher und keine auf
|
||||
maximalen Profit ausgerichtete Kapitalanlage.
|
||||
• Die, die tatsächliche Leistung erbringen und das wirtschaftliche Risko tragen,
|
||||
realisieren zugleich die höchste Wertschöpfung.
|
||||
• Der Nutzen der Beteiligungspartner und Akteure resultiert insbesondere aus
|
||||
ihrem Vorsprung an Information, Vernetzung und Realisierungsmöglichkeiten.
|
||||
17
|
||||
|
||||
www.team-mueller.net
|
||||
18
|
||||
Zielgruppen &
|
||||
Eckpunkte des strategischen Marketings
|
||||
|
||||
www.team-mueller.net
|
||||
Zielgruppen
|
||||
Zielgruppen
|
||||
• KMU
|
||||
• Fokus auf die Region Kassel?
|
||||
• Fokus auf produzierende Unternehmen?
|
||||
• Fokus auf sicherheitsaffine Unternehmen?
|
||||
• Fokus auf Unternehmen im Transformationsprozess?
|
||||
• Öffentliche Verwaltungen
|
||||
• Fokus auf die Region Kassel?
|
||||
• …
|
||||
• Verbände und Organisationen
|
||||
• Fokus auf die Region Kassel?
|
||||
• …
|
||||
19
|
||||
|
||||
www.team-mueller.net
|
||||
Eckpunkte
|
||||
des strategischen Marketings
|
||||
Eckpunkte
|
||||
des strategischen Marketings
|
||||
20
|
||||
Marketing Mix
|
||||
01
|
||||
0207
|
||||
0306
|
||||
05 04
|
||||
Pysicial | Ausstattung
|
||||
• TBD
|
||||
Process | Prozess
|
||||
• Transparent, unkompliziert & schnell
|
||||
• Digital
|
||||
• Bedarfsorientierter hybrider Support
|
||||
People | Personen
|
||||
• Besondere Struktur der Gesellschafter
|
||||
• Fachkompetenz und Praxiserfahrung führt
|
||||
Product | Produkt
|
||||
• Sichere, DSGVO- & AI-Act-konforme KI-Lösungen
|
||||
• Made in Germany/Made in Region Kassel
|
||||
• Praxiserprobte Angebote/Qualitätssicherung durch Akkreditierung (USP)
|
||||
Price | Preis
|
||||
• Platzierungskosten unter Würdigung der
|
||||
Anbietergröße
|
||||
• Vermittlungsgebühren nach Anzahl User etc.
|
||||
• Sonderkonditionen für Anbieter aus der Region
|
||||
Place | Distribution
|
||||
• Internet-Plattform
|
||||
• Regionale Präsenz (insbesondere Vernetzung)
|
||||
Promotion | Kommunikation
|
||||
• SEO/SEA im Internet und auf Social Media
|
||||
• Über Veranstaltungsangebote und Fachvorträge in der
|
||||
Region
|
||||
|
||||
www.team-mueller.net
|
||||
21
|
||||
Unterscheidungsmerkmale
|
||||
im Wettbewerbskontext
|
||||
|
||||
www.team-mueller.net
|
||||
Unterscheidungsmerkmale
|
||||
im Wettbewerbskontext
|
||||
Angestrebte Merkmale
|
||||
• Made in Germany, Made in der Region Kassel
|
||||
• Ganzheitliches Informations- und Leistungsangebot
|
||||
• Erste Qualitätssicherung durch Akkreditierung der Anbieter
|
||||
• Maximale Praxisorientierung und -relevanz bei den Leistungsangeboten
|
||||
• Use-Cases mit nachgewiesenem Wirkungsgrad
|
||||
• Niederschwelliger Zugang zu Information, Vernetzung und Förderung ebenso
|
||||
wie zu Qualifizierung, Lösungen und technischer Infrastruktur
|
||||
• Digitale Plattform und hybrider Support und regionale Präsenz
|
||||
• …
|
||||
22
|
||||
|
||||
www.team-mueller.net
|
||||
23
|
||||
Wertschöpfung,
|
||||
Aufbauorganisation & Investitionsbedarf
|
||||
|
||||
www.team-mueller.net
|
||||
Wertschöpfung
|
||||
Wertschöpfung aus …
|
||||
24
|
||||
Listungs-
|
||||
umsätzen
|
||||
• Websitepräsenz;
|
||||
Gebühren der
|
||||
Umsetzungs-
|
||||
partner
|
||||
Vermittlungs-
|
||||
umsätzen
|
||||
• Kontakt-
|
||||
herstellung
|
||||
zu Leistungs-
|
||||
anbietern
|
||||
Vermietungs-
|
||||
umsätzen
|
||||
• Technische
|
||||
Leistungen &
|
||||
Support
|
||||
Veranstaltungs-
|
||||
umsätzen
|
||||
• KI-Frühstück,
|
||||
Netzwerk-
|
||||
veranstaltungen
|
||||
etc. als
|
||||
eigenständig
|
||||
refinanzierende
|
||||
Einheiten
|
||||
Leistungs-
|
||||
umsätzen
|
||||
• Teilnahme-
|
||||
gebühren für
|
||||
Schulungen
|
||||
|
||||
www.team-mueller.net
|
||||
Aufbauorganisation
|
||||
25
|
||||
Organ-Geschäftsführer
|
||||
mit anteiliger Vergütung
|
||||
(Fixkosten,
|
||||
Refinanzierung über Wirtschaftsleistung der Gesellschaft)
|
||||
Organisationsleiter
|
||||
mit menschlicher & digitaler Assistenz
|
||||
(Fixkosten,
|
||||
Refinanzierung über Wirtschaftsleistung der Gesellschaft)
|
||||
Ausschüsse
|
||||
über Entsendung und
|
||||
Refinanzierung aus Angebot
|
||||
Fachdienstleister
|
||||
Budget-/projektorientiert
|
||||
eingekauft und abgerechnet
|
||||
Zusatzkräfte
|
||||
über evtl. Projektförderung
|
||||
als Option
|
||||
|
||||
www.team-mueller.net
|
||||
Investitionsbedarf
|
||||
TBD
|
||||
• Entwicklung Geschäftsplan im Detail, ca. 25 T€
|
||||
• Gründungskosten der Gesellschaft, ca. 10 T€
|
||||
• Logo mit Markenrechten, Marketing-Basics und Webplattform, ca. 75 T€
|
||||
• ?
|
||||
• Betriebsausstattung (insb. IT), ca. 50 T€
|
||||
• Betriebsmittelbedarf/Vorfinanzierung bis BEP , ca. *** noch zu errechnen ***
|
||||
26
|
||||
|
||||
www.team-mueller.net
|
||||
27
|
||||
Vor- und „Nachteile“ des Modells
|
||||
|
||||
www.team-mueller.net
|
||||
Vor- und „Nachteile“ des Modells
|
||||
28
|
||||
• Geringes/begrenztes Risiko
|
||||
• Vielseitige
|
||||
Einbeziehungsmöglichkeiten
|
||||
• Breites Leistungsangebot
|
||||
• Hoher Qualitätsmaßstab
|
||||
• Vorteile für die Region
|
||||
• Hohe Skalierbarkeit
|
||||
• Zeitnaher ROI
|
||||
• Maximale Wertschöpfung liegt nicht
|
||||
in der Gesellschaft, sondern bei den
|
||||
Leistungsanbietern
|
||||
• Leistungs- und Absatzmarkt sind nicht
|
||||
begrenzbar, die Region dient „nur“ als
|
||||
Keimzelle und kann einzelne Vorteile
|
||||
erhalten
|
||||
Vorteile „Nachteile“
|
||||
|
||||
www.team-mueller.net
|
||||
29
|
||||
Abstimmung nächster Schritte
|
||||
|
||||
www.team-mueller.net
|
||||
Abstimmung nächster Schritte
|
||||
• Reflexion Ergebnisse (Heute)
|
||||
• Endabstimmung der Inhalte
|
||||
• Finalisierung der Präsentation
|
||||
• Präsentation im Projekt (22.01.?)
|
||||
• …?
|
||||
30
|
||||
|
||||
www.team-mueller.net
|
||||
Kontaktdaten
|
||||
31
|
||||
Kontaktdaten
|
||||
Dipl. Ökonom Frank Müller
|
||||
Geschäftsführender Gesellschafter
|
||||
Telefon +49 (0)561 93746-0
|
||||
Telefax +49 (0)561 93746-200
|
||||
E-Mail fm@team-mueller.net
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
Werte (priorisierte Liste)
|
||||
|
||||
Souveränität
|
||||
Robust > fancy
|
||||
Open source
|
||||
Gemeinwohlorientiert
|
||||
Nutze die besten verfügbaren Methoden
|
||||
Geschwindigkeit
|
||||
Kundenfokus
|
||||
Minimale Verschwendung
|
||||
Feedback
|
||||
Keep it simple & stupid
|
||||
Kein overengineering
|
||||
Fancy
|
||||
Binary file not shown.
BIN
Binary file not shown.
Binary file not shown.
BIN
Binary file not shown.
Binary file not shown.
BIN
Binary file not shown.
Binary file not shown.
Reference in New Issue
Block a user