[productive]

Virvar - out of curiosity - why is it that you would like to let the users build those bots? Intuitively, users just don't have the skills, patience, the technical mindset, the understanding of the IT landscape (imagine some non-working SSO - which user is going to know how to get that to work!). Basically "what's wrong" with doing it 'the normal way' - which is to have an IT team (in-house or external like EY) do the work?

[JPKab]

Have you ever worked in a large enterprise? It doesn't seem like you actually have.

In large companies asking IT to do things is a death sentence for a project. They are viewed as a cost center and therefore typically under resourced and often times lacking in skill. Bringing in a consultant is even worse. They'll be gone as the tech rots and nobody will know how to fix it.

Democratizing these kinds of things to the users is highly successful and enhances business productivity. The old school only the pros know what they're doing mindset is awful.

The success of companies such as tableau and alteryx are examples of the huge value add that companies can get when they just let their business analysts do things that used to require coders.

[productive]

I hear you I hear you.

I guess my main curiosity is, given a) automations that are more useful / valuable / powerful require more sophisticated techniques and concepts (loops, sessions, states, etc.) and given b) that non-expert users typically don't have them, then how can we solve this problem?

I see the following options: 1) either (pro)users limit themselves to more trivial / simple automations that are useful enough, with the skills they have, but they can't do more and that's that 2) or there has to be some level of expert involvement (IT, freelancer, consultant, or an FTE hired by the department to do this kind of automation work) - so there needs to be some level of budget 3) there's some tool that makes it possible to deliver more complex scenarios without the (pro) user needing to understand those aforementioned concepts

I'd say the RPAs of the world fall into category 2) - requiring a lot of budget, thereby being limited to the very few highest RoI kind of use cases that can afford this budget.

I'd say many tools out there (including UIPath, Axiom, and many others) try to be 3) but end up being 1) or 2).

The problem seems to be not with the tool, but with the fundamental challenge of trying to do something more complex without the skill.

For the record, I'm not saying it is an unworthy endeavour, I just haven't seen any great examples that manage to crack this.

One exception: very domain specific topics. You mention Tableau - basically 'all' the user is doing with it is to slice and view and filter data (that has been connected by experts) in different ways. So the users aren't 'creating', the way they are when they are creating automations.

What is your view?

[virvar]

We operate 300ish IT systems of various size, from handling vacation time between leaders/employees to full fledged SAP solutions. We have 10,000 employees but only 5 developers of which 2 are also operations engineers developers. If an employee needs a little bit to automate some small workflow, to save them a few hours a week, that’s way below the scope of where we would get involved to do an RPA process. But that doesn’t mean we don’t want people to automate those tasks. In the ideal world we wouldn’t need RPA, because much of what it does is things that should work smarter in our current systems. But the enterprise world is far from ideal.

We didn’t use one of the big consultant houses like EY. We didn’t because we have plenty of business process people, project managers and so on ourselves. And that’s typically what the big consultants mainly offer, they offer it along with tech consultants that are often from some partner. We started by gathering info on what was available, as well as what we thought we needed and we drew on experiences from other cities. Many places had gone with the big consultant agencies and gotten this big package on the business end, and one or two processes build with the tech consultant, and then their project stranded because the business part doesn’t actually build RPA processes.

We decided to go with a small local startup, where we bought hours and “open” consulting. We did brainstorms with them, but then we build things ourselves and had them review it, and we put a much larger focus on learning the technical parts - and well - we are now the leading city on this area if you compare the 96 cities that aren’t our two largest cities. So from my anecdotal view, that is far better than using the big consultant agencies.

I named EY, and that may give them bad publicity here, but EY was actually the best of the big package offers that we didn’t decide to go with. Which is why their name stuck with me, so it’s a little unfair if this makes them look bad.

[productive]

Thanks Virvar, may I follow up (and I am really just trying to understand here, not to criticise or advocate one way or another): From what you said, I understand that, essentially, 'the kind of steps or tasks that employees would want automated' are too small for someone central to bother to look at. So it's an issue of economics - it's not worth the attention and not worth the cost. I fully understand.

On the flipside, you yourself mentioned a) the skill level (loops) and b) maintenance and - dare I add - say governance / standards.

I guess it comes down to the tradeoff of [not having tasks automated because it's not worth it for 'the experts'] vs [having a prolific ungoverned set of automations deployed by users with insufficient skill level perform them (kind of like excel macros)].

So given the skill issue, and given that users struggle with things like loops etc. - does that mean that they'll basically just be able to implement 'trivial automations that don't involve complex paradigms'? Or how can non-technical people, fundamentally, crack it and develop more elaborate (and therefore more powerful) automations?

This is what I'm grappling with - I see so many no code tools out there, but at the end of the day, you can only do very limited, not so valuable, automations with them. Curious to learn your thoughts there.

[virvar]

This is the issue. The “no-code” + “no real oversight” tools don’t really work for us, but we wish they did. ;)

[productive]

Alright -thanks for the clarification!

[syvl]

Virvar, I'm interested in learning more about those workflows that are too small to automate.

A friend and I recently started building something that might be useful with exactly those kinds of tasks, and we're looking to chat with people who'd be willing to share their real-life use cases for us to build towards.

If you're interested, I'd love to hear more about your needs and the challenges you've come across so far. And no worries if not. My email is in my profile. Cheers!