SaaS, Eigenentwicklung oder Co-Creation?

Welches Modell passt zu welchem Prozess?

Unternehmen stehen bei neuer Software häufig vor einer scheinbar einfachen Entscheidung: eine vorhandene SaaS-Lösung einführen oder eine individuelle Anwendung entwickeln.

Beide Wege haben klare Vorteile. Beide können aber auch zum falschen Modell werden, wenn sie ohne Bezug zum konkreten Prozess gewählt werden.

Standardsoftware ist nicht grundsätzlich unflexibel. Eigenentwicklung ist nicht automatisch souverän. Und Co-Creation ist nicht bloß ein neues Wort für Customizing.

Die richtige Entscheidung hängt davon ab, wie standardisierbar ein Prozess ist, wie strategisch die enthaltenen Daten und das Wissen sind und welche Verantwortung ein Unternehmen langfristig übernehmen kann.

Dieser Vergleich betrachtet drei Modelle:

1. klassisches SaaS,
2. vollständige Eigenentwicklung,
3. Co-Creation auf einer vorhandenen Plattform.

Die drei Modelle im Überblick

Keines dieser Modelle ist grundsätzlich überlegen. Entscheidend ist die Passung zum Anwendungsfall.

Wann klassisches SaaS sinnvoll ist

SaaS ist besonders stark, wenn ein Prozess weitgehend standardisiert ist und keinen direkten Wettbewerbsvorteil bildet.

Typische Beispiele sind:

• Videokonferenzen,
• Terminplanung,
• Reisekosten,
• einfache Kollaborationsfunktionen,
• oder klar definierte Verwaltungsprozesse.

Die Vorteile sind bekannt:

• schneller Start,
• planbare Updates,
• geringer eigener Betriebsaufwand,
• standardisierte Sicherheits- und Administrationsfunktionen,
• und ein großes Ökosystem aus Integrationen.

SaaS wird problematisch, wenn ein Unternehmen versucht, einen hochindividuellen Kernprozess dauerhaft in ein starres Standardmodell zu pressen.

Warnsignale sind:

• umfangreiche Workarounds,
• viele manuelle Exporte und Importe,
• Zusatztools für fehlende Funktionen,
• hohe Kosten für individuelle Anpassungen,
• oder Prozesse, die sich an der Software statt am tatsächlichen Bedarf orientieren.

SaaS ist dann weiterhin nutzbar, aber möglicherweise nicht mehr als alleinige Lösung.

Wann Eigenentwicklung sinnvoll ist

Eine vollständige Eigenentwicklung bietet maximale Freiheit. Datenmodell, Benutzeroberfläche, Integrationen und Prozesslogik können exakt auf das Unternehmen zugeschnitten werden.

Das ist besonders interessant, wenn:

• der Prozess einen wesentlichen Wettbewerbsvorteil schafft,
• Standardlösungen den Kernbedarf nicht abdecken,
• spezielle technische Anforderungen bestehen,
• oder vollständige Kontrolle über Betrieb und Weiterentwicklung notwendig ist.

Die Risiken liegen jedoch nicht nur in den Entwicklungskosten.

Eine produktive Unternehmensanwendung benötigt dauerhaft:

• Architekturentscheidungen,
• Rollen und Berechtigungen,
• Tests,
• Monitoring,
• Sicherheitsupdates,
• Dokumentation,
• Schnittstellenpflege,
• Datenmigration,
• und kompetente Verantwortliche.

KI-gestützte Entwicklung kann die Umsetzung erheblich beschleunigen. Sie beseitigt aber nicht diese langfristigen Aufgaben.

Eigenentwicklung ist deshalb dann sinnvoll, wenn das Unternehmen nicht nur entwickeln, sondern auch dauerhaft Produktverantwortung übernehmen kann und will.

Was Co-Creation auf einer Plattform bedeutet

Co-Creation versucht, die Stärken beider Modelle zu verbinden.

Eine vorhandene Plattform liefert das technische Fundament. Dazu können gehören:

• Identitäts- und Rechteverwaltung,
• Datenmodelle,
• Schnittstellen,
• Dokumenten- und Wissensmanagement,
• Prozessautomatisierung,
• KI-Assistenten,
• Betrieb und Monitoring,
• sowie Entwicklungswerkzeuge.

Das Anwenderunternehmen bringt den konkreten Prozess, die fachlichen Anforderungen, Daten und Expertenwissen ein.

Gemeinsam entsteht eine Anwendung, die individuell genug für den Prozess ist, aber nicht bei null beginnt.

Co-Creation eignet sich besonders für Fälle, in denen:

• Standardsoftware den Prozess nicht ausreichend abbildet,
• eine vollständige Eigenentwicklung unverhältnismäßig wäre,
• mehrere bestehende Systeme integriert werden müssen,
• Fachwissen eine zentrale Rolle spielt,
• und der Prozess schrittweise weiterentwickelt werden soll.

Co-Creation ist nicht Customizing

Beim klassischen Customizing bewegt sich der Kunde innerhalb eines vom Anbieter definierten Rahmens. Felder, Rollen, Masken und Workflows werden konfiguriert, die grundlegende Produktlogik bleibt jedoch unverändert.

Co-Creation geht weiter.

Der gemeinsame Lösungsraum kann wachsen. Neue Assistenten, Datenflüsse oder Fachmodule entstehen iterativ. Erkenntnisse aus dem Betrieb fließen in die Weiterentwicklung zurück.

