Make or Buy: Software für Arbeitsanweisungen und Checklisten selbst entwickeln oder kaufen?

In letzter Zeit sind LinkedIn und YouTube voll davon: Anleitungen, wie man mit Vibe-Coding „mal eben" eine eigene Softwareanwendung baut. Die Botschaft dahinter ist verlockend, und sie ist nicht falsch. KI-Tools, Low-Code-Plattformen und Vibe-Coding haben die Einstiegshürde für Eigenentwicklungen real gesenkt. Damit erlebt eine alte Frage ihr Revival: Sollen wir unsere Software für Arbeitsanweisungen und Checklisten selbst entwickeln oder kaufen? Make or Buy?

Als Head of Product bei Operations1 höre ich diese Überlegung regelmäßig: in Erstgesprächen, in laufenden Projekten, manchmal kurz vor der Vertragsunterzeichnung. Ich nehme sie ernst, denn sie ist berechtigter als noch vor wenigen Jahren. Ein funktionierendes Nischentool für einen klar umrissenen Anwendungsfall lässt sich heute schneller entwickeln denn je. 

Was ich in denselben Gesprächen aber ebenso regelmäßig erlebe: Sobald die Lösung über diesen einen Anwendungsfall hinauswachsen soll (auf weitere Bereiche, Werke oder Prozesse), zeigt sich, dass die Eigenentwicklung nicht skalierbar ist. Genau deshalb möchte ich diese Frage einmal fundiert beantworten. 

Wann ist eine Eigenentwicklung die richtige Antwort? 

So viel vorab: Ja, es gibt Szenarien, in denen die Eigenentwicklung sinnvoll ist. Ein Unternehmen mit einer starken internen IT-Abteilung, einem klar abgegrenzten Use Case, zum Beispiel einer einzigen Prüflinie in einem Werk ohne Skalierungsabsicht, und mit Anforderungen, die keine Standardlösung abdeckt: In diesem Fall ist es legitim, sich mit einer Eigenentwicklung zu beschäftigen.

Drei Kriterien, bei denen "Make" die bessere Wahl ist: 

1. Die Anforderungen sind so spezifisch, dass keine verfügbare Standardlösung sie abdeckt. 

2. IT-Kapazität ist dauerhaft verfügbar – nicht nur für die initiale Entwicklung, sondern für Betrieb, Pflege und Weiterentwicklung über Jahre. 

3. Der Use Case bleibt eng begrenzt und soll nicht auf weitere Bereiche, Werke oder Prozesse skaliert werden. 

Wer alle drei Punkte mit Ja beantwortet, braucht diesen Artikel nicht weiterzulesen. Für alle anderen lohnt sich ein genauerer Blick auf das, was in der "Make"-Rechnung so gut wie immer fehlt. 

Was entwickelt die IT stattdessen nicht? 

Das ist die teuerste Frage der Make-or-Buy-Entscheidung. Leider wird sie fast nie gestellt. 

IT-Kapazität, die in die Nachentwicklung von Standardsoftware fließt, fehlt bei Projekten, die echte Wettbewerbsvorteile schaffen. Während die Eigenentwicklung monatelang reift, liefert eine Standardlösung ab dem ersten produktiven Use Case messbaren Nutzen. 

Was auf dem Spiel steht, zeigt ein Beispiel aus meiner eigenen Projekterfahrung: Quantum Systems, ein deutscher Drohnenhersteller, hat nach der Einführung von Operations1 seinen Output binnen zwölf Monaten um 300 % gesteigert, ohne das Personal zu verdreifachen. Der Hebel dabei war die Standardisierung der Shopfloor-Prozesse, nicht die Kapazität. Parallel sank die Fehlerquote von über 50 auf unter 2 %. Dieser Wert wäre nicht entstanden, wenn die IT-Kapazität stattdessen in eine Eigenentwicklung geflossen wäre. 

Der verpasste Value-Add ist unsichtbar: Die Eigenlösung wird am ursprünglichen Ziel gemessen und gilt damit als Erfolg. Was mit einer durchdachten Standardlösung zusätzlich möglich gewesen wäre, taucht in keiner Bilanz auf. 

