By the time we reach this stage, there is already a high level of confidence that the process has been accurately captured and that the technical design is feasible and achievable. In our early days of automation, a single developer would own this entire stage. We found that sharing the development across the wider team promotes knowledge sharing and improves interaction amongst the team. It also means that everyone can develop and support all aspects of the process.
The team try to develop using Thoughtonomy's / Blue Prism Cloud's best practice techniques and standards. Anyone can build bot processes, but it can take a little more thought to create a process that offers a low exception rate from the point of go-live. For our processes, It is typical to see an initial exception rate of less than 3%. Exceptions are analysed and reviewed during the post-go-live stabilisation phase to reach a target of less than 1%.
While developing code is not an exact science, the team found a structured approach to development made sense.
Consider which data items are needed for the process and plan. For data inputs, especially inputs from OCR or structured data sources, we create data schemas. The schema defines naming conventions, data types, data descriptors, and into which data collections the data will be stored and manipulated. In some of our earlier processes, naming conventions were not consistent, and data flow between pages was unclear. No one other than the creator of the bot code could develop and support the process.
Understanding data structures and especially defining how sensitive personally identifiable data (PID) will be managed, stored and manipulated lowers the risk of misuse but also satisfies internal information governance (IG) that the development team are being responsible with the data being used. This approach also aids processes that require clinical safety scrutiny and sign-off.
An object teaches the robot how to interact with the target application. Objects are generally created one per application screen and only contain the actions required to support the process. This ensures processes run at optimum speed, and we are not storing unused object actions in memory.
To minimise exceptions, some resilience is built into our objects. Connecting to and activating application windows is defined in primary and secondary modes to increase the likelihood of success.
By the time the first few object actions have been created, it is known precisely the challenge we need to deal with. Sometimes applications do not behave as expected, and a more advanced method of automation is necessary. This is why we create a test object during the process deep dive, so any difficulties are known upfront. The last thing I want to do is to commit to a four-week development cycle and then discover I need to do some surface automation!
As with object design, we try to incorporate as many best-practice standards as possible. Our objective is to create bot code that is logical, fast and efficient and can be visually understood by a competent developer.
With the plan to share processes and objects through the NHS marketplace in 2020 with other public sector organisations it will be a 'challenge to ensure all participating organisations develop to the same standard and in the same way.
Thoughtonomy's wire-framer will help considerably here. The wire-framer allows the developer to carefully plan the process through a design portal and with a click of a button, the wire framer will generate templates for objects and processes in the most optimal way. The developer still needs to add the finer detail and apply logic. This technique will make collaboration and sharing of code more straightforward.
Developing processes and objects is a massive subject. This blog is just a high-level overview to explain the six-stage development process. Future blogs will explore more technical parts of the platform.
The next blog in this series will talk about testing - I hope you found something useful here!