qembu workplace: Eine Erfolgsgeschichte mit Hindernissen - Teil 1

Und plötzlich entsteht in dieser Firma das Software-Produkt „qembu“, das auf Anhieb am Markt auf grosses Interesse stösst. Wie kann das und kann das überhaupt funktionieren?

In diesem Beitrag zeige ich auf, wie qembu entstanden ist. Im zweiten Teil erfahren Sie mehr über die Hindernisse und wie wir diese überwinden konnten.

Warum ist das Projektgeschäft so anders als das Produktgeschäft?

Im Projektgeschäft steht ein firmenspezifisches Problem im Zentrum. Alles dreht sich um eine neu zu entwickelnde, maßgeschneiderte und wirtschaftliche Lösung. Beim Produktgeschäft sieht das anders aus. Hier geht es um eine möglichst gute Lösung für ähnlich gelagerte Problemstellungen, die für ein angenommenes Zielsegment, den künftigen Usern des Produktes, ein Bedürfnis darstellt.
Wesentlich ist dabei auch, dass beim Projekt der Kunde und somit auch der Benutzer persönlich bekannt ist, was beim Produkt ja nicht der Fall sein kann. Diese zwei wesentlichen Unterschiede erfordern eine komplett andere Vermarktung. Beim Projektgeschäft ist das Verkaufsteam zeitlich vor der Entwicklung und Umsetzung der Lösung gefordert, beim Produktgeschäft hingegen mit oder erst nach der Entwicklung der Lösung. Die Vermarktung der jeweiligen Lösung gestaltet sich also komplett unterschiedlich.

Auch hinsichtlich der finanziellen Aspekte gibt es grosse Unterschiede. Beim Produkt ist im Gegensatz zum Projekt eine (Vor-)Investition notwendig, die sich erst nach einer erfolgreichen Lancierung rechnen lässt (ROI). Risiken und Gefahren eines Verlustgeschäfts stehen einem potenziell höheren Gewinn bei Markterfolg gegenüber.

Es liessen sich noch weitere Unterschiede aufführen. Fürs erste soll das aber genügen.

Wie kann in einer projektorientierten Softwarefirma ein Produkt entstehen?
Durch die zahlreichen Einführungsprojekte bei Grosskunden bzgl. Microsoft Teams und Office 365 entwickelte sich in der Nexplore eine Sicht auf immer wieder vergleichbare, ähnliche Problemstellungen. Wiederholt tauchten ähnliche Anforderungen auf:

• Einhaltung von internen Richtlinien bezüglich Governance-Themen

• Übersichtlicher zentraler Einstieg in Office 365

• Einheitliche Erstellung von Arbeitsräumen in Microsoft Teams

Diese Probleme wurden für jedes Projekt und jeden Kunden firmenspezifisch gelöst. Diese Anforderungen erforderten die Entwicklung eines Produktes, das die festgestellten Lücken schliessen konnte. Ohne vorgängig lange darüber zu diskutieren, entwickelten wir das Teams Ad-Inn „qembu workplace“. Dabei haben wir auf die Erstellung eines wochenlang diskutierten Business Case verzichtet und uns viel mehr einfach auf die Implementation konzentriert. Dass wir das ohne grosse Strategie-Diskussionen getan haben, hat mit unserer neuen Organisationsform Holacracy zu tun, (siehe dazu meine Blog-Beiträge rund um Holocracy)

Die vielfältigen Erfahrungen aus zahlreichen Einführungsprojekten mit Teams und O365 war eine perfekte Ausgangslage für die Realisierung eines Produkts. Wir wussten aus eigenen Erfahrungen sehr genau, welche Lücken in Office 365 Teams zu schliessen waren und auf was die Kunden insgeheim warteten. Es war klar, was wir umsetzen mussten, um bei unseren Kunden einen grossen Nutzen stiften zu können. Kaum war das Produkt in einer Beta Version vorhanden, konnten wir auch schon einen ersten Erfolg verbuchen: „qembu workplace“ wurde im 2018 als Finalist an der European SharePoint Conference in der Kategorie „Best Office 365 Add-In“ nominiert.
Alles schön und gut. Wir hatten nun unsere Beta Version „qembu workplace“, das offensichtlich aktuellen Marktbedürfnissen entsprach. Wie weiter?