Was mich an Start-ups immer fasziniert hat, ist, dass man immer etwas lernt, was man nicht erwartet hat. Man würde annehmen, dass positives Lernen automatisch zu positiven Ergebnissen führt und umgekehrt. Dies ist leider nicht unbedingt der Fall. Ein Beispiel.
(Lesezeit 3 Minuten)
Produkt vs Forschung & Ingenieurwesen
Bei Parashift gibt es grundsätzlich zwei Phalanxen. Ein Research & Engineering-Front und eine Business-Front. Wir haben in den letzten 12 Monaten das Wissen aus unserer Forschung und Entwicklung in eine Infrastruktur gesteckt, damit wir a) Forschung und Entwicklung betreiben können. effizienter und schneller zu konstruieren und b) Produkte für die Märkte zu bauen. Diese Produkte helfen uns, das Geld zur Verfügung zu haben, um wieder in Forschung und Entwicklung zu investieren.
Die Produkte bestehen aus zwei Komponenten: APIs für Softwareanbieter (wie ERP-Systeme usw.), die die autonome Verarbeitung von Buchungsbelegen in ihre Systeme und die Parashift-Plattform integrieren möchten; eine Art vollautomatisches DMS SaaS für auf den Mittelstand zugeschnittene Buchhaltungsbelege.
Wir konzentrieren uns auf die 100% korrekte Zustellung der Dokumenteninformationen. Dies erreichen wir durch einen extrem hohen Automatisierungsgrad und die Überarbeitung des fehlenden Teils durch unser Betriebsteam, das wiederum einer der Haupttreiber für unsere schnellen Verbesserungen beim maschinellen Lernen ist. (Wir werden zu gegebener Zeit eine wirklich detaillierte technische Aufschlüsselung geben).
“100% Extraktions-API”
Wir konnten unsere ersten Kunden gewinnen und haben bereits zahlreiche Anfragen erhalten. Hinter jeder dieser Anfragen verbirgt sich ein spezielles Softwareprojekt und ein in der Regel komplizierter Entscheidungsbaum für den Kunden – die Verkaufszyklen sind entsprechend lang. In den meisten Fällen spielt auch eine politische Komponente eine Rolle, da zumindest ein teilweiser Strategiewechsel angegangen werden muss.
Was ich persönlich unterschätzt habe, ist, dass es auch ein großes Interesse an den Ergebnissen gibt, die nur von der Maschine erzeugt werden. Ich war so auf 100% konzentriert – und letztendlich auf die autonome Verarbeitung(denn das ist im Grunde der wahre Game Changer) dass ich blind für diese Forderung war. Sehr dumm.
“Kontinuierliches Benchmarking.”
Bei Parashift führen wir eine Reihe von Wettbewerbsfällen, an denen wir uns messen lassen. Es enthält so ziemlich jede Lösung, die auf dem Markt ist. Wir testen regelmäßig mit einem Dokumentenmix, den wir für repräsentativ halten. Ende dieses Sommers stellten wir fest, dass wir diese Dokumente insgesamt besser beherrschen als jeder andere Anbieter. Gleichzeitig erhielten wir immer mehr Anfragen, das Nicht-100% -Ergebnis einfach über eine Schnittstelle zu liefern.
Daher haben wir uns entschlossen, ein entsprechendes API-Produkt zu erstellen und es als “Basic Extraction API” zu bezeichnen. Was auf Prototypenebene gut funktioniert, ist noch kein Produkt. So haben wir im September und Oktober unter anderem unsere Infrastruktur ausgebaut.
Mit der “Basic-Extraction API” ändern sich einige grundlegende Anforderungen, da die Infrastruktur möglicherweise in der Lage sein muss, eine viel größere Menge von Dokumenten parallel zu verarbeiten.
“Durchbrüche pro Woche”
Neue Erkenntnisse und Ergebnisse aus Forschung und Technik fließen dann in die Mitte dieser Arbeit ein. Das sind immer wieder tolle Neuigkeiten, denn dadurch wird unsere Technologie schnell noch besser.
In der Regel sind wir jedoch auf solche Ereignisse etwas unvorbereitet, da wir neue Ideen in unterschiedlichen Strängen ausprobieren und kombinieren. Neben einem logischen Ansatz verfolgen wir auch Initiativen, die nach den aktuellen Regeln der Kunst keinen Sinn ergeben. Oft hat dies bereits eine entscheidende Rolle für unseren Gesamtfortschritt gespielt.
Wir nannten diesen Moment scherzhaft “Durchbruch” – was sie natürlich keineswegs im eigentlichen Sinne des Wortes sind. Sie sind wesentliche Verbesserungen, ok. Als neue Metrik haben wir jedoch sofort “Durchbrüche pro Woche” definiert. Schließlich messen wir alles.
Nun, diese Verbesserungen müssen zuerst analysiert und quantifiziert und später in das Produkt integriert werden. Es ist unglaublich zeitaufwendig festzustellen, was besser oder was schlechter funktioniert, obwohl wir es bereits weitgehend automatisiert haben. Im besten Fall würden Sie alle Dokumente und Ergebnisse verwenden, die jemals verarbeitet wurden, um Ihre Ergebnisse zu messen.
Delay due to progress
Infolgedessen haben wir die “Basic Extraction API”, die wir eigentlich im Oktober haben wollten, noch nicht veröffentlicht. Einzelne Kunden haben bereits Zugriff. Bald können wir endlich eine öffentliche Test-API und eine frei verfügbare Demo hinzufügen.
Die Verzögerungen sind auf lange Sicht nicht tragisch – zum einen, weil der Grund positiver ist – zum anderen, weil sich die Lead-Pipeline weiter aufbaut. Aber es ist alles andere als schön, zukünftige Kunden abzuhalten. Wir sind zuversichtlich, dass wir die Arbeiten in den kommenden Tagen und Wochen abschließen können. Neue “Durchbrüche” werden später veröffentlicht.
