Was Context Switching in ERP-Prozessen wirklich kostet
Wer mit einem ERP arbeitet, kennt den Rhythmus: Belege prüfen, Freigaben erteilen, Stammdaten pflegen, wieder zurück zum Beleg. Jeder dieser Schritte findet in einer Oberfläche statt, die Anwender kennen und der sie vertrauen. Dann kommt die Signatur, und plötzlich öffnet sich ein neues Fenster, eine fremde Seite, ein anderer Login, vielleicht eine E-Mail mit Link. Context Switching ist der Fachbegriff für den Verlust, der dabei entsteht: Aufmerksamkeit, Zeit, Sicherheit im Umgang mit dem Prozess und im schlimmsten Fall der Abschluss selbst.
In ERP-Umgebungen wiegt das schwerer als in Consumer-Anwendungen. Anwender führen täglich viele gleichartige Vorgänge durch und erwarten, dass sich Abläufe vorhersagbar verhalten. Ein Medienbruch an einer einzelnen Stelle wird zur Reibungsquelle, die sich hundertfach wiederholt. Die Folge sind Umgehungen: Dokumente werden ausgedruckt, per Hand unterschrieben und eingescannt, obwohl eine digitale Signatur verfügbar wäre. Das Werkzeug existiert, aber der Weg dorthin ist zu mühsam.
Wir nennen den Gegenentwurf Silent Tech: Technik, die ihre Arbeit tut, ohne sich in den Vordergrund zu drängen. Die Signatur ist da, sie hat Beweiswert, sie ist nachvollziehbar, aber sie ist kein eigenes Produkt im Erleben des Anwenders. Sie ist ein Schritt im Beleg-Workflow, der aussieht und sich anfühlt wie der Rest der Anwendung. Die eine harte Unterscheidung dieses Beitrags lautet: Eine Signatur, die der Anwender als eigenes Produkt wahrnimmt, ist im ERP eine Reibungsquelle. Eine Signatur, die als Prozessschritt wahrgenommen wird, ist ein Werkzeug.
Warum ist das für ERP-Hersteller und Integratoren geschäftlich relevant? Weil Akzeptanz über den Erfolg digitaler Prozesse entscheidet. Eine technisch perfekte Signatur, die niemand nutzt, spart nichts. Umgekehrt reicht ein einfacher, in den Prozess eingebetteter Schritt, um Papierwege dauerhaft zu ersetzen. Die Rechtsgültigkeit ist in beiden Fällen dieselbe, die Wirkung nicht. Wie das Thema im Kontext von mandantenfähigen Produkten aussieht, zeigt der Beitrag White-label Signatur ohne Medienbruch.
Hinzu kommt die Frage der Sicherheit. Anwender, die an Fremdseiten gewöhnt werden, werden anfälliger für Phishing. Wenn der reguläre Signaturprozess bereits aus Mails mit Links zu externen Seiten besteht, fällt es schwerer, echte von gefälschten Aufforderungen zu unterscheiden. Ein Prozess, der in der bekannten Oberfläche bleibt, erzieht zu einem sicheren Verhalten: Signiert wird dort, wo man ohnehin arbeitet. Das ist ein Sicherheitsargument, das in Gesprächen mit IT-Leitungen oft stärker zieht als jedes UX-Argument.
Das Video zeigt, wie sich eine Signatur in eine fremde Oberfläche einfügt, ohne den Anwender zu einem Fremdportal zu schicken. Achten Sie darauf, wie wenig vom Dienst im Hintergrund sichtbar wird. Genau das meint Silent Tech.
Embed statt Redirect: die technische Grundentscheidung
Technisch läuft die Entscheidung auf die Frage hinaus, wo die Signaturoberfläche gerendert wird. Beim Redirect verlässt der Anwender die Host-Anwendung und landet in einer Seite des Signaturanbieters. Beim Embed läuft die Signaturoberfläche innerhalb der Host-Anwendung, etwa als eingebettete Komponente oder als Dialog in der Oberfläche, und kommuniziert über die API mit dem Dienst. In beiden Fällen läuft die Signatur im Hintergrund über dieselben Funktionen, aber der Erlebnisunterschied ist groß.
Embed hat Anforderungen, die man vorab prüfen sollte. Die Host-Anwendung muss die Komponente einbinden können, was in modernen Weboberflächen unkompliziert ist, in älteren Desktop-Clients oder mit eingeschränkten Browserkomponenten aber Aufwand bedeutet. Sicherheitsrichtlinien wie Content-Security-Policy oder Einbettungsbeschränkungen müssen die Nutzung zulassen. Und die Kommunikation zwischen Host und Komponente, etwa der Rückkanal bei Abschluss, muss sauber definiert sein. Wer diese Fragen früh klärt, vermeidet unangenehme Überraschungen im Rollout.
Der Rückkanal ist der entscheidende Punkt für ERP. Nach dem Signieren muss das System wissen, dass der Beleg unterzeichnet ist, und den nächsten Schritt auslösen. Das geschieht über Ereignisse, die per Webhook an Ihr System gehen, und nicht über Annahmen aus der Oberfläche. Wie Sie das zuverlässig gestalten, mit Idempotenz, Zustandsmodell und Wiederholungen, haben wir im Beitrag Webhook State Management für E-Signatur-Events beschrieben. Ohne diesen Unterbau wird Silent Tech zur Schönwetterlösung, die bei Störungen Inkonsistenzen erzeugt.
Es gibt Fälle, in denen ein Redirect die bessere Wahl bleibt. Unterzeichner, die gar nicht Ihre Anwender sind, etwa externe Vertragspartner ohne Zugang zum ERP, brauchen einen Weg, der ohne Login auskommt. Hier ist ein Einladungslink mit klarer Oberfläche sinnvoll. Auch dann können Sie die Marke steuern und den Rückkanal sauber halten, aber der Anwender ist nicht im ERP. Silent Tech zielt auf die internen Signaturen, bei denen der Anwender ohnehin in der Oberfläche arbeitet: Freigaben, Verträge mit Mitarbeitenden, Bestellungen, Abnahmeprotokolle.
Ein pragmatisches Muster ist die Zweiteilung: Interne Unterzeichner signieren eingebettet im ERP, externe erhalten eine gebrandete Einladung. Beide Wege laufen über dieselbe Prozesslogik und denselben Webhook-Rückkanal, sodass das ERP einen einheitlichen Zustand führt. Das reduziert Sonderfälle und macht Auswertungen einfacher. Eine saubere Beschreibung der Rollen im Vorgang, wer unterzeichnet in welcher Reihenfolge und in welcher Form, ist dafür Voraussetzung.
Auch die Signaturstufe spielt hinein. Für interne Freigaben genügt häufig eine einfache Signatur (SES) oder eine fortgeschrittene (AES), für bestimmte Verträge ist QES erforderlich. Sign2x bildet SES, AES und QES ab. Wir sind kein qualifizierter Vertrauensdiensteanbieter, und bei QES arbeitet ein Partner-QTSP wie Sign8 im Hintergrund, der die Qualifikation trägt und dafür aufsichtsrechtlich verantwortlich ist. Für das ERP bedeutet das, dass sich der Ablauf je Stufe unterscheiden kann, etwa durch einen vorgeschalteten Identifikationsschritt. Der Beitrag AES vs QES per API hilft bei der Zuordnung.
White-label Host-UX: die Signatur in Ihrer Marke
Silent Tech funktioniert nur, wenn die Signaturstrecke Ihre Sprache spricht. Das beginnt bei Schriftarten und Farben, geht über Begriffe und Anreden weiter und endet bei Fehlermeldungen. Wenn Ihre ERP-Oberfläche Beleg, Freigabe und Zeichnungsberechtigung sagt und die Signaturkomponente von Dokument, Envelope und Signer spricht, bleibt der Bruch bestehen, auch wenn das Fenster eingebettet ist. Passen Sie deshalb Texte an die Terminologie Ihres Produkts an, und pflegen Sie sie zentral, damit Änderungen nicht an zehn Stellen nachgezogen werden müssen.
Die Host-UX umfasst außerdem das Verhalten. Tastaturbedienung, Fokusführung, Verhalten bei Abbruch, Verhalten bei Zeitüberschreitung und Rückkehr in den Beleg müssen sich anfühlen wie der Rest der Anwendung. Anwender, die in Sekunden zwischen Belegen wechseln, merken Abweichungen sofort. Ein Test mit echten Anwendern, die tagtäglich mit dem ERP arbeiten, zeigt solche Brüche schneller als jede Checkliste. Bauen Sie ihn früh ein, bevor die Gestaltung fest verdrahtet ist.
Für Hersteller mit mehreren Kunden kommt die Mandantenfähigkeit hinzu. Jeder Mandant hat eigene Absender, eigene Vorlagen und gegebenenfalls eigene Pflichttexte. Die Signaturstrecke sollte diese Konfiguration aufnehmen, ohne dass Sie pro Mandant Code anfassen. Im Beitrag Whitelabel-Anforderungen für ISVs haben wir die Anforderungen zusammengestellt, und die Mandantenseite beschreibt White-label ohne Medienbruch ausführlicher.
Die Dokumentenseite ist ebenso Teil der Host-UX. Anwender erwarten, dass das signierte Dokument im Beleg erscheint, versioniert und auffindbar, mit sichtbarem Status. Ob Sie das Dokument im ERP speichern, in einem Dokumentenmanagement oder in beidem, ist eine Architekturentscheidung. Wichtig ist, dass der Weg vom Abschluss-Ereignis zur Ablage automatisch läuft und dass Sie bei Fehlern eine klare Rückmeldung geben, statt Dokumente in einem Zwischenzustand zu belassen.
Zur Hosting-Frage: Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Für ERP-Kunden aus dem Mittelstand, dem öffentlichen Sektor oder der Industrie, die bei Cloud-Diensten Eigentümer und Zugriffsrechte hinterfragen, ist das eine knappe, überprüfbare Antwort. Hintergründe liefert der Beitrag Cloud Act vs Datensouveränität. Es ist eine Aussage über Betrieb und Jurisdiktion, keine Zertifizierung Ihres Produkts.
On-Premise-Eskalation: wenn die Cloud keine Option ist
ERP-Systeme stehen oft in Umgebungen, die strenger abgeschottet sind als typische SaaS-Anwendungen. Produktionsnetze, Behörden, Kliniken, kritische Infrastruktur: In vielen dieser Fälle darf ein Dokument das eigene Rechenzentrum gar nicht verlassen, auch nicht in Richtung einer souveränen Cloud. Für diese Fälle bieten wir die Option, die Signaturstrecke im eigenen Rechenzentrum zu betreiben. Wir nennen das On-Premise-Eskalation, weil es eine Eskalationsstufe über dem Standardbetrieb ist: mehr Kontrolle, mehr Verantwortung.
Was bedeutet das praktisch? Sie übernehmen Betrieb, Updates, Überwachung und Schlüsselverwaltung in Ihrer Umgebung, wir liefern die Software und die Unterstützung. Die Integration in das ERP bleibt über dieselbe API-Logik möglich, sodass Ihr Adapter und Ihr Zustandsmodell nicht neu entworfen werden müssen. Der Unterschied liegt im Betrieb: Netzwerkfreigaben, Zertifikate, Backups, Monitoring und Notfallkonzepte gehören dann in Ihre Verantwortung. Das sollten Sie nicht unterschätzen und mit Ihrer IT-Betriebsabteilung früh besprechen.
Wichtig ist die Ehrlichkeit bei den Grenzen. Bei QES bleibt der Partner-QTSP Teil der Kette, und je nach Konstellation müssen bestimmte Verbindungen zum Partner möglich sein. Welche Daten dabei fließen, welche Teile lokal bleiben können und wie sich das mit Ihrer Sicherheitsrichtlinie verträgt, klären wir im Einzelfall, statt pauschale Zusagen zu machen. Für reine SES- und AES-Szenarien ist die lokale Variante meist unkomplizierter als für QES, weil weniger externe Beteiligte im Spiel sind.
Wann ist die Eskalation sinnvoll? Wenn Vorgaben Ihres Kunden die Cloud ausschließen. Wenn die Dokumente selbst so sensibel sind, dass auch ein souveräner Betrieb als zu weitgehend gilt. Wenn Ihr ERP selbst in einem abgeschotteten Netz läuft und eine Internetanbindung nicht vorgesehen ist. In allen anderen Fällen empfehlen wir den Standardbetrieb, weil er Ihnen Betriebsaufwand erspart und Updates vereinfacht. Die Entscheidung ist reversibel, wenn Sie die Integration über die API sauber halten. Datenschutzrechtlich bleibt auch im lokalen Betrieb die DSGVO der Maßstab: Zweckbindung, Datenminimierung und Löschkonzepte gelten unabhängig davon, wo die Software läuft.
Für die Vertriebsseite ist die Eskalation ein starkes Argument, solange Sie es nicht überdehnen. Sagen Sie Kunden klar, dass es zwei Betriebsmodi gibt, und ordnen Sie jedem seinen Aufwand zu. Mehr zu Souveränität und Betrieb lesen Sie in den Beiträgen Open Sovereign Cloud für die E-Signatur-API und Die souveräne E-Signatur-Alternative aus Deutschland.
Wann Silent Tech greift und wann nicht
Silent Tech ist kein Allheilmittel. Es greift besonders gut, wenn vier Bedingungen zusammenkommen. Erstens: Die Signatur ist wiederkehrender Teil eines internen Prozesses, nicht ein einmaliges Ereignis. Zweitens: Die Unterzeichner arbeiten ohnehin im ERP. Drittens: Der Prozess hat klare Folgeschritte, die am Abschluss hängen, etwa Freigabe, Buchung oder Versand. Viertens: Ihre Organisation legt Wert auf einheitliche Bedienung und Nachvollziehbarkeit der Abläufe.
Weniger gut passt der Ansatz bei sehr seltenen Signaturen, bei denen der Aufwand der Einbettung den Nutzen übersteigt, oder bei Szenarien mit überwiegend externen Unterzeichnern, die keinen Bezug zum ERP haben. Hier ist ein gebrandeter Einladungsweg meist wirtschaftlicher. Auch wenn Ihr ERP keine Einbettung von Webkomponenten zulässt und ein Umbau nicht ansteht, sollten Sie realistisch prüfen, ob ein sauberer, markentreuer Redirect für den Anfang genügt. Besser ein guter Redirect als ein halb fertiger Embed. Entscheidend ist, dass Sie die Wahl bewusst treffen und den Rückkanal in beiden Varianten identisch halten, damit ein späterer Wechsel vom Redirect zum Embed keine Änderung am Zustandsmodell erzwingt und Ihre Ereignisdaten über beide Varianten hinweg vergleichbar bleiben.
Ein Beispiel aus der Praxis: Ein Hersteller von Branchensoftware für Wohnungsunternehmen lässt Abnahmeprotokolle von Handwerkern bestätigen. Die Handwerker sind extern, die Verwalter intern. Die Verwalter signieren eingebettet in ihrer Oberfläche, die Handwerker erhalten eine gebrandete Einladung auf dem Smartphone. Beide Wege münden in dasselbe Abschluss-Ereignis, das die Abrechnung auslöst. Für den Verwalter fühlt sich die Signatur an wie ein Klick im Protokoll, und das ist genau der Punkt.
Wenn Sie prüfen möchten, ob Silent Tech zu Ihrem Produkt passt, empfehlen wir einen kleinen Piloten: ein Prozess, eine Nutzergruppe, vier Wochen. Messen Sie Abschlussdauer, Abbrüche und Supportanfragen vor und nach der Umstellung. Daraus ergibt sich ein belastbares Bild, ohne dass Sie sich auf Versprechen verlassen müssen. Wir nennen bewusst keine pauschalen Verbesserungszahlen, denn sie hängen von Ihrer Ausgangslage ab. Wichtig für die Aussagekraft: Wählen Sie einen Prozess mit genügend Vorgängen pro Woche, damit Zufallsschwankungen nicht das Bild bestimmen, und halten Sie Ihre Hypothese vorher fest, etwa „die Abbruchquote im Signaturschritt sinkt“. Binden Sie außerdem zwei, drei Anwender als feste Ansprechpartner ein, die Beobachtungen aus dem Alltag zurückspielen. Solche Rückmeldungen sind oft wertvoller als jede Kennzahl, weil sie erklären, warum eine Zahl sich bewegt. Den technischen Einstieg bietet der Developer Hub, Begriffe erklärt das Help Center, Beispiele finden Sie unter Use Cases, eine Selbsteinschätzung im Sign2x Quiz und weitere Beiträge im Sign2x Blog.
Zum Abschluss eine Klarstellung zu Erwartungen: Wir behaupten keine Partnerschaft mit bestimmten ERP-Herstellern und keine fertigen Konnektoren für einzelne Systeme. Sign2x ist eine API-Schicht, die Sie oder Ihr Integrationspartner in die jeweilige Oberfläche einbauen. Wo wir helfen können, ist die Architektur: Zustandsmodell, Rückkanal, Mandantenkonfiguration und Betriebsmodus. Wer das sauber löst, hat die schwierigsten Teile erledigt, unabhängig vom konkreten ERP. Das spart Ihnen auch Diskussionen im Vertrieb, weil Sie Kunden klar sagen können, was Sie liefern, was der Integrationspartner übernimmt und was im Projekt gemeinsam festzulegen ist, bevor die erste Zeile Code entsteht.
Silent-Tech-Szenario mit uns besprechen
Weiterführend: Bulk-Signatur-API für Unternehmen und Von der Sandbox zur ersten QES-Strecke. Grundlagen zu Signaturstufen in der eIDAS-Verordnung, Hinweise zur Informationssicherheit beim BSI.
Häufige Fragen
Was bedeutet Silent Tech bei E-Signaturen?
Die Signatur arbeitet im Hintergrund und wird als Prozessschritt statt als eigenes Produkt wahrgenommen. Sie läuft eingebettet in Ihrer Oberfläche, in Ihrer Marke und mit Rückmeldung per Ereignis.
Wann ist ein Redirect trotzdem sinnvoll?
Bei externen Unterzeichnern ohne Zugang zum ERP, bei seltenen Signaturen oder wenn die Host-Anwendung keine Einbettung zulässt. Auch dann sollten Marke und Rückkanal sauber gesteuert werden.
Gibt es Konnektoren oder Partnerschaften mit bestimmten ERP-Herstellern?
Nein, wir behaupten keine Partnerschaften und keine fertigen Konnektoren für einzelne Systeme. Sign2x ist eine API-Schicht, die in die jeweilige Oberfläche integriert wird.
Ist ein Betrieb im eigenen Rechenzentrum möglich?
Ja, als On-Premise-Eskalation für Umgebungen, in denen die Cloud ausgeschlossen ist. Der Betriebsaufwand liegt dann bei Ihnen, bei QES bleibt der Partner-QTSP Teil der Kette.
Welche Signaturstufen werden unterstützt?
SES, AES und QES. Sign2x ist kein QTSP, für QES läuft die Qualifikation über einen Partner wie Sign8.
