Kickoff Meeting Notes 2026-05-18

==== 1. Einleitung und Ziel des Meetings ====

Das Meeting befasst sich mit der detaillierten Analyse und der geplanten Automatisierung des Incident- und Dispatching-Prozesses (Ticket-Zuweisung) für Außendiensttechniker (Field Service Engineers). Ziel ist es, ein Minimum Viable Product (MVP) mit Robotic Process Automation (RPA, konkret UI Path) zu entwickeln, um manuelle "Copy & Paste"-Aufgaben zu eliminieren. Das Meeting wird aufgezeichnet, um die pain points und Anforderungen genau zu dokumentieren.

4

5

==== 2. Derzeitiger Prozess & Tools ====

6

7

Das Kernsystem zur Verwaltung der Tickets ist Remo. Der aktuelle, stark manuelle Prozess sieht wie folgt aus:

8

9

10

* Ticketeingang: Meldungen kommen per E-Mail oder über API (derzeit nur bei einem Kunden) herein.

11

* Incident-Erstellung (Ticket-Anlage): Ein NOC-Mitarbeiter (Network Operation Center) legt manuell einen Incident in Remo an. Pflichtfelder sind u.a. Kunde, Priorität, Fehlerart (z.B. climbing/non-climbing), Adresse/Standort, Produkt und SLA (Service Level Agreement).

12

* Eingangsbestätigung: Nach der Anlage geht automatisch eine Bestätigung (Acknowledgement) mit einer Referenznummer an den Kunden.

13

* Ersatzteilprüfung (Spare Parts): Der Mitarbeiter prüft im Freitext der E-Mail, ob Ersatzteile benötigt werden und gleicht dies mit dem Lagerbestand in der Nähe des Einsatzortes ab.

14

* Sub-Tickets & Dispatching: Aus einem Incident können mehrere Sub-Tickets entstehen (z.B. wenn für Reparaturen in der Höhe zwei Personen benötigt werden). Über eine Kartenansicht und Schichtpläne (z.B. 06:00 bis 14:00 Uhr und 10:00 bis 20:00 Uhr) werden Techniker per Drag & Drop oder Zeiteingabe zugewiesen.

15

16

==== 3. Kunden & Eingangkanäle ====

17

18

19

* Hauptkunden: Huawei, Hutchison (Hutch), Magenta, Nokia, Nomad, OMV.

20

* Kleinere Kunden: Colt, FON, DFAC.

21

* Schnittstellen: Lediglich Hutchison nutzt eine direkte API-Schnittstelle zu Remo (hierbei wird bereits ein Ticket-Entwurf im System generiert). Alle anderen Kunden (insgesamt ca. 10-12) kommunizieren über standardisierte oder freitextliche E-Mails. Telefonische Meldungen kommen praktisch nicht mehr vor.

22

* Besonderheit Huawei: Nur Huawei übermittelt aktuell direkt in der E-Mail die benötigten Ersatzteile (Spare Parts). Bei anderen Kunden muss dies intern geklärt werden.

23

24

==== 4. Automatisierungspotenzial & MVP-Fokus ====

25

26

27

* MVP-Fokus: Die Automatisierung soll sich zunächst auf das ausgelagerte NOC in Serbien konzentrieren, das 24/7 arbeitet. Deren Hauptaufgabe ist das manuelle Übertragen von E-Mail-Daten in Remo (Copy & Paste) und das Dispatching von Notfällen außerhalb der regulären Arbeitszeiten an Bereitschaftstechniker.

28

* UI Path / RPA: Der Bot soll E-Mails auslesen, die Standard-Pflichtfelder in Remo ausfüllen (Kunde, Region, Prio, Fault Type) und die Erstanlage des Tickets übernehmen.

29

* Parallele Bots: Es wurde empfohlen, mindestens zwei Bots einzusetzen (einen für die Steuerung/Überwachung, einen für die Ausführung), um zu verhindern, dass ein Bot monatelang durch ein langlaufendes Ticket blockiert wird.

30

