Entwicklung und Kauf großartiger Software für die Metallfertigung

scanrail/iStock/Getty Images Plus

Software wird für den modernen Fab Shop immer relevanter und wichtiger. Unabhängig davon, ob Sie Code intern entwickeln oder ein Tool eines Drittanbieters kaufen, ist es wichtig zu verstehen, wonach Sie suchen. Das kann schwierig sein, ohne ein tiefes Verständnis dafür zu haben, wie Software erstellt wird.

Healthcare.gov ist eine leicht zugängliche Fallstudie zu den Risiken des Softwaredesigns. Es startete vor 10 Jahren und landete sofort mit einem Knall. Es war so langsam und fehlerhaft, dass sich in der ersten Woche nur 1 % der Interessenten anmelden konnten. Das Webdesign konnte nicht die absoluten Grundlagen liefern, mit schlechten Arbeitsabläufen und fehlerhaften Benutzeroberflächen. Hinzu kam, dass den Krankenkassen auf der Website ungenaue Informationen zur Verfügung gestellt wurden, die eine korrekte Bearbeitung der Anmeldungen erschwerten oder sogar unmöglich machten.

Stresstests, die das erwartete Benutzervolumen hätten untersuchen sollen, waren völlig unzureichend. Einen Tag vor dem Start stellte sich heraus, dass die Website mit nur 1.100 gleichzeitigen Benutzern zu langsam wurde. Die erwartete Benutzerzahl lag bei 50.000 bis 60.000. Und als ob das noch nicht schlimm genug wäre, stieg die tatsächliche Anzahl gleichzeitiger Benutzer innerhalb der ersten Woche auf 250.000, mehr als das 200-fache der Anzahl von Benutzern, die die Website laut Stresstests vor der Veröffentlichung bewältigen konnte. Im Nachhinein fragt man sich, warum die Stresstests überhaupt durchgeführt wurden. Ihr offensichtliches Scheitern änderte nichts am Zeitplan für die Veröffentlichung.

Das Projekt scheiterte nicht am fehlenden Budget. Ursprünglich wurden die Kosten auf 93,7 Millionen US-Dollar geschätzt, eine erstaunliche Summe, selbst wenn das Projekt nicht über dem Budget lag. Aber die Schätzungen waren völlig falsch. Vor der Fertigstellung stiegen die Gesamtkosten auf atemberaubende 1,7 Milliarden US-Dollar, fast 20-mal höher als geschätzt.

Healthcare.gov funktioniert im Jahr 2023 großartig, aber beim Start war es vielleicht das spektakulärste, teuerste und öffentlichste Software-Fiasko in der Geschichte. Während ein Großteil der Komplexität rund um die Einführung von Healthcare.gov unvermeidbar war, können wir die verpatzte Einführung nutzen, um herauszufinden, was Softwareprojekte zum Erfolg oder Misserfolg führt. Seine Fehler könnten Aufschluss darüber geben, wie Sie Ihr eigenes internes Software-Team aufbauen könnten. Es könnte auch Aufschluss darüber geben, worauf Sie beim Kauf von Software von Drittanbietern achten sollten.

In einem früheren Artikel habe ich darüber geschrieben, wie Southwest Airlines während der Feiertage im Jahr 2022 auseinanderfiel. Kurz gesagt, das Unternehmen verließ sich auf jahrzehntealte Software, die es extrem schwierig machte, mit Flugplanunterbrechungen umzugehen. Den Arbeitern war das Problem klar, aber die Führungskräfte des Unternehmens – isoliert von den alltäglichen betrieblichen Belastungen – versäumten es jahrzehntelang, in neue Infrastruktur zu investieren. Dieser Ausfall führte zusammen mit einem Wintersturm und einer hohen saisonalen Nachfrage dazu, dass das gesamte Unternehmen lahmlegte und Zehntausende Menschen in der Weihnachtswoche festsaßen. Southwest selbst schätzt, dass die Katastrophe das Unternehmen letztendlich fast eine Milliarde US-Dollar kosten wird. Diese außerordentlichen Kosten hätten vermieden werden können, wenn die Entscheidungsträger nah genug an den betrieblichen Problemen gewesen wären, um die Dringlichkeit zu verstehen.

Die Lehre daraus ist, dass gute Software von Teams mit räumlicher Nähe entwickelt wird. Gute Nähe impliziert zwei Dinge: Erstens, dass das Softwareteam genau mit dem Problem vertraut ist, das es zu lösen versucht; Zweitens haben Entwickler Nähe zu den Ergebnissen, die ihre Software hervorbringt. Anders ausgedrückt: Ein Team mit guter Nähe versteht den Schmerz und nutzt dann sein eigenes Softwaretool, um ihn zu lindern. Wenn die Software ihr Ziel verfehlt, fehlerhaft oder schwer zu bedienen ist, sollten die Entwickler die Ersten sein, die davon erfahren.

