Join AITSM Co-Op, A community for those who ♥️ AITSM (ITSM, ITIL, AI and Automation for ITSM)

Scaling Your Automation Journey (Part-2) Citizen-Developer Dilemma & Making Automation Accessible To Everyone. How To Have Automation Like Apple Store?

March 3, 2022

Scaling Your Automation Journey (Part-2) Citizen-Developer Dilemma & Making Automation Accessible To Everyone. How To Have Automation Like Apple Store?

Scaling Your Automation Journey (Part-2)

Citizen-Developer Dilemma & Making Automation Accessible To Everyone. How To Have Automation Like Apple Store?

AITSM Show - Episode 3 - Special Interview With Fernando Baldin

Scaling Your Automation Journey (Part-2), Citizen-Developer Dilemma & Making Automation Accessible To Everyone. How To Have Automation Like Apple Store?

We discussed five unique key elements to scale your automation journey with Fernando in the last episode. In this episode, we'll go deeper into one of the exciting concepts of the Citizen Developers Dilemma. 

We'd have our pertinent questions like - How To Scale Our Automation Journey? What is the Citizen-Developer Dilemma? What are the bottlenecks & How To Solve Them?

We asked Fernando Baldin, SAB(Sr. Advisory Board) at HDI(Help Desk Institute). With plenty of creative metaphors like the Apple Store and unique ideas from his passionate and rich career path. Like How To Have Automation Like Apple Stores? We'd learn a lot from him. 

Don't miss the end, where he shares three secrets of his success. 

"Think of the Apple store, right? How many apps there are in the Apple store, millions and billions. How many of them have Apple actually developed? If they wanted to develop everything, they wouldn't be able to. So that's, you must see yourself as an apple store of automation in your organization."

Learn and Grow, With AITSM Show!!!


Anand Tambey: Welcome back to the AITSM show. In the last episode of our discussion with Fernando, we discussed how to scale your automation journey. So, one point came up there, and we would like to go deep about it with Fernando again. It is about the citizen developer dilemma. So, Fernando, could you please explain more about it and what would be the significance, and what kind of challenges you faced here?

Fernando Baldin: Of course, it's nice to be here again, Anand. Thank you for the second invite. It was good to talk and share our ideas with the audience, and hopefully, they will get and bring us their ideas, and we will learn together.

So, the citizen developers dilemma is something that we could see sort of, especially at the beginning of the RPA market; as I mentioned in our last podcast, I come from the stone age of automation. So, I was a skeptical guy about interface automation.

So, we had all that going on, and with that, they need to bring the subject of, look, everybody can develop a bot. This is easy. So that's where we call it citizen developer nowadays, but at that time, it was like business developer, and it was a different way of saying. But the idea was that anyone with a proper tool could record their job. And once they had recorded, they had just published this on some automation platform. They were free, free to go, free to be humans again.

And what I tell you that, so that the first dilemma was that never actually happened. And I mean, many vendors positioned themselves like these easy to go and finished tools. And even they changed the way they were approaching the market because that is not true. I'm going to tell you what the dilemma is? Because at the time, I was very skeptical about it. I used to have a lot of discussions in other markets, our recorder; it doesn't help do it all.

It's only for some very simple tasks, maybe for learning, but once you go to the second step of automation, you see. Oh, this recorded thing gets not the best element. It gets another best organization of the job. And that comes through the first thing. Do want to be sure to fail in your automation journey, just copy how people do their jobs. Just copy without thinking, right?

So that's the first thing. So, the first thing is that look; people do not always do the best way they did. They did not always have the best-optimized way of working. So that's why the recorder was already dead.

And the second one, when you go for automation, you're enhancing capabilities. Why would you do it? Secondly, what are people doing?

A very simple example is that once I talked with a customer, they had this copy and paste. It had a spreadsheet and had to copy and paste each line into its HR system. When you think of a human, how you must think line one paste, line two, paste, but when we go for Bot, all those spreadsheet lines are in the memory. And then I'll go only once. I did not open both applications. I work in. First, spreadsheet, then this HR application, then I'll control it. Somehow, I have to control it. If there's some outage in the system, how do I know where I have stopped? So, all of those things, they're sort of natural for the human being, have to be thought of when you go for automation, from an architecture point of view.