* Technologie-Mix: Für unstrukturierte E-Mails (Freitext von Endusern) wird der Einsatz von LLMs (Large Language Models, z.B. in Azure) in Kombination mit UI Path diskutiert. Hierbei müssen jedoch die wirtschaftlichen Aspekte (Kosten für API-Calls / Azure-Infrastruktur) beachtet werden.

31

32

==== 5. Herausforderungen & Ausnahmen (Edge Cases) ====

33

34

35

* Datenqualität & Logik:

36

** Widersprüchliche Infos: Ein Ticket fordert nur einen Techniker an, im Freitext steht aber, dass eine 20-Meter-Leiter bestiegen werden muss (was aus Sicherheitsgründen zwingend zwei Personen erfordert). Hier muss eine Eskalation an einen Menschen ("Human in the Loop") erfolgen.

37

** Standort unbekannt: Wenn ein Standort nicht im System ist, muss der Platzhalter "Unknown" verwendet werden.

38

* Ressourcen & Logistik:

39

** Ersatzteile müssen geografisch passen (z.B. Region 1: Niederösterreich, Wien, Burgenland). Sind hochpriorisierte Teile nicht in der Region verfügbar, muss das SLA mit dem Kunden neu verhandelt werden.

40

** Komplexes Routen-Management und Ausnahmen (z.B. Bedarf an einem Kran, extreme Wetterbedingungen, weite Anfahrtswege) bleiben vorerst beim menschlichen Disponenten, da die Planungslogik zu komplex für den Start-Bot ist.

41

* Feedback-Schleifen: Wenn ein Techniker vor Ort meldet "Es ist zu dunkel" oder "Der Zugang ist blockiert (z.B. durch Kühe)", muss diese Information vom System verarbeitet werden, damit das Ticket nicht endlos offenbleibt.

42

43

==== 6. Projektrelevante Fragen & Technische Details ====

44

45

46

* Kann Remo direkt über eine API Tickets aus E-Mails erstellen? Derzeit gibt es keine API-Felder im Ticket Handling System, um alles direkt zu befüllen (außer bei dem speziellen Hutchison-Setup). UI Path muss das UI bedienen (bzw. verfügbare Schnittstellen prüfen).

47

* Wie funktioniert das Dispatching im Tool? Aktuell per Drag & Drop in einer Kalender/Karten-Ansicht. Alternativ kann man das Ticket auch einfach markieren und die Startzeit manuell über ein Menü eingeben, was für den Bot wesentlich fehleranfälliger umsetzbar ist als Drag & Drop.

48

* Wie wird das SLA berechnet? Das System zieht standardmäßig die Zeit aus der Priorität, jedoch schickt der Kunde oft eine harte Deadline in der E-Mail. Der Bot/Mitarbeiter muss das "Planned End" auf die Zeitvorgabe des Kunden überschreiben.

49

50

==== 7. Offene Punkte & Nächste Schritte ====

51

52

53

* Schnittstellen-Prüfung: Das Technik-Team (BCA) muss das Dokument mit den verfügbaren APIs prüfen, um zu sehen, welche Schritte direkt via API statt über UI-Klicks erledigt werden können.

54

* Mapping-Tabellen: Es müssen Tabellen erstellt/hinterlegt werden für geografische Regionen (Welches Bundesland ist welche Region?), Prioritäten und Fehlerarten (Fault Types).

55

* "Human in the Loop"-Prozess: Wie genau wird der RPA "Task Handling" Prozess aussehen, bei dem der Bot eine Aufgabe an einen Menschen übergibt (z.B. bei Widersprüchen in der Ticket-E-Mail), der Mensch diese per Klick löst und der Bot den Prozess fortsetzt?

56

* Nach der Pause: Im weiteren Verlauf des Meetings (nach der dokumentierten 15-minütigen Pause) sollen noch technische Risiken, KPIs, Governance und offene Fragen besprochen werden.

----

\\

1. Introduction and Meeting Goal

65

66

The meeting focuses on the detailed analysis and planned automation of the incident and dispatching process (ticket assignment) for Field Service Engineers. The goal is to develop a Minimum Viable Product (MVP) using Robotic Process Automation (RPA, specifically UiPath) to eliminate manual "copy & paste" tasks. The meeting is recorded to accurately document pain points and requirements.