Dies ist ein Bereich, in dem das Healthcare.gov-Projekt sicherlich gescheitert ist. Den Entwicklern war vielleicht klar, welche Probleme ihre Website lösen sollte, aber der Hauptauftragnehmer operierte von Kanada aus und nicht von den Vereinigten Staaten aus, dem Land, das Healthcare.gov bedient. Verschiedene Komponenten des gesamten Systems wurden außerdem an viele Subunternehmer vergeben, von denen keiner die vollständige Anwendung besaß. Selbst wenn die Entwickler den Schmerz verstanden hätten, den die Software lösen sollte, hätte die End-to-End-Benutzererfahrung eindeutig außerhalb der Kontrolle jedes einzelnen Softwareentwicklers gelegen.

Ein Auftragnehmer kümmerte sich beispielsweise ausschließlich um Authentifizierungssysteme. Wenn die Registrierung und Authentifizierung langsam oder fehlerhaft waren (und das waren sie), wessen Fehler war es? Die User-Experience-Designer? Die Datenbank? Die Ingenieure, die sich um die Serverinfrastruktur kümmern? Die Webanwendungsentwickler? Oder alle zusammen? Jede einzelne Untergruppe könnte sich in einem anderen Unternehmen befunden haben. Es wäre schwierig gewesen, das Kernproblem herauszufinden, es zu kommunizieren und eine Lösung in die Produktion zu bringen, selbst wenn das Problem gut verstanden worden wäre.

Für einen Hersteller sollte das alles nicht überraschend sein. Nähe ist nur eine andere Art zu sagen: Geh zur Gemba. In mancher Hinsicht unterscheidet sich die Softwareentwicklung nicht wesentlich von der kontinuierlichen Verbesserung in der Fertigung.

Stellen Sie sich vor, Sie hätten die Aufgabe, in einer Branche, die Ihr Unternehmen noch nie zuvor bedient hat, eine neue Fertigungslinie mit neuer Ausrüstung von Grund auf aufzubauen. Sie haben ein riesiges Budget, also sollten Sie in der Lage sein, es zum Laufen zu bringen. Aber es gibt einen großen Vorbehalt: Sie haben nur einen Versuch, um alles perfekt zu machen. Von Anfang an müssen Sie die Ausrüstung, das Fabriklayout und die Anzahl der Personen auswählen; wie ihre Ausbildung aussieht und wie sie ausgebildet werden; und wie viele unfertige und fertige Waren Sie vorrätig halten müssen. Sobald Sie mit der Planung fertig sind, sind Sie fixiert. Sie können das Design nicht mehr ändern.

Was wäre das für ein Projekt. Es ist nicht nur unmöglich, die Probleme und Ineffizienzen in einer neuen Branche im Voraus vorherzusagen, sondern der gesamte Designprozess – alles im Voraus, ohne Änderungen – steht im Widerspruch zum PDCA-Zyklus (Plan, Do, Check, Act) der Hersteller habe gelernt, kontinuierlich anzuwenden. Es würde keinen Sinn machen, die Fertigung auf diese Weise anzugehen.

Für Software macht es auch keinen Sinn, aber genau so wurde Healthcare.gov entwickelt. Das gesamte System wurde im Voraus von einem Ausschuss in einem monatelangen Prozess entworfen. Anschließend wurden sorgfältig ausgearbeitete Gantt-Diagramme erstellt, die zeigten, wie lange die Entwicklung jedes Elements dauern würde, und die schließlich in den endgültigen Tests und der Veröffentlichung gipfelten. Aber wie jeder Hersteller vermuten kann, sind Zeitpläne unmöglich vorherzusagen und noch schwieriger ist es, sie einzuhalten.

In der Fertigung orientiert sich der kontinuierliche Verbesserungsprozess häufig am PDCA-Zyklus. Wir planen eine Produktionsumstellung, die als Experiment angelegt ist; Anschließend implementieren wir die Änderung, um das Experiment durchzuführen. Aber wir hören hier nicht auf. Sobald eine Änderung vorgenommen wird, überprüfen wir das Ergebnis, um sicherzustellen, dass sie den gewünschten Effekt erzielt hat. Schließlich reagieren wir auf der Grundlage dieser Informationen und passen unsere Pläne auf der Grundlage der gewonnenen Erkenntnisse an.

Dieser Prozess ist iterativ und soll kontinuierlich und konsistent angewendet werden. Dies könnte nicht unterschiedlicher sein als ein Wasserfall-Softwareentwicklungsprozess, bei dem das gesamte Projekt im Voraus in einem Hunderte von Seiten langen Spezifikationsdokument entworfen wird. Stattdessen würde PDCA relativ kleine Softwareänderungen erfordern, die schnell vorgenommen und dann bereitgestellt und vollständig getestet werden, bevor mit dem nächsten Schritt fortgefahren wird. Healthcare.gov wurde erst wenige Tage vor der Veröffentlichung vollständig getestet, sodass vor der Veröffentlichung keine Änderungen mehr möglich waren.

