Mit KI können Unternehmen eigene Anwendungen schneller
entwickeln. Im Gespräch mit Marek Chroust, Gründer von MCS
Consult, geht Norman Müller der Frage nach, wie daraus
verlässliche Unternehmenssoftware und neue Angebote für Kunden
entstehen. Marek beschreibt Erfahrungen mit CRM, Zeiterfassung
und Schatten-IT und erläutert den Ansatz von CONTOPS 360. Im
Mittelpunkt stehen klare Anforderungen, menschliche Freigaben und
die Zusammenarbeit zwischen Fachbereichen, IT und
Geschäftsführung.
* 00:00 Eigene Software und die Frage nach Verantwortung
* 03:07 Mareks Weg zur Plattform CONTOPS 360
* 06:25 Wie KI die individuelle Softwareentwicklung verändert
* 10:10 Ein Handwerksbetrieb entwickelt seine eigene
Zeiterfassung
* 12:48 Warum Datenmodelle und Standards wichtig bleiben
* 16:02 Vibe Coding und strukturierte Anwendungsentwicklung
* 19:35 Vom CRM-Prototyp zum Betrieb bei Hetzner
* 22:32 Software an die Arbeit im Unternehmen anpassen
* 27:31 Fehlerhafte Workflows und menschliche Qualitätsprüfung
* 29:23 Für wen der Ansatz passt und wie Schatten-IT entsteht
* 38:10 Entwicklung und IT-Betrieb zusammenbringen
* 41:05 Verantwortung zwischen Fachbereich und Geschäftsführung
* 47:05 Neue Geschäftsmodelle und schnellere Marktreaktionen
* 49:28 Das Gedankenexperiment mit dem Getränkegroßhandel
* 55:00 Fragen für eine Fortsetzung
* 57:39 Mareks Schlussgedanke zur menschlichen Kontrolle
Mehr KI mit Substanz. Jetzt abonnieren!
Shownotes
Marek Chroust ist Gründer und Inhaber von MCS Consult, das er
2009 als Management- und IT-Beratung aufgebaut hat. Er bringt
mehr als 30 Jahre Erfahrung in IT-Transformation und der
Steuerung großer Projekte mit. Von 2018 bis Ende 2025 war er
Mitgründer und CFO des IT-Serviceproviders omniIT. Seit Ende 2025
treibt er die Entwicklung von CONTOPS 360 voran. Daneben
organisiert er unter der Marke MCS events geführte mehrtägige
Motorradtouren.
* Marek Chroust: LinkedIn-Profil
* MCS Consult GmbH: Website ·
LinkedIn-Unternehmensseite
* CONTOPS 360: Website · LinkedIn-Produktseite
* Heiko Oberleitner, zusätzlicher Teamkontakt:
LinkedIn-Profil
Eigene Software verändert die Verantwortung der
Geschäftsführung
Ein Handwerksunternehmer entwickelt nachts seine eigene
Zeiterfassung. Tagsüber führt er einen Metallbetrieb. Er möchte
die Software an seine Arbeit anpassen und stößt auf fehlende
Schnittstellen zu seinem ERP-System. Im Gespräch erzähle ich
Marek Chroust von diesem Fall. Der Unternehmer denkt bereits
darüber nach, gemeinsam mit anderen Betrieben ein eigenes System
zu bauen.
In dieser Geschichte steckt eine Frage, mit der sich
Geschäftsführungen beschäftigen sollten: Wie viel von der eigenen
Arbeitsweise haben sie bisher einem Softwareanbieter überlassen?
Unternehmen kaufen Programme, richten sie ein und gewöhnen ihre
Mitarbeiter an die vorgesehenen Abläufe. Wer einen besonderen
Prozess braucht, muss für Anpassungen bezahlen, auf eine
Schnittstelle warten oder mit einer Behelfslösung arbeiten.
KI-gestützte Entwicklung erweitert den Handlungsspielraum.
Fachbereiche können Anforderungen formulieren und erste
Anwendungen ausprobieren. Marek, Gründer von MCS Consult,
beschreibt im Venture AI Podcast, wie sein Team dafür einen
Rahmen entwickelt hat. Mit CONTOPS 360 will es den Weg von der
Anforderung über Prüfung und Freigabe bis zum laufenden Betrieb
organisieren. Seine Beispiele führen zu einer Führungsaufgabe:
Wer eigene Software nutzt, muss auch entscheiden, wer sich
dauerhaft um sie kümmert.
Die Fachbereiche kennen die Arbeit
Marek berichtet von einem CRM, für das sein Team zuvor Salesforce
nutzte. Nach seiner Schätzung brauchte es nur einen kleinen Teil
des Funktionsumfangs. Also beschrieb das Team zunächst die
eigenen Abläufe: Wie entstehen Kontakte, Kundenbeziehungen und
Projekte? Was muss die Anwendung dafür können? Daraus entwickelte
es mit Lovable einen Prototypen. Als weiteres Beispiel nennt er
Zeiterfassung und Projektabrechnung.
Interessant ist die Reihenfolge. Die Beteiligten mussten sich
zuerst verständigen, wie sie arbeiten. Ein Unternehmen kann mit
KI auch einen unklaren Prozess in Software übersetzen. Es bekommt
dann eine Anwendung, in der die Unklarheit weiterlebt.
Deshalb gehören die Menschen in die Entwicklung, die den Ablauf
kennen. Sie wissen, an welcher Stelle Mitarbeiter Daten mehrfach
eingeben, welche Freigabe wartet und welche Information später
bei der Abrechnung fehlt. Dieses Wissen muss in die Anforderungen
eingehen. Die Geschäftsführung sollte dafür Zeit und
Verantwortliche benennen.
Der Betrieb braucht eigene Entscheidungen
Ein besonders aufschlussreicher Fall stammt aus der Baubranche.
Marek berichtet von einem Unternehmen mit rund 150 Mitarbeitern,
dessen Fachbereiche 14 Anwendungen an der zentralen IT vorbei
entwickelt hätten. Teilweise seien diese mit dem ERP-System
verbunden gewesen. Nach seiner Darstellung fehlten ausreichende
Vorkehrungen für sicheren und verlässlichen Betrieb. Eine
unabhängige Prüfung des Falls liegt uns nicht vor.
Das Beispiel zeigt, welche Fragen mit der Entwicklung entstehen.
Wer darf auf die Daten zugreifen? Wer stellt die Anwendung nach
einem Ausfall wieder her? Wer prüft eine Änderung, bevor
Mitarbeiter damit arbeiten? Wer kennt die Abhängigkeiten zum
ERP-System?
Marek beschreibt auch Workflows, die KI anders umgesetzt habe als
erwartet. Menschen mussten die Ergebnisse prüfen und die
Anforderungen genauer formulieren. Diese Prüfung ist Teil der
Entwicklungsarbeit. Ein ansprechender Bildschirm sagt wenig
darüber aus, ob ein Prozess bei unvollständigen Angaben, falschen
Berechtigungen oder einer unterbrochenen Verbindung noch richtig
funktioniert.
Für die Geschäftsführung folgt daraus: Sie sollte vor dem Einsatz
festlegen, wer fachlich prüft, wer technisch freigibt und wer den
laufenden Betrieb verantwortet. Diese Rollen können je nach
Unternehmensgröße unterschiedlich verteilt sein. Die Aufgaben
bleiben bestehen.
Die IT braucht einen gemeinsamen Auftrag
Marek beobachtet unterschiedliche Reaktionen innerhalb der IT.
Entwicklungsbereiche nutzen aus seiner Sicht die neuen Werkzeuge
oft früher. Menschen im Betrieb fragen stärker danach, welche
Anwendungen sie übernehmen sollen und ob sie dafür genügend
Dokumentation erhalten.
Diese Zurückhaltung ist verständlich. Wer den Betrieb
verantwortet, muss auch dann handeln können, wenn der
ursprüngliche Entwickler das Unternehmen verlässt. Fachbereiche
wiederum brauchen einen Weg, ihre Ideen zu erproben und gute
Anwendungen weiterzuentwickeln.
Im Gespräch diskutieren wir deshalb eine Organisation mit
fachlichen Product Ownern und einer übergreifenden
Architekturverantwortung. Ein Chief AI Officer oder eine
Stabsstelle könnte das Thema auf Geschäftsführungsebene
vertreten. Ob ein Unternehmen diese Titel braucht, hängt von
seiner Größe ab. Es muss aber jemanden geben, der Entwicklung,
bestehende Systeme und Betrieb zusammenführt und Entscheidungen
treffen darf.
Zu diesen Entscheidungen gehört auch die Wirtschaftlichkeit. Für
ein eigenes CRM fallen über die Entwicklung hinaus Kosten an:
Betreuung, Sicherheitsprüfung, Änderungen und Betrieb. Das
Gespräch liefert dafür keine belastbare Vergleichsrechnung.
Unternehmen sollten diese Kosten gegen eine passende
Standardlösung rechnen, bevor sie sich für den Eigenbau
entscheiden.
Neue Angebote müssen sich beim Kunden bewähren
Gegen Ende entwerfe ich ein Gedankenexperiment: Ein
Getränkegroßhändler könnte seine Kunden in der Gastronomie
gezielter bei Sortiment und Nachbestellung unterstützen. Er kennt
bisherige Bestellungen und könnte zusätzliche Informationen über
Nachfrage oder Trends einbeziehen. Daraus ließe sich eine
Leistung entwickeln, die über die Lieferung von Getränken
hinausgeht.
Die im Gespräch genannten Umsatzsteigerungen sind hypothetische
Größen. Wir präsentieren weder einen gemessenen Kundenerfolg noch
eine Zusage. Die spannende Frage lautet, ob Gastronomen für einen
solchen Service bezahlen würden und ob er ihnen im Alltag hilft.
Marek sieht den wirtschaftlichen Nutzen KI-gestützter Entwicklung
vor allem in der schnelleren Anpassung an Veränderungen.
Unternehmen könnten …
Get full access to VENTURE AI STACK at
www.ventureaistack.com/subscribe
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.