own methodology and documentation to work for RPA. It is the purpose of the documentation that is important, the documents themselves are merely vehicles - for defining requirements, exposing detail and for reaching agreement. 11.1. ‘As is’ Definition and Requirements As mentioned elsewhere in this document, the Process Definition Document (PDD) is used to describe the ‘as is’ manual process. This information may already exist in Statements of Procedure (SOP) or other process documentation, but it should be in sufficient detail that an unthinking robot could be instructed to work the process. In tandem with the definition of the manual process, the process owner’s wishes for the automated solution should be docum ented. The Functional Requirements Questionnaire (FRQ) isn’t used to describe how the automated solution will work cases, but rather it is a means of interviewing the process owner to extract high- level requirements of how they would like the solution to operate. For example, should it run during business hours Monday to Friday, or to some other schedule, how should exception be communicated? 11.2. ‘To be’ Design With the PDD and the FRQ complete, the designer can translate the information into Solution design Document (SDD). We have found that separating the ‘as is’ and the ‘to be’ into different documents to be a great defence against misunderstandings and omissions. As with the PDD, walking through the SDD in a workshop scenario is also a great way of not only explaining the proposal but also of exposing any shortcomings. The SDD also gives the Development Lead the chance to assess the quality of the proposed solution and check that full use of any existing logic (i.e. an object library) is being used and valuable project time will not be wasted. With the design signed off, development can be initiated via the Process Design Instruction (PDI) and Object Design Instruction (ODI). Both these documents are a means of the designer informing the developers how and what to build. 11.3. Shock Proof Design A design should be tested by theoretical ‘shock testing’. What is meant by this is to imagine how the solution will respond to a sudden blow, for example a network outage. Imagine that a process is midway through a case and all network communication is lost, database connectivity is lost, and the process terminates. When the network is restored, and the process is restarted, what will happen? What will happen to the previous case? If the process reworks it, will it duplicate steps or pick up where it left off? If applications have been left open, can the process deal with that? As well as a sudden event occurring mid-case, what if it happened while loading the queue, would duplicates be added or cases lost once the shock had abated? Although such imaginings may seem pessimistic, they may well be necessary if the consequences of a malfunctioning solution are serious enough.
Commercial in Confidence Page 24 of 27 11.4. Application Assessment Whenever a new target system comes into scope it is always worth while performing an application assessment.
You've reached the end of your free preview.
Want to read all 27 pages?
- Summer '09
- ramana rao
- Blue Prism