Solution Factory – In 9 Wochen von der Idee zum Produkt

1 Kommentar

Digitalisierung revolutioniert jedes Business und das schon seit über einer Dekade. Dieser andauernde Trend wird auch Ihr Business-Modell nicht unberührt lassen und hat einiges zu bieten. Es gibt zahlreiche Beispiele, wie und wo eine digitale Transformation helfen kann. – Ein neues Kundenportal, um die herausfordernden Anforderungen des Kunden zu bedienen, oder gleich komplett neue Zielgruppen anzusprechen. Alternativ helfen innovative Software-Lösungen beim Ersetzen von manuellen und zeitkonsumierenden, oftmals auch fehleranfälligen Prozessen. Sie helfen auch beim Erzeugen einer modernen Datenanalyse-Plattform, um “state of the art” künstliche Intelligenz auf die wertvolle Ressource Daten anzuwenden. Die Möglichkeiten sind unendlich und vielfältig. Aber so einfach es zunächst klingen mag, sehr oft gibt es Abhängigkeiten in der Organisation oder anderen Bereichen, die es einfach nicht ermöglichen ein neues Experiment zu starten. Besonders für die kleinen und mittleren Unternehmen ist es oft riskant, wenn nicht sogar unmöglich, ein neues Entwicklungsteam mit den benötigten Erfahrungen auf die Beine zu stellen. Wenn doch, dann bedarf es vieler Zyklen an Planung, Entwicklung, Testen und Messen bevor überhaupt ein Kunde die Anwendung zu Gesicht bekommt.

Die so entstehende Verzögerung des echten Kundenfeedbacks führt mit einer hohen Wahrscheinlichkeit dazu, dass das Produkt fehlschlägt. Denn nur zeitnahes Feedback verhindert Missverständnisse des zu lösenden Problems oder Fehlinterpretationen der Anforderungen.

Entwicklung einer kundenzentrischen Software, schnell und verlässlich

Solution Factory ist ein kundenzentrierter, schneller und verlässlicher Ansatz, um neue Ideen zu verproben und innovative zukunftsweisende Lösungen durchzuführen. Die Idee und die User Experience stehen im Mittelpunkt dieses Vorgehens. Sie sind die maßgeblichen Faktoren anhand derer der Erfolg des Projekts evaluiert wird. In enger Zusammenarbeit mit den Domain-Experten und dem Endbenutzer wird der Kunde durch die gesamte Reise der Problemeingrenzung geführt – durch das Bauen eines Minimal Viable Product (MVP), das sich bis hin zu einem vollständigen Produkt entwickeln läßt. Solution Factory setzt sich aus drei Phasen zusammen: Design Sprint, MVP Development und Solution Development.

Design Sprint

Das Konzept des Design Sprints basiert auf der Lean-Startup-Methodik. Diese erlaubt es uns, disruptive Geschäftsmodelle zu designen während gleichzeitig die Risiken berücksichtigt werden. Wir definieren eine neue Geschäftshypothese (idea) und übersetzen (build) diese in Code. Dann wird diese Hypothese gemessen (measure) und die Ergebnisse analysiert (data). Daraus entwickeln sich neue Ideen, die wir im Nachgang optimieren (learn). Hierdurch ist es möglich, den Benutzer besser zu verstehen und ihn somit in den Prozess für neue Hypothesen zu integrieren. Daraus bildet sich eine Beweiskette von Möglichkeiten die funktionieren, und Möglichkeiten die nicht funktionieren. Durch iteratives Vorgehen können neue Ideen schnell getestet und schlechte Ideen schneller verworfen werden, ohne den Verlust von Endkunden oder Budget.

Mit neuen Produkten hat man aber ein sogenanntes “Henne-Ei-Problem”, oder auch “Kausalitäts-Dilemma”: Ohne eine “theoretische” Lösung können wir keine Daten sammeln und ohne Daten keine neue Hypothese aufstellen. Der Design-Sprint-Ansatz versucht hier einen Kurzschluss. Endkunde, Domain-Experte und Stakeholder werden zusammen gebracht, um gemeinsam ein klares Bild des Problems zu definieren. Auf dieser Basis wird der Prototyp der Lösung skizziert, um direkt vom Endkunden zu lernen, bevor auch nur eine einzige Zeile Code geschrieben wurde. 

Um es in der Sprache des “Lean-Software-Development” auszudrücken: Es wird direkt aus der Geschäftshypothese gelernt, ohne viele Daten zu sammeln.

MVP Development

