4 ms·

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

by 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.
    - Mister_Snuggles 5y ago
      In my experience, the lifecycle is more like: * Person in the business area implements RPA. Business area is happy. * Person who implemented RPA moves on to greener pastures. * RPA breaks, business area calls IT. * IT is horrified at the unsupportable mess that's just been dropped in their laps.
      - jwally 5y ago
        1000% this. I’ve seen it happen with excel, access sql-server; and RPA. Some some Frankenstein’s monster is cobbled together to solve a problem whose best solution would be “stop producing the report that nobody looks at” only to have it slowly decay out of orbit. The other major flaw with RPA is non-engineering LOB employees (in my experience) are incredibly myopic and implement solutions to get shit done now without thought about future consequences of their decisions. They try to replicate the 800 steps they take to make something work instead of asking “more steps adds opportunity for failure; what is the minimum I need to do to reach goal”. /soapbox (Sorry)
        ethbr0 5y ago
        That's why the documentation prod gatekeeping is critical to long term company health. You're not going to stop them doing things -- because there's never "enough" IT / they always have Excel. So what's the next least bad? IMHO, give them something flexible enough (RPA) that they don't have to go outside of the box + require they leave a documentation trail of what / why they built. (Oh! And teach them about SLAs and SRE best practices!) Then come down like a ton of bricks if they don't follow the latter. Carrot & stick. Cheaper pressure release valves (RPA), not expensively overengineered containers (hiring more engineers). --- Ironically, the hardest conversation at (insert F500 I designed an RPA practice for)? "Business users shouldn't be able to use IT change control tools!" Wait... isn't this exactly what we're always griping they don't do?

by jwally 5y ago

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.
  - Mister_Snuggles 5y ago
    In my experience, the lifecycle is more like: * Person in the business area implements RPA. Business area is happy. * Person who implemented RPA moves on to greener pastures. * RPA breaks, business area calls IT. * IT is horrified at the unsupportable mess that's just been dropped in their laps.
    - jwally 5y ago
      1000% this. I’ve seen it happen with excel, access sql-server; and RPA. Some some Frankenstein’s monster is cobbled together to solve a problem whose best solution would be “stop producing the report that nobody looks at” only to have it slowly decay out of orbit. The other major flaw with RPA is non-engineering LOB employees (in my experience) are incredibly myopic and implement solutions to get shit done now without thought about future consequences of their decisions. They try to replicate the 800 steps they take to make something work instead of asking “more steps adds opportunity for failure; what is the minimum I need to do to reach goal”. /soapbox (Sorry)
      - ethbr0 5y ago
        That's why the documentation prod gatekeeping is critical to long term company health. You're not going to stop them doing things -- because there's never "enough" IT / they always have Excel. So what's the next least bad? IMHO, give them something flexible enough (RPA) that they don't have to go outside of the box + require they leave a documentation trail of what / why they built. (Oh! And teach them about SLAs and SRE best practices!) Then come down like a ton of bricks if they don't follow the latter. Carrot & stick. Cheaper pressure release valves (RPA), not expensively overengineered containers (hiring more engineers). --- Ironically, the hardest conversation at (insert F500 I designed an RPA practice for)? "Business users shouldn't be able to use IT change control tools!" Wait... isn't this exactly what we're always griping they don't do?