本文详细介绍了UiPath项目的组织和管理，包括理解自动化过程选择FOR或BOR，文档记录，如解决方案设计文档（SDD）和过程设计指令（PDI），项目结构的规划，使用源代码控制，设置上下文参数，凭证管理，代码审查，自动化维护性检查，测试策略，错误处理，以及保持工作流清洁等关键环节。强调了采用BOR以提高效率和ROI，以及使用配置文件或Orchestrator资产存储外部设置的重要性。
3.1 Understanding the process
FOR or BOR? Deciding between an automation for front office robots (FOR) or back office robots (BOR) is the first important decision that impacts how developers will build the code. The general running framework (robot triggering, interaction, exception handling) will differ. Switching to the other type of robots later may be cumbersome.
For time critical, live, humanly triggered processes (e.g. in a call center) a Robot working side by side with a human (so FOR) might be the only possible answer.
But not all processes that need human input are supposed to run with FOR. Even if a purely judgmental decision (not rule-based) during the process could not be avoided, evaluate if a change of flow is possible - like splitting the bigger process in two smaller sub-processes, when the output of the first sub-process becomes the input for the second one. Human intervention (validation/modifying the output of the first sub-process) takes places in between, yet both sub-processes could be triggered automatically and run unattended, as BORs.
A typical case would be a process that requires a manual step somewhere during the process (e.g. checking the unstructured comments section of a ticket and - based on that - assign the ticket to certain categories).
Generally speaking, going with BOR will ensure a more efficient usage of the Robot load and a higher ROI, a better management and tracking of robotic capacities.
But these calculations should take into consideration various aspects (a FOR could run usually only in the normal working hours, it may keep the machine and user busy until the execution is finished etc.). Input types, transaction volumes, time restrictions, the number of Robots available etc. will play a role in this decision.
This decision is not entirely the developer’s responsibility, but he/she is the most knowledgeable person to evaluate (from the early process assessment stages), what’s possible from the UiPath technical point of view.
3.2 Documenting
Process documentation will guide developer's work, will help in tracking the requests and application maintenance. Of course, there might be lots of other technical documents, but two are critical for a smooth implementation: one for setting a common ground with the business (solution design) another one detailing the RPA developer work (design instructions).
Solution Design Document (SDD) - its main purpose is to describe how the process will be automated using UiPath. This document is intended to convey to the Business and IT departments sufficient details regarding the automated process for them to understand and ultimately approve the proposed solution. Critically, it should not go into low-level details of how the UiPath processes will be developed, as this is likely to cloud the cli
最低0.47元/天 解锁文章
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
