Developed entirely with Java and a modular SDK, Jidoka is the best RPA tool for developers.
The article published by HfS, titled “Bots are Starting to Comprehend Spanish” situates Jidoka as “a leading position in the Spanish-speaking world” and highlights the fact that it is a Java platform (unlike the competition that offers .NET solutions). Our vision is to approach business processes programmatically with a “top down” approach instead of a “recorder” using a “bottom up” approach.
For those who don’t know, top-down and bottom-up approaches are two software system design strategies; in the case of Robotic Process Automation (RPA) they are translated into:
- Focuses on the automation of individual tasks that are composed to define a business process.
- The construction is based on “scripts” of tasks as well as “session recording.” An end-to-end process is complicated to record, but it is more feasible to record individual tasks.
- The starting point is a high-level business flow (workflow) that describes the process where , depending on the granularity of the flow, there isn’t necessarily a relationship between the workflow action and the individual task being performed by a person.
- This is a common approach when construction is done programmatically, i.e. with an SDK/API.
An unprogrammed RPA solution?
The “RPA universe” is much broader than what the majority of manufacturers are telling customers, “you don’t need programmers to build software robots.”
These RPA manufacturers openly state that in order to program a robot (note that they themselves speak of “programming” a robot), it is enough for a business analyst to use a recorder that captures all the actions carried out on the screen associated with a business process, and voilà, you already have a working robot.
I’m not saying that for a demonstration the effect “I make you a robot in 5 minutes” is not spectacular, but the problem arises not in a controlled demonstration but in real environments where you must connect to several applications. These processes can be repetitive and highly complex but they tend to change: it is not possible to have a clear design from the beginning about what steps to take or what business rules to implement.
What happens in this case? Do we record the process again? The answer most of the time is no, you need a programmer to code these changes, and of course, you have to do it in code that is not yours, which is alien to your way of programming as it has been generated automatically by the recorder.
Any real process includes a series of cases, bifurcations, exceptions, etc. that do not appear in a single demonstration session by the people who perform the process before undertaking its automation. These variations always appear posteriori, as the robot develops and larger volumes of input data are used. That’s when the developer’s knowledge, skills, and programming knowledge come into play. That to “do 4 clicks and mount an Excel sheet do not need a programmer” can be true, the point is, in a real process there are never just 4 clicks and manage an Excel sheet. Playing with scripts is fun for a while, for something serious: make a program.
The advantages of being able to program software robots
There are many other questions around a recorder: Does the recorder also generate test cases on those robots? How is the code generated by a recorder? Is it modular and easy to maintain? Does it comply with design patterns or industry accepted quality rules? We have already found some RFI’s where the customer, among his requirements, includes the revision of the robot code to validate its quality.
Our vision is clearly different: it is the programmers who must build the robots, right from the start.
To do this, manufacturers must provide the most powerful weapon in the world of programming, not normally a recorder (few programmers are passionate about automatically generated code) or even an IDE, but a powerful SDK (Software Development Kit) which is modular, extensible and reliable, built in a robust language, universal, and is what we know as Java.
In Jidoka a robot is not a program in a script. It is a program stored in a code repository (Subversion, Git), which complies with quality rules defined in tools such as PMD or Checkstyle, which implements test cases (for example with JUnit) and is included in continuous integration tools such as Jenkins.
Customers must invest in licenses and train their programmers. Jidoka has an extensive self-training plan that includes development guides and tutorials. And the question that customers ask is always the same: How long can it take for my programmer to be able to develop robots? Based on our experience, with an average of 30-60 hours of self-training, a developer is able to build and deploy a Jidoka robot. If self-training is not enough, you can hire a face-to-face or remote course for your programmers, taught by the team that builds and supports the platform. And finally, if you need more assistance you can hire technical support through a development seat (developer seat) by which we assist in the use of the Jidoka SDK for the construction of Software Robots.
So, to answer the question of “record or program a robot?” is quite simple: Program. And if we want to program a robot, it would be better for a programmer to do it, as the popular saying goes: “shoemaker to your shoes”.
CEO at Jidoka.