Was kostet der laufende Betrieb einer Eigenentwicklung wirklich? 

Eine erste funktionierende Version entsteht schnell. Und wer die erste digitale Checkliste in die Anwendung gebracht hat, wähnt sich schon am Ende eines erfolgreichen Projekts. Doch in Wahrheit fängt die Arbeit dann erst an: Betrieb, Pflege, Weiterentwicklung, Fehlerbehandlung, Skalierung auf weitere Bereiche. 

Was in der Vollkostenrechnung für eine Eigenentwicklung fast immer fehlt: 

1. laufender Support und Troubleshooting 

2. Weiterentwicklung bei neuen Anforderungen 

3. Ausfallabsicherung und Hosting 

4. Opportunitätskosten der gebundenen IT-Kapazität 

Eine Standardlösung bringt das ab Tag eins mit. Die Eigenentwicklung dagegen ist nie fertig, sondern ein Dauerprojekt. 

Warum ist die Pflege von Shopfloor-Software schwerer als ihre Entwicklung? 

 Arbeitsanweisungen und Checklisten sind kein statischer Inhalt. Sie müssen aktualisiert werden, sobald sich ein Produkt, eine Norm oder ein Prozess ändert. Das klingt einfach, ist es aber nicht: Jede Änderung muss von den zuständigen Fachabteilungen selbst vorgenommen werden können, ohne IT-Ticket, ohne Entwicklerkapazität. Wer das nicht von Anfang an in die Architektur einbaut, schafft einen Flaschenhals, der mit jeder Änderung teurer wird. 

Zudem stehen Eigenentwicklungen vor einem strukturellen Problem: Sie sind Nischenlösungen. Was für die Montage entwickelt wurde, passt selten für Qualitätsprüfung, Instandhaltung oder Audits. Jeder neue Bereich bringt eigene Anforderungen mit. In der Praxis baut man diese einfach obendrauf, statt einmal grundsätzlich zu klären, was die Lösung insgesamt leisten muss. 

Das Ergebnis ist eine gewachsene Sonderlösung mit steigender Komplexität und sinkender Wartbarkeit. Operations1 z.B. ist an dieser Stelle grundlegend anders aufgebaut: Die Plattform wurde von Beginn an für unterschiedliche Prozesse konzipiert, von Montage über Qualitätsprüfung bis Instandhaltung. Ein neuer Bereich ist dort ein Konfigurationsthema auf einem gemeinsamen Datenmodell, kein neues Entwicklungsprojekt. 

Dazu kommen zwei Punkte, die bei der Eigenentwicklung fast immer unterschätzt werden: 

1. Wiederverwendbare Bausteine, bei denen eine Änderung überall wirkt, müssen selbst konzipiert, entwickelt und gepflegt werden. Ohne diese Modularität pflegt man dieselbe Information x-fach. 

2. Anstelle von Maximallisten nur die relevanten Schritte pro Produktvariante anzuzeigen, ist genau der Teil, der den Werker am meisten entlastet. 

Was eine Standardlösung mitbringt, das sich nicht selbst entwickeln lässt 

Eine Eigenentwicklung löst das Problem, das der anfragende Bereich gerade formuliert. Eine Standardlösung bringt dagegen das Wissen mit, wie dieses Problem am besten gelöst wird – basierend auf der Nutzung in hunderten Unternehmen. Dieses Wissen steckt bereits im Produkt; es muss nicht erst durch eigene Fehlversuche erarbeitet werden. 

Wer schnell etwas aus der akuten Anforderung eines einzelnen Bereichs heraus entwickelt, deckt genau diese Anforderung ab, mehr nicht. Angrenzende Potenziale wie Auswertbarkeit, Wiederverwendung von Modulen, Qualifikationslogik oder Zurückschreiben ins ERP werden oft nicht gesehen. 

