3 ms·

Well said. > The moat protecting the market share of the big RPA companies is created by the mature deployment systems that enable large enterprises to run hun

by ethbr0 5y ago

Well said. > The moat protecting the market share of the big RPA companies is created by the mature deployment systems that enable large enterprises to run hundreds or thousands of automated processes This is completely incorrect. Managing processes and bots is the absolute easiest thing they do, because it's entirely under their control and a solved problem. The actual moat is legacy compatibility -- how broad a tech stack does your RPA engine cover? Microsoft Active Accessibility? Excel? Excel + VBScript? Legacy Windows native? VB6? Early Java with custom UI grid classes? The point the author should be making is that Microsoft, Google, and Amazon have zero interest in eating UiPath's lunch. It's expensive (in people-time-dollars) and custom per customer. And ultimately, it's a long-tail game. Microsoft's play is to trivially link together new deployments or migrations (i.e. to O365), then continue adding customers as more migrate to them. Why pay to chase the customer, when they're already running towards you? (FWIW, I think UiPath realizes this, which is why most of their new products / features are pivoting to become an Appian-esque rapid app platform. AA and BP? Less clueful)

ajcp 5y ago
100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API). The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those legacy systems that required the RPA solution. I have never seen a company disciplined enough to direct those savings in that way. RPA companies have been so caught up in being a "hot item" and classified as a sub-category of AI (for whatever reason) that they don't seem to realize they've been selling their own demise.
- jwally 5y ago
  Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them. Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions". I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.
  - ajcp 5y ago
    You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT.
    - ethbr0 5y ago
      The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT. IT promise to business: "You can use RPA if we tell you we can't build a thing in time." Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution." And then be very particular that business needs to have documentation of their RPA in order to implement in production (business process / ask, notsomuch technical). This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}. In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data. (It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)
      - ajcp 5y ago
        >IT promise to business: "You can use RPA if we tell you we can't build a thing in time." > >Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution." This is the _whole_ life-cycle of a correct RPA implementation. The only successful RPA automation is the one that gets turned off because it has been solved for in the enterprise application level.
mgummelt 5y ago
How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.
- m1sta_ 5y ago
  Most of them look for window events. I've not seen an RPA tool that actually reads the screen like a human, even though that's how you're thinking about it.
  - ethbr0 5y ago
    The bit players simply map Active Accessibility / whatever MS calls it now (Windows Automation Framework?). The more serious players shadow Windows events. The real stuff does process injection and directly shadow copies / modifies in-memory data structures.
  - mgummelt 5y ago
    That's not how I'm thinking about it.
- ethbr0 5y ago
  "Integrate at the UI layer" is a can of worms. In simple cases, it's clicking a button. In real practice, it's triggering some esoteric sub-event the developer hooked, or returning coherent data tables from whatever not-table thing a developer cobbled together. Example from current work (US government system, Oracle Forms / Java based): a scrollable "grid", actually composed of individual, carefully-lined up text boxes, containing 12 rows, which moves / updates the contents of each box as the user scrolls.
  - mgummelt 5y ago
    I'm not saying integrating with UI layer isn't fragile. I'm saying it doesn't offer a "moat".

by ethbr0 5y ago

ajcp 5y ago

100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API). The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those legacy systems that required the RPA solution. I have never seen a company disciplined enough to direct those savings in that way. RPA companies have been so caught up in being a "hot item" and classified as a sub-category of AI (for whatever reason) that they don't seem to realize they've been selling their own demise.

jwally 5y ago
Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them. Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions". I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.
- ajcp 5y ago
  You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT.
  - ethbr0 5y ago
    The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT. IT promise to business: "You can use RPA if we tell you we can't build a thing in time." Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution." And then be very particular that business needs to have documentation of their RPA in order to implement in production (business process / ask, notsomuch technical). This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}. In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data. (It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)
    - ajcp 5y ago
      >IT promise to business: "You can use RPA if we tell you we can't build a thing in time." > >Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution." This is the _whole_ life-cycle of a correct RPA implementation. The only successful RPA automation is the one that gets turned off because it has been solved for in the enterprise application level.

mgummelt 5y ago

How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.

m1sta_ 5y ago
Most of them look for window events. I've not seen an RPA tool that actually reads the screen like a human, even though that's how you're thinking about it.
- ethbr0 5y ago
  The bit players simply map Active Accessibility / whatever MS calls it now (Windows Automation Framework?). The more serious players shadow Windows events. The real stuff does process injection and directly shadow copies / modifies in-memory data structures.
- mgummelt 5y ago
  That's not how I'm thinking about it.
ethbr0 5y ago
"Integrate at the UI layer" is a can of worms. In simple cases, it's clicking a button. In real practice, it's triggering some esoteric sub-event the developer hooked, or returning coherent data tables from whatever not-table thing a developer cobbled together. Example from current work (US government system, Oracle Forms / Java based): a scrollable "grid", actually composed of individual, carefully-lined up text boxes, containing 12 rows, which moves / updates the contents of each box as the user scrolls.
- mgummelt 5y ago
  I'm not saying integrating with UI layer isn't fragile. I'm saying it doesn't offer a "moat".