Building a cyborg team

Imagine you are a manager of a high performing team. You’ve spent years learning the fine art of leading, mentoring and instructing people from all walks of life. You’ve used varying communication techniques across coffee catch ups, formal meetings, emails and phone calls in order to ensure that your team performs.

In recent years however, the concept of a “virtual workforce” has emerged and you feel that the time is right for your team to consider utilizing these technologies to remove the effort spent on transactional, high volume, low value tasks. It’s an exciting change that your team are eager to embrace.

As expected, adopting a robot into the team poses some challenging questions; your management style won’t translate into the virtual domain so how can you best prepare yourself for this change? What tools and processes need to be defined to make the transition as smooth as possible?

1. Use robot activity logs and supporting dashboards

Robots should be built to record every activity and key decision that it makes for each transaction. These records should also be date and time stamped so that metrics such as number of transactions completed per day and time spent on each transaction can be easily reported. Not only will this enable you to keep track of what your robot is working on, it will allow you to track any expected benefits i.e. has the robot completed more transactions in a more time efficient manner then your human team members? Has the amount of effort previously applied to this process by your team lessened significantly?

Activity logs should also record when a transaction has been unsuccessful and, where possible, why. Was a variable identified in an incorrect format? Or was the information provided to the robot incomplete? By recording these findings, you and your team will be able to investigate any systemic process issues and identify any patterns that allow for additional functionality to be built into the robot.

Activity logs can be augmented with dashboards to simplify the presentation of data (particularly in an activity log with thousands of transactions) – this could assist you in obtaining key performance information quickly.

2. Clearly define roles and responsibilities

As the manager/process owner, you need to ensure that there is clarity regarding who is responsible for what aspect of the robot’s functionality. For example, if your robot is triggered by a specific input file, who is responsible for ensuring that the input file is provided – you or your robot support team? If your robot fails to run today because of a server issue, who is responsible for investigating and resolving it, your team or your IT function? By ensuring that all parties are aware of their roles and responsibilities, any robot issues that you encounter will be resolved in a timelier manner with less confusion.

3. Clearly define escalation processes

Linked to point no. 2 above, all parties involved in the maintenance of your robot need to agree on the escalation processes so that issues can be managed and resolved in a timely manner. Key questions to consider include:

  1. Who is responsible for investigating which type of issue in the first instance? Who should the issue be escalated to if it cannot be resolved?
  2. What tool or interface will be used to record, monitor and escalate issues? Extending the functionality of an existing service management tool may be easier to implement and would allow for effective reporting
  3. What will need to be communicated to the process owner and end users of the robot while the issue is being resolved? What channel will be used to convey this information? Will it be integrated into your service management tool or will separate emails need to be sent?
4. Establish Service Level Agreements (SLAs)

As with all support functions, SLAs need to be defined to measure two things:

  1. The robot’s performance – it is important to define this SLA so that the robot’s performance can be monitored against an agreed metric. Knowing that there is an expectation for a robot to execute before 9am every day, at least 95% of the time, provides the support team with an understanding of the manager/process owner’s expectations. It also provides an avenue for the manager/process owner to provide feedback to the support team if these metrics are not being met.
  2. The turnaround timeframes for issue resolution – the required resolution timeframe may differ depending on the criticality of the process that the robot is executing. Having this agreed will assist the support team in prioritising their work and ensures that the manager/process owner’s expectations are effectively managed.

All of these components are imperative to supporting managers with their new virtual team members. All RPA implementation projects should include these tools within change management and training prior to go-live, enabling managers to manage their robots independently and effectively from Day One.

Although these tools will set you up for success, do not undervalue or neglect your leadership skills; these will still need to be harnessed to ensure that your wider team are able to effectively adapt to their new working arrangement. By involving them in the development of the robot, being transparent about the robot’s scope and expected benefits and providing an avenue for your team to discuss their concerns, you will reduce any uncertainty that may be experienced during this period of change.

Visit the Analytics and Exponentials page to explore our latest thought leadership on this topic.

Want to stay up-to-date?

Stay on trend and in the know when you sign up for our latest content