So, the citizen developer was an idea, in my view, to sell licenses and not to actually solve or create a new way of doing activities in the market.

I think that's one thing. The second thing why people thought at the time was that everybody had to be an RPA developer. RPA platforms you can learn in three months. I mean, easily even one month, it depends on how much time you're spending on that. But to know that logistics or financial processes, to understand the dynamics, some business rules, that's not something I can learn in three months.

That's something that will take me a year or maybe more, depending on the complexity. And that's where those business developers, citizen developers, or whatever you want to call them. That's where their value is. They know the rules, the process and know a lot of it. So, all you have to do is, give them some general idea. They would know about RPA automation, technologies, and their business. But since the world is not how we want it to be, it's just the way it is. Let them bring value with their business knowledge. And then, you can help them with RPA technology to implement that.

Anand Tambey: Correct. So, to summarize, if there are say developers without any business knowledge, they cannot do much, but business analysts or businesspeople. If they have this power of automation and the management of RPA in their hand, they can do way better than that. Right.

Fernando Baldin: And there's a second point to it, which is, we see a lot of COE, centralized view, is becoming a bottleneck.

Some automation I've seen many companies facing huge backlogs of bots to be developed by the business. Some COEs are too focused on developing automation.

And I truly believe that citizen development idea, it's a very interesting one. I've seen customers in Brazil doing very well with that, but they changed a little bit aspect of the COE. So instead of becoming the main developer, they become the main mentors in the organization for automation. There's a huge difference, they support the business developers to start their automation journey, do their first bots, but they spend a lot of time mentoring them. So, this is the first point. It's much easier to mentor 20 people than to create 20 bots at the same time.

The second point as a mentor and the more you mentor more is the need to create your own Bot library. So that's a second point. Mentor-directed, oriented, and build your own bot library.

I mean, you have the same systems. You have your ERP. You have CRM. You're seeing people interact with the same systems over and over. Why don't you create those pieces of software, reusable pieces of automation logging into system A? This is already done.

I mean, where are you going to put it? It could be SharePoint; it could be on a shared folder. It doesn't matter where you're going to put it; the key points are that you help people speed things up on their side. So, they will learn a bit about automation. They have those pre-ready parts. So, you're going to speed them up really, really fast.

For example, let me give an example of reports. There's there are many automations that are report-oriented. So, they go to ERP. If they read some reports and need to do some sort of ETL. With those prebuilt blocks, the development becomes very fast.

And with the mentoring behind showing what they are doing. So, you can see the scale that can achieve at the end of the.

And the third point is quality control. We talked about our last podcast. It's not the number of bots you have, but what is the success rate of those?

That's the key point. So, and that's where the COE, you could not only mentor but also do quality control. So before going to production, first runs of the bot. That's where you should take some quality controls and apply some best practices. Okay. Oh, please change this, change that, this way is better than that way. So, you’re still always telling people, think of the Apple store, right? How many apps there are in the Apple store, millions and billions. How many of them have Apple actually developed, a hundred, not even 10? I think it was 40. It's the same, right?

If they wanted to develop everything, they wouldn't be able to. So that's, you must see yourself as an apple store of automation in your organization.

Anand Tambey: Beautiful idea. It's a very insightful, very unique idea here. Like having to think automation, not just automating a few apps, but I think you will be going to explain that like Apple’s scaled app development process.

Fernando Baldin: Exactly. It's a matter of time. Right. So, every bot takes time to develop. So that's a universal truth. We still don't have any artificial intelligence that can create bots.

I mean, without any human thinking, but it's the scale. How many bots do you have? It's how many bots can you do in a single month? That's the real scale. That's the real number you should achieve. And to do that, there are two ways you can do that.

