Start · Lösungen · IT & Services
Lösung · IT & ServicesPortal und App bei jedem Build getestet, nicht am letzten Nachmittag vor dem Release
Jedes Release regressionsgetestet, auch die mobile App
Jeder Build von Portal und mobiler App durchläuft die Regressionssuite unbeaufsichtigt; Fehler erreichen die Entwicklung in Teams samt Nachweisen, die Release-Reife ist vor der Entscheidung sichtbar.
Kurzfassung für die Geschäftsführung
Regression ist eine Checkliste, die zwei Personen am letzten Nachmittag vor dem Release durchklicken.
Wir bauen die Regressionssuite als Produktgut und nicht als Tätigkeit der Release-Woche.
Regression ist kein Termin im Kalender mehr.
das Kundenportal sowie die iOS- und Android-Builds; die Policen-, Schaden- und Zahlungsdienste; das Backlog in Azure DevOps
Geschäftsproblem
Release-Qualität
Kundenportal und mobile App sind die Orte, an denen ein Versicherer den meisten seiner Kunden zwischen zwei Verlängerungen begegnet. Versicherte melden sich an, um ein Policendokument herunterzuladen, einen Schaden mit Fotos zu melden, eine Rate zu zahlen, eine Bankverbindung zu ändern oder Deckung zu kaufen und zu verlängern. Jeder dieser Wege führt durch mehrere Backend-Systeme, und jedes Release im Zwei-Wochen-Takt kann jeden davon unbrauchbar machen.
Regressionstests sind das Versprechen, dass weiterhin funktioniert, was im letzten Release funktioniert hat. Dieses Versprechen halten zwei Personen und eine Checkliste, in dem einzigen Zeitfenster, das der Kalender lässt. Unter Termindruck wird eine Checkliste nicht nach Risiko gekürzt, sondern nach Reihenfolge: Zuerst fallen die unteren Schritte weg, und unten stehen die selten begangenen Wege, das Tablet-Layout, die vorherige Betriebssystemversion, der Kunde mit drei Policen.
Die mobile App ist schwieriger als das Web. Ein Portalfehler wird am selben Tag behoben und ausgeliefert; ein Fehler in einer veröffentlichten App-Version bleibt bis zum Update auf dem Telefon des Kunden, und wer am seltensten aktualisiert, nutzt meist die am wenigsten getesteten Geräte.
Spürbar ist das nicht nur in der IT. Das Servicecenter nimmt die Anrufe entgegen, die Schadenabteilung erhält halbfertige Meldungen, und der Product Owner beantwortet die Frage nach der Sicherheit eines Releases mit einem Gefühl statt mit einer Zahl.
Wie es heute läuft
Unabhängig von der Methode an der Wand sieht die Regression selbst meist so aus.
- SystemDer Sprint-Build wird am Mittwochabend auf die Testumgebung ausgerollt
- MenschZwei Personen aus dem Testteam öffnen die Checkliste in SharePoint und teilen 180 Schritte unter sich auf
- WartezeitTestdaten müssen zuerst von Hand entstehen: eine Police mit offenem Schaden, eine unbezahlte Rate, ein Kunde mit drei Fahrzeugen
- MenschDie Web-Wege werden in einem Browser durchgeklickt, die App auf dem Telefon geprüft, das die Testperson gerade trägt
- FehlerrisikoLäuft der Nachmittag ab, entfallen die restlichen Schritte, und welche das waren, wird nirgends festgehalten
- MenschFehler werden im Release-Kanal in Teams beschrieben und, sofern reproduzierbar, in Azure DevOps erfasst
- FehlerrisikoDas Release geht auf Basis einer mündlichen Zusammenfassung live, und die erste Meldung über den Ausfall kommt aus dem Servicecenter oder aus einer Store-Bewertung
Warum der heutige Prozess mehr kostet, als es scheint
Die Rechnung, die im Budget nie auftaucht.
- Dieselben Wege alle zwei Wochen von Hand zu testen hinterlässt nichts Bleibendes. Sechsundzwanzig Nachmittage im Jahr ergeben sechsundzwanzig mündliche Zusicherungen und kein Gut, das morgen jemand erneut ausführen kann.
- Die Abdeckung sinkt genau dann, wenn sie steigen müsste. Ein Release mit vielen Änderungen lässt weniger Zeit zum Testen, also erhalten die größten Änderungen die dünnste Prüfung, und ein Team, das nicht günstig testen kann, antwortet mit noch größeren Releases.
- Ein von Kunden gefundener Fehler kostet ein Vielfaches eines Fehlers, der auf einem Build auffällt. Eine Portalkorrektur ist ein Hotfix und eine Entschuldigung; eine App-Korrektur bringt zusätzlich eine Store-Einreichung und die Kunden, die nie aktualisieren.
- Barrierefreiheit und Last stehen gar nicht auf der Liste, weil sich beides an einem Nachmittag nicht durchklicken lässt, also landen beide einmal im Jahr in einem externen Audit, wenn überhaupt.
Kosten des Nichtstuns
Nichts im Release-Kalender erzwingt eine Änderung, und deshalb gibt es keine. Der Nachmittag kehrt alle zwei Wochen wieder, die Checkliste wird von unten gekürzt, und die Kürzung bleibt unsichtbar, bis ein Kunde findet, was gekürzt wurde. Die 8.000 € je entwichenem Defekt sind unsere eigene Mischung aus Hotfix, den Kontakten im Servicecenter, den von Hand neu erfassten Vorgängen und der Store-Einreichung, die eine App-Korrektur verlangt; neun davon auf sechsundzwanzig Releases ist keine pessimistische Annahme.
Was sich aufbaut, ist langsamer und weniger sichtbar. Ein Team, das nicht günstig testen kann, veröffentlicht seltener, wodurch jedes Release größer und schwerer prüfbar wird. Die Barrierefreiheitsprüfung findet weiterhin nicht statt, und die zwei Personen, die noch sagen können, was die Checkliste wirklich abdeckt, werden zu den zweien, die das Produkt nicht verlieren darf.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein europäischer Versicherer, rund 1.400 Beschäftigte, etwa 600.000 Privatkunden in drei Märkten; ein Kundenportal sowie native iOS- und Android-Apps, zwei Produktteams, ein gemeinsames Qualitätsteam aus zwei Personen, Azure DevOps, Microsoft 365 E3.
26 Releases im Jahr für das Portal und beide App-Builds; eine Checkliste mit rund 180 manuellen Schritten über zwölf Kundenwege; etwa drei Personentage Regression je Release.
Zwei Personen gehen die Checkliste am Nachmittag vor dem Rollout durch, in einem Browser und auf einem Telefon, mit von Hand erstellten Testdaten. Befunde landen im Release-Kanal in Teams; die reproduzierbaren werden zu Arbeitselementen in Azure DevOps.
Ein Nachmittag ist ein festes Budget, die Checkliste nicht. Schritte entfallen in Listenreihenfolge statt nach Risiko, die mobile Abdeckung ist ein Gerät, und Barrierefreiheit und Last liegen außerhalb der Übung.
Testfälle in UiPath Test Manager decken die zwölf Wege auf Web-, Mobile- und API-Ebene ab, erstellt und gepflegt mit Autopilot for Testers aus den Anforderungen, die bereits in Azure DevOps stehen. Jeder Build startet die Suite über einen Orchestrator-API-Trigger, Fehler erreichen die zuständige Entwicklung in Microsoft Teams samt Nachweisen, und die Ergebnisse fließen zurück nach Azure DevOps.
Im modellierten Fall läuft die Regression, die einen Nachmittag verbrauchte, unbeaufsichtigt bei jedem Build, die zwölf Wege sind über mehrere Geräte- und Browserkombinationen statt über eine abgedeckt, und die Release-Reife wird zu einer Zahl. Illustrativ, kein Kundenergebnis.
Vorgeschlagene Lösung
Wir bauen die Regressionssuite als Produktgut und nicht als Tätigkeit der Release-Woche. Jeder der zwölf Wege wird zu einer Anforderung und einem Satz Testfälle in UiPath Test Manager, dem Teil von UiPath Test Cloud, der Fälle und Ausführungsnachweise hält. Autopilot for Testers entwirft sie aus den User Stories, die bereits in Azure DevOps stehen, erzeugt die Automatisierung dahinter und liefert die synthetischen Testdaten, die jeder Fall braucht.
Die Ausführung deckt beide Kanäle und die Schicht darunter ab: Web-Wege gegen die Browser und Bildschirmgrößen, die Ihre Kunden nutzen, mobile Wege gegen die App-Builds Ihrer Pipeline, auf den Geräte- und Betriebssystemkombinationen, die Ihre Analytik als relevant ausweist. Test Cloud unterstützt Web-, Mobile- und API-Tests an einer Stelle, sodass ein Testsatz eine Maske bedienen, den Dienst dahinter aufrufen und beides prüfen kann. Nichts wartet auf einen Menschen: Nach jedem erfolgreichen Build ruft die Pipeline einen Orchestrator-API-Trigger auf, und die Suite läuft unbeaufsichtigt. Ein Fehler wird zu einem Arbeitselement, das mit seinem Testfall verknüpft ist und Screenshot, Aufzeichnung und die gescheiterte Prüfung trägt, und erreicht die für den Bereich zuständige Entwicklung als Actionable Notification in Microsoft Teams. Kunden mit Jira werden dorthin synchronisiert.
Darüber steht eine Sicht auf die Release-Reife: Abdeckung je Weg, Zahl der bestandenen und gescheiterten Fälle sowie der Trend über die Builds, daneben die offenen Fehler nach Schwere in Power BI. Wo der Kunde es braucht, trägt dieselbe Suite Barrierefreiheitsprüfungen nach WCAG-Kriterien und Performance-Läufe für Last, Spitzen, Stress und Dauer. Das ist eine andere Aufgabe als die nächtliche SAP-Regression, die ein Backend-System gegen die dort eingespielten Transporte schützt, und wiederum eine andere als die Migrationsabsicherung, bei der eine einmalige Datenübernahme vor dem Cutover Satz für Satz nachgewiesen wird.
UiPath Test Cloud mit Test Manager (Testfälle, Nachweise, Synchronisation mit Azure DevOps und Jira, WCAG- und Performance-Tests); Autopilot for Testers (Testerzeugung, synthetische Testdaten, Selbstheilung); UiPath Orchestrator API-Trigger und Prüfpfad; UiPath Action Center Actionable Notifications in Microsoft Teams
Die Zuordnung von Wegen zu Testfällen samt Risikoreihung, die Objektbibliotheken, die Testdatensätze und deren Bereinigung, die Pipeline-Integration, die Regeln für die Fehlerzustellung, den Reifebericht und das Runbook
Der Pipeline-Schritt, der die Suite startet und auf ihr Urteil wartet; die Anbindung Ihres Gerätebestands, einer Gerätecloud oder eines eigenen Labors; Aufrufe der Policen-, Schaden- und Zahlungsdienste, die Testdaten vorbereiten und wieder aufräumen
So läuft der automatisierte Prozess
- AutomatisierungEin erfolgreicher Build in Azure DevOps ruft einen Orchestrator-API-Trigger auf und startet den Testsatz für die betroffenen Bereiche
- AutomatisierungTestdaten werden bereitgestellt: Policen, offene Schäden, unbezahlte Raten und Einwilligungen entstehen über die Dienste und werden danach entfernt
- SystemRoboter fahren die Web-Wege über die Browser und Bildschirmgrößen im Umfang und die mobilen Wege gegen die neuen App-Builds im Gerätebestand
- AutomatisierungAPI-Prüfungen laufen parallel gegen die Policen-, Schaden- und Zahlungsdienste; die Suiten für Barrierefreiheit und Performance laufen nach vereinbartem Plan
- SystemJedes Ergebnis landet mit seinen Nachweisen im Test Manager, und Fehlschläge erzeugen oder aktualisieren Arbeitselemente in Azure DevOps, verknüpft mit Testfall und Build
- MenschDie für den Bereich zuständige Entwicklung erhält den Fehler in Microsoft Teams und stuft ihn als Defekt, Testkorrektur oder beabsichtigte Änderung ein
- AutomatisierungDie Reifesicht aktualisiert sich: Abdeckung je Weg, Bestehensquote, offene Fehler nach Schwere, Trend über die letzten Builds
Zusammenspiel von Mensch und Automatisierung
Die Automatisierung übernimmt
- Den Lauf der Wege-Suite auf Web-, Mobile- und API-Ebene nach jedem Build, ohne Aufforderung
- Das Bereitstellen und Entfernen der Testdaten, die jeder Fall braucht
- Das Sammeln der Nachweise zu jedem Ergebnis und das Anlegen des verknüpften Arbeitselements in Azure DevOps
- Die Pflege der Elementbeschreibungen bei Oberflächenänderungen und die Meldung der reparierten Tests
Menschen entscheiden
- Welche Wege in die Suite gehören und welches Risiko jeder von ihnen trägt
- Ob ein Fehlschlag ein Defekt, eine beabsichtigte Änderung oder ein zu aktualisierender Test ist
- Das Release-Gate: was noch offen sein darf, wenn ein Build in Produktion geht
- Die Schwellen für Barrierefreiheit und Performance, die das Portal erfüllen muss
Vorher und nachher
Systeme und Integrationen
Wir fügen keine Technologie hinzu, damit eine Architektur seriös aussieht. Jedes Element unten hat hier eine konkrete Aufgabe.
Eingänge
- Anforderungen und User Stories in Azure DevOps
- Build-Artefakte aus der Pipeline
- die zwölf Kundenwege und ihre Risikoreihung
- Geräte- und Browsernutzung aus Ihrer Analytik
Automatisierungsschicht
- UiPath Test Cloud mit Test Manager
- Autopilot for Testers
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
Zielsysteme
- das Kundenportal sowie die iOS- und Android-Builds
- die Policen-, Schaden- und Zahlungsdienste
- das Backlog in Azure DevOps
- der Reifebericht in Power BI
Berührungspunkte für Menschen: Fehlertriage in Microsoft Teams; der Reifebericht; die Testfallprüfung im Test Manager
Eingesetzte Technologien
Anforderungen, Testfälle, Nachweise, Synchronisation mit Azure DevOps oder Jira
Aentwirft Tests aus Anforderungen, erzeugt Automatisierung und synthetische Testdaten, heilt Tests selbst
Afahren die Suite unbeaufsichtigt über API-Trigger aus der Pipeline, mit Wiederholungen und Prüfpfad
Astellt jeden Fehlschlag der zuständigen Entwicklung zu, mit Nachweisen
ABuild-Pipelines, die die Suite starten; das Backlog, in dem die Defekte leben
Atechnische Zugangsdaten; beherbergt Testumgebungen und Robotermaschinen
Ader Release-Reifebericht, der vor der Freigabeentscheidung gelesen wird
Adie Geräte- und Betriebssystemkombinationen, gegen die die mobilen Wege laufen
CIllustratives Wirtschaftlichkeitsmodell
Was es wert ist, mit offener Rechnung.
Ein Personentag sind hier 480 Minuten, und 6,5 davon im Monat sind der Kalender aus 26 Releases, gleichmäßig über das Jahr verteilt; beides sind ausgewiesene Annahmen, keine Messungen bei einem Kunden. 42 € sind ein vollbelasteter Stundensatz für eine Qualitätsfachkraft in Mitteleuropa. Das Modell bewertet allein die manuelle Regression, nicht die Defekte, die Kunden erreichen; die stehen im nächsten Abschnitt. Es zeigt freigesetzte Kapazität; wie sie genutzt wird, entscheiden Sie.
Rechnen Sie mit Ihren Zahlen
Eine illustrative Schätzung aus Ihren Eingaben. Sie modelliert freigesetzte Kapazität und verspricht keine Einsparung.
Geschäftlicher Nutzen
- Regression ist kein Termin im Kalender mehr. Jeder Build wird getestet, das Release-Datum entscheidet nicht länger über den Testumfang, und Releases dürfen kleiner und häufiger werden.
- Abdeckung wird zur Tatsache statt zur Absicht: zwölf Wege, auf den Browsern und Geräten Ihrer Kunden, bei jedem Build, je Lauf dokumentiert.
- Defekte erreichen die Entwicklung binnen Minuten nach dem Build, der sie verursacht hat, solange die Korrektur noch günstig ist.
- Die mobile App ist nicht länger der Kanal, für den nie Zeit war, und Barrierefreiheit und Last werden zur laufenden Prüfung statt zum Jahresaudit.
Aus Sicht der Geschäftsführung
- Die Release-Reife wird zu einer Zahl, die der Product Owner zeigen kann: Abdeckung je Weg, Bestehensquote und offene Fehler nach Schwere, je Build.
- Die Freigabeentscheidung verlässt den Bereich der Zuversicht. Was geprüft wurde, was scheiterte und was akzeptiert wurde, steht zu jedem Release fest.
- Die Lieferfähigkeit wächst ohne Einstellungen, und was das Team über Qualität weiß, ist nicht länger mündliche Überlieferung, sondern besteht aus Testfällen, die jeder lesen kann.
KPIs für die Geschäftsführung
Sicherheit und Governance
Vertrauen in Automatisierung entsteht durch den Prüfpfad, nicht durch ein Versprechen.
- Tests laufen gegen Umgebungen mit synthetischen Kunden, und die Suite maskiert jedes Feld in Screenshot und Aufzeichnung, das personenbezogene Daten tragen könnte. Produktionsdaten von Versicherten werden nicht in einen Testlauf kopiert, und nur diese Variante besteht eine Datenschutzprüfung.
- Jeder Roboter meldet sich mit einem eigenen technischen Konto an. Die Geheimnisse verlassen Azure Key Vault nicht, Orchestrator verweist nur darauf, und die Konten tragen Rechte in den Testmandanten und sonst nirgends.
- Anforderungen, Ergebnisse und Nachweise bleiben in Ihrem Azure-DevOps-Projekt und in der EU-Region der UiPath Automation Cloud, wo die Ausführungshistorie noch Monate später beantwortet, wer einen Testfall geändert und wer einen Fehlschlag akzeptiert hat.
Warum jetzt
Barrierefreiheit ist für online verkaufte Dienstleistungen nicht mehr optional. Der European Accessibility Act, Richtlinie (EU) 2019/882, gilt seit dem 28. Juni 2025 und erfasst Dienstleistungen des elektronischen Geschäftsverkehrs, also Dienstleistungen, die im Fernabsatz auf elektronischem Weg zum Abschluss eines Verbrauchervertrags erbracht werden, und genau das tut ein Portal, das Policen verkauft und verlängert. Ob ein bestimmter Weg in den Anwendungsbereich fällt, ist eine Frage an Ihre Rechtsabteilung; so oder so ersetzt ein Jahresaudit keine Prüfung bei jedem Build.
Die modellierten 26.208 € Regressionsaufwand im Jahr sind die kleinere Hälfte der Rechnung. Die Defekte, die ein Nachmittag nicht findet, sind die größere, und beide werden in jedem Jahr bezahlt, in dem die Checkliste überlebt.
Das Schreiben war nie der Grund, warum automatisierte Suiten verfielen; die Pflege war es. Autopilot for Testers entwirft Fälle aus Anforderungen, erzeugt die Automatisierung und die synthetischen Daten dahinter und repariert Tests bei Oberflächenänderungen, wodurch sich der Aufwand auf die Entscheidung verlagert, was zu testen ist.
Relevante Führungsrollen
Release-Qualität wird zu einer gemessenen Eigenschaft der Pipeline statt zu einer Diskussion am Nachmittag vor dem Rollout
Die Kanäle, die Kunden nutzen, werden geprüft, bevor die Kunden sie nutzen, sodass das Servicecenter Releases nicht mehr entdeckt
Das Produkt veröffentlicht häufiger, weil der Nachweis eines sicheren Releases nicht mehr mit der Zahl der Wege wächst
Die freigesetzte Kapazität ist klein und zählbar; die Kosten der Defekte, die Kunden erreichen, sind größer und landen in Servicevolumina statt im IT-Budget
Häufige Fragen und Einwände
Gemeinsam ist die Plattform, sonst fast nichts. Die nächtliche SAP-Regression schützt ein Backend-System gegen die Transporte, die Sie dort einspielen; diese Suite schützt die zwei Kanäle, die Ihre Kunden berühren, gegen Browser und Telefone, die sich nach eigenem Takt ändern. Die meisten Unternehmen betreiben am Ende beides, oft mit demselben Team.
Genau deshalb sterben Suiten an der Pflege und nicht am Schreiben. Die Automatisierung baut auf gemeinsamen Elementbibliotheken statt auf Koordinaten, Autopilot for Testers repariert, was möglich ist, und meldet, was repariert wurde, und UiPath Healing Agent deckt Testautomatisierung ebenso ab wie Produktionsläufe.
Schneller Wandel spricht dafür. Die wichtigsten Wege, Anmeldung, Schadenmeldung, Ratenzahlung, ändern sich am seltensten und schmerzen am meisten, wenn sie brechen. Beginnen Sie mit diesen auf zwei oder drei Gerätekombinationen und erweitern Sie, sobald die Suite Vertrauen gewinnt.
Wann diese Lösung nicht passt
- Ein Produkt, das zweimal im Jahr veröffentlicht und dazwischen wenig verändert wird, wo eine Checkliste tatsächlich günstiger ist als eine Suite, die jemand pflegen muss
- Eine Anwendung, die noch umgebaut wird, deren Masken und Kennungen sich jeden Sprint aus Gründen ändern, die keine Defekte sind
- Keine Testumgebung und keine Möglichkeit, Testdaten zu erzeugen, sodass jeder Lauf von Produktionsdatensätzen abhinge
Eine Frage für die nächste Sitzung
Welchen Nachweis wird dieses Unternehmen vor dem nächsten Release dafür haben, dass Portal und mobile App weiterhin funktionieren, und wer wird ihn erbracht haben?
Vorgehen bei der Umsetzung
Was wir liefern und was wir für den Start brauchen.
Wir liefern
- Einen Workshop zu Wegen und Risiko: welche Wege die Suite abdecken muss, was jeder wert ist, was kaputt bedeutet
- Anforderungen und Testfälle im Test Manager, mit Autopilot for Testers aus den Stories entworfen, die Sie ohnehin schreiben, dazu die Web- und Mobile-Automatisierung dahinter und die Objektbibliotheken, die sie pflegbar halten
- Testdatensätze, die ihre Policen, Schäden und Zahlungen selbst anlegen und wieder aufräumen, damit kein Lauf von einem handgebauten Satz abhängt
- Die Pipeline-Integration in Azure DevOps, die Fehlerzustellung nach Microsoft Teams und die Zuständigkeitsregeln dahinter
- Den Reifebericht in Power BI, die Suiten für Barrierefreiheit und Performance, soweit im Umfang, sowie ein Wartungs-Runbook
Wir brauchen von Ihnen
- Eine produktionsnahe Testumgebung, App-Builds, die die Pipeline übergeben kann, und Ihre Geräte- und Browseranalytik
- Zugriff auf die Dienste zur Testdatenerzeugung, ausschließlich auf Testdaten beschränkt
- Eine benannte Product-Owner-Rolle, die entscheidet, was das Release-Gate verlangt
Etappen
Analyse
Wege, Risikoreihung, heutige Checkliste, Umgebungen, Geräte- und Browsermix
Design
Abdeckungsmatrix, Testdatenstrategie, Gate-Kriterien, Zuständigkeit und Zustellung von Fehlern
Aufbau
Testfälle und Automatisierung für Web, Mobile und API, Pipeline-Integration, Zustellung in Teams
Stabilisierung
Die Suite läuft neben der manuellen Checkliste, bis beide übereinstimmen, dann entfällt die Checkliste
Betrieb
Wartungsrhythmus, Umgang mit instabilen Tests, Suiten für Barrierefreiheit und Performance, quartalsweise Abdeckungsprüfung
Abteilungsweit. Den Aufwand treiben die Zahl der Wege, die Prüfbarkeit der Anwendung (stabile Elementkennungen, ein Dienst hinter jeder Maske) und die Zahl der Geräte- und Browserkombinationen in der Matrix.
Die Regression, die Sie am Donnerstagnachmittag kürzen, finden Ihre Kunden am Freitag.
Senden Sie uns Ihre heutige Regressions-Checkliste und die Release-Historie des letzten Quartals. Wir liefern eine Karte der Wege und Risiken, eine vorgeschlagene Abdeckungsmatrix und eine schriftliche Einschätzung, was zuerst automatisiert gehört.
Zwei kritische Journeys automatisierenDer Nachbarprozess hat meist dasselbe Problem
Eine Tabellenstichprobe von einigen Hundert Datensätzen steht heute zwischen Ihrer Migration und dem Go-live.
Lösung ansehen IT & ServicesZugriffsanträge und quartalsweise BerechtigungsprüfungFührungskräfte bestätigen Berechtigungen, die sie nicht lesen können, und niemand entzieht Ungenutztes.
Lösung ansehen KundenserviceService Levels gemeldet, bevor der Kunde sie bestreitetMonatliche SLA-Berichte entstehen in Excel aus Ticketexporten, und die Gutschriften rechnet der Kunde zuerst aus.
Lösung ansehen IT & ServicesJedes Gerät erfasst: von der Bestellung bis zur LöschungHardware per Mail bestellt, ohne Beleg übergeben und abgeschrieben, wenn die Prüfung danach fragt.
Lösung ansehen Case StudySAP-Regression jede Nacht — Case StudyStatt drei Personen, die zwei Tage lang klicken — UiPath-Testagenten durchlaufen die kritischen SAP-Pfade jede Nacht.
Case Study ansehen Case StudyRoboter, die sich selbst reparieren — Case StudyEin SAP-Bildschirm ändert sich und das halbe Roboter-Portfolio steht? Der Healing Agent erkennt die Oberflächenänderung und repariert Selektoren im Flug.
Case Study ansehenBranchen, in denen wir das am häufigsten umsetzenHandel & E-CommerceDienstleistungen & ITFinanzen & Versicherung