67

68

69

1. Current Process & Tools

70

71

The core system for ticket management is Remo. The current, highly manual process looks as follows:

72

73

74

* Ticket Receipt: Notifications come in via email or API (currently only for one customer).

75

* Incident Creation: A NOC (Network Operation Center) agent manually creates an incident in Remo. Mandatory fields include customer, priority, fault type (e.g., climbing/non-climbing), address/location, product, and SLA (Service Level Agreement).

76

* Acknowledgement: After creation, an automated acknowledgement containing a reference number is sent to the customer.

77

* Spare Parts Check: The agent checks the free text of the email to see if spare parts are needed and compares this with the available inventory near the deployment site.

78

* Sub-Tickets & Dispatching: One incident can result in multiple sub-tickets (e.g., if two people are required for a task involving climbing). Technicians are assigned via a map view and shift schedules (e.g., 06:00 to 14:00 and 10:00 to 20:00) using drag & drop or manual time entry.

1. Customers & Input Channels

* Main Customers: Huawei, Hutchison (Hutch), Magenta, Nokia, Nomad, OMV.

87

* Smaller Customers: Colt, FON, DFAC.

88

* Interfaces: Only Hutchison uses a direct API interface to Remo (which already generates a draft ticket in the system). All other customers (about 10-12 in total) communicate via standardized or free-text emails. Telephone reports practically no longer occur.

89

* Huawei Specifics: Currently, only Huawei directly states the required spare parts in their emails. For other customers, this has to be clarified internally.

1. Automation Potential & MVP Focus

* MVP Focus: Automation will initially focus on the outsourced NOC in Serbia, which operates 24/7. Their main task is manually transferring email data into Remo (copy & paste) and dispatching emergencies outside regular working hours to on-duty technicians.

98

* UiPath / RPA: The bot is expected to read emails, fill in the standard mandatory fields in Remo (customer, region, priority, fault type), and handle the initial ticket creation.

99

* Parallel Bots: It was recommended to use at least two bots (one for oversight/management, one for execution) to prevent a bot from being blocked for months by a long-running ticket.

100

* Technology Mix: For unstructured emails (free text from end users), the use of LLMs (Large Language Models, e.g., in Azure) combined with UiPath is being discussed. However, economic aspects (costs for API calls / Azure infrastructure) must be taken into consideration here.

1. Challenges & Exceptions (Edge Cases)

* Data Quality & Logic:

109

** Conflicting Info: A ticket might request only one technician, but the free text states that a 20-meter ladder needs to be climbed (which strictly requires two people for safety reasons). In this case, an escalation to a human ("Human in the Loop") must occur.

110

** Unknown Location: If a location is not in the system, the placeholder "Unknown" must be used.

111

* Resources & Logistics:

112

** Spare parts must match geographically (e.g., Region 1: Lower Austria, Vienna, Burgenland). If high-priority parts are not available in the respective region, the SLA must be renegotiated with the customer.

113

** Complex route management and exceptions (e.g., need for a crane, extreme weather conditions, long travel distances) will remain with the human dispatcher for now, as the planning logic is too complex for the initial bot.

114

* Feedback Loops: If a technician on-site reports "It's too dark" or "Access is blocked (e.g., by cows)", this information must be processed by the system so the ticket doesn't stay open endlessly.

1. Project-Relevant Questions & Technical Details

* Can Remo create tickets directly from emails via API? Currently, there are no API fields available in the ticket handling system to populate everything directly (except for the specific Hutchison setup). UiPath will have to operate the UI (or verify available interfaces).

123

* How does dispatching work in the tool? Currently via drag & drop in a calendar/map view. Alternatively, a ticket can simply be selected and the start time entered manually via a menu, which is much easier and less error-prone for a bot to execute than drag & drop.

124

* How is the SLA calculated? By default, the system pulls the time from the priority; however, the customer often sends a hard deadline in the email. The bot/agent must overwrite the "Planned End" with the time limit specified by the customer.

