Anpassbare Standardsoftware trifft KI
von Alexander Huber
Standardsoftware funktioniert gut, solange der eigene Prozess dem vorgesehenen Standard entspricht. Schwierig wird es bei einer besonderen Anforderung: Bestimmte Zeitbuchungen sollen etwa zuerst von der Projektleitung und ab einem Grenzwert zusätzlich von der Geschäftsführung freigegeben werden. Unterstützt die Software diesen Workflow nicht, muss das Unternehmen seinen Prozess ändern, auf eine neue Produktfunktion warten oder eine individuelle Lösung entwickeln und dauerhaft pflegen.
Die grundsätzliche Lösung ist ein anpassbares Datenmodell. In time cockpit können Kunden mit dem OnCockpitAdmin selbst eigene Felder, Beziehungen, Regeln, Listen, Formulare und Berechtigungen ergänzen. Aus dem fehlenden Freigabeworkflow werden so ein zusätzlicher Status, die passenden Rollen, eine Liste der offenen Fälle und eine Aktion zur Freigabe. Der Standardkern bleibt erhalten, und es muss keine eigene time-cockpit-Version kompiliert werden.
Diese Möglichkeit war bisher vor allem für Menschen zugänglich, die das Datenmodell, TCQL und die Skriptumgebung gut kennen. KI kann diese Einstiegshürde senken. Aus einer fachlichen Beschreibung kann sie einen ersten Vorschlag für Modelländerung, Prüfregel, Abfrage, Liste und Geschäftslogik ableiten. Datenmodell, TCQL, Skriptumgebung und Sandbox geben dabei einen klaren Weg vor, um die Änderung umzusetzen und zu überprüfen.
Möglichkeiten, KI und LLMs in ein Produkt zu integrieren, gibt es viele: Assistenten in der Oberfläche, Abfragen in natürlicher Sprache, generierter Code oder neue Zugänge über MCP. Am Anfang war auch für uns nicht klar, welche Ideen im Arbeitsalltag wirklich Mehrwert schaffen und welche vor allem in einer Demo gut aussehen. Einen konkreten Ansatzpunkt fanden wir dort, wo KI nicht als isolierte Funktion auftritt, sondern den bestehenden Anpassungsprozess unterstützt.
Als wir erstmals ein LLM mit dem time-cockpit-Datenmodell, TCQL, der Skriptumgebung und unseren Werkzeugen verbunden haben, waren wir überrascht, wie gut die vorhandenen Bausteine zusammenspielten. Schon mit wenigen gezielten Skills konnte die KI daraus brauchbare Vorschläge für Modelländerungen, Abfragen, Listen und Skripte ableiten.
Nicht jeder Vorschlag war sofort produktionsreif, und die fachliche Prüfung bleibt notwendig. Entscheidend war für uns etwas anderes: Die KI musste time cockpit nicht neu erfinden. Datenmodell, TCQL, Skriptsprache und Werkzeuge boten bereits einen festen Weg, um fachliche Änderungen zu beschreiben, umzusetzen und zu prüfen. Darin liegt für uns der Grund, warum anpassbare Standardsoftware und KI so gut zusammenpassen.
Warum Geschwindigkeit allein nicht reicht
KI kann sehr schnell Code erzeugen. Sie weiß deshalb noch nicht, was in einem Unternehmen ein abrechenbares Projekt, eine genehmigte Zeitbuchung oder eine zulässige Ausnahme ist. Diese Bedeutung steckt im Fachsystem: in Datenstrukturen, Beziehungen, Regeln, Berechtigungen und vorhandenen Abläufen.
Der Vorteil liegt deshalb nicht allein in der Geschwindigkeit. Das kundenspezifische Datenmodell enthält die fachlichen Zusammenhänge. TCQL, Skriptsprache, OnCockpitAdmin und Sandbox geben vor, wie eine Anpassung umgesetzt und geprüft wird. KI kann auf dieser Grundlage schneller einen ersten funktionierenden Vorschlag erstellen. Der Kunde muss dadurch nicht zum Hersteller einer eigenen Softwareversion werden. Diese langfristige Verantwortung beleuchten wir auch in Zeiterfassung selbst programmieren mit KI.
Fünf Bausteine, die zusammen den Unterschied machen
Bei time cockpit greifen dafür fünf Bausteine ineinander. Jeder davon löst ein konkretes Problem.
1. Das Metamodell beschreibt, wie time cockpit aufgebaut ist
Das Metamodell ist die gemeinsame Grammatik des Systems. Es beschreibt, was eine Entität, eine Eigenschaft, eine Beziehung, eine Validierung, eine Berechtigung, eine Liste oder ein Formular ist.
Die praktische Folge: Viele Teile der Anwendung sind nicht fest in Programmcode eingebaut. Sie können als strukturierte Informationen gelesen und verändert werden. Ein KI-Agent muss daher nicht erraten, wie eine Erweiterung grundsätzlich funktioniert. Das System beschreibt seine Struktur selbst.
2. Das anpassbare Datenmodell bildet die Sprache des Kunden ab
Im Datenmodell werden aus allgemeinen Bausteinen konkrete Fachbegriffe. Ein Kunde ergänzt zum Beispiel einen Projekttyp, eine Kostenstelle, einen Freigabestatus oder eine Beziehung zum Rahmenvertrag. Dazu kommen berechnete Eigenschaften, Pflichtfelder, Regeln und Berechtigungen.
Damit kennt die Zeiterfassung die Zusammenhänge, die für Abrechnung und Projektsteuerung tatsächlich wichtig sind. Wenn sich Organisation oder Geschäftsmodell verändern, kann das Modell mitwachsen.
Der OnCockpitAdmin steht dafür auch Kunden zur Verfügung. Wer die Rolle Customization Admin besitzt, kann eigene Datenstrukturen, Listen, Formulare und Regeln ergänzen. Kunden können diese Arbeit selbst übernehmen oder gemeinsam mit uns umsetzen.
3. TCQL macht das Modell abfragbar
TCQL ist die Abfrage- und Ausdruckssprache von time cockpit. Sie folgt den Beziehungen im Datenmodell und wird nicht nur für Listen verwendet. Auch Berechnungen, Validierungen, Bedingungen und Teile des Berechtigungssystems bauen darauf auf.
Für den zweistufigen Genehmigungsworkflow könnte TCQL festlegen, welche Zeitbuchungen noch auf eine Freigabe warten, wann zusätzlich die Geschäftsführung zuständig ist und welche Personen die jeweiligen Einträge sehen oder genehmigen dürfen. Dieselben fachlichen Beziehungen stehen damit in Listen, Prüfungen und Auswertungen zur Verfügung.
Für KI ist das wertvoll, weil eine erzeugte Abfrage nicht auf unbekannte Tabellen und zufällige Spaltennamen zielt. Sie arbeitet gegen ein beschriebenes Modell mit fachlichen Beziehungen.
4. Die generische API wächst mit dem Modell
Die Web API von time cockpit folgt dem Datenmodell. Neue kundenspezifische Entitäten und Eigenschaften können dadurch über denselben Zugang gelesen und bearbeitet werden wie vorhandene Strukturen. Der OData-Endpunkt stellt Modell und Daten einschließlich individueller Datenmodellerweiterungen bereit. Für komplexere Abfragen steht zusätzlich der TCQL Query Endpoint zur Verfügung.
Ein Kunde kann zusätzliche Projektinformationen für Auswertungen bereitstellen oder Daten aus einem Vorsystem übernehmen, ohne für jedes neue Feld eine Produkt-API abwarten zu müssen. Berechtigungen bleiben Teil des Systems.
5. Die Skriptsprache definiert Erweiterungen und führt Geschäftslogik aus
Die integrierte Skriptsprache basiert auf IronPython. Der Name der Sprache ist aber nicht der Kern des Vorteils. Entscheidend sind ihre zwei Rollen.
Erstens ist sie eine Definitionssprache. Skripte können das Datenmodell dynamisch um Entitäten, Eigenschaften, Beziehungen und Validierungen erweitern. Auch Listen, Formulare, Aktionen und weitere Modellbestandteile lassen sich reproduzierbar registrieren. Zweitens enthält sie kundenspezifische Geschäftslogik, zum Beispiel für Freigaben, Schnittstellen, Aktionen oder Batchprozesse. Die Scripting-Dokumentation beschreibt diese Einsatzmöglichkeiten und die Arbeit mit dem Datenkontext.
Für ein LLM ist diese doppelte Rolle besonders nützlich. Mit der Dokumentation und gezielten Skills kennt es nicht nur die Syntax der Sprache, sondern auch die Muster einer gültigen time-cockpit-Anpassung. Aus einer fachlichen Anforderung kann es einen Entwurf erzeugen, der benötigte Felder, Beziehungen und Regeln definiert und zusätzlich die passende Geschäftslogik enthält.
Über den OnCockpitAdmin-MCP kann ein KI-Agent das tatsächliche Kundenmodell lesen, den Entwurf in einer Sandbox einspielen und Rückmeldungen des Systems auswerten. Existiert eine verwendete Eigenschaft nicht oder ist die Modelländerung ungültig, kann der Agent den Vorschlag überarbeiten. Menschen prüfen weiterhin die fachliche Richtigkeit und entscheiden, ob die Anpassung übernommen wird.
Beim Genehmigungsworkflow definiert ein Skript also nicht nur einen Programmablauf. Es kann die benötigten Statusfelder, Beziehungen und Regeln anlegen und zusätzlich die Aktion implementieren, mit der Projektleitung oder Geschäftsführung die betreffenden Zeitbuchungen genehmigen.
Diese Änderungen werden in die Kundeninstanz eingespielt, ohne den time-cockpit-Produktkern neu zu kompilieren und eine eigene Version bereitzustellen. Anpassungen sind als Code nachvollziehbar, versionierbar und zwischen Test- und Produktivumgebung übertragbar. IronPython kann dabei auf Objekte und Bibliotheken des .NET Frameworks zugreifen (IronPython).
Was Kunden damit machen und was wir damit machen
Kunden ergänzen eigene Projektmerkmale, Freigabeprozesse, Vertragsinformationen, Auswertungen oder Schnittstellen. Die Software folgt damit dem tatsächlichen Ablauf und kann auch bei neuen Anforderungen vertraut bleiben. Ein Produktwechsel mit Datenmigration und Schulungen lässt sich dadurch oft vermeiden.
Wir verwenden dieselben Mechanismen in der Produktentwicklung und in Kundenprojekten. Eine neue Idee kann zunächst als Modelländerung, TCQL-Abfrage, Liste und Skript entstehen. Im echten Daten- und Berechtigungskontext zeigt sich schnell, ob die fachliche Annahme trägt. Danach entscheiden wir, ob die Lösung kundenspezifisch bleibt oder als allgemeine Funktion in den Standardkern gehört.
KI verkürzt beide Wege. Ein Kunde oder Consultant kann eine Anforderung in Fachsprache beschreiben. Ein KI-Agent kann daraus einen ersten Änderungsvorschlag ableiten. Unsere Entwicklung kann Varianten schneller ausprobieren und die tragfähige Lösung anschließend sauber in das Produkt überführen.
Der gemeinsame Nenner ist das anpassbare Datenmodell: Kunden beschreiben darin ihre Besonderheiten, wir entwickeln darauf den Standard weiter und KI hilft, zwischen fachlicher Absicht und technischen Artefakten zu übersetzen.
Der OnCockpitAdmin-MCP schließt die Lücke zwischen Wissen und Ausführung
Damit KI nicht nur plausible Skripte ausgibt, braucht sie einen kontrollierten Zugang zum tatsächlichen System. Genau hier liegt die Verbindung zu unserem OnCockpitAdmin-MCP. Er ist ein internes Entwicklungswerkzeug und ergänzt den OnCockpitAdmin um Werkzeuge für KI-Agenten.
Ein Agent kann darüber das vorhandene Datenmodell lesen, eine Anpassung einspielen, Testdaten erzeugen und das Ergebnis prüfen. Er arbeitet also nicht nur mit einem langen Prompt, sondern erhält Rückmeldung vom System: Gibt es die verwendete Entität? Ist das Modell gültig? Funktioniert die Liste mit realistischen Daten? Greifen die vorgesehenen Regeln?
Hier wird das Zusammenspiel für KI praktisch: Das Metamodell liefert die Landkarte, das Kundenmodell den fachlichen Kontext, TCQL die Abfragen, die Skriptsprache die Definition und Logik, und der OnCockpitAdmin-MCP ermöglicht die kontrollierte Ausführung und Prüfung.
Der OnCockpitAdmin-MCP ist für unsere Produktentwicklung und autorisierte Customizing-Arbeit am Datenmodell gedacht. Für die Zukunft planen wir daneben einen stärker kunden- und benutzerorientierten MCP. Dieser soll nicht zur Erweiterung des Datenmodells dienen, sondern die Nutzung von time cockpit unterstützen, etwa beim Abfragen freigegebener Projektinformationen oder beim Vorbereiten von Arbeitsschritten im Kontext des angemeldeten Benutzers. Funktionsumfang und Verfügbarkeit sind noch nicht final festgelegt.
Dokumentation wird ausführbarer Kontext
Ein KI-Agent kann nur sinnvoll mit diesen Bausteinen arbeiten, wenn ihre Verwendung beschrieben ist. Deshalb erklären wir beispielsweise, wie Listen aufgebaut, Beziehungen abgefragt und Skripte mit dem Datenkontext verwendet werden.
Wir veröffentlichen dieses Wissen in unserer Dokumentation. Dienste wie Context7 können die Inhalte indexieren und gezielt für KI-Werkzeuge bereitstellen. Context7 ist darauf ausgelegt, aktuelle technische Dokumentation abzurufen und die passenden Abschnitte in den Arbeitskontext eines Coding Agents zu bringen (Context7).
So entsteht eine durchgängige Kette: Die Dokumentation erklärt die korrekte Verwendung. Der Agent liest Modell und Regeln. Er erzeugt eine Anpassung. Der OnCockpitAdmin-MCP spielt sie in einer kontrollierten Umgebung ein. Tests und menschliche Prüfung entscheiden, ob sie übernommen wird.
Fazit: Der Vorteil liegt im Zusammenspiel
KI-Zeiterfassung beginnt für uns nicht beim Chatbot. Sie beginnt bei einer Software, die ihr Fachwissen strukturiert ausdrücken kann.
Bei time cockpit greifen dafür fünf Dinge ineinander: Metamodell, anpassbares Datenmodell, TCQL, generische API und Skriptsprache. Dokumentation und OnCockpitAdmin-MCP machen dieses Wissen für KI auffindbar und kontrolliert nutzbar.
Für Kunden bedeutet das schnellere, passendere Erweiterungen ohne eigene Produktversion. Wir können Ideen näher am realen Anwendungsfall entwickeln und erfolgreiche Lösungen gezielt in den Standard übernehmen. Andere Produktteams können aus dieser Perspektive prüfen, wie klar ihr Produkt Anpassungen beschreibt, unterstützt und kontrolliert ausliefert.
Anpassbare Standardsoftware und KI entfalten ihren gemeinsamen Nutzen nicht automatisch. Erst wenn Datenmodell, Geschäftslogik, Schnittstellen und Werkzeuge ineinandergreifen, wird aus KI-Unterstützung ein verlässlicher Weg zu passenden Erweiterungen.
Wenn Sie eigene Projekt-, Abrechnungs- oder Zeiterfassungsprozesse abbilden möchten, zeigen wir Ihnen gerne, wie die anpassbare Zeiterfassung von time cockpit dafür eingesetzt werden kann.