Die MVP-Entwicklung startet direkt nach dem Design Sprint. Sie besteht aus sechs Software-Entwicklungs-Sprints, ein Sprint pro Woche. Jeder Sprint startet montags und endet freitags mit einer Sprint Review, bei der die Sprint-Ergebnisse (Features) gezeigt werden und der nächste Sprint geplant werden kann. Nach sechs Sprints ist diese Phase beendet, und das Produkt, ein MVP, wird an den Kunden übergeben. Das MVP ist eine funktionierende Anwendung, welche die Schlüsselaspekte der Ziellösung bereits abbildet und durch den Endkunden genutzt werden kann. Es folgen zwei Wochen Entwicklungspause während der das MVP durch den Benutzer getestet werden kann. 

In dieser Phase stehen alle Entscheidungswege offen. Der Kunde kann an dieser Stelle entscheiden, ob aus dem MVP ein Produkt entwickelt wird, oder ob die Hypothesen nochmal überarbeitet werden müssen.

Solution Development

Die Solution-Development-Phase schließt an das MVP an. Hier wird aus dem MVP ein Produkt gebaut, das letztendlich so auch in Produktion läuft. 

In dieser Phase ist es das Hauptaugenmerk, festzustellen, welche Funktionalitäten im MVP fehlen, um es zu dem gewünschten Ziel zu bringen. Noch während der Entwicklung des MVPs war das Ziel, dem Endkunden ein minimales Set an Inhalten zum Experimentieren zur Verfügung zu stellen. Um dieses Ziel zu erreichen, ist es notwendig, ein gesundes Maß an technischen Schulden aufzubauen. Während der Solution-Development-Phase werden diese technischen Schulden iterativ abgebaut, so das aus dem MVP eine produktionsfähige Lösung entsteht.

Success Story

Unserer Erfahrung nach ist Solution Factory eines der effektivsten Modelle, um neue Projekte und Produkte anzustoßen. Experimentieren mit neuen Ideen – mit einem Minimum an Risiko und einem Maximum an Kundenzufriedenheit. Im Folgenden erläutern wir beispielhaft, wie Solution Factory geholfen hat, ein immanentes Problem im internen Kunden-Onboarding-Prozess unseres Kunden zu lösen.

Das Problem

Unser Kunde, einer der größten in seinem Sektor in Deutschland, ist gesetzlich dazu verpflichtet, einen komplexen Onboarding-Prozess für seine neuen Kunden zu durchlaufen: Zahlreiche Informationen müssen gesammelt, unterschiedliche rechtliche Aspekte beachtet und Verträge unterzeichnet werden, und das zwischen unterschiedlichen Dienstleistern. Der Prozess verteilt sich über viele teilnehmenden Partner und benötigt teilweise Wochen, bevor er abgeschlossen werden kann. 

Um all diese Komplikationen zu bewältigen, waren viele manuelle Schritte im direkten Kontakt mit den Kunden notwendig. Ein Mitarbeiter musste dabei kontinuierlich betreuen, alle Schritte mit durchlaufen, den andauernden Prozessablauf sicherstellen und die Kunden an die Berichtigung von fehlenden Informationen oder an nahende Fristen erinnern. Auf der einen Seite erhöhte dieser manuelle Prozess die Aufwände bei unserem Kunden erheblich, zum anderen verschlechterte sich aufgrund dieses Prozesses die Kommunikation mit dem Endkunden und führte oft zu Verwirrungen, erhöhte die Fehlerrate, verzögerte den Prozess und schadete so der Kundenzufriedenheit.

Die Lösung

Zuerst wurde eine Gruppe aus Design Sprint Coaches, einem User-Experience-Experten, einem User Interface (UI) Designer und einem Software- und Cloud-Architekten gegründet. Seitens des Kunden wurden sowohl ein technischer Experte als auch ein repräsentativer Endbenutzer in das Projekt involviert.  Alle Beteiligten trafen sich für den Design Sprint in unserem Office in Karlsruhe getroffen.

Der Montag diente dem Ziel, die Kundendomäne und das eigentliche Problem zu verstehen. Die Domänenexperten durften die aktuelle Situation beschreiben und ihre Sicht auf die aktuell größten Schwierigkeiten darstellen. Das gesamte Team partizipierte aktiv bei dieser Diskussion, indem Fragen gestellt und weitere Punkte gesammelt wurden. Das Ergebnis wurde anschließend gruppiert und formalisiert in eine eindeutige Beschreibung des Problems gefasst. Dieses definierte das Ziel des Design Sprints. Die Zusammenarbeit am Montag zeigte sich als sehr wertvoll für das gesamte Team, da es den Scope des Design Sprints klar definierte und half, eine gemeinsame Sprache zwischen Domänen- und IT-Experten zu finden. 

Nachdem das Problem identifiziert war, wurde der Dienstag der Lösungsfindung gewidmet. Jeder Teilnehmer wurde nach seinen Ideen befragt und sollte skizzieren, wie eine mögliche Lösung aussehen könnte. Am Ende des Tages wurden die Skizzen dem Team präsentiert, um potentielle Diskussionen in den nächsten Tag zu schieben. Am Mittwoch und Donnerstag wurden die Skizzen evaluiert und die Ideen, die dahinter standen, in einem finalen Lösungsansatz zusammengefasst. Diese Idee wurde dann in einen “Click-Dummy-Prototypen” umgesetzt, welcher die komplette User Journey ohne wirkliche Implementierung nachahmte. 

