Welcome to our Stellar Keynote Recap Series!

As part of the 1st Annual Pathfinder Community Space Camp & Generative AI Showcase, we’re hosting live sessions with Community MVPs and industry experts to share the latest developments in intelligent automation—especially Generative AI!—and provide you with learnings and resources to drive success at scale. If you don’t have the chance to attend the live session or want to come back to reference some of the critical mission information that was discussed, we’ve captured key intel from each session to share with you!
 

Day 4 Stellar Keynote

For this session we invited Citizen Development experts into a roundtable discussion with lively audience participation. Two women paving the way for citizen developers—Anna Marie DeBolt, Lead Program Manager at TIAA, and Afreen Chaus, RPA Process Analyst & Developer at NVIDIA—led an astronomically informative conversation with insights from our own Anupama Ramesh, Director of Product Management.
 

What is Citizen Development?

 Main Intel: Citizen Developers are the backbone of Intelligent Automation. Being able to empower people to take their process and develop it in a way that helps them in their day-to-day is a beautiful thing.

Anna: Citizen development is a non-traditional programming path. You don’t necessarily need to know coding language, but these people know the business, the business processes, and logic inside and out. Honestly it might take a bigger investment in time to teach a developer the business rules than to teach someone who knows the business rules how to use an intelligent automation low-code solution. A bit of a flipped script from what we’re used to seeing.

Afreen: Citizen developers are the backbone of intelligent automation. These are people who you’ve hired because of their talent and we want to leverage that talent and know-how of the business to enable their learning of the technology. They really help accelerate development of bots because they are taking responsibility for their own processes. They have the business background and know what they’re trying to achieve. Being able to empower people to take their process and develop it in a way that helps them in their day-to-day is such a beautiful thing.

Automation Success Platform for Citizen Developers

 Main Intel: The Automation Success Platform and community lead to success within your automation program.

Afreen: The Automation Success Platform itself is low code. You can look at the interface, play around with it, and get building. But also, Automation Anywhere University is full of useful trainings. Then the Bot Store has so many pre-built bots as well that you can take and customize for what you need. The Automation Success Platform really leads to success of intelligent automation within your company.

Anna: A lot of the core functionality in the Automation Success Platform is really user friendly. With citizen developers not coming from a programming background, they don‘t necessarily have to know how it works, just that it works and why it works. You drag and drop and it does what you tell it to. Not only that, it’s great to have the AAI community space where you can bounce ideas off of people when you are trying to accomplish something. For example, from the community platform we learned not only how to launch a browser with the URL up, but also how to suppress pop-ups. That’s something I would have no idea how to do on my own as a coder. The community space where you can bounce ideas off of people is invaluable.

Blueprint for Citizen Developer Success

 Main Intel: Having a CoE and a true working partnership with IT are key to building a successful citizen developer program. Check out the Pathfinder Program’s blueprint for citizen developer success if you are needing extra support.

Anna: This is debated, but in my opinion you must have a CoE. If you dont, you’re setting yourself up for failure. Citizen developers cannot have that on their plate to control permissions and rules. You need a team taking charge from an enterprise level and factoring in cyber securities, etc. Without that, it’s a long road to haul.

Afreen: Along with simply having a CoE, you need a tight partnership with them. As citizen developers, you don’t want a shadow IT, you want a partnership that helps you build and grow together, rather than having people setting up their own securities and controls and the rest of the enterprise is doing something different. Also very important is the drive and commitment from leadership. Citizen developers come from various backgrounds and putting forth the energy and priority time to train, practice, develop, etc. needs to come from leadership. For us, these people have regular day jobs, so if leaders are not prioritizing giving them that time to learn, a citizen developer program is not going to succeed. And finally, at Nvidia, like the community at AAI, we’ve created a community we call the Citizen Developer Forum. It’s a constant connection with other citizen developers to talk about obstacles and successes, so we’re not all facing the same learning curve, but rather learning from each other to better ourselves.

Anupama: The Pathfinder Program also has a blueprint for Citizen Developer success that is worth checking out.

SESSION POLL SAYS…

What methods or approach did you follow to identify the initial set of low complexity, limited reach uses cases for your Citizen Developer program?

• Our audience was perfectly split 50/50 between Crowd-sourced and Process Discovery/Mining

So You Want to be a Citizen Developer?

 Main Intel: Anyone and everyone has the potential to be a citizen developer, but some qualities that make the strongest citizen developers are self-starting, perseverance, and love of learning.

