Sollen wir kaufen oder sollen wir bauen? Als Leiter eines internen Softwareentwicklungsteams an einem akademischen medizinischen Zentrum ist dies eine der häufigsten Fragen, mit denen wir konfrontiert sind. Aufgrund der langfristigen Auswirkungen unserer Entscheidung ist diese Frage auch am schwierigsten zu beantworten.
Ich werde hier ein wenig darüber sprechen, wie wir Kauf- vs. Build-Entscheidungen angehen, und dann einige der Schlüsselfaktoren für den erfolgreichen Aufbau und Support intern entwickelter Softwarelösungen diskutieren.
Die Entscheidung, zu kaufen oder zu bauen
Der wichtigste Faktor bei dieser Entscheidung sind die Verfügbarkeit, Eignung und Kosten der kommerziell angebotenen Produkte. Unsere Entscheidung fällt am einfachsten, wenn es ein im Handel erhältliches Produkt gibt, das unseren spezifischen Anforderungen entspricht und zu einem Preis erhältlich ist, den wir für angemessen halten, insbesondere im Vergleich zu den gesamten Lebenszykluskosten für die interne Entwicklung einer Alternative.
Noch besser ist es, wenn das Produkt von einem unserer wichtigsten Softwarepartner entwickelt wurde, beispielsweise von unseren bestehenden EHR- oder ERP-Anbietern. In dieser Situation profitieren wir von der Zusammenarbeit mit einem vertrauenswürdigen Partner, und die Lösung wird sich wahrscheinlich reibungslos in unsere bestehenden Arbeitsabläufe integrieren lassen.
Aber oft ist unsere Entscheidung nicht so einfach. Je einzigartiger unsere Bedürfnisse sind, desto wahrscheinlicher ist es, dass eine kommerzielle Lösung diese Bedürfnisse nicht erfüllen wird.
Beispielsweise stehen uns für die Patientenversorgungsaspekte unserer Arbeit tendenziell mehr kommerzielle Produkte zur Verfügung als die Angebote, die unserer medizinischen Fakultät dienen könnten. In Situationen, in denen es kein kommerziell erhältliches Produkt gibt, kommt es auf die Entscheidung „Bauen oder nicht bauen“ an, bei der wir auf der Grundlage der Bewertung des ROI der Anstrengung entscheiden, ob wir fortfahren oder nicht.
In Situationen, in denen es kommerziell erhältliche Produkte gibt, erstellen wir häufig eine Ausschreibung und bewerten die Produkte des Anbieters, ihre Funktionen und ihre Kosten im Vergleich zu einer intern entwickelten Option.
Innen bauen – was nun?
Wir haben unsere Möglichkeiten geprüft und sind zu dem Schluss gekommen, dass der beste Ansatz darin besteht, eine benutzerdefinierte Anwendung zu erstellen und zu warten. Offensichtlich haben wir noch viel Arbeit vor uns, um eine benutzerdefinierte Anwendung zu entwickeln, vor allem die klassische Arbeit mit Anforderungen, Design, Build und Test. Was jedoch oft nicht gewürdigt wird, ist der Umfang an nichttechnischer Arbeit, der erforderlich ist, um eine benutzerdefinierte Anwendung während ihres gesamten Lebenszyklus zu erstellen und zu unterstützen.
Wenn Sie ein Anbieterprodukt kaufen, erwerben Sie mehr als nur Software. Kommerzielle Anbieter aktualisieren ihre Produkte kontinuierlich. Dabei müssen sie entscheiden, welche neuen Funktionen zur Verbesserung des Produkts eingeführt werden sollen. Auch wenn die Kunden mit diesen Entscheidungen möglicherweise nicht einverstanden sind, ist dies eine Arbeit, die nicht intern erledigt werden muss. Wenn eine Lösung intern entwickelt wird, muss jemand die Produktmanagementfunktion übernehmen und entscheiden, was als nächstes aus einer immer länger werdenden Liste von „Wunschlisten“-Elementen der internen Benutzergemeinschaft entwickelt werden soll.
Dies sind drei der Bereiche, auf die wir uns konzentrieren, um den Erfolg sicherzustellen:
Produktmanagement-Partnerschaft zwischen dem operativen Bereich und dem Softwareentwicklungsteam. Wenn wir eine benutzerdefinierte Anwendung erstellen, liegt das in der Regel daran, dass unser Unternehmen einzigartige Anforderungen hat, die mit kommerziellen Produkten nicht erfüllt werden können. Um erfolgreich zu sein, brauchen wir also einen operativen oder klinischen Leiter, der die Geschäftsanforderungen vermitteln und Prioritäten für unsere Arbeit festlegen kann. Wenn uns ein solcher Partner fehlte, waren unsere Softwareentwicklungsbemühungen weniger erfolgreich, da es für ein Softwareteam schwierig ist, die Grundlagen dessen zu verstehen, was es operativ benötigt. Auf Seiten des Entwicklungsteams können unsere Softwareproduktbesitzer zu diesem Prozess beitragen, aber es gibt keinen Ersatz für einen engagierten, kreativen Betriebspartner.
Ein Team für den gesamten Lebenszyklus des Produkts vor Ort haben. Nach der ersten Lieferung einer individuell entwickelten Lösung müssen wir das technische Personal verpflichten, das Produkt zu verbessern, Fehler zu beheben und den Endbenutzern technischen Support zu bieten. Aber genauso wichtig ist das langfristige Engagement unseres operativen Partners, das Produkt weiterhin in die richtige Richtung zu lenken. Ohne dieses Engagement können unsere internen Produkte scheitern und an Akzeptanz verlieren, weil sich das Produkt nicht weiterentwickelt, um den sich ändernden Bedürfnissen der Benutzer gerecht zu werden. Zu unserem Produktmanagementteam gehören idealerweise Teilnehmer unserer täglichen Benutzer sowie unserer Analyse- und Schulungsgemeinschaften.
Planung einer Technologieaktualisierung. Einige der von uns erstellten Anwendungen haben einen kurzen Lebenszyklus von mehreren Jahren, um einen kurzfristigen Bedarf zu decken (z. B. als Reaktion auf die COVID-Pandemie) oder um eine Lücke zu schließen, bis ein geeignetes kommerzielles Produkt verfügbar ist. Im anderen Extrem haben wir eine Reihe von Anwendungen entwickelt, die seit über 20 Jahren in Produktion sind. Für diese langlebigen Anwendungen müssen wir Erwartungen festlegen und regelmäßig Ressourcen zuweisen, um unsere Anwendungen umzugestalten und zu modernisieren, damit sie weiterhin ordnungsgemäß funktionieren.
Wenn kommerzielle Softwarelösungen nicht verfügbar sind oder nicht gut passen, kann maßgeschneiderte Software Unternehmen dabei helfen, ihre individuellen Anforderungen zu erfüllen. Erhöhen Sie Ihre Chancen auf langfristigen Erfolg, indem Sie von Anfang an das richtige Team und die richtigen Partnerschaften aufbauen.
Glenn Fala ist Associate CIO für Softwareentwicklung bei Penn Medicine.