Dazu kommt ein Aspekt, der in der Make-or-Buy-Diskussion selten auftaucht: der Zugang zu einer Anwender-Community. Was das praktisch bedeutet, sehe ich jedes Jahr auf unserem Future Manufacturing Summit: Kunden, die dieselbe Lösung nutzen, tauschen dort ihre Erfahrungen aus, lernen voneinander und entwickeln gemeinsam Lösungsansätze für Probleme, die sie alle kennen. Wer selbst entwickelt, steht dabei allein. 

Auch der Support ist kein Nebenaspekt. Wer selbst entwickelt, übernimmt auch den Support selbst. Was das bedeutet, kann ich aus unserer eigenen Organisation beziffern: Operations1 bietet seinen Kunden persönliche Betreuung mit einer Kundenzufriedenheit von 97,1 % (Stand: August 2026). Ein solches Niveau erreicht eine interne IT-Abteilung nicht nebenbei, und das ist kein Vorwurf: Es ist schlicht nicht ihre Kernaufgabe. 

Revisionssicherheit: Warum eine Eigenentwicklung zum Audit-Risiko wird 

Wenn ein System im Audit nicht nachweisen kann, wer wann welche Version freigegeben hat, ist das ein Risiko – unabhängig davon, ob die Software gekauft oder selbst entwickelt wurde. 

Für die Eigenentwicklung bedeutet das: Mehrstufige Freigabe-Workflows (also z.B. Review durch Fachbereich, Qualität und Werksleitung) sauber abzubilden, ist aufwendig. Dazu gehört mehr als eine Freigabe-Checkbox: eindeutige Protokoll-IDs, die Verknüpfung jedes Protokolls mit der genutzten Dokumentversion und die Wiedereröffnung abgeschlossener Protokolle nur mit Pflicht-Begründung und Kennzeichnung als Revision. In der Eigenentwicklung wird dieser Teil fast immer zurückgestellt, weil er in der ersten Version nicht dringend erscheint. Im Audit ist er Pflicht. 

Das Muster, das dann folgt, ist vorhersehbar: Wo die Eigenlösung Freigaben nicht sauber führt, laufen Änderungen wieder über E-Mail und Excel. Genau der Zustand, den man abschaffen wollte, kehrt durch die Hintertür zurück. 

In einer ausgereiften Standardlösung ist diese Logik dagegen von Anfang an enthalten, weil sie von hunderten Kunden in Audits gebraucht und deshalb längst eingefordert wurde. Dieses Argument spricht klar für die Standardlösung. 

Selbst entwickeln heißt nicht Unabhängigkeit gewinnen 

Die Eigenentwicklung verschiebt die Abhängigkeit nach innen. Zwar lässt sich eine Eigenentwicklung so anlegen, dass die Fachabteilung ihre Inhalte selbst pflegt. Die funktionale Weiterentwicklung, Architekturentscheidungen und Fehlerbehebungen bleiben jedoch Aufgabe der internen IT, die diese Arbeit neben ihren übrigen Projekten leisten muss. 

Hinzu kommt ein Schlüsselpersonenrisiko: Selbst entwickelte Lösungen hängen häufig am Wissen einzelner Entwickler, deren Weggang die Wartbarkeit gefährdet. Damit eine Lösung über Jahre wartbar bleibt, braucht sie eine tragfähige Architektur, Tests und Dokumentation. Genau dieser Aufwand fehlt in vielen initialen Kalkulationen. 

Neue Anforderungen wie KI-Funktionen oder ERP-Integrationen müsste die interne IT jedes Mal selbst entwickeln, und jede dieser Funktionen wird zu einem eigenen Projekt mit eigenem Budget. Eine langfristig kohärente Weiterentwicklung, bei der jede neue Version auf eine klare Vision einzahlt, ist unter diesen Bedingungen kaum zu leisten. 

Bei einer Standardlösung ist das der Normalfall: Funktionen, die bereits für andere Kunden entwickelt wurden, stehen per Update zur Verfügung. Aus meiner eigenen Arbeit weiß ich, wie viel Aufwand dahintersteckt: Im Product-Team von Operations1 pflegen wir eine Roadmap, an der jede neue Version ausgerichtet ist. Genau diese kontinuierliche, geplante Evolution ist es, die man mitkauft. 

