This is a general question. For those that are developing the Bot are you first creating diagram of the flow in some diagram tool or are you just building the flow is studio Pro?
Hello @javierruiz
I’d love to get the conversation started around how everyone starts building their workflows and what they do from the ideation phase. Do you draw the flow on a diagram tool first, or how do you achieve this? Perhaps @Muhammad_Hayyan, @Pedro.azevedo, @cris-dsc, @BrandonTerry, and anyone else can demystify this subject.
Thank you, @Mabwa_Neek, for including me on this! For each process I design, I also create a Process Design Document that details how human Associates complete these tasks and includes a flowchart for the overall process. There is also a Solution Design Document that details how the bot performs the same process with another flowchart, and analytics that show how the bot performs the same process more accurately and efficiently. I hope this helps!
Ok this is the same of what I do which I agree to this process.
I use diagram.net for my flowcharts.
I am also looking at possibly adding the electeoneek activities shapes to diagram.net so as we create the flowcharts we can easily do a 1 to 1 for the shapes to the activities. This would be easier if a BA or SA is handing the flowchart to a RPA developer to now develop in Studio.
Sorry here is the full link
Hi @javierruiz
Thank you for including me @Mabwa_Neek
For me, Time Management is very important. So I prioritize things for me. I take my most of the time gathering the right requirements and then developing the Bot on Studio Pro. However I roughly go through the steps and design the flow on a notebook, for better understanding, rather than using any particular tool. In your case if you want the overall working of the project in a very professional way and you are not bound with time. Then it’s a very good practice, designing flow on a tool. In this case I would recommend using Creately Flowchart Software | Create Flowcharts Instantly | Creately.
However I have been working on ElectroNeek for the past two months, so I am quite familiar with how to develop a flow only by reading the requirements. But again I would say “ gathering the right requirement is more important than any other step “.
So I would suggest everyone to give most of their time on gathering right requirement. It will definitely gives you the best result.
PS: I know I slipped out of the topic. But I really wanted to share this information. It is the efficient way of building a Bot. I am sure it will be very helpful.
Hello!
Well, I’m new to RPA and ElectroNeek and I’m a hands-on type of person. That means I learn better when I do things. So I start by building the flow in Studio Pro and testing chunks of it. I think that’s not the recommended approach, but so far it has worked for me. I intend to build diagrams using tools in the future because I think it looks more professional and also because I’ll be more familiarized with RPA and Studio Pro by then. For now I think it just takes up too much time and in the end things might be done differently, so I’d rather start building right away.
I have create a shape library for all electroneek activities for drawio. This helps me to create the solution design diagram flow using the same shape as the studio pro activities. This way when we give this to a developer they know what activities to use. What do you guys think? If you like or think you could use I can share the repo on GitHub where I have stored the libraries.
Hi all,
I’ve been working in the RPA/AI industry for 8 years now and we’ve always treated building bots (or Digital Workers as we call them) very much like building small software.
There has to be a process mapping exercise which captures the process as-is, assuming we are automating an existing process, some people call this the PDD document, and then we work on designing what the solution will be like the SDD for some.
We actually only create one document that includes the various steps and it just evolves over time.
As with all software development, it’s easy to start building the solution, before designing it, but that’s always going to take you longer to do so. We find that spending longer on the design stage, actually means spending less time on the coding part and also results in less issues/bugs needing to be resolved at testing time.
In the past we used the BPMN 2.0 notation to capture the process at 2 different levels, a high-level which captures the main components and we can confirm this with the business, and then a deeper, step-by-step level, which is the level the Digital Worker does its thing, to make the development easier.
However, we’re working on simplifying the diagram flows as I like to keep things as simple as possible, and get the business involved in doing that part for us instead, so something like what @javierruiz suggested above could work really well, albeit with normal diagram shapes as they wouldn’t know the EN ones. Then it’s a case of converting that to a solution flow with the EN shapes if that’s what you want.
Hope this helps!
Thanks Alex for replying and welcome to the forum. This is exactly what I was thinking when I created the shape library to help simplify things. Now I started thinking like you and what if the business created there process flow then they may not be able to do that with these shapes.
Now I have started to work on an ideal where we use ChatGPT to create the process flow diagram just from someone typing out the steps. It is amazing as it is working and pretty good.
We will also be able to use API calls to certain diagram system to take what ChatGPT created and create the FlowChart and email it or post for review.