Kurz gesagt
Pharen Hub entstand aus einem Widerspruch in unserer Beratungsarbeit: Kunden bezahlten uns dafür, ein Problem zu lösen, und dann erneut, sobald sich ihre Arbeit änderte und „nur noch eine Sache“ angepasst werden musste. Jede dieser Änderungen begann mit einer neuen Erklärung, berührte Rollen, Daten, Workflows und Benachrichtigungen und ließ immer mehr Wissen über das System bei uns statt beim Kunden. Dasselbe Durcheinander sahen wir auf unseren eigenen Bildschirmen: Das CRM kannte den Kunden, ein Drive das Angebot, ein Chat die Entscheidung. AI beschleunigte einzelne Schritte, wurde aber nur ein weiterer Tab, weil den Kontext weiterhin ein Mensch zusammentragen musste.
Die Idee für Pharen entstand 2025, die erste funktionierende Version von Pharen Hub folgte Anfang 2026, geschärft im Traction Lab des HHL Digital Space. Pharen Hub bringt Aufgaben, Wissen, operative Daten, Gespräche und Workflows in einen gemeinsamen Arbeitsbereich, damit Menschen und AI denselben Kontext nutzen und die Schlüssel beim Team bleiben.
In verschiedenen Projekten wiederholte sich dieselbe Szene. Der Prozess funktionierte. Das neue System war fertig. Das Team arbeitete bereits damit.
Dann kam eine Nachricht.
„Könnt ihr nur noch eine Sache ändern?“
Sie sah harmlos aus. Meistens war auch der Wunsch dahinter völlig vernünftig. Eine Führungskraft wollte eine weitere Freigabe. Ein Team brauchte eine andere Sicht auf die Daten. Für einen bestimmten Kunden gab es einen Sonderfall, den der normale Ablauf nicht abbilden konnte.
Der Kunde hatte uns schon dafür bezahlt, das Problem zu lösen. Nun würde er uns noch einmal bezahlen.
Für eine Beratung war das ein gutes Geschäft. Für uns war es der Grund, unsere Arbeit grundsätzlich zu hinterfragen.
Was nur noch eine Sache wirklich bedeutete
Nehmen wir eine zusätzliche Freigabe in einem laufenden Prozess. Zuerst mussten wir herausfinden, an welcher Stelle sie erscheinen sollte. Dann mussten wir klären, wer sie geben durfte, was diese Person sehen konnte und was nach einer Ablehnung passieren sollte.
Die neue Rolle brauchte Zugriff auf die richtigen Daten. Der Workflow brauchte einen weiteren Weg. Benachrichtigungen mussten die richtigen Menschen erreichen. Der normale Fall musste weiter funktionieren. Dasselbe galt für die seltsame Ausnahme, die nur bei einem Kunden vorkam.
Im Gespräch bestand der Wunsch aus einem Satz. Im System konnte er fast alles berühren, was ihn umgab.
Das machte den Kunden nicht schwierig. Seine Arbeit hatte sich verändert, also musste sich die Software mit ihr verändern. Wir gingen den Prozess durch, passten die Logik an und testeten erst den normalen Ablauf und dann die Ausnahme. Danach prüften wir, ob die neue Lösung nicht an anderer Stelle ein neues Problem geschaffen hatte.
Die Stunden auf der Rechnung waren echt. Die Zeit, die der Kunde mit Warten verbrachte, war es ebenfalls.
Wofür der Kunde wirklich bezahlte
Jede Änderung begann mit einer weiteren Erklärung. Jemand aus dem Kundenteam musste uns zeigen, was sich verändert hatte, unsere Fragen beantworten, auf die neue Version warten und am Ende prüfen, ob sie noch zur echten Arbeit passte.
Gleichzeitig trugen wir immer mehr vom System in unseren Köpfen.
Wir wussten, warum eine Berechtigung existierte. Wir erinnerten uns daran, weshalb eine Integration ein Feld nutzte, das auf den ersten Blick falsch aussah. Wir wussten, dass eine merkwürdige Ausnahme bleiben musste, weil sie einen wichtigen Kundenfall absicherte. Sechs Monate später stand dieses Wissen vielleicht nur in unseren Notizen oder lebte in der Erinnerung der Person, die es gebaut hatte.
Die Software gehörte dem Kunden, doch zu viel von ihrer Geschichte blieb bei uns.
Genau das konnten wir nicht länger übersehen. Eine individuelle Anpassung hatte ein echtes Problem gelöst. Gleichzeitig hatte sie den Kunden abhängiger von den Menschen gemacht, die sie entwickelt hatten. Wir wollten nicht, dass ein Kunde vor allem deshalb wieder bei uns anruft, weil nur wir sein System verstehen.
Auf unseren Bildschirmen herrschte dasselbe Durcheinander
Bei uns selbst sah es kaum besser aus.
Manche Arbeitstage begannen mit einer einfachen Frage: Wo liegt die aktuelle Version?
Die Antwort steckte vielleicht in einem Dokument, die Entscheidung dahinter jedoch in einem Chat. Die Aufgabe lag in einem anderen Tool. Die letzte Nachricht des Kunden wartete in einem Postfach. Bevor die eigentliche Arbeit beginnen konnte, suchten, kopierten und erklärten wir Dinge, die irgendwo schon einmal erklärt worden waren.
In Gesprächen mit Kunden sahen wir beim Teilen des Bildschirms dasselbe Muster. Das CRM kannte den Kunden. Ein Drive enthielt das Angebot. Im Postfach lag die letzte Unterhaltung. Ein Tool wusste, welche Aufgabe als Nächstes anstand. Die eine Entscheidung, die alles miteinander verband, war vielleicht tief in einem Chat versteckt.
Die Informationen waren alle da. Trotzdem mussten wir die Verbindung zwischen ihnen jedes Mal neu herstellen.
Als Berater wurden wir gut darin, diese Verbindung immer wieder herzustellen. Wir stellten Fragen, zeichneten Prozesse auf und verbanden Tools. Trotzdem führten uns neue Projekte ständig zu denselben einfachen Fragen. Wo liegt die verlässliche Information? Wer ist jetzt verantwortlich? Was wurde entschieden? Was passiert, wenn der normale Fall nicht funktioniert?
Das Unternehmen und die Software änderten sich von Projekt zu Projekt. Die Fragen blieben jedoch dieselben.
AI wurde zu einem weiteren Tab
AI konnte ein Dokument lesen, ein Gespräch zusammenfassen oder eine Nachricht viel schneller vorbereiten als zuvor. Wir nutzten sie. Unsere Kunden taten es auch.
Bevor eine brauchbare Antwort entstehen konnte, musste jedoch jemand die ganze Geschichte vorbereiten. Wir suchten das richtige Dokument, ergänzten den Kontext zum Kunden, kopierten die frühere Entscheidung und erklärten, was die AI tun durfte. Wenn die Antwort fertig war, übertrug ein Mensch sie in das passende Tool und sagte der nächsten Person, was passiert war.
AI war schnell, sobald der Kontext vorhanden war. Diesen Kontext zusammenzutragen, blieb unsere Aufgabe.
Das Problem der vielen Tabs verschwand also nicht. AI wurde zu einem weiteren Tab.
Damit änderte sich unsere Frage. Wir wollten kein klügeres Chatfenster neben der Arbeit. Die Arbeit selbst sollte ihren Kontext mitbringen. Eine Aufgabe sollte die Entscheidung dahinter bewahren. Ein Workflow sollte zeigen, wem der nächste Schritt gehört. Ein AI Agent sollte wissen, welche Quellen er nutzen darf und an welcher Stelle ein Mensch verantwortlich bleibt.
Den gemeinsamen Teil wollten wir nur einmal bauen
Die Idee für Pharen entstand 2025. Sie kam nicht während eines einzigen genialen Meetings. Sie wuchs aus einer eher unscheinbaren Gewohnheit. Nach Projekten schrieben wir auf, was sich wiederholt hatte.
Verschiedene Kunden brauchten verschiedene Ergebnisse. Die fehlende Grundlage war jedoch oft dieselbe. Aufgaben, Wissen, operative Daten, Gespräche und Workflows waren voneinander getrennt. Jede individuelle Lösung begann damit, diese Teile erneut zusammenzuführen.
Wir fragten uns, was passieren würde, wenn wir diese gemeinsame Grundlage einmal bauen.
Anfang 2026 folgte die erste funktionierende Version von Pharen Hub. Im Traction Lab des HHL Digital Space mussten wir die Idee genauer machen. Eine große Vision reichte nicht. Wir mussten entscheiden, welches Problem zuerst gelöst werden sollte und was ein Team brauchte, um dem Produkt im Arbeitsalltag zu vertrauen.
Diese Fragen brachten uns zurück zu der Nachricht aus unseren Beratungsprojekten. Das eigentliche Problem war nicht der Wunsch nach einer weiteren Änderung. Das Problem war ein System, dessen Kontext, Logik und Geschichte für das eigene Team kaum sichtbar waren.
Was sich mit Pharen ändern soll
Pharen Hub bringt Aufgaben, Wissen, operative Daten, Gespräche und Workflows in einem gemeinsamen Arbeitsbereich zusammen. Wir wollen AI nicht einfach über eine weitere Sammlung getrennter Tools legen. Menschen und AI sollen denselben nützlichen Kontext rund um die Arbeit erhalten.
Ein AI Agent kann mit den Informationen beginnen, die bereits mit einer Aufgabe verbunden sind. Wenn ein Schritt Geld, Kundenkommunikation oder sensible Daten betrifft, kann ein Mensch für die Entscheidung verantwortlich bleiben. Ein Team kann einen Workflow oder ein internes Tool anpassen, ohne mit einem leeren System zu beginnen. Je nach Bedarf kann Pharen als betreuter Dienst, auf der eigenen Infrastruktur oder in einem privaten Setup laufen.
Damit werden nicht alle Unternehmen gleich. Das sollen sie auch nicht. Unternehmen haben eigene Regeln, Kunden und Verantwortlichkeiten. Manche Probleme werden immer fachliche Unterstützung brauchen.
Ändern soll sich die Grundlage unter dieser Arbeit. Eine sinnvolle Anpassung sollte etwas erweitern, das das Team sehen und verstehen kann. Sie sollte kein weiteres privates System schaffen, das nur seine Erbauer pflegen können.
Was diese Nachricht heute bedeuten soll
Kunden werden weiterhin fragen: „Könnt ihr nur noch eine Sache ändern?“ Das sollen sie auch. Ein System, das sich nicht mit den Menschen darin verändern kann, bleibt nicht lange nützlich.
Wir möchten, dass der nächste Teil der Geschichte anders verläuft.
Das Team sollte den Workflow öffnen und erkennen können, was die Änderung berührt. Es sollte wissen, woher die Daten kommen, wer das Ergebnis freigeben muss und warum die Ausnahme existiert. Wenn Hilfe von außen nötig ist, sollte diese Arbeit etwas erweitern, das der Kunde selbst weiter verstehen und betreiben kann.
Deshalb haben wir Pharen gebaut. Unsere Beratungsarbeit hat uns gezeigt, wie man individuelle Probleme löst. Sie hat uns aber auch gezeigt, was es kostet, wenn nur die Erbauer eine Lösung verstehen.
Ein Kunde kann unsere Hilfe weiterhin brauchen. Wir möchten nur, dass diese Hilfe ihm am Ende mehr Verständnis und mehr Kontrolle gibt als zuvor.
Die Schlüssel sollten beim Team bleiben.