1. Open Items & Next Steps

* API Check: The technical team (BCA) needs to review the document containing the available APIs to determine which steps can be handled directly via API instead of UI clicks.

133

* Mapping Tables: Tables must be created/provided for geographic regions (which state belongs to which region?), priorities, and fault types.

134

* "Human in the Loop" Process: What exactly will the RPA "Task Handling" process look like, where the bot hands over a task to a human (e.g., in case of logical contradictions in the ticket email), the human resolves it with a click, and the bot resumes the process?

135

* After the Break: In the remainder of the meeting (after the documented 15-minute break), technical risks, KPIs, governance, and open questions are scheduled to be discussed.

1. Comprehensive Meeting Summary

144

145

The meeting served as a kick-off and discovery session for an RPA (Robotic Process Automation) project using UiPath. The goal is to automate existing incident management and monitoring processes and to become more independent from a currently outsourced Network Operation Center (NOC) located in Serbia.

146

147

A. Process Analysis: Remote Door Opening (Site Access)

148

149

A specific process that needs to be automated or newly set up is the physical access for technicians to certain locations (approx. 10-15 sites in Austria).

150

151

152

* Initial Situation (Trigger): A client sends sensor data (e.g., air conditioning failure or power supply issues) via a monitoring tool ("RIMO") over a VPN. This generates an alarm.

153

* Current Workflow:

154

*1. An alarm is received (currently, the first-level response is handled in Serbia).

155

*1. The alarm justifies an on-site visit by a technician (internal or third-party).

156

*1. The technician arrives at the site and calls a number ("knocking") displayed on the door.

157

*1. The technician's authorization is verified against a list.

158

*1. The door is opened remotely.

159

* Special Requirement: Since this process is currently partially handled in Serbia, a new, automated solution must be found for this.

160

161

B. Incident Management & Ticketing Rules

162

163

164

* Standard Process: Normally, an incident/ticket is created based on an alarm. This should be maintained and automated.

165

* Exception (External Companies): If external companies are commissioned to resolve the issue, currently no incident is created; often, only an email is sent.

166

* Best Practice: The consultant (Speaker 2) strongly recommends always creating a ticket/incident for reasons of traceability (observability). Even if the problem resolution is outsourced, the process must be documented and the end customer informed.

167

168

C. "BOS" Project & Security Constraints (Very Important!)

169

170

171

* Extremely high security requirements apply to a specific customer (project name "BOS").

172

* Constraint: All data for this customer must remain in Austria. The team in Serbia is not allowed to see this data.

173

* Current Status: Currently, there is a manual workaround in place where the Serbian team operates "blindly" (they organize things but do not see the content).

174

* Goal: The new RPA solution (on-premise) is intended to replace this workaround. Certain sensitive information must be masked/blacked out during the process.

175

176

D. Implementation Strategy & UiPath Setup

177

178

179

* Design First: The team will first create a detailed design document (including screenshots and exact process steps). Development will only begin after this document is approved ("Decision Point"). The scope will be strictly frozen by this document.

180

* Infrastructure & Setup (in parallel with the design):

181

** Provisioning of the virtual machine (VM) / workstation.

182

** Setup of access points, user accounts, and logins.

183

** Creation of a generic service email account (e.g., Automation@...) for UiPath.

184

** Installation of the UiPath robot. The license trial phase will only be started once the robot is actually in use.

185

* Process Splitting: The consultant suggests building the robot in a modular way (e.g., one sub-process handles only incoming emails, another creates the tickets).

186

* Historical Data: The automation will not be trained with historical data for now (even though a Data Warehouse is available). The robot will be configured using a classic rule-based approach ("Click here, type this").

187

188

E. Timeline, Priorities & Training Phase

189

190

191

* Timeline: The original proposal suggested an implementation time of 4 + 6 weeks. The consultant indicates that they need another 1 to 2 weeks to finish their familiarization with the UiPath Academy.

192

* Customer's Priorities:

193

** Quality over speed: Since the process controls critical incident management, there must be no errors (end-customer penalties threaten). If development takes longer, this is acceptable provided there is prior communication.

194