Afreen: When I started our citizen developer program, I came in with the idea that everyone and anyone can become a citizen developer. And while that is still true, we’ve also learned that at certain checkpoints we need to reassess citizen developers’ skills to make sure the time and effort they are putting in matches what they’re getting out of automation. For training, we have the AAU trainings which are amazing. We also provide one-on-one training with citizen developers and if at any point they find it to be not within their scope of capabilities, we can pivot and find an alternative person in their team so that their team has at least one person who is a citizen developer.

Anna: Our citizen developers, that is their only day job. We don’t do operations work and then also automate. We automate the operations work in conjunction with the businesses who are doing it. So what we are looking for more than anything is the propensity to learn. Our biggest recruiting criteria are—are you a self starter, are you willing to learn, how do you deal with set backs, and can you troubleshoot and follow the logic?

SESSION POLL SAYS…

What type of users do you shortlist as candidates for citizen developers?

• Over nearly 60% of our live audience answered Business Process SMEs

Driving Engagement & Adoption

 Main Intel: Humanizing your work (read: bots) really helps keep citizen developers engaged and drives business users to take an interest in your work.

Anna: Part of how we keep our citizen developers engaged is we name all of our bots, so they feel like they become part of the team. They have a name and a personality and that’s how we relate to them. It really helps people stay focused and engaged and we get that adoption from this. We have our “problem children,” and we have our “honor roll” bots. And this keeps not only our team engaged, but also the business team that’s using them.

Internal Support

 Main Intel: Genuine buy-in and partnership from leadership and IT are essential to program success and scale.

Afreen: Leadership driving the program is absolutely needed for our program to be successful. We have a dedicated person making this digital transformation happen, both on the Ops side and the IT side. Without these 2 key stakeholders, the program would plateau. You aren’t going to drive that interest or communication to different teams to get use cases or citizen developers without the supportive push from leadership.

Anna: One of the big challenges we had when starting up was getting buy-in from IT and application owners. When we were automating something that we knew was going to be an unattended bot run and we needed a service account to login in order to be compliant with cybersecurity, we ran into an issue because some applications don’t want service accounts touching their stuff. They want to know it’s a real person and not a “group of people” running the bot. We also found we really needed to speak up and say we’re a legitimate solution, we’re freeing up your capacity by doing this work for you, so at the very least you can meet us at the table and answer our questions or provide the support so that this new work doesn’t come to your team. Then everybody wins. It has to be a partnership and we have to play in the sandbox together.

Measuring Success

 Main Intel: There are several ways to measure success from time and cost savings (hard metrics) to compliance maintenance (soft metrics), and all can be equally valuable to an organization.

Afreen: We measure by time returned back to the business - and I want to highlight returned rather than saved - because the goal of our program is to give back time to business people for them to tackle the other things on their plate. So this time returned allows people to feel empowered for job security. We also look at value, which is a little tricky. Every bot, every use case has a different understanding of value whether it may be cycle time reduction, improved response time, etc. I try to group them into different categories to understand how they are affecting the business besides hours returned. One thing we don‘t generally look at is cost savings, unless it’s specific to a use case. What we take to leadership, besides all these hours returned, is how these bots are really adding to the business.

Anna: We have a couple different levers we look at. FTE saves and hours saved is at the top. We don‘t necessarily look at time saved versus work avoidance. We understand that in this current climate hiring is not really an option, but volumes are still increasing, so rather than asking our staff to do more work, we provide those automated solutions, so our staff can focus on the tasks that we need actual humans to do—those higher cognitive activities. The other thing we look at is whether there are any risks involved. As a financial company, we have rules we have to follow, so if there is a process or gap that opens us up to risk or fines, even if there is not a huge dollar save or huge FTE save, we strongly consider and prioritize those opportunities. The reputation damage of not being in compliance, as well as fines avoided is worth it to us.

SESSION POLL SAYS…

What KPIs are used for your Citizen Developer program?

• An overwhelming 83% of our audience said Hours/Money Saved

Lifecycle Management

 Main Intel: Bots have a shelf life, so doing check ins to ensure they are still providing value and the best solution is key. CoE Manager has some new features that can make lifecycle management easier.

Anna: I feel very strongly that every bot should have a shelf life. Any bot that we create, in reality, is a stop gap solution for what is ultimately a workflow deficiency. If all of our systems did everything we wanted to do on time and in budget, we would not have an automation program. Anytime we talk about updating workflow applications it’s 3 - 5 year commitment, multi-million dollar budget, which is not always realistic. So when we approach new use cases, first we look at the roadmap, because automating something that will have a workflow solution in 6 months is not worth our time. If we’ve got a bot moving data from one application to another so a person doesn’t have to do that, the ideal solution is an API in place that does that discussion between applications, and a bot theoretically would be out of a job once that ideal solution is met.