One, hire developers as much as you or freelancers, whatever, hire from India. That's one thing, but it's still going to have a lot of project management and quality control. So, if you hire a thousand developers still, there will be similar and additional work. And the second one is like, why do we not use this mentorship? You can.

Also, remember it is mentorship oriented; it’s also training oriented. So, the COE focuses on quality control, mentorship, and training. So, give monthly training for your business users for all their community that wants to learn automation. So, you're doing training. So every month you're doing training and let's say I'm from the financial department.

I appoint someone, and there's always someone in the department that is sort of, I mean, technology-oriented. This is, especially with this new generation, they are born with cell phones and digital, by birth. They're eager to do things differently. Why do we do this this way?

So, if you get those people and empower them with the RPA platform, and that's one thing I like about; I’m going to do like a, we call in Brazil aljabbah, which is some sort of propaganda. That's why I don't like tools that charge for a developer interface or a studio, whatever you call it because I truly believe in scaling; you have to become very open and accessible for everybody in the organization. So, they can learn, they can develop. Maybe they're going to take more time to develop our first bot than a developer, have the opportunity to interact. That's why I think in the future, most solutions will adapt. It will not charge for this studio part because that will impact the speed that the customer can have. Then you can use mentorship and training, and quality control.

Anand Tambey: Well, various unique ideas have come up with this discussion. If I can Summarize, like training, mentorship, right? Mentorship is actually a game-changer here, right. Where you can actually put a young mind and a mentor with them and then have business knowledge, development knowledge, and altogether and scaling with, trying to automate bit by bit, as you talked about earlier, 1% you try each and every day and then making it scale, like an apple store. What an idea that is.

Fernando Baldin: Exactly. That's. I mean, that's a different way of thinking because most RPA initiatives are laying down with IT, and IT tends to control, right? IT wants to control everything. No, no, no. Don't go so fast. And I think that we, as IT, must change our minds. I'm not saying we should run like crazy and don't think about the maintenance and all that. It's not that. But I think RPA goes further. I mean, to the business, it is a core, and we should think of it as a daily tool for all companies and keep control of quality and mentorship, not focused on developing too much.

Anand Tambey: Right. So, empowering everybody with automation and then automating their own tasks.

Fernando Baldin: Exactly.

Anand Tambey: So that is the best vision here. Right. Great insights are coming up from these discussions, and before closing this, I think we can do another podcast about AI implementation. We can put that topic for the next episode, right?

Fernando Baldin: Sure. You mentioned the one thing that I think it's very interesting to say why we talked about this mentorship and scaling because the RPA developers of your COE, of your organization, should focus on these AI initiatives because that's something that business users won't be able to do themselves. The impact it can have on business goals and invoice inputs or task-oriented automation.

So that's the key point. Step out of the daily activities and help others do it.

I mean the automation of daily and simple to medium and complexity cases and focus on high complexity AI. Create your algorithms. Because of a lot of AI efforts, you will find yourself in a dead-end. That happens. And it had to get that. Okay. We took that path. That's the algorithm. This is the strategy. We tried, it didn't work. Let's go back to the beginning, the training set. Some tweaks here and there, all this works, but not at the level of confidence our business requests. So, that is where as a COE, you should focus on.

Anand Tambey: Great discussions and great ideas coming of this one even. So, we'll definitely keep coming back to you for more episodes and probably a series of episodes for this. Fantastic ideas are coming up and deep-diving into other ideas. Right. Thanks a lot, Fernando, for your time, and we love to have you on our show.

Thanks. Thanks very much.

Fernando Baldin: Thank you, all the best. Always a pleasure to be here; all the best. Theek Hai (Hindi)

Anand Tambey: Obrigado (in Portuguese - Thank you).

If you've loved this conversation and discussion, please share it generously. And if you have any questions to be asked to our guests and IT Pros. Please let us know.

Watch this space for more talks like this and wonderful insights. Till then. Bye-bye. Thank you.

Fernando Baldin Profile Photo

Fernando Baldin

SAB(Strategic Advisory Board) at HDI(Help Desk Institute)