** Independence from the external NOC: The outsourced Network Operation Center should be replaced by automation as quickly as possible.

195

** Further optimizations: Fine-tuning will take place only after that.

196

* Knowledge Transfer: The development team is to closely involve the internal project manager (Speaker 2) in the development so that they understand the configuration and can maintain the system in the future. Testing phases are considered very resource-intensive but essential.

197

* Project-Relevant Questions (Meeting Q&A)

198

* Question (Consultant): How does the automation know there is an alarm? Does it come via email?

199

** Answer (Customer): No, the alarm comes from a customer monitoring tool called "RIMO" via a VPN connection.

200

* Question (Consultant): When the alarm arrives, do we always have to create an incident and sub-ticket? Is it always the same process?

201

** Answer (Customer): Generally yes, except for external subcontractors, where often only an email is sent. However, the consultant recommends ticket creation in the future (for observability).

202

* Question (Consultant): What type of account should we use for UiPath? A personal or a service account?

203

** Answer (Customer): A new, dedicated service email address (e.g., Automation@...) should be set up.

204

* Question (Consultant): Should the UiPath robot be trained with historical data?

205

** Answer (Customer): Not for now. If needed later, data can be exported from the Data Warehouse.

206

* Question (PM/Speaker 3): How far along are you (Consultant) with the UiPath Academy (training)? Should we involve you in the early phases?

207

** Answer (Consultant): I still need 1-2 weeks. Yes, please involve me in the configuration so I can learn to understand the system as it grows.

208

* Question (Consultant): To which company address should the NDA (Non-Disclosure Agreement) be issued?

209

** Answer (PM): To "BCA Digital" (registration number and address remain the same).

1. Open Points & Next Steps (To-Dos)

214

1. Sign NDA: The NDA for "BCA Digital" needs to be sent as a Word file, printed, signed, and scanned. (This was initiated directly at the end of the meeting).

215

1. Create Design Document: The development team will create the detailed process description (including screenshots and authorization logic).

216

1. Set up Infrastructure:

217

1*. Provision the virtual machine / workstation.

218

1*. Create the UiPath service email account ("Automation@...").

219

1*. Set up VPN access, system logins, and permissions.

220

1*. Install the UiPath robot on the machine (the trial license will be activated later).

221

1. Information Gathering: The customer will promptly provide contracts, SLAs, and sample emails to help map out the process logic more accurately.

222

1. Define BOS Project Specifications: Determine exactly how the data in the "BOS Project" needs to be masked to ensure the data does not leave Austria.

223

1. Organize Training Setup: Define meetings/processes to train the internal project manager (Speaker 2) on the UiPath system configuration.

224

1. Clarify Responsibilities: It needs to be defined exactly who will handle the testing (which was identified as being resource-intensive).

----

=== 2. Umfassende Zusammenfassung des Meetings ===

232

233

Das Meeting diente als Kick-off und Discovery-Session für ein RPA-Projekt (Robotic Process Automation) mit UiPath. Ziel ist es, bestehende Incident-Management- und Monitoring-Prozesse zu automatisieren und sich von einem derzeit ausgelagerten Network Operation Center (NOC) in Serbien unabhängiger zu machen.

234

235

==== A. Prozess-Analyse: Remote-Türöffnung (Site Access) ====

236

237

Ein spezifischer Prozess, der automatisiert bzw. neu aufgesetzt werden soll, ist der physische Zugang für Techniker zu bestimmten Standorten (ca. 10-15 Standorte in Österreich).

238

239

240

* Ausgangslage (Trigger): Ein Kunde sendet Sensordaten (z. B. Ausfall der Klimaanlage oder Stromversorgung) über ein Monitoring-Tool ("RIMO") via VPN. Dies generiert einen Alarm.

241

* Derzeitiger Ablauf:

242

*1. Alarm geht ein (derzeit Erste-Hilfe-Reaktion in Serbien).

243

*1. Der Alarm rechtfertigt einen Vor-Ort-Einsatz eines Technikers (intern oder von Fremdfirmen).

244

