Robotic Process Automation – licensing dangers
What is Robotic Process Automation?
Robotic Process Automation (RPA) can be a powerful tool, typically adopted by power users first. Imagine that you can now easily create automatic processing for Office documents received in your mailbox, for example to store them on OneDrive and send alerts by mail and through your Teams channel.
It’s a basic example, but you can already imagine this as a kind of VBA 2.0 which transcends the Office limitations and allows you to connect to all kinds of existing environments. Things like automating Azure Management or interacting with your SAP ERP are now possible without needing to “program” it.
As always, early, fast-growing adoption of any software may cause issues – and RPA is no different. Firstly, it’s a great example of shadow IT, with potential issues around security for example, but on top of that it may open new breaches regarding Software Asset Management.
New Metrics: A Microsoft Illustration
A good representation of RPA licensing issues is Microsoft’s Power Automate (formerly Flow) product. We all know how the life of a SAM manager can be complex when dealing with metrics. Until now, it was pretty clear for Microsoft products. Especially for workstation side software, it was mostly about choosing between users and devices. But what does an RPA bot correspond to?
Microsoft wants now to introduce a difference between attended and unattended RPA automations. To make it short: Attended means RPA executed on the user workstation, with the intervention of this user to trigger processing. Unattended, on the opposite, is when you want to execute your bot outside of a single workstation and trigger it without manual intervention (for example through an event). So, you may license the user (attended) or the bot itself (unattended).
Power Automate is also available through other subscriptions – Office 365 and Dynamics 365 – and these are known as “seeded apps”. However, depending which license is granting you these “seeded” rights, you may find that not all features are available to you. There is also a new Microsoft 365 E3 Unattended License that you may have to take into consideration.
Good old multiplexing is here
RPA is new, with various new metrics, but it doesn’t get rid of traditional licensing concepts like multiplexing. Remember, multiplexing is about using hardware and/or software to pool or reduce direct access to a software. Microsoft makes it very clear in its Client Access Licenses (CAL) licensing guide:
“Multiplexing does not reduce the number of Microsoft licenses required. Users are required to have the appropriate licenses, regardless of their direct or indirect connection to the product. Any user or device that accesses the server, files, or data or content provided by the server that is made available through an automated process requires a CAL”
Source: Volume Licensing brief Multiplexing—Client Access License (CAL) requirements
For example, any user accessing a Microsoft Power Automate service must be properly licensed. This is the same thing for external users accessing your Power Automate service via portals: external users can be licensed via number of logins or page views.
Third party risk
Beyond the RPA tool licensing itself, interacting with other software also means that it is necessary to check licensing for it. If you’re creating a Power Automate bot to access Dynamics, end users using it must be properly licensed both for Power Automate and Dynamics usage.
Multiplexing is not a Microsoft only concept, and RPA is vendor agnostic. It can be used to interact with a wide variety of software, Operating Systems, web sites, databases, ERP systems etc. This means it is the perfect candidate for indirect access scenarios in your SAP or Salesforce systems for example. Remember the SAP v Diageo case? Tools like Microsoft Power Automate make it very easy for any number of users across your organisation to create situations like this – leaving your organization open to potentially very large bills.
Dealing with RPA licensing dangers
When talking about RPA, SAM managers may have the difficult task to take control of individual productivity initiatives to stay compliant or to avoid overspending. Working with stakeholders will be key: Identify early adopters, and the relevant stakeholders that may be involved with RPA already. This will be both those people using RPA in their roles as well as the department leaders and business unit owners.
Prevention is always the best remediation: take time with your power users to explain to them the deep impacts of RPA usage on software licensing and the associated risks. They will be your best ambassadors as always. Then extend your communication to the rest of your organization. Last, try as soon as possible to monitor RPA usage. The sooner the better, as monitoring will help you to correctly plan the capacity and licensing required and better avoid falling into a non-compliance hole! However, such monitoring is easier said than done and, ironically, is likely to be quite a manual process.
It should be noted too that there are several RPA solutions other than Power Automate from Microsoft. Other Tier 1 vendors such as IBM & SAP have their own robotic automation tools and there are standalone solutions too – the most notable of which is UIPath, the current “leader” in the Gartner Magic Quadrant for RPA.
Conclusion
If you are looking for Sarah Connor, knocking on each door may be time consuming, and you may be tempted to create a robot to assist you with your epic search. But please remember that if your bot is interacting with third party software (like Skynet…or Salesforce), you may have to license it for. And don’t also forget to license John Connor for the bot usage at least! This might be a new topic that isn’t really on your radar yet but it’s safe to say that RPA is happening – so it’s not about stopping it, it’s about managing it.
By Mathieu Dufetelle, November 5, 2020
