AutomationOps Analyst Course
When December times become quite, I turn to little projects I dream about all year, but never manage to make room for. Those projects usually involve something with Arduinos, but also revisiting Robocorp tool stack. Today, I finished the AutomationOps Analyst course provided by Robocorp.
The course does not require coding. So it is mainly a listen and repeat exercise in order to earn the certificate. The list of chapters already caught my eye:
In the center it states Documenting the process. I am curious how Robocorp approaches documenting a process. As creator of the robotframework-camunda library, I already have a favor for process documentation, which is BPMN.
In the beginning, the course sets the right tone for developers: mocking sales people. Generalization is never fair. But the power seems sometimes that unbalanced, that my science oriented soul occasionally sighs in relief, when people are mocked who sell problems accidentally their employer has the solution for.
At one point Maria, the admin in this story, has to assess the feasibility of automating a process:
The order of bullet points seems to be from feasible to less feasible. However, I find the 3rd being a patch for the 2nd: most automated business processes require a human at some point (so category 3). You may place the human at the end or in a wrapping process, but at some point a person is involved. In RPA we talk then about “human tasks”. In BPMN we call it “user task”. I brought processes in to production with users being integrated in to the process as consultant for ambiguous cases.
Consider this example:
A workflow engine like Camunda supprting BPMN lets you integrate users in to an automated process. A user can also structure data when rules are to ambiguous (see first user task in this example). And a user can decide when to give up on a process execution (see second user task). In my opinion, using Camunda for task orchestration improves capabilities of an automated process significantly.
The documentation part of the course for shocked me, at first: Maria, the admin, is supposed to write a Process Definition Document — a MS Word document that has to be revisioned. On the one hand, Word documents are awful. Especially as evolving documents. But on the other hand so many corporations still in 2021 install this nostalgia of the typewriter age by default on all their workstations. So it’s probably fair to provide a DOC template for spreadsheet managers. Everyone who grew up making their homework with Wikipedia will know how to migrate such a “document” in to proper knowledge management anyway.
The content of the PDD feels right, though. For example, you create a list all 3rd party systems and their interfaces. When describing the process, a “flow chart” is proposed. I find a simple “flow chart” ok-ish for drafting. But there is ISO 19510 for describing a process, which I would use from the start. Because it is a standard, ISO 19510 is well known across different professions. And this ISO is known as BPMN. It would also express the paragraph about exceptions more effectively than only having textual documentation.
The next chapters about implementing and launching are straight forward. I still find them practical, because they provide a checklist with links to further documentation. I like the closing quote
As you can see, launching automation to production does not mean you can then forget about it completely.
Because this statement is exactly my experience, although gen1 RPA vendors constantly claim the opposite. But as soon as a vendor is adopted, customers hire gen1 RPA developers to applying automation seriously. Only that you now fight for a limited amount of people, because you maneuvered your company on an expensive island.
That’s why I’d always recommend to invest on a stack of specialists. Especially open source oriented specialists. And yes, investing means also financially. With open source solutions you always have the option to evolve beyond your current use case. Otherwise you would have to wait for your vendor to sell you a new use case you did not even know you need. You can even port to other vendors, if you like. That competition keeps open source oriented vendors sharp. They cannot lay low on their lazy income stream from license fees. Since you always have the option to switch, vendors need to offer you reasons to stay. Those reasons usually are awesome support, interoperability and an ear not only for your current but also your future challenges. That’s why I like products from companies like Camunda and Robocorp.
The AutomationOps Analyst course ends with a test, which you probably would also pass without having read the course material. But the material is well crafted, entertaining to read and has some moments to reflect even when you are working in the field for some while already. For instance the chapter about feasibility: is calculation of ROI complete, when I have not assessed the option assigning the manual tasks to sales?