*1. Der Techniker kommt an den Standort und ruft eine Nummer an ("knocking"), die an der Tür steht.

245

*1. Die Autorisierung des Technikers wird anhand einer Liste geprüft.

246

*1. Die Tür wird aus der Ferne (remote) geöffnet.

247

* Besonderheit: Da dieser Vorgang momentan teils in Serbien abgewickelt wird, muss hierfür eine neue, automatisierte Lösung gefunden werden.

248

249

==== B. Incident Management & Ticketing-Regeln ====

250

251

252

* Standard-Prozess: Normalerweise wird basierend auf einem Alarm ein Incident/Ticket erstellt. Dies soll beibehalten und automatisiert werden.

253

* Ausnahme (Externe Firmen): Wenn externe Firmen zur Problemlösung beauftragt werden, wird derzeit kein Incident angelegt, sondern oft nur eine E-Mail geschrieben.

254

* Best Practice: Der Berater (Sprecher 2) empfiehlt dringend, aus Gründen der Nachvollziehbarkeit (Observability) immer ein Ticket/Incident zu erstellen. Auch wenn die Problemlösung extern stattfindet, muss der Prozess dokumentiert und der Endkunde informiert werden.

255

256

==== C. Projekt "BOS" & Security-Constraints (Sehr wichtig!) ====

257

258

259

* Für einen speziellen Kunden (Projektname "BOS") gelten extrem hohe Sicherheitsanforderungen.

260

* Constraint: Alle Daten dieses Kunden müssen in Österreich bleiben. Das Team in Serbien darf diese Daten nicht sehen.

261

* Aktueller Status: Momentan gibt es hierfür einen manuellen Workaround, bei dem das serbische Team "blind" agiert (sie organisieren Dinge, sehen aber keine Inhalte).

262

* Ziel: Die neue RPA-Lösung (On-Premise) soll diesen Workaround ablösen. Bestimmte sensible Informationen müssen im Prozess maskiert/geschwärzt ("blacked out") werden.

263

264

==== D. Implementierungs-Strategie & UI-Path Setup ====

265

266

267

* Design First: Das Team erstellt zunächst ein detailliertes Design-Dokument (inkl. Screenshots und genauen Prozessschritten). Erst nach Freigabe dieses Dokuments ("Decision Point") beginnt die Entwicklung. Der Scope wird durch dieses Dokument fest eingefroren.

268

* Infrastruktur & Setup (Parallel zum Design):

269

** Bereitstellung der virtuellen Maschine (VM) / Workstation.

270

** Einrichtung von Access Points, User Accounts und Logins.

271

** Erstellung eines generischen Service-E-Mail-Accounts (z. B. Automation@...) für UiPath.

272

** Installation des UiPath-Robots. Die Lizenz-Trial-Phase wird erst gestartet, wenn der Roboter tatsächlich genutzt wird.

273

* Prozess-Splitting: Der Berater schlägt vor, den Roboter modular aufzubauen (z. B. ein Teilprozess bearbeitet nur den E-Mail-Eingang, ein anderer Teilprozess erstellt die Tickets).

274

* Historische Daten: Die Automatisierung wird vorerst nicht mit historischen Daten trainiert (obwohl ein Data Warehouse vorhanden wäre). Der Roboter wird klassisch regelbasiert konfiguriert ("Click here, type this").

275

276

==== E. Timeline, Prioritäten & Trainingsphase ====

277

278

279

* Timeline: Der ursprüngliche Vorschlag war eine Implementierungszeit von 4 + 6 Wochen. Der Berater gibt an, für die Einarbeitung in die UiPath-Academy noch 1 bis 2 Wochen zu benötigen.

280

* Prioritäten des Kunden:

281

*1. Qualität geht vor Geschwindigkeit: Da der Prozess das kritische Incident Management steuert, darf es keine Fehler geben (Pönalen durch Endkunden drohen). Wenn die Entwicklung länger dauert, ist das nach vorheriger Kommunikation akzeptabel.

282

*1. Unabhängigkeit vom externen NOC: Das ausgelagerte Network Operation Center soll so schnell wie möglich durch Automatisierung ersetzt werden.

