4 ms·

That's a very interesting assessment, thanks for typing this up! What are the most important use-cases that you see UIPath solving? I'm familiar with what they

That's a very interesting assessment, thanks for typing this up! What are the most important use-cases that you see UIPath solving? I'm familiar with what they do at a high level, but I'm not sure who they're really most useful to in practice. Also curious who their typical buyer is - eg functional heads, IT, eng, or someone else...

ethbr0 6y ago
The typical use case is "As a business user, I want to automate my existing workflow or create new functionality through automation. I have little or no ability to change anything (either due to vendor- or IT-apathy). Therefore my input, output, and applications-used are effectively frozen." Typically, applications will be a mix of web (potentially back to IE-11-only type stuff), Windows (including whatever old UI libs might have been used), and mainframe (via emulator). None of these have modern-style APIs (except for mainframe via the surprisingly foresightful HLLAPI). So tl;dr, "I want to do new things, but can't change anything." An example would be insurance companies having to quickly alter their processing, in a matter of months, due to the Affordable Care Act. Using the med insurance example, an average claims processors will have to interact with a claims system (3rd party Windows app), workflow management / audit system (3rd party Windows app), possibly core data systems (mainframe and/or legacy DB), and 1+ ancillary unsynchronized data systems (e.g. med review, communication portals, external processors for various functions). All of this to do a "pay the claim" process. For 100+ claims a day. So that "stack" is your average automation target, which you typically want 100% automation coverage against, or it isn't viable. The typical buyer is almost always on the business side. Either a business VP or Director, or someone under the CFO. CFO-initiated projects usually focus on cost saving by re-onshoring low-value work previously offshored to India et al. Data entry into legacy systems, etc. Surprisingly, another key reason is usually "increasing ability to own and quickly change processes" (vs simply headcount reduction)! But organizations are waking up to the peril of that's-too-legacy-to-change components.
- Aeolun 6y ago
  I’m curious how this looks in reality. They install a tiny client on their machine that follows their clicks, evaluates what’s on the screen and then does more clicks? Then once it’s made the first time, it runs on their machine again. Or it runs on some central server?
  - isp 6y ago
    Think about it as a programming language but with integrated support for automating user interfaces. Typical workflow for an "unattended" automation (which runs on a headless VM in a data centre somewhere) would be: - Run "Developer Studio" on a dev machine - Write "code" (in a visual programming language) to tell the software how to interact with other user interfaces (there are various different methods for this: via browser plugin to interact with the DOM in a web browser, or using screenreader APIs for native Windows applications, or even via OCR-like methods if all else fails) - Save the automation "source code" (it's a visual programming language, based on VB.NET/C#, and the underlying source code is XAML files), ideally add to version control - "Publish" the new automation to a central "Orchestrator" server - which is responsible for pushing the new automation code to other headless VMs, and coordinating execution
    - ethbr0 6y ago
      To add one addition piece: selectors / match rules. The key to getting automation reliable is being able to reliably identify target objects (e.g. button, grid cell, etc). ... reliably identify it, regardless of what screwed up, unsupported, what-were-these-devs-thinking underlying code. I once had to automate a webpage that was dynamically built, at user runtime, from a mainframe screen. Of course without any classes or id tags anywhere. So if the tool doesn't give you a toolbox big enough to handle pathological cases, it's not really fit for purpose.
  - donarb 6y ago
    It's not always just a screen logging thing. You can automate manual non-computer stuff as well. For example I had a client who had a manual process where a clerk entered info from physical cancelled checks into a spreadsheet. The spreadsheet was then fed into their accounting system for balancing. I wrote some Python code that would take a PDF of scanned check images, run the file through Google vision to OCR it, then pull the check info from the scanned data and put it into the spreadsheet. The accuracy is pretty good and any errors are put into a comment column of the spreadsheet where the user can review it. This code runs in a Windows server and becomes a UIPath bot in the system. So the user who is not very technically inclined merely has to log into the system, upload a scanned PDF and will receive the scanned results after the batch runs.
- staysaasy 6y ago
  That's incredibly insightful, thank you! The idea of RPA-as-glue-for-legacy-systems is something that a friend who's building a company in the RPA space had mentioned once. It made sense to me at the time in theory, but this example really helps to drive home how that plays out in practice.
  - ethbr0 6y ago
    It's a terrible space to build a new business in, unless you're very careful about scoping your target client. This is because it's a game of long tail compatibility. That one Java UI library from the mid-90s that one Japanese bank wrote half their systems in? Better support it! Unfortunately, that's tough to do without amortizing the development cost over a large customer base.

ethbr0 6y ago

The typical use case is "As a business user, I want to automate my existing workflow or create new functionality through automation. I have little or no ability to change anything (either due to vendor- or IT-apathy). Therefore my input, output, and applications-used are effectively frozen." Typically, applications will be a mix of web (potentially back to IE-11-only type stuff), Windows (including whatever old UI libs might have been used), and mainframe (via emulator). None of these have modern-style APIs (except for mainframe via the surprisingly foresightful HLLAPI). So tl;dr, "I want to do new things, but can't change anything." An example would be insurance companies having to quickly alter their processing, in a matter of months, due to the Affordable Care Act. Using the med insurance example, an average claims processors will have to interact with a claims system (3rd party Windows app), workflow management / audit system (3rd party Windows app), possibly core data systems (mainframe and/or legacy DB), and 1+ ancillary unsynchronized data systems (e.g. med review, communication portals, external processors for various functions). All of this to do a "pay the claim" process. For 100+ claims a day. So that "stack" is your average automation target, which you typically want 100% automation coverage against, or it isn't viable. The typical buyer is almost always on the business side. Either a business VP or Director, or someone under the CFO. CFO-initiated projects usually focus on cost saving by re-onshoring low-value work previously offshored to India et al. Data entry into legacy systems, etc. Surprisingly, another key reason is usually "increasing ability to own and quickly change processes" (vs simply headcount reduction)! But organizations are waking up to the peril of that's-too-legacy-to-change components.

Aeolun 6y ago
I’m curious how this looks in reality. They install a tiny client on their machine that follows their clicks, evaluates what’s on the screen and then does more clicks? Then once it’s made the first time, it runs on their machine again. Or it runs on some central server?
- isp 6y ago
  Think about it as a programming language but with integrated support for automating user interfaces. Typical workflow for an "unattended" automation (which runs on a headless VM in a data centre somewhere) would be: - Run "Developer Studio" on a dev machine - Write "code" (in a visual programming language) to tell the software how to interact with other user interfaces (there are various different methods for this: via browser plugin to interact with the DOM in a web browser, or using screenreader APIs for native Windows applications, or even via OCR-like methods if all else fails) - Save the automation "source code" (it's a visual programming language, based on VB.NET/C#, and the underlying source code is XAML files), ideally add to version control - "Publish" the new automation to a central "Orchestrator" server - which is responsible for pushing the new automation code to other headless VMs, and coordinating execution
  - ethbr0 6y ago
    To add one addition piece: selectors / match rules. The key to getting automation reliable is being able to reliably identify target objects (e.g. button, grid cell, etc). ... reliably identify it, regardless of what screwed up, unsupported, what-were-these-devs-thinking underlying code. I once had to automate a webpage that was dynamically built, at user runtime, from a mainframe screen. Of course without any classes or id tags anywhere. So if the tool doesn't give you a toolbox big enough to handle pathological cases, it's not really fit for purpose.
- donarb 6y ago
  It's not always just a screen logging thing. You can automate manual non-computer stuff as well. For example I had a client who had a manual process where a clerk entered info from physical cancelled checks into a spreadsheet. The spreadsheet was then fed into their accounting system for balancing. I wrote some Python code that would take a PDF of scanned check images, run the file through Google vision to OCR it, then pull the check info from the scanned data and put it into the spreadsheet. The accuracy is pretty good and any errors are put into a comment column of the spreadsheet where the user can review it. This code runs in a Windows server and becomes a UIPath bot in the system. So the user who is not very technically inclined merely has to log into the system, upload a scanned PDF and will receive the scanned results after the batch runs.
staysaasy 6y ago
That's incredibly insightful, thank you! The idea of RPA-as-glue-for-legacy-systems is something that a friend who's building a company in the RPA space had mentioned once. It made sense to me at the time in theory, but this example really helps to drive home how that plays out in practice.
- ethbr0 6y ago
  It's a terrible space to build a new business in, unless you're very careful about scoping your target client. This is because it's a game of long tail compatibility. That one Java UI library from the mid-90s that one Japanese bank wrote half their systems in? Better support it! Unfortunately, that's tough to do without amortizing the development cost over a large customer base.