Was nach der ersten Version kommt: Integration, Sicherheit, Compliance 

ERP- und MES-Anbindungen produktionsreif und dauerhaft stabil zu halten, ist ein eigenes Projekt. Und neue regulatorische Anforderungen an Dokumentation und Nachweisführung müssen kontinuierlich eingearbeitet werden. Das bindet Kapazität ohne Enddatum. 

Besonders deutlich wird der Unterschied bei Informationssicherheit und Datenschutz. Die Anforderung ist für beide Seiten dieselbe: sicheres Hosting, Schutz von Produktions- und Qualitätsdaten, nachweisbare Sicherheitsstandards gegenüber Kunden und Auditoren. Der Unterschied liegt darin, wer diese Arbeit als Kerngeschäft betreibt. 

Für ein produzierendes Unternehmen ist Informationssicherheit für eine selbst entwickelte Software eine Daueraufgabe neben dem eigentlichen Geschäft: Zertifizierungen wie ISO 27001 müssen erarbeitet und in jährlichen Audits verteidigt werden, Sicherheitslücken müssen kontinuierlich überwacht und geschlossen werden, und jede neue Kundenanforderung an die Nachweisführung landet wieder bei der internen IT. 

Für einen Softwareanbieter ist genau das Kerngeschäft. Bei Operations1 haben wir diese Kompetenz im Haus aufgebaut: Die Plattform ist nach DIN EN ISO 27001 zertifiziert und wird in der Microsoft Cloud mit EU-Hosting betrieben. Dieser Sicherheitsstandard geht über das hinaus, was ein Fertigungsunternehmen für eine intern entwickelte Einzellösung wirtschaftlich sinnvoll leisten kann. 

Shopfloor-Software scheitert nicht nur an Funktionen, sondern auch an mangelnder Akzeptanz 

Eine Lösung, die Werker nicht annehmen, wird umgangen. Das Ergebnis: Der gesamte Business Case verpufft. 

Usability auf Shopfloor-Niveau entsteht nicht nebenbei, sondern ist eine eigene Disziplin. Eine Oberfläche, die jeder Werker ohne Vorkenntnisse bedient, ist das Ergebnis von UX-Expertise, Research und Testing: Beobachtung direkt am Arbeitsplatz, Auswertung, wo Werker im Prozess hängen bleiben, welche Interaktion zu viele Klicks kostet und welche Formulierung missverstanden wird. Diese Reibungen konsequent zu eliminieren, ist die Arbeit von Designern und UX-Researchern, nicht von Entwicklern. 

Hier hat eine Standardlösung einen Vorteil, den keine noch so gute interne IT ausgleichen kann: die Masse. Aus meiner Arbeit im Product-Team weiß ich, wie viel unserer UX-Qualität daraus entsteht, dass wir Verbesserungen parallel in vielen Kundenprojekten vertesten. Jede Reibung, die in einem Werk auffällt, wird für alle Kunden eliminiert. Eine Eigenentwicklung hat dagegen genau einen Testkunden: das eigene Werk. 

Dazu kommt die Frage der Kompetenz. Ein Softwareanbieter beschäftigt UX-Expertise in-house, weil sie sein Kerngeschäft ist. In einem Fertigungsunternehmen ist diese Rolle in der Regel gar nicht vorgesehen – und das ist auch völlig in Ordnung, denn dort wird anderes Know-how gebraucht. 

Bild- und Video-Unterstützung, mit der die Arbeitsvorbereitung selbst multimediale Anweisungen erstellt, ist ebenfalls Voraussetzung für Verständlichkeit und wird in der Eigenentwicklung oft nicht mitgedacht. 

Wissenssicherung: Wo Eigenentwicklungen strukturell an Grenzen stoßen 

