Professional Documents
Culture Documents
Contents
Introduction .................................................................................................................................................................1
Triage 1 .........................................................................................................................................................................1
Step Types ................................................................................................................................................................1
Triage 2 .........................................................................................................................................................................3
Triage 3 .........................................................................................................................................................................4
Summary ......................................................................................................................................................................5
Introduction
This guide is intended as an aide to creating a Blue Prism solution and in particular presents a technique for
deconstructing an AS IS process definition into TO BE automation steps, from which a design and development
plan can be devised.
In essence the technique is to repeatedly revise a list of AS IS steps until a picture of the corresponding TO BE
steps emerges. Depending on the project at hand, the number of revisions required may vary.
An imaginary AS IS definition will be used to illustrate the concept, where the document has page numbers and
reference numbers that can be used when performing the triage.
It is assumed the reader has completed the Blue Prism developer course (Foundation Training plus mandatory
guides) and is familiar with process definition and solution design concepts.
Triage 1
The aim of the first triage is simply to list all the steps in the AS IS definition, identifying which application is
being used and what generic type of activity is involved in each step.
Step Types
Here is the list of generic AS IS step types and examples.
Triage 2
The next triage is to enhance the list with intermediate steps until all are categorised as Read, Write, Update
Record or Process Data and none are left as Multi System or Multi Type.
1. Insert a column called Automation Step.
2. Break any AS IS steps classed as Multi System or Multi Type into smaller automation steps.
3. Insert rows to accommodate additonal automation steps.
4. Keep breaking down the steps until there are no more Multi steps.
5. If a step does not involve any application, then enter Process as the System.
6. Pay attention to and highlight any Update Record steps.
Triage 3
The third triage involves adding more detail about each step, where a case could be classed as a business
exception, or if the logic to perform a step already exists, either within the current list or has already been
developed for a previous project.
1. Insert columns called Business Exception, Duplicate Step, New Logic and Existing Logic.
2. For Business Exception, describe which business exceptions could be a result of the step.
3. For Duplicate Step, indicate whether the step reappears elsewhere in the list.
4. For New Logic, indicate whether the step logic will need to be created.
5. For Existing Logic, indicate whether the step logic can be re-used from an existing project.
By this stage what should become apparent is that the list starts to resemble a ‘bill of materials’ for the TO BE
solution. As mentioned above, it may be necessary to perform more than three iterations, each time refining
the list and breaking steps down into more and more precise and singular actions.
Once the list cannot be refined any more, the separation between application logic and process logic should be
clear, providing the delivery team with a foundation from which to create or update Object Definition
Instructions, Process Development Instructions, delivery plans, estimates and trackers, test and acceptance
plans, exception dictionaries and object libraries.
Summary
• The triage technique is based on an AS IS process definition.
o If the AS IS definition is not yet finished or approved, the triage may need adjustment once the
definition is signed off.
o Output from the triage does not need approval, although obviously the subsequent solution
design will need to go through the normal delivery control gates.
• The technique involves refining the list into ever smaller steps until all steps can be classified.
o The classification should bring clarity on how to procede with delivery.
• The potential advantages of the technique are as follows:
o Visibility and quantification of the effort ahead.
o Improved accuracy in effort estimation.
o Avoidance or reduction of duplication.
o Maximised re-use for faster delivery.
o Easier collaboration and distribution of delivery tasks.