TIVIO Antrags- und Förderverwaltung: Konfigurierbare Multi-Instanzen-Plattform
TIVIO ist der KI-Partner für Kommunen: zentrale, datenschutzkonforme KI Plattform, die unterschiedliche Anwendungsfälle der Verwaltung in einer gemeinsamen Arbeitsumgebung bündelt – statt für jede Aufgabe eine separate KI Lösung einzuführen oder sensible Daten unkontrolliert über allgemeine Dienste wie ChatGPT zu verarbeiten.
Die Idee für TIVIO entstand in einer kommunalen Verwaltung in Süddeutschland; das Gründerteam bringt eigene kommunalpolitische Erfahrung mit und kennt Abläufe, Zwänge und Bedürfnisse von Verwaltungen daher aus der praktischen Arbeit vor Ort. Wichtige Weiterentwicklungsschritte gehen wir bewusst interkommunal: Teile unserer Software haben wir gemeinsam mit dem Innenministerium Baden-Württemberg entwickelt.
Mittlerweile setzen zahlreiche Verwaltungen unterschiedlichster Größe auf TIVIO: von der kleinsten Partnerkommune mit 5 Verwaltungsmitarbeitenden bis zu Kreisverwaltungen mit über 1.000 Mitarbeitenden. Der Nutzen ist dabei nicht theoretisch, sondern in laufenden Verwaltungen gemessen, u. a.: Landratsamt Rastatt: rund 7.000 Stunden/Jahr Zeitersparnis durch strukturierte Prozessoptimierung, u. a. in Schriftverkehr und Vorgangsbearbeitung.
Speziell für das in dieser Challenge beschriebene Themenfeld ist zudem relevant: TIVIO entwickelt aktuell gemeinsam mit einem hessischen Landkreis ein digitales Antragswesen für das Jugendamt – als Co-Development-Partnerschaft, in der konkrete fachliche Anforderungen direkt in die Produktentwicklung einfließen statt am Reißbrett entstanden zu sein. Im Rahmen dieser Partnerschaft sind Zentralstellen-Rollen und eine mehrstufige Bewilligungslogik bereits umgesetzt; die Antragsstellung wird derzeit gemeinsam mit dem Landkreis weiterentwickelt und konzipiert.
→ Positionierung: TIVIO bringt damit sowohl breite, im Wirkbetrieb nachgewiesene Erfahrung mit KI-gestützter Verwaltungsarbeit (Case Studies, Partnerschaft mit dem Land BW) als auch konkrete, im Aufbau befindliche Erfahrung mit der Digitalisierung von Antrags- und Bewilligungsprozessen im Förder-/Jugendhilfekontext mit. Die im DPJW-Vorhaben beschriebene Zentralstellen-Logik ist der bei einem hessischen Landratsamt bereits umgesetzten Struktur strukturell sehr ähnlich – eine vergleichbare Co-Development-Partnerschaft mit dem DPJW-Konsortium ist für uns ein naheliegender nächster Schritt.
TIVIO verbindet leistungsfähige Infrastruktur mit dem Wissen, Strukturen und den bestehenden Arbeitsmitteln einer Verwaltung. Eigene Dokumente, Richtlinien, Vorlagen und weitere Wissensbestände werden eingebunden und über natürliche Sprache durchsucht, ausgewertet und für konkrete Aufgaben genutzt. Statt vorhandene Systeme zu ersetzen, fügt sich TIVIO als No-Code-Lösung in die bestehende Systemlandschaft ein – Anwenderinnen und Anwender formulieren ihr Anliegen im Chat, der IT-Aufwand für Einführung und Betrieb bleibt gering.
Zentrale, bereits produktiv genutzte Bausteine: Browserbasierte, DSGVO-konforme Plattform, gehostet in einem deutschen Rechenzentrum, auf Wunsch: kein lokaler Installationsaufwand bei der Institution. Bei Bedarf:
Dokumente & Vorlagen: bestehende Word-Vorlagen, Briefköpfe und Serienbriefe können automatisiert erstellt, befüllt und weiterverarbeitet werden.
Daten & Auswertungen: Excel- und CSV-Dateien können analysiert, gefiltert, ausgewertet und als Tabellen, Diagramme oder Schaubilder aufbereitet werden.
Dokumentenverarbeitung: PDF-Dateien und andere Dokumente können zusammengeführt, aufgeteilt, umgewandelt, zusammengefasst oder gezielt ausgewertet werden.
KI-gestützter Assistent für Antragstellende: beantwortet Rückfragen 24/7, mehrsprachig, auch in leichter Sprache.
E-Mail_GPT: unterstützt Sachbearbeitende bei Kommunikation mit Antragstellenden, Zentralstellen und Partnern.
Fachverfahren-Unterstützung: wiederkehrende Arbeitsschritte – etwa das Erstellen von Bescheiden, Bestätigungen oder Urkunden aus Fachdaten – werden automatisiert statt manuell erledigt.
Speziell für die in der Challenge beschriebene Prozesskette (Antragstellung, Bearbeitung, Abrechnung) gilt: Im Co-Development mit einem hessischen Landkreis (Jugendamt) sind Zentralstellen-Rollen und mehrstufige Bewilligung bereits umgesetzt. Für ein Vorhaben in der Größenordnung des DPJW-Konsortiums sollte der konkrete Funktionsumfang hierzu vorab gemeinsam abgeglichen werden.
Durchgängiges Prinzip dabei: Human-in-the-Loop: TIVIO trifft keine automatisierten Entscheidungen, sondern bereitet vor, entlastet und macht Vorschläge. Mitarbeitende prüfen, korrigieren und geben frei; fachliche Verantwortung und Ermessen bleiben in der Institution. Jede Antwort ist zudem auf ihre Quelle zurückführbar, bei eigenen Dokumenten bis zur konkreten Fundstelle
TIVIO ist als Plattform von Grund auf darauf ausgelegt, unterschiedlich große, eigenständige Verwaltungseinheiten zu bedienen: von der kleinsten Partnerverwaltungen mit 5 Mitarbeitenden bis zu Kreisverwaltungen mit über 1.000 Mitarbeitenden. Jede Institution erhält eine eigene, getrennte Umgebung/Instanz mit eigenem Datenraum, während Betrieb, Weiterentwicklung, Bedienkonzept und Administration zentral auf derselben technischen Basis laufen. Dieses Prinzip lässt sich unmittelbar auf das DPJW/DFJW/DGJW/Tandem/ConAct-Szenario übertragen: eigenständige Instanzen je Institution, gemeinsame Codebasis, gemeinsame Weiterentwicklung, institutsspezifische Konfiguration (Sprache, Förderrichtlinien, Formulare, Rollen)
Ohne Programmierung anpassbar: Texte, Antwortbausteine, hinterlegtes Wissen/FAQ, Tonalität der Kommunikation, Sprachumfang. Durch Fachadministration/Poweruser konfigurierbar: welche Dokumente/Wissensbestände dem Assistenten zugrunde liegen, Freigabe Workflows, sowie individuelle die passgenau für eine Institution oder einen Fachbereich neu entwickelt oder angepasst werden können – ohne dass daraus eine Sammlung isolierter Einzeltools entsteht, sondern eine mitwachsende Plattform.
Im Antragswesen-Modul werden Förderprogramm- und Formularlogiken bewusst gemeinsam mit dem jeweiligen Partner erarbeitet und konfigurierbar gestaltet, statt sie starr vorzugeben – ein Ansatz, der sich auf die institutsspezifischen Förderrichtlinien der Jugendwerke übertragen lässt. Individualentwicklung ist typischerweise dort zu erwarten, wo sehr spezifische, bislang nicht abgedeckte Anforderungen bestehen z. B. die Projektabrechnung) – genau hier setzt das Co Development-Modell an, um diesen Bedarf systematisch in die Produktentwicklung zu übernehmen statt ihn als isoliertes Individualprojekt zu behandeln.
Ohne Programmierung anpassbar: Texte, Antwortbausteine, hinterlegtes Wissen/FAQ, Tonalität der Kommunikation, Sprachumfang. Durch Fachadministration/Poweruser konfigurierbar: welche Dokumente/Wissensbestände dem Assistenten zugrunde liegen, Freigabe Workflows, sowie individuelle die passgenau für eine Institution oder einen Fachbereich neu entwickelt oder angepasst werden können – ohne dass daraus eine Sammlung isolierter Einzeltools entsteht, sondern eine mitwachsende Plattform.
Im Antragswesen-Modul werden Förderprogramm- und Formularlogiken bewusst gemeinsam mit dem jeweiligen Partner erarbeitet und konfigurierbar gestaltet, statt sie starr vorzugeben – ein Ansatz, der sich auf die institutsspezifischen Förderrichtlinien der Jugendwerke übertragen lässt. Individualentwicklung ist typischerweise dort zu erwarten, wo sehr spezifische, bislang nicht abgedeckte Anforderungen bestehen z. B. die Projektabrechnung) – genau hier setzt das Co Development-Modell an, um diesen Bedarf systematisch in die Produktentwicklung zu übernehmen statt ihn als isoliertes Individualprojekt zu behandeln.
Berechtigungslogik für Dokumenten- und Wissenszugriff ist grundlegend in der Plattform vorhanden. Das Zentralstellen-Modell (Dachverbände, Länderstellen als Zwischeninstanz zwischen Antragstellenden und Förderstelle) sowie eine mehrstufige Bewilligungslogik werden im Antragswesen-Modul umgesetzt. Auch die gleichberechtigte, partnerschaftliche Mitbearbeitung von Anträgen durch mehrere Personen ist eine Anforderung, die uns aus dieser Praxis vertraut ist. Für das DPJW-Szenario mit fünf eigenständigen Institutionen und ihren jeweiligen Zentralstellen-Konstellationen würden wir empfehlen, die konkreten Rollenmodelle frühzeitig gemeinsam zu spezifizieren, aufbauend auf dem bereits erprobten Zentralstellen- und Bewilligungsmodell
In der Mehrsprachigkeit liegt eine Kernstärke der Plattform: Der Antrags-Assistent beherrscht mehrere Sprachen nativ sowie leichte Sprache, ohne dass jede Textvariante separat händisch gepflegt werden muss. Für hinterlegte Formulare, Vorlagen und Dokumente lässt sich dieses Prinzip nutzen, um automatisiert Übersetzungsvorschläge zu erzeugen, die durch die jeweilige Fach- und Förderstelle fachlich geprüft und freigegeben werden – passend zum in der Challenge beschriebenen Bedarf, dass Übersetzungen bei Bedarf durch die Fach- und Förderstellen selbst bereitgestellt werden können.
Ein Vorhaben dieser Größenordnung würden wir typischerweise in mehreren Phasen umsetzen:
Zunächst eine gemeinsame Konzeptionsphase mit allen beteiligten Institutionen, in der wir an unserer bereits vorhandenen Plattformbasis ansetzen – also nicht bei null beginnen, sondern die bestehenden Bausteine (u. a. Antragsportal, Zentralstellen-Rollen, mehrstufige Bewilligungslogik) mit dem konkreten fachlichen Bedarf der Institutionen abgleichen. In dieser Phase werden Anforderungen, Förderrichtlinien, Rollen- und Zentralstellen-Modelle sowie der Funktionsumfang der Projektabrechnung im Detail spezifiziert, und dort, wo der bestehende Funktionsumfang nicht ausreicht, werden gezielt Sonderfunktionen für das Konsortium konzipiert und in die Plattform aufgenommen – statt eine komplette Individuallösung neu zu entwickeln.
Darauf folgt der Aufbau der gemeinsamen Plattform-Basis sowie die Konfiguration der ersten institutsspezifischen Instanz, typischerweise als Pilotinstitution. Anschließend werden die Instanzen der übrigen Institutionen sukzessive eingerichtet, konfiguriert und getestet, bevor der reguläre Wirkbetrieb je Institution startet.
Für den Rollout auf mehrere Institutionen empfehlen wir grundsätzlich ein gestuftes statt eines gleichzeitigen Vorgehens: Da DPJW, DFJW, DGJW, Tandem und ConAct jeweils eigene, getrennte Instanzen mit eigenen Förderrichtlinien, Formularen, Sprachen und Rollenmodellen erhalten (siehe Frage zu Multi-Organisationen), lässt sich jede Institution unabhängig von den anderen live schalten. Das reduziert Risiko und Komplexität gegenüber einem gemeinsamen „Big-Bang“-Start und passt zu einem Zeitrahmen, bei dem einzelne Institutionen zu unterschiedlichen Zeitpunkten starten können.
Zu Zeitrahmen: Konkrete Aussagen dazu hängen stark vom Umfang der final abgestimmten Anforderungen ab, insbesondere der Projektabrechnungslogik, etwaiger Sonderfunktionen und der Anzahl/Komplexität benötigter Schnittstellen. Erfahrungsgemäß ist die Einführung der Kernplattform (Antragsportal, Bearbeitung, Zentralstellen-Rollen, mehrstufige Bewilligung) je Institution vergleichsweise schnell möglich, da wir auf unserer bestehenden, im Wirkbetrieb erprobten Basis aufsetzen und diese als No-Code-Lösung konzipiert ist; die Anbindung von Schnittstellen und die Migration von Altdaten sind demgegenüber die zeitkritischeren Bausteine.
Zu Schnittstellen und Import-/Exportmöglichkeiten: Strukturierte Im- und Exporte (z. B. Excel/CSV) sowie flexible Dokumentenverarbeitung sind bereits Bestandteil unserer Plattform. Standardisierte, vorkonfigurierte Schnittstellen zu Buchhaltungs-, DMS- oder E-Akte-Systemen bieten wir aktuell nicht als fertiges Produktmodul an; eine technische Anbindung ist grundsätzlich möglich, hängt aber auch von der Offenheit der jeweiligen Drittsysteme ab. Da die fünf Institutionen voraussichtlich unterschiedliche Buchhaltungs- und Dokumentenmanagementsysteme einsetzen, wäre der Aufbau institutsspezifischer Schnittstellen ein eigenständiger, gemeinsam zu konzipierender Projektbestandteil.
Zu Migration von Altdaten: Dies ist ein eigenständiger, sorgfältig zu planender Baustein, der über die reine Softwareeinführung hinausgeht. Typische Voraussetzungen und Herausforderungen sind dabei: die Bereinigung und Vereinheitlichung heterogener Altdatenformate je Institution, die Klärung von Zuständigkeiten für die Datenqualität sowie ausreichend Testzeit vor dem produktiven Umstieg. Angesichts des Umfangs bei einzelnen Institutionen (z. B. rund 1.412 Anträge/Jahr beim DPJW) sehen wir die Altdatenmigration als einen der zeitintensiveren Arbeitsschritte im Projekt.
Zu Mitwirkungspflichten: Für ein reibungsloses Vorgehen benötigen wir von jeder Institution insbesondere: fachliche Ansprechpartner:innen zur Spezifikation von Förderrichtlinien, Formularen, Bewilligungslogik und etwaigen Sonderfunktionen; Zugriff auf bzw. Bereitstellung der zu migrierenden Altdaten in einem verarbeitbaren Format; Testkapazität für die fachliche Abnahme vor dem Livegang; sowie – bei gewünschter Schnittstellenanbindung – Ansprechpartner:innen bzw. Dokumentation der jeweiligen Drittsysteme (Buchhaltung, DMS).
Betriebsmodelle: Unser Standardmodell ist der vollständig Managed-Service/SaaS-Betrieb aus einem deutschen Rechenzentrum, bei dem TIVIO den kompletten technischen Betrieb übernimmt und kein Software-Betrieb auf Servern/Clients der Institutionen notwendig ist.
Auf Wunsch bieten wir auch einen On-Premise-Betrieb an, bei dem die Lösung in der Infrastruktur der jeweiligen Institution betrieben wird. Für ein Konsortium wie dieses, in dem einzelne Institutionen einen Managed-Service und andere eine On-Premise-Lösung bevorzugen, lassen sich beide Betriebsmodelle je Institution flexibel kombinieren.
Eine Private-Cloud-Variante (dedizierte, isolierte Umgebung statt gemeinsam genutzter Infrastruktur) ist auf Anfrage ebenfalls möglich; ein hybrides Modell, bei dem einzelne Komponenten SaaS und andere On-Premise laufen, wäre gemeinsam zu konzipieren und im Detail zu prüfen.
Datenschutz und Hosting: Die Plattform ist von Grund auf für den öffentlichen Sektor konzipiert und verarbeitet Daten in einer datenschutzkonformen Umgebung. Im Managed-Service-Modell erfolgt das Hosting in einem deutschen Rechenzentrum; Daten werden verschlüsselt übertragen und gespeichert. Im On-Premise-Modell verbleiben die Daten vollständig in der Infrastruktur der jeweiligen Institution.
Informationssicherheit, Protokollierung und Nachvollziehbarkeit: Zugriffe und Bearbeitungsschritte im Antragswesen – etwa Bewilligungsentscheidungen, Freigaben durch Zentralstellen oder Änderungen an Anträgen – werden protokolliert und sind nachvollziehbar dokumentiert.
Eine vollständig revisionssichere Dokumentation im Sinne einschlägiger Standards ist derzeit kein fertiges Produktmerkmal; die konkreten Anforderungen (z. B. Aufbewahrungsfristen, Unveränderbarkeit, Prüfpfade) würden wir im Rahmen der Konzeptionsphase gemeinsam mit dem Konsortium aufnehmen und, soweit erforderlich, gezielt als Sonderfunktion ergänzen.
Schulung, Onboarding, Support und Weiterentwicklung: Da unsere Plattform auf einfache Bedienbarkeit ausgelegt ist, ist der Einstieg für Mitarbeitende erfahrungsgemäß niedrigschwellig; wir begleiten die Einführung mit Onboarding für die jeweiligen Fach- und Administrationsteams.
Laufender Support steht für Rückfragen im Betrieb zur Verfügung. Die Weiterentwicklung erfolgt kontinuierlich und, wie in unserer Partnerschaft mit dem Landkreis Waldeck-Frankenberg praktiziert, im engen Austausch mit den Institutionen – neue Anforderungen fließen direkt in die gemeinsame Plattformbasis ein, statt in isolierten Einzelprojekten zu versanden. Für ein Konsortium dieser Größe würden wir empfehlen, Umfang und Format von Schulung und Support (z. B. zentrale Schulung vs. institutsweise, Reaktionszeiten) in der Konzeptionsphase gemeinsam festzulegen.
Lizenz- und Betriebsmodelle: Unser bestehendes Modell ist ein modulares Abonnement je aktiviertem Baustein, das unabhängig von der Größe der Institution skaliert – bewährt von der 5-Personen-Verwaltung bis zur Kreisverwaltung mit über 1.000 Mitarbeitenden. Für den in dieser Challenge beschriebenen Managed-Service/SaaS-Betrieb würde dieses Abonnementmodell greifen; für Institutionen, die stattdessen einen On-Premise-Betrieb wünschen (siehe Frage zu Betriebsmodellen), wäre ergänzend ein Lizenzmodell für den lokalen Betrieb vorzusehen, das sich strukturell vom laufenden Abonnement unterscheidet.
Für ein Konsortium dieser Größenordnung – fünf eigenständige Institutionen mit deutlich unterschiedlichem Fördervolumen– halten wir ein gestaffeltes Modell mit Rahmenvertrag für sinnvoll: eine gemeinsame Grundplattform/-lizenz plus institutsspezifische Instanzen, deren laufende Kosten sich am jeweiligen Nutzungsumfang (z. B. Antragsvolumen) orientieren, statt einer einheitlichen Pauschale für alle Institutionen unabhängig von deren Größe.
Typische Struktur des wirtschaftlichen Aufwands: Erfahrungsgemäß gliedert sich der Gesamtaufwand vergleichbarer Projekte in folgende Bausteine:
Einführung/Konfiguration: Einmaliger Aufwand für die gemeinsame Konzeptionsphase, die Einrichtung der Grundplattform sowie die institutsspezifische Konfiguration (Förderrichtlinien, Formulare, Rollen- und Zentralstellen-Modelle, Sprachen) je Institution.
Sonderfunktionen/Weiterentwicklung: Aufwand für fachliche Bausteine, die über den bestehenden Funktionsumfang hinausgehen – im DPJW-Kontext insbesondere die Projektabrechnungslogik, die aktuell gemeinsam mit unserem Referenzpartner konzipiert wird.
Schnittstellen: Aufwand für die Anbindung an institutsspezifische Buchhaltungs-, DMS- oder E-Akte-Systeme; abhängig von Anzahl und Offenheit der jeweiligen Drittsysteme, entsprechend pro Institution unterschiedlich.
Migration: Einmaliger Aufwand für Bereinigung, Vereinheitlichung und Übernahme der Altdaten aus den historisch gewachsenen Systemen der beteiligten Institutionen; abhängig von Datenmenge und -qualität je Institution.
Betrieb: Laufende Kosten für Hosting und technischen Betrieb (im Managed-Service-Modell durch TIVIO abgedeckt) bzw. für die Bereitstellung eigener Infrastruktur (im On-Premise-Modell durch die Institution selbst).
Support und Weiterentwicklung: Laufender Aufwand für Anwendersupport sowie kontinuierliche Weiterentwicklung der gemeinsamen Plattformbasis, aus der alle Institutionen profitieren.
Lizenzen/Abonnement: Laufende Kosten je aktiviertem Baustein und institutsspezifischer Instanz, gestaffelt nach Nutzungsumfang.
Einordnung für eine spätere Ausschreibung: Die größten Aufwandstreiber sehen wir erwartungsgemäß bei der Projektabrechnungslogik, dem Aufbau strukturierter Schnittstellen zu bestehenden Drittsystemen sowie der Altdatenmigration – deutlich weniger bei der Einführung der Kernplattform selbst, die als No-Code-Lösung vergleichsweise schnell konfigurierbar ist.
Für eine belastbare Kostenschätzung empfehlen wir, diese drei Punkte in einer möglichen Ausschreibung so konkret wie möglich zu beschreiben (Umfang der Abrechnungsanforderungen, Anzahl/Art der anzubindenden Drittsysteme, Umfang und Qualität der zu migrierenden Altdaten je Institution), da sie den wirtschaftlichen Aufwand stärker beeinflussen als die reine Plattformlizenz. Eine verbindliche Preisangabe geben wir im Rahmen dieser unverbindlichen Markterkundung entsprechend der Aufgabenstellung nicht ab.