In der Make-or-Buy-Diskussion gerne unterschätzt wird die Wissenssicherung, obwohl genau hier einer der größten Hebel gegen den Fachkräftemangel liegt. Wenn erfahrene Fachkräfte in den Ruhestand gehen, verlässt jahrzehntelang aufgebautes Montage- und Prozesswissen das Unternehmen. Rückläufige Bewerberzahlen und kürzere Betriebszugehörigkeiten verschärfen das Problem zusätzlich. Wer Kopfwissen nicht rechtzeitig externalisiert, verliert es unwiederbringlich. 

Kopfwissen wiederverwendbar zu machen gelingt nur, wenn die Hürde für die Dokumentation niedrig ist. Mit Operations1 z. B. lassen sich bestehende Anweisungen aus PDF, Word, Excel oder PowerPoint per KI automatisch in strukturierte digitale Dokumente überführen. Fotos und Videos werden direkt am Arbeitsplatz aufgenommen und in die Arbeitsschritte eingebettet: ein erfahrener Monteur zeigt einen Handgriff einmal vor der Kamera, statt ihn umständlich zu beschreiben. Und Wissen, das bei der Lösung konkreter Probleme auf dem Shopfloor entsteht, wird dokumentiert, fachlich validiert und steht beim nächsten vergleichbaren Fall per KI-Abruf zur Verfügung. 

In einer Eigenentwicklung müsste jedes dieser Werkzeuge einzeln konzipiert, entwickelt und gepflegt werden. 

Ein Beispiel aus meiner Projekterfahrung: Liebherr-Verzahntechnik hat mit Operations1 die Erfahrung von 83 altersbedingt ausscheidenden Mitarbeitenden gesichert und für die Belegschaft dokumentiert: Zusammengerechnet entspricht das rund 1.200 Berufsjahren.

Wie sieht ein fairer Vergleich zwischen Operations1 und einer Eigenentwicklung aus? 

Wie lässt sich die Entscheidung seriös durchrechnen? 

Wer die Make-or-Buy-Entscheidung intern begründen muss, braucht Zahlen – auf beiden Seiten. 

Bei der Eigenentwicklung ist die Rechnung schwieriger, als sie zunächst wirkt. Die Entwicklungskosten sind greifbar, aber die Folgekosten nicht: Wie viel IT-Kapazität bindet der laufende Betrieb dauerhaft? Was kostet die kontinuierliche Weiterentwicklung, wenn neue Anforderungen aus den Fachbereichen kommen? Und was wäre mit dieser Kapazität alternativ möglich gewesen? Wer diese Opportunitätskosten nicht einrechnet, unterschätzt die Eigenentwicklung systematisch. 

Bei einer Standardlösung ist die Rechnung transparenter. Die Lizenzkosten sind klar definiert. Der zu erwartende Nutzen lässt sich strukturiert beziffern: Stunden, die in der Dokumentationspflege gebunden sind. Onboarding-Aufwand pro neuem Mitarbeiter. Fehlerkosten durch veraltete Anweisungen. Falls Sie sich für Operations1 entscheiden, ist auch die Time-to-Value kalkulierbar: Mit einem begleiteten Onboarding-Projekt ist der erste Use Case nach 8 Wochen produktiv. 

Wer das strukturiert durchrechnen möchte: Der interaktive ROI-Rechner von Operations1 macht die relevanten Hebel für den eigenen Betrieb durchspielbar. Wer lieber erst die Lösung sieht, bevor er rechnet: Die selbstgeführte Product Tour gibt einen vollständigen Überblick, ganz ohne Verkaufsgespräch. 

FAQ: Arbeitsanweisungen und Checklisten selbst entwickeln oder kaufen? 

Was kostet es, ein Tool für digitale Arbeitsanweisungen selbst zu entwickeln? 

Die Kosten für eine erste funktionsfähige Version sind heute gering. Low-Code-Tools und KI-gestützte Entwicklung ermöglichen erste Versionen innerhalb weniger Tage. Die eigentlichen Kosten entstehen danach: laufender Betrieb, Pflege bei Prozessänderungen, Weiterentwicklung bei neuen Anforderungen, Hosting, Sicherheit und Support. Diese Folgekosten übersteigen die Initialentwicklung in der Regel deutlich und sind schwer vorherzusagen. 