Der Unterschied zeigt sich in den Fragen:

Beim Customizing:

Welche vorhandene Funktion können wir anpassen?

Bei Co-Creation:

Welcher konkrete Prozess soll messbar besser werden und welche Plattformbausteine benötigen wir dafür?

Co-Creation darf dabei nicht mit unstrukturierter Auftragsentwicklung verwechselt werden. Die Plattformgrenzen, Rechte und Verantwortlichkeiten müssen klar definiert sein.

Welche Verantwortung beim Anbieter bleibt

Ein Co-Creation-Modell funktioniert nur, wenn der Plattformanbieter mehr übernimmt als einzelne Entwicklungsleistungen.

Typische Verantwortungsbereiche sind:

• technische Architektur,
• Sicherheit und Updates,
• Plattformbetrieb,
• Integrationsstandards,
• Qualitätsmanagement,
• Dokumentation,
• Monitoring,
• und langfristige Kompatibilität.

Der Anbieter stellt sicher, dass individuelle Erweiterungen nicht zu einer unwartbaren Insellösung werden.

Welche Verantwortung beim Kunden bleibt

Das Anwenderunternehmen ist nicht nur Auftraggeber. Es ist fachlicher Mitgestalter.

Dazu gehören:

• klare Prozessziele,
• Verfügbarkeit von Fachexperten,
• Entscheidungen zu Daten und Berechtigungen,
• Priorisierung von Anforderungen,
• Tests im realen Arbeitsablauf,
• und eine interne Verantwortung für Einführung und Veränderung.

Ohne aktive Mitarbeit entsteht keine Co-Creation, sondern lediglich ein weiteres IT-Projekt mit unklaren Erwartungen.

Entscheidungskriterien für das richtige Modell

1. Wie standardisierbar ist der Prozess?

Je stärker ein Ablauf branchenübergreifend gleich funktioniert, desto eher eignet sich SaaS.

2. Wie strategisch sind Daten und Wissen?

Wenn ein Prozess geschäftskritisches Erfahrungswissen enthält, steigt der Bedarf an Kontrolle und Weiterentwicklungsfähigkeit.

3. Wie stark müssen bestehende Systeme integriert werden?

Viele individuelle Integrationen können ein Standardprodukt wirtschaftlich unattraktiv machen. Eine Plattform mit wiederverwendbaren Konnektoren kann hier Vorteile bieten.

4. Wie schnell verändert sich der Prozess?

Ein stabiler Standardprozess benötigt weniger Flexibilität. Ein wachsender oder experimenteller Prozess profitiert von iterativer Entwicklung.

5. Welche Betriebsverantwortung kann das Unternehmen übernehmen?

Wer keine eigene Produktorganisation aufbauen will, sollte eine vollständige Eigenentwicklung kritisch prüfen.

6. Wie wichtig ist die Ausstiegsfähigkeit?

Datenexport, Quellcode-Rechte, Dokumentation, Betriebsmodell und Übergabemöglichkeiten sollten vor Vertragsabschluss geklärt werden.

Drei typische Szenarien

Szenario 1: Standardprozess

Ein Unternehmen benötigt eine etablierte Lösung für Reisekosten. Die Anforderungen unterscheiden sich kaum vom Marktstandard.

Geeignetes Modell: SaaS.

Szenario 2: Strategischer Kernprozess

Ein Maschinenbauer entwickelt einen proprietären Konfigurationsprozess, der unmittelbar Teil seines Wettbewerbsvorteils ist und tief in Produktdaten integriert werden muss.

Geeignetes Modell: Eigenentwicklung oder sehr weitreichende Co-Creation, abhängig von vorhandener Produktkompetenz.

Szenario 3: Wissensintensiver Industrieprozess

Ein Produktionsunternehmen möchte Störmeldungen per Sprache erfassen, SAP PM integrieren, Erfahrungswissen sichern und schrittweise weitere Assistenten ergänzen.

Geeignetes Modell: Co-Creation auf einer industriell geeigneten Plattform.

Warum ein Pilotprozess besser ist als eine Grundsatzentscheidung

Unternehmen müssen nicht zuerst eine unternehmensweite Plattformstrategie beschließen.

Ein sinnvoller Einstieg ist ein klar abgegrenzter Prozess mit messbarem Problem:

• unvollständige Meldungen,
• manuelle Doppelarbeit,
• fehlende Systemintegration,
• lange Informationssuche,
• oder drohender Wissensverlust.

An diesem Prozess lässt sich prüfen:

• wie schnell eine Lösung entsteht,
• welche Plattformbausteine wiederverwendbar sind,
• wie gut Fachanwender beteiligt werden,
• und ob das gewählte Modell langfristig tragfähig ist.

So wird aus einer abstrakten Build-or-Buy-Diskussion eine konkrete wirtschaftliche Entscheidung.

Fazit

SaaS ist stark, wenn Standardisierung wichtiger ist als Individualität.

Eigenentwicklung ist stark, wenn ein Prozess strategisch einzigartig ist und das Unternehmen langfristig Produktverantwortung übernehmen kann.

Co-Creation ist stark, wenn ein individueller Prozess auf einem vorhandenen technischen Fundament entstehen soll.

Die entscheidende Frage lautet nicht:

Welches Modell ist grundsätzlich das beste?

Sondern:

Welches Modell gibt diesem konkreten Prozess die richtige Balance aus Geschwindigkeit, Kontrolle und Weiterentwicklungsfähigkeit?