Zwei der einflussreichsten Softwarekreationen der Welt, Git und Linux, wurden ursprünglich von einem brillanten Entwickler erstellt: Linus Torvalds. Git ist ein Versionskontrollsystem, das von praktisch jedem Softwareteam intensiv genutzt wird, und Linux ist ein Computerbetriebssystem. Die Chancen stehen gut, dass der Großteil der von Ihnen verwendeten Software mit Hilfe von Git entwickelt wurde. Und wenn Sie eine moderne CNC-Ausrüstung besitzen, wird diese wahrscheinlich von Linux unter der Haube betrieben.

Nachdem Torvalds den Stein ins Rollen gebracht hatte, haben viele andere zu diesen beiden Tools beigetragen (und tragen weiterhin dazu bei). Dennoch ist es für mich faszinierend, dass ein einziger brillanter Visionär eine so große Wirkung haben kann. Torvalds verstand den Bedarf, stellte sich die Lösung vor und setzte sie um.

Es liegt auf der Hand, dass es umso schwieriger ist, ein System zu entwerfen, das ein Problem perfekt löst, je mehr Stakeholder es gibt und je höher die Softwarekomplexität ist. Denken Sie noch einmal an Healthcare.gov. In jeder Hinsicht war das Projekt unglaublich kompliziert. Es wird geschätzt, dass mindestens 47 verschiedene private Auftragnehmer daran gearbeitet haben. Die Tatsache, dass es sich bei 47 um eine Schätzung handelt, ist bezeichnend – niemand weiß überhaupt, wie viele Unternehmen beim Schreiben des Systems mitgeholfen haben! Unternehmen, die daran gearbeitet haben, wurde grobe Inkompetenz und Korruption vorgeworfen. Und die Gesamtbemühungen wurden von einer Regierungsbehörde koordiniert, die keinerlei Erfahrung in der Softwareentwicklung hatte, ganz zu schweigen von einem Projekt dieser Größe.

Vergleichen Sie das mit Torvalds‘ Entwicklung von Linux und Git. Sie könnten unterschiedlicher nicht sein. Am einen Ende des Spektrums haben wir einen brillanten Mann mit einer Vision, der ein klares Problem zu funktionalen Nullkosten löst. Auf der anderen Seite haben wir Software, die von einem Komitee entwickelt wurde, an dem Tausende von Beteiligten beteiligt sind, mit scheinbar unbegrenztem Budget, die von mindestens 47 Unternehmen implementiert wird, die zusammen Hunderte von Mitarbeitern beschäftigen, und die alle von einer Regierungsorganisation ohne Erfahrung in der Softwareentwicklung verwaltet werden.

Fairerweise muss man sagen, dass das Schreiben der Grundlagen von Linux ein ganz anderes Projekt war. Linux ist nicht einfach, aber es ist auf eine quantifizierbarere Art und Weise kompliziert, als es das Katzenhüterprojekt Healthcare.gov gewesen sein muss. Ich beneide die Manager und Ingenieure nicht, die dafür sorgen mussten, dass es funktioniert.

Die Lehre daraus ist, dass ein Projekt mit größerer Wahrscheinlichkeit erfolgreich sein wird, wenn es von einem kleinen Team intelligenter und fokussierter Menschen umgesetzt werden kann, die das Problem genau verstehen, eine klare Vorstellung von der Lösung haben und schnell iterieren können. Wenn Ihr Unternehmen Software intern entwickelt, kann und sollte diese Lektion auf Ihre eigenen Entwicklungsteams angewendet werden. Aber die interne Softwareentwicklung ist eine große Verpflichtung, die möglicherweise nicht immer sinnvoll ist.

Für diejenigen, die Software kaufen, ist möglicherweise nicht so sofort ersichtlich, wie die Software entwickelt wurde. Aber es gibt Anzeichen. Softwareanbieter, die speziell Ihre Branche bedienen (d. h. Metallhersteller), verfügen wahrscheinlich eher über eine Lösung, die Ihren Anforderungen entspricht, da sie den Umfang einschränken und eine gute Nähe aufrechterhalten können. Wenn alle anderen Faktoren gleich bleiben, wird Software wahrscheinlich nicht so gut passen, wenn sie für Zehntausende von Unternehmen in allen Branchen konzipiert ist.

Sie könnten auch untersuchen, wie oft Software-Updates veröffentlicht werden und wie Entwickler Benutzer-Feedback erhalten und darauf reagieren. Die Art und Weise, wie ein Softwareteam mit Kunden in Kontakt tritt, kann einen großen Einfluss auf den Wert der Software für Ihr Unternehmen haben.

Ob Sie bauen oder kaufen, Software ist ein unverzichtbarer Bestandteil des modernen Fab Shops. Es ermöglicht eine unglaubliche Effizienz und eine verbesserte Lebensqualität. Aber die Vergangenheit ist voller unvorstellbar teurer Software-Katastrophen wie Healthcare.gov. Es kann schwierig sein, sich in dieser Realität zurechtzufinden, aber Sie werden einen Schritt voraus sein, wenn Sie Software bevorzugen, die von Herstellern für Hersteller entwickelt wurde, mit relativ kleinen Teams, die Änderungen schnell vornehmen und persönlich testen.