Getting Started with Blue Prism
Starting your journey with a Digital Workforce can be challenging. There is a lot to consider and to prioritize. This page covers some of the most commonly requested information for projects starting out. We have provided links to useful information based on your skill and a quick guide to what to look out for when you start.
Read our Getting Started FAQs to help you answer those questions you are likely to hear within your organization.
Need a bit more of a helping hand? Then join our 6-weeks ROM Essentials coaching program here.
We also recommend reading our page on the RPA Maturity Model Initialize phase which describes some of the key aspects of setting up for success early.
Finding the information relevant to you
- The Developer jump start (existing customers)
- The Developer roles
- Check out our list of ‘how to’ guides
- Building strong Solution designs
- Build best practices
- Customer support procedure and service centre
- Logging Best Practice
- Blue Prism Community Forum - share knowledge with other developers
- Blue Prism Online Help
- Check out our guide to Process Discovery
- Assessing applications
- Writing a Process Definition Document
- Gathering functional requirements
- Check out our Blue Prism University
- Blue Prism Community Forum - share knowledge with other Analysts
- Blue Prism basics
- Service FAQs
- Understanding the Control Room
- Understanding scheduling
- How to manage queues
- Getting help from Blue Prism Customer Support
- Blue Prism Community Forum - share knowledge with other Controllers
- Check how you can TEST the automated processes.
- USER ACCEPTANCE TESTING.
- BLUE PRISM COMMUNITY FORUM - share knowledge with other Test Analysts.
- Check what the UAT Sign Off should include to successfully test a process prior to deployment to the Production Environment.
Find out more about all the Skills and Responsibilities here.
What to look out for when you start
A low-level work instruction written as if it were to be given to someone with no prior experience of the applications, but has some software appreciation. The logic must be clearly defined and any decisions documented. Digital Workers only do what they are told, they are not intelligent, and therefore the instructions must be highly detailed 'one click' actions.
This is important because an incomplete or inaccurate PDD can lead to:
- Delays in development while gaps, inconsistencies or ambiguities are clarified
- Digital workers may execute incorrect processes if ambiguities are not identified
Without a well-defined process in place, fast and smooth development is not possible. This tends to be a big gap in many organizations.
Find out more here.
In most cases a process is developed against a development or pre-production environment. However, often the PDD is written against the live environment (understandably), which in many cases does not accurately reflect the development or pre-production environment (either the functionality or data).
It is recommended that if a PDD is written against the live environment, the document should be compared against the target development environment in order to highlight any differences and identify any missing functionality or data prior to submission to the Developers.
This is important because when a PDD is written against a live environment, but initial development is against a pre-production/development application and the environments are not identical this can cause considerable frustration for all stakeholders and is likely to lead to:
- Delays to development
- Delays in moving a process to production if it is unclear what changes will need to be made to match the environment
- Process errors if the functionality in one environment is not the same as the other.
Find out more here.
The PDD should be reviewed and signed off by the business process Subject Matter Expert (SME) prior to development. This ensures that there is a clear baseline for development and scope will not change and extend the development duration. Further extensions to the process should be managed as secondary phases to development under change control.
This is important because scope creep can cause multiple issues:
- Delays on initial estimate
- Frustration for the Developers as additional work is added or rework is required
- Frustration for the Client/Process SME
- Solution designs may require rework
- Initial metrics may require re-adjustment
- Possible impact to capacity planning
Find out more here.
The process is not outsourced to the RPA development/support team to own as they are not (in most cases) the process experts. Ownership remains with the team who performed the process manually. Where a process is new, the owner is the area who would have performed that task manually if RPA was not available. The Digital Workers should be looked at as resources augmenting the business team.
This is important because should there be an issue with the automation, the process will need to be performed by people with the requisite skills and knowledge in the relevant business area for business continuity purposes.
The business should be aware when there are changes required to a process, for example due to regulatory changes. They will need to raise change records to amend the process as required.
Before development commences it is important to collate quantitative metrics for that process such as current effort and frequency of task, peaks and troughs throughout the year and any times when a target application may be slower to respond.
This is important to:
- Provide a monthly run-time estimate ahead of development.
- Assist with capacity management of the Digital Workforce.
- Appropriately schedule the process automation.
- Establish a baseline from which to assess the success of the process automation.
Validate the business case for automating this process, if driven by cost saving rather than quality improvements.
Find out more here.
Instant direct access to the business process SME throughout the project is essential. This will minimize any delays caused by inconsistencies or unexpected obstacles (i.e. pop up boxes) during development. Equally the process SME should be someone who wrote or has had full visibility of the PDD and supports that approach.
It is also recommended that when an inconsistency is identified, the PDD is updated to reflect the solution and signed off by the SME.
This is important because:
- Having infrequent access to a process SME will inevitably delay development
- Having access to a Process SME who has not had sight of the PDD before or does not work the processes in the same way will lead to delays,friction and frustration
- It is not recommended that the Developers make their own assumption when something unexpected is encountered, unless they are the process SME as this could lead to inaccuracies.
Find out more here.
Test data should be available from the start of development to enable the automation build, as well as effective system testing throughout the build. RPA development teams rely on the data being available to build against.
As with training a new employee, a Digital Worker cannot learn a task if the data is not present to work against. If a process requires selecting a data type in a drop-down field for example and that data type is not available,development cannot be completed. Issues with data can be particularly impactful when developing against test or pre-production environments where the lack of test data often means a process can only be followed up to a point, with screens and navigation being different to those documented.
Find out more here.
Access to the target business applications is required for the Digital Workers. Access must be available prior to the development so the process can be 'walked through' by the Developer ahead of development to identify any possible idiosyncrasies in the process and to assist with the Solutions Design.
It is recommended, where possible, that each Digital Worker has their own login for an application in order to increase flexibility and auditability.
This is important because:
- Without access to the target applications the Digital Worker cannot perform the necessary tasks
- Providing multiple Digital Workers with individual logins improves auditability and flexibility
- It is important that human logins are not provided as this is a security risk and impacts auditability.
In addition, the correct permissions to allow the Digital Workers to perform the defined tasks must be in place ahead of development beginning. Without this it is not possible to walk-through or automate the process. Permissions should be granted in line with the relevant access management policy for the business.
This is important because:
- Permissions which are too limited to perform the task required will mean the automation cannot be performed
- Permissions which are too expansive and enable actions beyond the prescribed task may pose a security risk.
Find out more here.
When a process is automated and ready to deploy into production it is essential that there is a business continuity plan in place should the automation fail for any reason. The RPA team will need to know who to contact in the first instance. The process owner in the business must be prepared to manually complete the task until the issue is resolved.
This is important because:
- Minimize impact of failures
- Clarity for all stakeholders
Find out more here.
Blue Prism’s Success Accelerator program combines various levels of mentorship and access to our Expert Services, Technology Ecosystem and Certified Partners based on the size and maturity of your digital workforce operations.