Wie lange dauert es, ein Tool für Arbeitsanweisungen oder Checklisten selbst zu entwickeln? 

Eine erste funktionsfähige Version für einen einzelnen Use Case kann per Vibecoding in wenigen Stunden entwickelt werden. Eine produktionsreife Lösung mit Freigabe-Workflows, Audit-Trail und stabilen ERP-Schnittstellen erfordert typischerweise mehrere Monate Entwicklungsarbeit. Hinzu kommt, dass die Lösung nie wirklich fertig ist: Neue Anforderungen, Prozessänderungen und regulatorische Vorgaben erfordern eine kontinuierliche Weiterentwicklung. 

Welche Anforderungen werden bei der Eigenentwicklung eines Tools für Arbeitsanweisungen gerne unterschätzt? 

Revisionssichere Versionierung mit lückenlosem Audit-Trail, mehrstufige Freigabe-Workflows und stabile ERP- oder MES-Anbindungen. Diese Anforderungen erscheinen in der ersten Version nicht dringend, sind im Produktivbetrieb aber Pflicht. 

Kann ich ein Checklisten-Tool auch mit Low-Code oder KI selbst entwickeln? 

Ja, eine erste funktionsfähige Version. Low-Code-Tools und KI ermöglichen schnelle erste Versionen, sind aber generisch. Ein spezialisiertes Tool für den Shopfloor ist von Beginn an für die spezifischen Anforderungen der Fertigung ausgelegt: Variantenlogik, Qualifikationsmanagement, revisionssichere Dokumentation und Integration in bestehende Produktionssysteme. Diese Fachlogik selbst in einem Low-Code-Tool abzubilden entspricht im Ergebnis einer vollständigen Eigenentwicklung – mit allen Folgekosten, die das mit sich bringt. 

Wie funktioniert Revisionssicherheit bei digitalen Arbeitsanweisungen? 

Revisionssicherheit erfordert mehr als einen Zeitstempel. Notwendig sind eindeutige Dokumentversionen, die Verknüpfung jedes ausgeführten Reports mit der zum Zeitpunkt gültigen Dokumentversion, ein lückenloser Freigabe-Workflow mit nachvollziehbaren Freigeber-Informationen und geregelte Prozesse für die Wiedereröffnung abgeschlossener Reports. Ausgereifte Lösungen bilden diese Anforderungen out of the box ab. Bei Eigenentwicklungen wird dieser Teil häufig weggelassen und erst im Audit als Lücke sichtbar. 

Wann lohnt es sich, ein eigenes Tool für Arbeitsanweisungen selbst zu entwickeln? 

Eigenentwicklung lohnt sich, wenn alle drei folgenden Bedingungen erfüllt sind: 1) Die Anforderungen sind so spezifisch, dass keine verfügbare Lösung sie abdeckt. 2) IT-Kapazität ist dauerhaft für Betrieb und Weiterentwicklung verfügbar, nicht nur für die initiale Entwicklung. 3) Der Use Case bleibt eng begrenzt ohne Skalierungsabsicht auf weitere Bereiche oder Standorte. Trifft auch nur eine dieser Bedingungen nicht zu, überwiegen in der Regel die Folgekosten und Risiken der Eigenentwicklung. 

Was passiert mit bestehenden Word- und PDF-Dokumenten, wenn ich auf ein digitales Tool umsteige? 

Bestehende Arbeitsanweisungen aus Word, Excel, PDF oder PowerPoint müssen nicht neu erstellt werden. Ausgereifte Lösungen bieten Importfunktionen, die vorhandene Dokumente einlesen, Arbeitsschritte, Texte und Bilder erkennen und daraus editierbare digitale Anweisungen erzeugen. Bei Eigenentwicklungen ist die Migration bestehender Dokumentation ein eigenes Teilprojekt, das in der Anfangsphase selten eingeplant wird.