Conversion Playbook

Converting a robot from one technology to another is usually not a flick-of-a-switch type of effort, but it might not be as intimidating as people tend to think.

In this documentation, we collected a set of best practices and guides to help eliminate some assumptions we have seen hindering the process and just to reduce conversion anxiety. 😉

It is good to note that most of the guides below fit directly into new automation projects.

Checklist for your conversion project

Know the process.

In general, as you have the process implemented once, you are a lot further than starting from scratch; that is, you should already know why the process has been automated and what value is it generating.

1. Start with a simple "Why?"
   • Above any documentation or implementation defining why the process exists in the first place in three sentences or less is absolutely worth it.
   • The 'why' should not go into any technical details, just stating who needs or benefits from the automation and how is enough; this gives everyone involved the common goal.
   • From the simple why you should be able to deduce the value proposition of the automation and therefore the value proposition of converting it.
   • Examples:
     • Handling the order releasing with automation means 50 production planners will save 15 minutes to an hour every day and can focus on handling the true edge-cases.
     • Having the incoming emails pre-processed at the beginning of the workday enables the customer service directly start working with customers with better accuracy, instead of spending the first hour each day sorting emails
2. Collect the existing documentation and knowledge
   • As with any automation process, having up-to-date documentation is always a big plus.
     • ...but expect the documentation not to be entirely up to date.
     • Always get a person who can walk you through the process as well.
   • Collect the latest process descriptions (PDDs)
     • Any other documentation, for example, videos describing the process
     • Screenshots or access to the original workflows, for example, in Blue Prism or Automation Anywhere
   • Recording the process or recording an interview with the person who does this every day is ideal.
     • This helps developers in the future and can be reviewed without having to ask the person the same information again and again.
   • Visualize the wanted high-level process early on
     • A really valuable way of doing this is to place this where the robot implementation will reside
     • GitHub and GitLab support Mermaid tooling, which provides a really fast way of writing diagrams into markdown files, making them easy to update and always be available right next to the robot.
   • Collect the list of target systems and applications used by the bot
   • Collect the list of crucial contacts for the bot, that is, people using the end results
   • Export of the bot itself.
     • The Robocorp Conversion Accelerator can help get out what the bot is currently really doing.
   • Collect the documentation and contacts on the test environments/infrastructure and test data
     • Any documentation on User Acceptance Testing (UAT) is invaluable if it is up-to-date
   • Collect the documentation and contacts on the existing infrastructure for the bot
     • We recommend NOT leaving IT out of the loop.
   • For all of the above, we heavily recommend collecting this list as close to the robot logic as possible
     • Documentation that you cannot find or is out-of-date is usually worse than not having the documentation at all
     • We recommend using the existing version control system like GitHub or GitLab and placing the above documentation (or links to them) in a readme.md markdown file in the root of your robot repository.
     • The markdown files are nicely rendered by GitHub and GitLab websites, meaning you can share just a normal browser link to the documentation.
3. Re-evaluate the process
   • For any bot, it is worth checking if it is still worth automating
     • Business needs and applications change more rapidly every year, so do not assume anything.
     • Check if the process is still what the end-users want and need from it.
   • The term big robot can mean very different things to different people.
     • A robot with a ton of runtime might be a simple bot used a lot and provides a lot of ROI. Vice-versa, a vast complex bot might only run once a month, so the ROI value is always good to keep in mind.
   • Some common things to look out for:
     • Cleanup the bot, getting rid of legacy code or dead-code in the bot before starting the conversion is always a good practice.
       • Use the original tool for this whenever possible.
       • You should be doing this even if you are not doing conversion... we've seen things.
     • Can the project be bypassed by writing a new, smaller bot using new APIs and access avenues?
     • Note that many desktop applications have moved to the web, allowing direct integrations between systems
     • If data retrieved from an application is now available via API, you can save days or weeks of conversion work AND execution time will drop drastically.
     • If the source data is now available in a database or via API, then parsing it from PDFs is a waste of time.
     • In general, if there is no mandatory reason to use or printout PDFs or other document files, it is always good to avoid them... as you might be the one translating them a few months down the line 😉

Evaluate over multiple processes

This is the key to figuring out a good spot to start from. Finding a common step in multiple bots, converting that, and comparing the results is usually the path of the smallest risk.

Even something as simple as sending an Email can get you started.

Compare multiple robots enables you to find the common components like:

• "Basic file handling is the same in all of these"
• "Login to SAP is always the same"
• "We are using Sharepoint in all bots"

This comparison will help you determine code reuse and the best structure for "doing things only once".

This kind of evaluation also highlights the standards and practices used in Blue Prism that will affect the work amount needed in the conversions. With the comparison results in hand, it is also good to check out the existing implementations available "out-of-the-box" like rpaframework and 3rd party libraries, to name a few.

You can use the Robocorp Conversion Accelerator to "harmonize" bots to Robot Framework format to simplify comparisons.

Tip: We recommend starting from some common component and a bot using it.
When you get to the bigger robots (in terms of lines of code), you probably have many re-usable items under your belt, making the bigger ones easier to digest.

The main drivers for the guides and tooling are to give the confidence of where and how to start converting and evaluate what is worth converting.

One thing to "convert" is the mindsets and learned behaviors of "working around" the licensing restrictions. We have seen a bunch of bots now that have ended up having everything crammed into a single colossal bot. The clear reason in some of these cases has been the need to manage the limitations coming from either licenses or the machines required for the executions. Executing bots not just in Cloud Containers in parallel but also running multiple executors on a single Windows VM enables you to figure out a better bot design that can yield significant performance improvements.

Reach out to us if you'd like our help performing a bot commonality analysis for conversions!

Start converting your first process (or bot)

While you can just get to work, running the Conversion Accelerator -tool and start making the conversion, there are a few steps we heavily recommend before jumping in.

• A clear first step would be to set up a Git repository for your bot via GitHub or GitLab.

  • Getting the README.MD markdown file in the root of the repository, as stated in the Know your Process -chapter, enables you to collect the documentation right next to the robot and save a lot of time.
  • People who are working with the bot need the documents next to them as much as possible without having to jump around between systems.

• Define a test infrastructure and data

  • Typically, for conversion projects, the production needs to run on the old bot before jumping to the new.
  • Setting up or defining the test infrastructure and data to validate the conversion is the key to success.
  • Test infrastructure allows the maintenance and further developments in a much more secure fashion.
  • Test infrastructure allows the IT to set up the production infrastructure and introduce target system updates in a controlled manner.
  • Test infrastructure also includes figuring out the testa data that can be used to evaluate and validate the new bot
    • Any existing User Acceptance Testing (UAT) documentation is worth a LOT in here.. if it is up-to-date.
    • Obsolete test data will cause significant problems, so verify the data with your end-users.

• Cleanup the bot

  • Getting rid of legacy code or dead-code in the bot before starting the conversion is always a good practice.

• Get familiar with the conventions used in the initial bot code and in Robot Framework to simplify automation through robot syntax

  • For example, Blue Prism has a lot of concepts that are just a lot simpler when moving to code.

• Robocorp Conversion Accelerator gives you scaffolding based on your Blue Prism project export to get you started.

• Think outside the box

  • It is really easy to convert to bot just as-is, but you are most likely leaving a lot of performance and simplicity on the table.
  • You can handle most web automation, data scraping, email handling, Excel and database data tasks in Cloud containers which will save a lot of hard cash from the infra maintenance.
  • Identifying parts of the bot that can be executed in parallel will save a lot of actual "wall time" which in some cases can make or break the validity of the entire process.
    • Without license restrictions, the amount of executors is no longer a limitation; it is a possibility.

• Consider the maintenance

  • ...as it can be you doing it in 3-6 months 😉
  • In general, thinking about how the bot will be maintained is a key part of any implementation.
  • If the bot you are converting has been a brittle one that has caused a lot of support work, this is the time to fix it.
  • Having a bot that is easy to support and extend will pay back the initial investment many times over.

Test and agree on maintenance model

"The Only Constant in Life Is Change." - Heraclitus

It is good to know how often and by who the bots and infrastructure around them are maintained. Maintenance cycles that converge on a single time, usually at midnight during a weekend, have been known to happen 😉.

• How does IT notify of updates to the target systems or applications?
• How do business users / end-users notify about change needs to the automation?
• How do developers notify and update the bots?
• How are urgent incidents notified and handled?

All of the above have to do with people knowing who to contact and giving as much lead time as possible to make needed changes. Checking this list will also guide your development in setting up the correct access policies and possible DevOps processes that fit the needs of the end-users. Doing this right on the business level enables correct resourcing so that your developer does not end up swamped by maintenance and change work blocking all new development.