Afreen: Agreed. We do 6-month check ins from bot production date. We ask users: is this still adding the value that you initially told us it would? Are you still using it? Do any changes need to be made? These follow ups allow us to make sure we don‘t have too many bots in production that aren’t being used. Lifecycle management is very important. You don‘t want all these bots out in the field doing nothing.

Anna: Expanding from that — the number of bots you have in production also means that much more support that you’re probably providing yourself.

Anupama: In terms of lifecycle management, the new CoE manager features that we just rolled out are going to be very useful. It gives you visibility centrally to see what your status is, where you are in your development as well as your whole deployment, and what kind of value you’re getting out of it, your change management to a large extent, stakeholder reporting, and managing your cadence, etc. That’s a great tool for everyone to check out.

Bot Governance

Main Intel: It’s important to make sure to have proper governance in place to ensure process integrity and results.

Anna: We have a change management process driven by our CoE. They basically do weekly deployments. For AAI, given that it's such a contained ecosystem, they've agreed to let our CoE man weekly releases, so we set up a process around how to request to change, what documents are required to validate the change evidence of testing, sign off - all those normal things that you include in SDLC changes. Then we implement a code freeze. The change needs to be submitted by a certain deadline, and whatever code that’s been packaged up for deployment can't be changed after that deadline to ensure that it is stable and is ready to go into production. And then, of course, we also talk about what our rollback plan is—if we have new files deployed and we run them in production and see an issue, we maintain copies of what was there before so that we can go back to the last usable version.

Afreen: It’s exactly the same for us—we have all of these IT controls. We have our change review board, who
is very familiar with RPA technology now, so we get approval from them. However, we roll our bots out ad hoc, so we don't have a specific window that we wait for that.

SESSION POLL SAYS…

If you consider the four roles Citizen Developers play, which is the most difficult to fulfill in your organization?

• 45% answered Creators who are accountable for building automations
• 23% answered Contributors who support automation growth by submitting ideas

LIVE COMMUNITY QUESTIONS

• If you have an extensive Citizen Development program, why would you need a CoE?
  • Anna: We employ a federated model at TIAA and what that means is we have different factories throughout the enterprise, different pockets of automation, and each of those would have varying levels of citizen developers. I think our factory is the only one that's truly all citizen developers. Sometimes we have robotics, factories where it's just kind of like there's an IT group over here. We're just also going to give them a license, and so it's not necessarily citizen development. but any of our automation anywhere groups roll up to the CoE, and so the CoE is a bit broader than just citizen development, which is why we have the difference. They control and set policy at the enterprise level. So we can set policy—what citizen developers best practices are—but we can't necessarily influence another factory directly in our enterprise.
  • Afreen: We have so many securities and controls in place, and that is not in the realm of the business. So the CoE is really driving that, as well as managing licensing, contracts, etc. We don't want to give more responsibilities to the business side.

• Are there any limitations for citizen developers that may prevent them from building and deploying bots following the necessary procedures established by the company IT and audit processes?
  • Anna: This is one where it is so vital to have that buy-in from traditional technology partners. If you need to make an API call, or a database connection, or if there is an old antiquated application where the UI just does not support automation anywhere screen scraping—and the example I’ll give you is…we have one I like to call Oregon Trail. It's called legacy, but it looks like you're playing Oregon Trail, and there's absolutely no way we can automate in the UI there. So what we have to do anytime we need data out of Legacy is make an API call to the Legacy database. The IT teams who hold the keys to that want to know who's calling, how many connections are left open, what our volume is, etc. All those things that traditional IT departments and teams care about and track that maybe we, as citizen developers, aren’t even aware of that could potentially be an issue. So there's absolutely stuff out there that is not in a citizen developer's control that can adversely impact your project. At the end of the day, if IT won't give you access to their tool or their application, you can't do it. But this is where building that relationship and having an open dialogue and saying, this is why I need to do it, and if you don't let me do it, business is going to come to you and ask you to do it.
  • Afreen: We have that partnership with IT, and that goes beyond just working with them. For all of our use cases we have stakeholders from IT, we have BSAs, we have the SME, and we have the developer. All of these people are constantly working together and are aware of all of the security and control, so that limits those conversations because it happens way earlier before production even starts. It's really important to have those stakeholders on board, in constant communication, and working with the developer.

