I have been thinking of composing my ideas on robotic process automation for a while. My initial gut feeling was like “there is something wrong about it”. However, to be more serious, I've read about it, examined the current market and tools, learnt typical use cases and challenges so that I postponed the blog post until this day. And today, I am still saying that “something is wrong”.
I am living on enterprise software development and
information systems automation for about 20 years. I have seen
mainframe systems, client server systems, three tiered systems, n
tiered systems, distributed ones, comet servers, cloud based systems,
re-invention of virtualization and I am still experiencing new models
of computation and automation.
Treat a macro as it is a macro
In my interpretation, RPA approach is a type of
macro. We are familiar with macros since assembly programming
language was dominating the realm of software development. Macros are
good for improving a person's repetitive task performance and not
good for enterprise automation.
People have been using macros for decades, solving
their information processing problems in a, so called, IT independent
way. Remember the times you faced big macro embedded spreadsheets,
actively in use in a department, where you are conducting systems
analysis for better automation. You must read the macro codes,
extract the logic and after perfecting it, design the enterprise
automation in a more manageable and accountable way. We were calling
that hidden macro code silos as shadow IT. Our mission was
illuminating the shadow.
Nowadays, people are calling those department based
macro codes “robots”. Moreover, they are saying that they
optimize and automate processes by using those robots. The only
difference is, they don't want you to code your macros in spreadsheet
applications but by using some RPA tools.
It is wrong. It is still the macro. And it must be in
personal self-service use in departments no matter the department is
in IT organization or not. You must not try to automate your
enterprise wide processes by using macros. Full stop.
Record 'n Play
We are living in 21st century in the middle of information boost, hyper connectivity, remote cars on the surface of Mars but we call a record and play based fancy software a robot. Asimov must be aching in his grave. Please have a look at the video below.Those were the days we call macros as macros, not robots. Today, many RPA tools are still recording and playing. Very interesting, right?
Process engineering and automation
RPA approach proposing that if you have some rule
based repetitive tasks handled by human beings in your processes, you
can create a macro code for eliminating human task force in the
operations given. So that you can reduce the operational expenses in
a very fast way. Trivial jobs to be done by macro codes, faster than
a human, more accurate than a human, cheaper than human manXhours.
Sounds good. Some limitations of contemporary RPA projects are (a) no
critical communications can be handled, (b) no critical decisions can
be made, (c) no rules, no actions. That means, no intelligence.
Although, some AI algorithms are being tried to be
embedded in RPA macro codes, companies cannot take the risk of
millions of wrong messages sent to customers or delegation of
critical decision making to algorithms because of possible legal
consequences. So there is still time for achieving so called
cognitive RPA. That means, no intelligence again.
When it comes to process automation. It's becoming
more interesting. Imagine your are reviewing a company process and
you found out that a team of people is checking a screen, controlling
the values in some text boxes considering some rules and approve or
reject based on those rules. And at the end of the shift, they are
sending e-mails for reporting number of approved and rejected records
to their bosses. It sound like this operation can be fully automated
because structured digital data is used to execute some deterministic
rules and finally number of processed records are reported to a
parametrically known authority.
Healthy steps of automation can be listed as follows
- Investigate the software system carrying data to operators and find data sources that are displayed to operators
- Check data flows, assure data validation steps, define exceptions
- Define the rules of approval and rejection to run on identified data sources
- Develop a software module for processing approval and rejection rules with no human interaction.
- Develop a software module for consolidating and counting processed records in bullet 4 and sending automated e-mails to defined recipients for reporting
- Test the modules
- Launch the modules
- Discard the approval screens in the systems
- Discard the human operations in the process
- Document the jobs done
Of course, you need system analysts, programmers and
testers to make this automation happen. The meta process regulating
those actions is called SDLC, owned by CIOs. It is business as usual
in IT world. By following this methodology, you are guaranteeing
portability, performance, maintainability, usability and the
functionality of the software systems used for process automation.
What RPA suggests for the same situation is GUI to
GUI operator mimicking through macro coding and calling this a sort
of process automation. This is a fast but weak way of integration.
Because, software systems have different layers of data, business
logic execution, data exchange, service integration and presentation
(graphical user interface). If, in this scenario, you do not make the
necessary changes in the proper layers of the software systems, you
end up with non maintainable systems. Systems are not designed to be
integrated through their graphical user interfaces. If you do this by
recording and playing some GUI steps, it is in decent words, sub
optimal. From software engineering perspective, I would call it ugly.
Forget any ugliness but just think of the regression effect: GUIs
will be changing in time and your macros will be obsolete. Since no
software provider is considering their GUIs as system to system
integration points, they will not be warning you regarding system
integration complications after GUI upgrade they released. As a
result, your so called automated process will be broken. Actually, if
it is rule based, it will be broken; if you used cognitive RPA by
including adaptive algorithms, you will never understand what's
happening. And who will be the responsible?
Silos against central IT
RPA tool providers are using the argument of IT independent process automation. If the aim is non maintainable system to system glue application, it is OK. It is OK for a very short term indeed.Imagine you have non IT RPA departments using RPA tools to glue systems. After 5 years, there will be piles of RPA macro codes that are not managed by IT but by RPA departments who are trying to synchronize their macros with enterprise software modules managed by IT. Those enterprise systems will be more likely developed in continuous delivery/continuous integration fashion. Therefore, massive software change will be inevitable. What will happen to RPA macro codes? What will happen to so called automated systems? Who will be the responsible party to keep things together? Are RPA departments going to be a part of IT organization? Then, is it still be an IT independent thing?
So what?
In short, RPA is a macro. Use it as a macro. Embed it into operating systems or make it a personal solution tool for empowering professionals who are to formulate their repetitive operations and save time. Actually, hundreds of thousand are using macros today: It is a part of programming languages, code editors and IDEs, spreadsheets, operating systems, BPM tools, software testing tools etc. It has been a commodity for years. The idea is just not to make it a sort of enterprise IT solution. Keep it as a self service feature.Or maybe I am old fashioned.
No robots detected.
