UIPath进阶教程-3-Project Organization

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