• How are your citizen developers documenting their bots? Which and what requirements have you implemented? And how are they monitoring or tracking the bots?
  • Anna: We have an application that is homegrown that our CoE has sent out called the Bot Center. And whether it's an AAI bot or Java bot or open source, everything is registered there. That is one of the ways that we track who's automating and what it's touching. If we bring something down, we need some kind of trail that says this is who did it, and have approved their use case. One of the great things that the Bot Center lets us do, is it lets us put in what we think the value is, either the time or the money saved, run per task, and it generates a dashboard for us, based on how many times the bot has run, how many unique users, etc. We can then tell that story up to our management that this bot is consistently working and healthy. So that's one of the ways that we document after it's deployed. And then in terms of design and sign off, I'm sure every enterprise has required SDLC documentation. So yes, do that. It will make your life easier later. But then we go a little bit above that, and we also take into account auditors and business regulators and the things we know they're going to look for more than just the IT minimum. We look at what are the potential risks and how we're mitigating them from a business perspective document. And we keep it all recorded anytime we go in and make an enhancement. It's all about a (digital) paper trail.
  • Afreen: I'll tackle the monitoring. So our citizen developers are basically one developer per team in the business. We initially decided citizen developers will go out and tackle all projects, but that wasn't feasible. So per team, we have one citizen developer, and the developer is working with the SME also in their team to monitor these bots on a regular basis. They maintain it. We highly depend on both the SME and the developer to reach back and let us know something's broken, or this bot needs to be terminated, etc. So we're fully engaging the SME in this automation process.

• Do you have your bot registry tied into your CMDB?
  • Anna: Yes, we do. And this has actually been a point of contention with us. We have some bots that we consider parent and child relationship. So, for example, we'll go into one application, and there might be 5 or 6 bots that do different things in that application, and one of the issues where we run into the CMDB causing problems for us is that we don't necessarily want a unique CMDB ID for that. It's an application family that the CMDB is trying to get us to use, and we're kind of vying to use sub services. So we have one service with multiple sub-services, and that's definitely a conversation you want to have upfront before you get too deep into your automation journey and say—what makes sense? What architectural structure do we want to go with? Then commit to that and if things change in the future you will reassess. But does it make sense to have a different CMDB ID for every bot, or does it make sense to group them? Cyber Arc is a pretty common thing, but that's where at least with TIAA, we were getting into issues with Cyber Arc because they want a specific arc for every CMDB ID and I don't know if that's a Cyber Arc enterprise policy at TIAA, or if that's something that's also mirrored in the industry? But we don't necessarily want 25 different Arcs with one credential each. So that's our push to not necessarily use CMDB in that way.

• Anything to add on how are you training your citizen developers? And what does that kind of that program look like?
  • Afreen: We require them to take the AAU Citizen Developer Basics training. That's step one. Step 2 for training is to have them take a basic use case from their day-to-day job, and they work with me for about a month on a weekly basis to build out that bot. We learn the nuances of the tool, we talk about what other folks are doing, etc. So it's really that one-on-one engagement that gets that foundation set and then they're off on their own, and they can set up time with me if they need it. We do have AAI engineers come in if we have any issues, as well. I think that foundation within my team has just been exceptionally helpful to grow our program because they have a key person to communicate to. They're not dependent on just finding something off the Internet. They can directly reach out to me. I've also found that as many training videos as I can provide, it's less interesting to citizen developers unless they're working on a process that's important to them. So, being able to work with them on something that excites them is the way to go. They have access to any and all the training they can, and you know they do that when they need to. But using the use cases that directly affect them to help them learn is the best way to go.
  • Anna: We certainly encourage our citizen developers to make use of Automation Anywhere University. All that training is out there, it’s specific to AAI, so it's incredibly helpful. We offer the educational licenses that include access to the live trainings that are instructor led, not just the webinars. And then when we first started with AAI at TIAA we created a yammer group called The Mastermind. And that was a place for us to go and ask questions pre-Automation Anywhere community platform to potentially pick up some nuggets from sharing and communicating. Having the training available, but also having a forum where you can ask questions is key. We also do a lot of peer code reviews, and that's honestly how I think most of our citizen developers pick stuff up.

• Do you have your citizen developers in the business, if it's not their day job complete a process design document?
  • Yes, that’s a requirement. We don’t want to do things differently than what IT does because it is changes in the system, so we do require that.