Der Freitag war der letzte und der aufregendste Tag dieser intensiven Woche aus Know-How-Transfer, Diskussionen und Ideengenerierung. Obwohl wir jetzt eine Vorstellung hatten, wie das Produkt aussehen kann, gab es keine Garantie, dass es den echten Anforderungen des Endkunden gerecht werden würde. Es war immer noch unklar, ob das eigentliche Problem damit gelöst wird. Daher wurden am Freitag fünf separate Interviews mit der Zielgruppe des Produktes organisiert. Diese waren sich der Ausgangssituation durchaus bewusst und durften die Lösung zum ersten mal sehen. Jedes Interview dauerte zwischen 45 und 60 Minuten. Am Ende wurde der Interviewte gebeten, das Erlebte in Summe zu bewerten. 

Auf einer Skala von 1 bis 10 erreichte der Prototyp einen Durchschnitt von 8,5. Interessanterweise fragten alle Interviewten, wann denn das Produkt zur Verfügung stehen würde. Dies war eindeutig ein Zeichen des Erfolgs und gab grünes Licht für die nächste Phase.

Resultat

Ein Kunden-Management-Portal ist konzipiert. Es bildet den kompletten Onboarding-Prozess für neue Kunden ab und ermöglicht es den Kunden, ihre Produkte jederzeit selber zu pflegen, ohne irgendeine weitere manuelle Interaktion. Der Benutzer kann neue Verträge anlegen, bereits existierende im Prozessverlauf verfolgen und die nächsten Schritte überwachen. Das Portal verfolgt alle Verträge und führt den Kunden durch alle notwendigen Schritte. Automatische Erinnerungen stellen sicher, dass keine Termine verpasst oder übersehen werden. 

Während der folgenden sechs Wochen nach dem Design Sprint wurde das MVP in den Räumen der codecentric AG in enger Zusammenarbeit mit den Domänen-Experten des Kunden entwickelt. Das MVP wurde anschließend evaluiert und ist in den folgenden 12 Monaten bis hin zur endgültigen Lösung weiterentwickelt worden. 

Das Entwicklungsteam bestand aus einem Architekten aus Karlsruhe zusammen mit zwei Full-Stack-Entwicklern aus dem codecentric Büro in Banja Luka (Bosnien) und einem Designer vom codecentric-Partner UX&I aus Düsseldorf. 

Für ein optimales Team Building waren die Kollegen aus Bosnien in den ersten drei Wochen der MVP-Entwicklung in Karlsruhe und anschließend remote am Projekt beteiligt. Sie waren während des Projektes in konstantem Kontakt und  durch Ad-hoc-Kommunikation und reguläre Meetings immer mit dem Rest des Teams synchronisiert. Trotz der Verteilung im Team wurde eine hohe Geschwindigkeit und Effizienz erreicht. Dank der Cloud-Native- und Serverless-Architektur mit einer Continuous Delivery Pipeline war es möglich, die Stakeholder eng in den Entwicklungsprozess zu involvieren und kurze Feedback-Zyklen zu etablieren. Auch die Infrastrukturkosten wurden dank dieses Vorgehens deutlich reduziert.

Fazit

Klassische Software-Entwicklung ist oft langsam, im Sinne von Kundenfeedback und Adaption an das Feedback. Das erhöht das Risiko und die Kosten von konventionellen Vorgehen deutlich, wenn mit neuen Ideen und Hypothesen experimentiert werden soll. 

Solution Factory offeriert hier einen neuen Ansatz: die Entwicklung von Kunden-zentrischen Software-Produkten.
Es gibt disruptiven Innovationen in einer Organisation Platz sich zu entfalten, bei Minimierung des Risikos, der Kosten und einer erhöhten Feedbackschleife. Wenn Sie mehr über die Konzepte der Solution Factory wissen wollen und wie es Ihnen helfen kann, neue Hypothesen zu validieren, melden Sie sich bei uns.

Avatar

Mahdi Ebrahimi is an IT consultant at codecentric AG in Karlsruhe. His main focus is designing and implementing cloud-native, resilient, and scalable distributed systems.

Achim Nierbeck

Achim Nierbeck ist Solution Architect & Niederlassungsleiter bei der codecentric AG in Karlsruhe. Er hat 20 Jahre Erfahrung im Java-Enterprise- Umfeld. Die letzten Jahre lag der Fokus vor allem auf Big- und Fast-Data Architekturen.
In seiner Freizeit beschäftigt sich der Apache Member unter anderem mit dem OSGi Server Apache Karaf, bzw. dem OSGi Web-Container Pax Web.

Kommentare

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.