Process Discovery vs. Process Mining

The first step in automation is to gain a complete understanding of the current state business processes. Often enterprises do not have a knowledge base of all their existing processes and hence identifying automation opportunities becomes a challenge. 

There are two techniques to address this challenge:

Process Discovery

Process Discovery tools typically record an end-user's interactions with the business applications. This recording is then intelligently transformed into process maps, BPMN diagrams and other technical documentation. The output from the Process Discovery tool can also be used to serve as a foundation for building automation bots. Given below are some examples of Process Discovery tools:

• https://www.atos-syntel.net/insights-and-resources/publications/syntbots-process-recorder
• https://www.uipath.com/product/task-capture
• https://www.automationanywhere.com/products/discovery-bot
• https://www.blueprism.com/products/process-assessment-tool/

Process Mining

Process Mining is all about extracting knowledge from event data. Today all IT systems and applications emit event logs that can be captured and analysed centrally using tools such as Splunk or ELK stack. As one can imagine, the biggest drawback of Process Mining is that it would not work if your legacy IT systems do not emit logs/events. 

By analysing event data, Process Mining tools can model business process and also capture information on how the process performs in terms of latency, cost and other KPIs (from the log/event data). 

Given below are some examples of Process Mining tools:

• https://www.uipath.com/product/task-mining  & https://www.uipath.com/product/process-mining
• https://www.celonis.com/solutions/celonis-snap
• https://www.abbyy.com/timeline/
• https://fluxicon.com/disco/

Ticket Triaging with AI

The below link is a comprehensive article that introduces "ticket traiging" and also explains how AI can be used to automate this important step. 

https://monkeylearn.com/blog/how-to-implement-a-ticket-triaging-system-with-ai/

Some snippets from the article:

"Automated ticket triaging involves evaluating and directing support tickets to the right person, quickly and effectively, and even sorting tickets in order of importance, topic or urgency. Triage powered by Natural Language Processing (NLP) technology is well-equipped to understand support ticket content to ensure the right ticket gets to the right agent.

NLP can process language like a human, by reading between the lines and detecting language variations, to make sense of text data before it categorizes it and allocates it to a customer support agent. The big advantages of using NLP is that it can triage faster, more accurately and more objectively than a human, making it a no-brainer for businesses when deciding to switch from manual triage to auto triage."

Ruminating on JAB (Java Access Bridge)

Quite often, we need to build automation around Java desktop apps. The default MS UI automation framework would not be able to identify Java UI components (based on Swing). 

Hence we need to use a bridge..and this technology is called as JAB (Java Access Bridge). Using the JAB dll on windows, you can access Java client UI controls and build your automation use-case. All commercial tools such as UiPath, AA also use JAB behind the scenes for Java desktop automation. 

Google has also released a cool tool called "Access Bridge Explorer" that can allows exploring, as well as interacting with, the Accessibility tree of any Java applications that uses the Java Access Bridge to expose their accessibility features,

Ruminating on Automation (RPA) Security Risks

 Intelligent automation & RPA can drive operational efficiencies at organizations and help boost the productivity of enterprise resources. But there is also a risk of cyber-attacks as bots introduce a new attack surface for hackers. 

Without proper measures, enterprises may face increased risk exposure due to bots. The following recommendations would enable organizations to mitigate the risk of such security attacks.

1. Secure Vault: All credentials required by the bot to execute tasks on applications should be securely stored in a Vault (e.g. CyberArk or HashiCorp Vault). This ensures that the target application credentials are not stored by the bot and only accessed at runtime by the bot from the vault. 

2. Least Privilege Access: bots should not be given a blanket access to perform all operations, but should be given only appropriate access as required for the automation usecases - e.g. many automation usecases would entail 'read-only' access to databases/applications. 

3. Selecting appropriate Automation use-cases: While down-selecting automation usecases, it would be good to have 'Security Risk' as an parameter for assessment. If a bot needs admin access across multiple applications to perform critical business functions, then the organization can decide to NOT automate this usecase and handover the case to a knowledge worker. The bot can enable this smooth transition to humans (via a workflow or case management tool).

4. Change Bot passwords/secure keys: As a security best practice, change the passwords and secure keys for the bots (and machines where bots run) regularly (e.g. once a month). 

5. Security Testing of Bots: Ultimately bots are also software components and we need to make sure that the bots undergo both static code security analysis and runtime security testing. 

6. Audit Trail & Proactive Monitoring: The automation framework should provide a detailed audit log of all bot activities. Each and every step executed by the bot should be available for forensic audit if required. Proactive monitoring of this audit log can also be automated to quickly alert users of any anomaly pattern or security breach. 

7. Governance Framework - Last but not the least, it is important to setup a proper governance framework for bot lifecycle management. The governance framework should clearly define the roles and responsibilities and the proper process to be followed for the entire bot lifecycle. 

Ruminating on the hype around hyper-automation

 So what exactly is hyper-automation?

In simple terms 'Hyper-Automation' is going beyond plain RPA. In RPA, the bot just mimics what a human would do. 

But in hyper-automation, along with the RPA tool, we use other technologies like AI/ML, workflow engine, rules engine to automate E2E process flows. Thus we make the business process more streamlined and robust ---- essentially better than what the human was doing. 

Even Process Discovery Tools are considered to be an important part of the hyper-automation journey. Process Discovery Tools enable us to understand the current state business processes and offers suggestions on streamlining it. It does not make sense to automate a fragmented process, but we should first streamline the process, remove redundancies and then automate it. 

Example - A bot reading an unstructured email and understanding its intent, extracting relevant data points from it (AI) and completing the requested transaction via a desktop app (RPA). 

Java libraries for SSH and Powershell automation

If you are doing some basic automation and want to execute commands on Linux or Windows, then the following open source libraries would help.

JSCH : http://www.jcraft.com/jsch/
JSch is a pure Java implementation of SSH2 and once you connect to a Linux server, you can execute all commands. A good tutorial is available here - https://linuxconfig.org/executing-commands-on-a-remote-machine-from-java-with-jsch

jPowerShell:  https://github.com/profesorfalken/jPowerShell
This is a simple Java API that allows to interact with PowerShell console. Sample code below:

Ruminating on the 'Infrastructure as Code' paradigm

Setup (installation and configuration) of servers and other infrastructure components is a tedious process.

In the olden days, process-oriented teams created meticulous documentation on 'how to setup a server' - typically in a word document with screenshots and step-by-step instructions.
Folks then tried to automate some tasks using scripts - e.g. unix shell scripts/bash etc.

But today, in a cloud-first world, setup of servers and deployment of applications need to be completely automated. The whole premise of 'Infrastructure-as-Code' is to write code in a high level language (e.g. Java, Python, Ruby) or a DSL (domain specific language) to automate the provisioning of infrastructure and managing configurations.

So this goes beyond just writing simple scripts. You utilize all the best practices of agile development projects - i.e. version control, unit testing, iterative development, etc. The whole revolution happening in DevOps acted as a catalyst in promoting the concept of 'programmable infrastructure'. In DevOps, the core concept of 'You built it, You run it' promotes closer collaboration between the development teams and IT ops team.

Popular tools such as Ansible, Kubernetes, Puppet, Chef, etc. can be used to automate your complete deployment cycle and help you achieve Continuous Delivery.