Verzögerungen durch… Innovation.

Etwas was mich seit jeher an Start-Ups faszinierte ist, dass man immer wieder Learnings macht, die man nicht erwartet hätte. Nun könnte man meinen, dass positive Learnings auch automatisch positive Resultate und vice versa mitbringen. Leider ist das nicht zwingend so. Ein Beispiel.

 (Lesedauer 3 Minuten)

Produkt vs Research & Engineering

In Parashift gibt es grundsätzlich zwei Phalanxen. Eine Research & Engineering–Front und eine Business-Front. Die letzten 12 Monate haben wir damit verbracht, Erkenntnisse aus unserem R&D so in eine Infrastruktur zu giessen, damit wir a) Research & Engineering effizienter und schneller betreiben können und b) dass wir basierend darauf Produkte für den Markt bauen können. Diese Produkte helfen, das Geld zur Verfügung zu haben wiederum ins R&D zu investieren.

Bei den Produkten gibt es wiederum zwei Stränge: APIs für Softwareanbieter (wie z. Bsp. ERP Systeme etc) die autonome Dokumentverarbeitung in ihre Systeme einbauen möchten und die Parashift Platform; eine Art vollautomatisches DMS für Buchhaltungsbelege das auf die Bedürfnisse von mittelgrossen Unternehmen zugeschnitten ist.

Dabei fokussieren wir uns auf die 100% korrekte Auslieferung der Dokumentinformationen. Das können wir erbringen, weil wir zum einen super-hohe Extraktionsraten haben und den fehlenden Teil an Informationen durch unser Operation-Team nacharbeiten – einer der Schlüssel-Treiber unseres schnellen maschinellen Lernens (wir werden zu gegebener Zeit einen wirklich detaillierten technischen Break-Down dazu geben).

«100% Extraction API»

Wir konnten damit erste Kunden gewinnen und bekommen bereits zahlreiche Anfragen. Hinter jeder dieser Anfrage steht ein eigenes Softwareprojekt und ein komplizierter Entscheidungsbaum beim Kunden – entsprechend lange sind die Sales-Cycles. Meist spielt zudem auch eine politische Komponenten mit rein, da auch ein zumindest teilweiser Strategiewechsel angegangen werden muss.

Was ich persönlich unterschätzt habe ist, dass auch für die Resultate wie sie die Maschine generiert, ein grosses Interesse besteht. Ich war so auf die 100%- und schlussendliche autonome Verarbeitung fokussiert (weil diese im Grunde genommen der wirkliche Game-Changer ist), dass ich blind für diese Nachfrage war. Ziemlich dumm.

«Continuous Benchmarking»

Wir haben bei Parashift so ein Set an Konkurrenzofferings gegen welche wir benchmarken. Darin ist so ziemlich jede Lösung vertreten, welche sich in dem Gebiet bewegt. Wir testen regelmässig mit einem Dokumentenset, das wir für repräsentativ halten. Ende diesen Sommers realisierten wir, dass wir dieses Dokumentenset in Summe besser als alle andere Anbieter beherrschen. Gleichzeitig bekamen wir immer mehr Anfragen, einfach auch das nicht-100 prozentige Resultat über eine Schnittstelle auszuliefern.

Also entschieden wir uns ein entsprechendes API-Produkt zu bauen und tauften es «Basic Extraction API». Was auf Prototype-Ebene gut funktioniert, ist aber bekanntlich noch lange kein Produkt. Wir verbrachten den September und Oktober damit, unsere Infrastruktur zu erweitern.

Mit der «Basic-Extraction API» ändern sich einige Anforderungen, denn potentiell muss die Infrastruktur eine viel grössere Menge an Dokumenten parallel verarbeiten können.

„Breakthroughs per week“

Mitten in diese Arbeiten platzten dann neue Erkenntnisse und Ergebnisse aus dem Research & Engineering. Das sind grundsätzlich immer großartige Neuigkeiten, denn das heißt dass unsere Technologie rasch noch besser wird.

In der Regel trifft uns das aber doch einigermaßen unvorbereitet, da wir an verschiedenen Strängen neue Ideen ausprobieren und kombinieren. Neben einer logischen Herangehensweise verfolgen wir auch Initiativen die nach aktuellen Regeln der Kunst erstmal keinen Sinn machen. Oft hat uns das schon entscheidend weiter gebracht.

Wir nannten diesen Moment vorletzte Woche scherzhaft «Breakthroughs» – was sie natürlich im eigentlichen Sinne keinesfalls sind. Es sind substantielle Verbesserungen, ok. Und als neue Metrik haben wir umgehend «Breakthroughs per Week» definiert. Wir messen ja schliesslich alles.

Nun, diese Verbesserungen wollen dann erstmal analysiert und quantifiziert und später ins Produkt eingebaut werden. Die Feststellung was ist besser oder was ist schlechter ist unglaublich aufwändig, auch wenn wir sie weitgehend schon automatisiert haben.

Verzögerung durch Fortschritt

Das führte im Endeffekt dazu, dass wir die «Basic Extraction API», die wir eigentlich schon im Oktober verfügbar haben wollten noch nicht in der Breite released haben. Einzelne Kunden haben bereits Zugriff, bald werden wir dazu endlich eine öffentliche Test-API plus eine frei verfügbare Demo aufschalten können.

Die Verzögerungen sind in der Perspektive nicht weiter tragisch – zum einen weil der Grund ein positiver ist – zum anderen auch weil sich die Lead-Pipeline weiter aufbaut. Aber es ist alles andere als schön, zukünftige Kunden zu vertrösten. Wir sind zuversichtlich die Arbeiten in den nächsten Tagen und Wochen abschliessen zu können. Neue «Breakthroughs» releasen wir nun erstmal später.