With a modular SDK developed entirely in Java, Jidoka is the best Robotic Process Automation tool for developers.
A recent research note published by Horses for Sources HfS, titled Bots are Starting to Comprehend Spanish situates Jidoka as having “a leading position in the Spanish-speaking world” and highlights the fact that it is a Java platform (in comparison to competitive solutions developed in .net) and also our vision in programmatically undertaking entire business processes (“top down” approach) instead of a “recorder” focused on individual tasks (“bottom up”).
For those of you unfamiliar with these approaches, both top-down y bottom-up are strategies used in the design of systems software and when applied to Robotic Process Automation (RPA) essentially mean the following:
- Bottom up
- This approach is centered on the automation of individual tasks until a business process if defined.
- The construction process is based upon scripts created from “recording sessions” of individual tasks. An entire end-to-end business process is difficult to record, being more feasible the recording of individual tasks.
- Top down
- The starting point is a high level workflow which describer the business process, and depending on the granularity of the process, may or may not have a direct relationship between actions in the workflow and the individual tasks performed by a person.
- It is a very common approach when building programmatically, ie: when an SDK / API is utilized.
An RPA solution without programming?
The truth of the matter is that the ” RPA universe ” is much broader than what the vast majority of manufacturers are telling potential customers asserting that “no programmers are needed to build software robots“.
Some of these Robotic Process Automation manufacturers openly state that to program a robot (note how they use “program” a robot), all you need is for a business analyst to use a recorder that captures all the actions performed on the screen associated with a given business process, and voila! You have an operational robot.
I’m not saying that for demonstration purposes, the impact of “I can make a robot in 5 minutes” is not impressive, but the problem arises not in a controlled demonstration, but in real environments where you must connect to multiple applications, where the processes can be highly repetitive but of great complexity, and these processes are usually subject to change: it is not possible to have a clear vision from the beginning in what steps to take or what business rules to implement.
So what do we do in these cases? Do we re-record the process? I think that the answer in the vast majority of cases is no, you need a programmer to code these changes, and the best part is, since the code was automatically generated by the recorder, the programmer is forced to work in a unfamiliar environment and with code that isn’t his.
We all know that real world processes include a series of conditions, bifurcations, exceptions, etc. Situations, that before undertaking automation, that are not evident in a single demonstration session by the users of the process. All these variations always appear afterwards, while building the robots and the volume of input data usage becomes more extensive. This is the moment when the experience, know-how, and programming skills of the developer come into play. It may be true that to “automate 4 clicks and create an excel sheet” we don’t need a programmer, but the issue here is that in real enterprise processes we are never limited to 4 clicks and managing a excel sheet. Playing around with scripts for a while is fun, but if you’re serious: create a program.
The benefits of being able to develop software robots
There are many other questions surrounding recorders: Does the recorder generate test cases for these robots? How is the code generated by the recorder? It is modular and easy to maintain? Does it meet design requirements, quality, and security standards accepted by the industry? We have already encountered numerous cases where customers RFI include amongst their requirements, the revision and validation of the quality and security of the robot code.
Our vision is clearly different: programmers are the ones who should build robots from the beginning
And to do just that manufacturers of RPA solutions must provide them with the most powerful tool in the programming world and this isn’t exactly a recorder – very few programmers are passionate about code generated automatically – not even an IDE, but a SDK (Software Development Kit), that is modular, extensible and reliable, built on a robust, open, and universal language, such as Java.
At Jidoka a robot is not a script, but a program. It’s a program that is stored in a code repository (Subversion, Git), while meeting strict quality standards defined by tools such as PMD or Checkstyle, that implement test cases (such as JUnit for example) and that are included in continuous integration software tools such a Jenkins.
Along with the investment in licenses, customers should also invest in training their programmers. With this in mind Jidoka has an in depth self-paced education program including tutorials and development guides. And the most frequent question asked by customers is always the same: How long will it take my programmer to develop robots? Based on our experience, a developer is able to build and deploy Jidoka Robots after an average of 30-60 hours of self-paced training.
If the self-training program is not sufficient the option exists of contract on-site training or personalized on-line courses tutored by the same team that developed Jidoka and supports the platform on a daily basis. And finally, if you need further assistance you can contract technical support through a development seat (developer seat) where we provide assistance in the use of the Jidoka SDK in building Jidoka Robots.
So the answer to the question of recording or programing a robot is really simple: programming. And if we want to program a robot, we’d better have a programmer do it, as the popular Spanish proverb says: “the shoemaker to his shoes”.