|
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. |
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.