283

*1. Weitere Optimierungen: Erst danach erfolgen Feinjustierungen.

284

* Know-how-Transfer: Das Entwicklungsteam soll den internen Projektleiter (Sprecher 2) eng in die Entwicklung einbinden, damit dieser die Konfiguration versteht und das System künftig warten kann. Testphasen werden als sehr aufwendig, aber essenziell eingestuft.

----

=== 3. Projekt-relevante Fragen (Q&A aus dem Meeting) ===

289

290

291

* Frage (Berater): Woher weiß die Automatisierung, dass es einen Alarm gibt? Kommt das per E-Mail?

292

** Antwort (Kunde): Nein, der Alarm kommt aus einem Kunden-Monitoring-Tool namens "RIMO" über eine VPN-Verbindung.

293

* Frage (Berater): Wenn der Alarm kommt, müssen wir dann immer ein Incident und Sub-Ticket erstellen? Ist das immer derselbe Prozess?

294

** Antwort (Kunde): Grundsätzlich ja, außer bei externen Subunternehmern, da wird oft nur eine E-Mail geschrieben. Der Berater empfiehlt hier künftig dennoch die Ticket-Erstellung (Observability).

295

* Frage (Berater): Welche Art von Account sollen wir für UiPath verwenden? Ein persönliches oder ein Service-Konto?

296

** Antwort (Kunde): Es soll eine neue, dedizierte Service-E-Mail-Adresse (z. B. Automation@...) eingerichtet werden.

297

* Frage (Berater): Soll der UiPath-Roboter mit historischen Daten trainiert werden?

298

** Antwort (Kunde): Vorerst nicht. Falls später benötigt, können Daten aus dem Data Warehouse exportiert werden.

299

* Frage (PM/Sprecherin 3): Wie weit bist du (Berater) mit der UiPath Academy (Schulung)? Sollen wir dich in die frühen Phasen einbinden?

300

** Antwort (Berater): Ich brauche noch 1-2 Wochen. Ja, bitte bindet mich in die Konfiguration ein, damit ich das System beim Wachsen verstehen lerne.

301

* Frage (Berater): An welche Firmenadresse soll das NDA (Non-Disclosure Agreement) ausgestellt werden?

302

** Antwort (PM): An "BCA Digital" (Registrierungsnummer und Adresse bleiben gleich).

----

=== 4. Offene Punkte & Next Steps (To-Dos) ===

307

308

309

1. NDA unterzeichnen: Das NDA für "BCA Digital" muss als Word-Datei geschickt, ausgedruckt, unterschrieben und eingescannt werden. (Wurde am Ende des Meetings direkt in die Wege geleitet).

310

1. Design-Dokument erstellen: Erstellung der detaillierten Prozessbeschreibung (inkl. Screenshots und Logik für Autorisierungen) durch das Entwickler-Team.

311

1. Infrastruktur aufbauen:

312

1*. Virtuelle Maschine / Workstation bereitstellen.

313

1*. UiPath Service-E-Mail-Account anlegen ("Automation@...").

314

1*. VPN-Zugänge, Systemlogins und Berechtigungen einrichten.

315

1*. UiPath-Roboter auf der Maschine installieren (Trial wird später aktiviert).

316

1. Informationsbeschaffung: Der Kunde wird zeitnah Verträge, SLAs und Beispiel-E-Mails zur Verfügung stellen, um die Prozesslogik besser abbilden zu können.

317

1. BOS-Projekt Spezifikationen definieren: Festlegen, wie genau die Daten im "BOS Projekt" maskiert werden müssen, damit sichergestellt ist, dass die Daten Österreich nicht verlassen.

318

1. Trainings-Setup organisieren: Termine/Prozesse definieren, um den internen Projektleiter (Sprecher 2) in die Systemkonfiguration von UiPath einzuarbeiten.

319

1. Zuständigkeiten klären: Es muss definiert werden, wer genau das Testing übernimmt (wurde als ressourcenintensiv identifiziert).

----

== Verwandte Themen ==

324

325

//Kuratiert — kann direkt im Editor ergänzt werden://

326