Leadership is the invisible yet powerful force behind bringing in the alignment in an organization. The difference between an efficient and successful organization and an inefficient and unsuccessful one is the alignment of goals and vision across teams. A true leadership would succeed in bringing that alignment and making sure everyone’s talent and effort are put in right things and in the right direction, at all times. Love your customer and fear your competitor – your fellow team member is your only ally that can help you succeed.

What Electromagnetism tells us about Leadership. This question might sound funny at first. However, if you understand the mechanism at work behind electromagnetism, you can draw a lot of similarities between an electromagnet and a successful organization. If you are interested keep reading …

Throughout my schooling I loved Physics. It kept me intrigued and interested at all times. A few concepts of Physics stuck with me till date. Now and then I find a few analogies of physics which I apply in my professional and personal life. Electromagnetism is one such concept that stuck with me.

The concept behind it is very simple. Take a piece of Iron, attach both sides of it to a power supply and let the electricity flow through it continuously. After a certain time the iron piece becomes a Magnet. It’s that simple. Let’s see what happens behind the scene. Before the electricity is passed through, the iron atoms are all haphazardly aligned – although the parts (domains) of the iron piece have magnetic power, the random alignment of atoms across domains cancel out each other’s magnetic power. Electricity brings all those atoms across all domains into alignment and in one direction. That’s all electricity does. The result is – a piece of iron with a limited to no usage becomes a highly useful magnet that enables a lot of technologies that transformed the world.

To apply this to the culture of an organization, we often see a lot organizations with missing alignment across multiple teams and organizational units. Although the individual teams are capable and intend well, their efforts could cancel out each other’s unless their goals are well aligned. In my opinion, the first and foremost responsibility of a Leader is to bring that alignment in the organization.

Leadership is the invisible yet powerful force behind bringing in the alignment of goals in the organization. The difference between an efficient and successful organization and an inefficient and unsuccessful one is that alignment of goals and vision across teams. A true leadership would succeed in bringing the alignment and making sure everyone’s talent and effort are put in right things and in the right direction, at all times. Unfortunately, it’s not as easy to implement as it sounds. That’s where true leaders stand out. The forces of destruction often found within the organization. There isn’t a single successful country with severe internal conflicts. So do the organizations.

Love your customer and fear your competitor – your fellow team member is your only ally who can help you succeed.

Electromagnets remain to be magnets until the alignment is in place which fades away slowly – unless that electricity is flown time to time through it. One day these iron pieces become permanent magnets that do not require electricity anymore – An organization that’s self-sustainable and the one that does not require a Leader – that’s the nirvana of Leadership.

Please share your views and comments below…

What should give birth to a Tech project? A series of User Empathy sessions or a new fascinating technology? Where should a technology roadmap starts – from customer interactions or exploration of upcoming technologies or the project wishlist of a technology leader? If so, what about the Accountability, Attribution and Return-On-Investment? Instead, should Corporate Strategy be giving birth to it while strategic targets play the yardstick of performance?Make Corporate Strategy the language of Tech Roadmaps.

The essence of strategy is choosing what not to do – Michael Porter

In today’s world, no business or industry is untouched by Technology. Digital revolution has started a while back and is still underway. Given Tech’s omnipresence, strategic importance and the cost it incurs to an organization, it’s very crucial to use Tech resources diligently. Technology roadmap, which is generally created annually, sets the direction for the upcoming year. Then the question is where should it be created from?

Methodology to Define Tech Roadmap

If the Technology roadmap is driven by the feedback from user empathy sessions, user interviews or upcoming technologies or interests of a Tech Leader, it may soon diverge from the Strategy. Corporate Strategy should be the Origin of Tech Roadmaps. Here is a methodology I believe helps to create effective tech roadmaps.

• Understand different aspects of Corporate Strategy
• Define Tech’s role in achieving it. Define the role in terms of different aspects/streams of corporate strategy
• Align the streams of corporate strategy to the Tech organization’s hierarchy
• Each Tech Department should take on one or more streams which set the department roadmap
• Split each stream into further granular pieces that should define the project themes
• Onboard each new project by tying it to a stream of corporate strategy
• Define project outcome in terms of strategic objectives to which project contributes to
• Educate the entire project team on the strategic initiative and the expected outcome
• Measure the outcomes when the project is delivered and put to use
• Make sure all strategic initiatives are fully covered by the projects

The above methodology has a few distinct advantages, in my opinion.

• Brings the Corporate Strategy to grassroots of the organization where each individual is educated and empowered to contribute to it
• Makes it possible to define concrete Return on Investment in terms of not just dollar amount but in terms of strategic initiatives as well. If a given project cannot be aligned with the strategy, it can be dropped – hence the resources can be used very efficiently.
• Saves cost in terms of both dollar amount and opportunity. It keeps individuals motivated by helping them understand how their work contributes to the organization.

In today’s world, technology is the fuel every business runs on. This puts tech roadmaps at the center of corporate strategy. I believe the above methodology keeps tech roadmaps in sync with the strategy.

I welcome all the comments and views. Feel free to share.

When you travel through the froth, reach to the core and witness the reality, RPA does not look like what you were told by the Sales reps and the Service providers. RPA as a concept certainly got a potential for cost savings. Is RPA useful at all? – Yes. Should you look at RPA? – Yes, you must. Can you eliminate dependency on Technical People and let Business Subject Matter Experts automate the processes? – A resounding NO. Can RPA use an App Store? Yes, Yes and Yes. These are RPA’s promises and realities – RPA minus all the BS built around it. RPA vendors must concentrate on building a highly extendable and customizable platform not the individual skills. Although vendors can build a few necessary skills, it must be the job of developers

If you are a pragmatic person and keen to produce value with everything you do, you want to understand a concept or a technology for its true worth. Because of the forth created by Marketing people, this info is unavailable in ready-to-consume form. This article is intended to process all the crude info that’s freely available around RPA and get to the core of what it is truly capable of – at least as of today. If you are new to RPA, please refer to my previous post to get an idea of what it is.

RPA is incapable of empowering business subject matter experts to automate without the help of technical people. RPA is a platform that comes with a suite of tools that make automation possible. However, the current platform and toolset are inadequate and unreliable to achieve this technical independence. Here is a list of ares where I think the problem is.

Openness

Openness is my big concern with RPA. Currently RPA products are mostly closed environments. The vendors look at them as a platform that does not need to integrate with other non-RPA systems. If the vendors do not open their platforms up to other systems, it would be a disaster for them. For example, ability to trigger an automation task – may be exposing the script as a REST endpoint, ability to share application context or transaction context among RPA and non-RPA systems, ability to pass input/output parameters with native datatypes instead of passing through files – pass an array of integers vs writing the integers to a file and pass the file as input etc.

OS Openness

Most of today’s RPA products can run only on Windows machines. This means irrespective of your IT policies and guidelines, you are forced to use Windows servers(or desktops) to run RPA. For a few organizations that would be a showstopper.

For a few vendors, this restriction is partly caused by the technologies they used to build the product itself. For example, if a particular vendor’s RPA product is built using .NET framework, it cannot run on non-Windows platforms. Some of the RPA products heavily rely on Windows internal libraries directly (instead of abstracting it out) to achieve majority of the system level work. This is another reason why they cannot be ported to other platforms easily.

Code Openness

Most of RPA products allow you to write custom code and run them along with other standard activities. Technically they can allow this custom code to be written in any language and still be able to run it with proper execution environment – whether they ship the environment along with the product or provide a way to the admins to install and configure it. In my opinion, this is a great opportunity to RPA vendors to open up their environment. But most of the RPA products allow only one or two scripting languages to write libraries in. VBScript, JScript – are you really serious, guys? This is 21st century AND we are 17 years into it already. Wake up !!! No technology can have mass adoption without support of developer community. This is the way RPA vendors to get the much needed support from developers – support as many programming languages as possible to implement custom functionality

Platform Openness

In general, RPA platform itself is very closed. For technical people, developing automation scripts with RPA products is nothing less than torture. For example, the script you compose through dragging and dropping a few activities cannot be hand edited – Behind the scenes this script is nothing but a bunch of commands written in a sequence. However, most of the vendors won’t allow you to edit this script by typing. If allowed, this would help developers save a lot of development time. The scripts are stored in proprietary binary formats. This is a lot of inconvenience that could be easily avoided by exposing the textual format of the script to developers. Even if the targeted audience to these editors are non-technical people, RPA vendors can support a developer mode of the editor which will allow developers to do more sophisticated development – one solution does not fit all.

Open for extension – App Store

No general purpose platform can claim that it supports all the use cases that are ever possible in the world. Even packaged solutions such as SAP FI/CO or SD which are built for specific domains need customizations and enhancements for real world scenarios. How can a generic platform like RPA which claims to support any domain – whether it be finance or energy or any other thing in the world – think that the standard tool suite provided would be comprehensive enough for all real world use cases? This problem can be solved by an App Store – Let the developers around the world build general purpose and specific purpose automation tools that can be seamlessly plugged into the RPA platform.

Compound Deployment Artifacts

Today all RPA vendors expect automation scripts to be single files. I think for any serious real world usage, you would build a bunch of reusable libraries which can save developers a lot of time. Although building reusable libraries is possible today, there is no proper way of packaging a script along with all the required libraries. Support for building compound deployment artifacts is necessary. Think of a script as a bunch of files that are packaged into a deployable package.

Reliability of Tools

Although there are a lot of tools – such as Web Scrapper, OCR, PDF reader – shipped with the RPA platforms, they are unreliable for real world scenarios. For example, PDF reader let you highlight a text and copy it – but few products let you specify which page of the file this text is expected to be found or which pattern should be used to identify the text etc. This information will be implicitly determined by the tool itself. The problem with this approach is, the script developer won’t have any control on influencing the decision except he/she will highlight and copy and product will figure out the pattern. In real world, this approach won’t work very well. For example, for all PDF’s the text may not appear at the same location on the same page – if not, then the script will fail. Similar reliability issues are present with other tools too. Again the solution could be to build an adaptable UI so that if the developer wants to work with the script at a higher level of sophistication, they can. RPA vendors must not keep the control with them – they must give it to the developer/implementer.

Cloud & CI/CD Support

It’s mostly safe to say that RPA vendors are not cloud ready yet. It seems they don’t have a proper plan to support Continuous Integration and Deployment also. Although you may achieve this today, it would prove to be a Herculean task.

Closing Remarks

RPA vendors must concentrate on building a platform that’s extendable, optionally customizable and can plugin and naturally play any custom built skills. Let the developers around the world build the skills. If they try to eliminate the developers from the equation, RPA will be a disaster and will bite the dust. Who knows what Artificial Intelligence would be fully capable of. Until AI proves that it’s feasible to eliminate coders, RPA should NOT assume it. As it’s today, RPA is an Orchestrator that can create symphonies by leveraging several individual skills that are part of or plugged into the platform or running externally somewhere on the Internet. Building the platform in such a manner could be the recipe for success. Openness alone can dictate the fate of RPA as a technology (or as a concept). The more open you are to the world, the more open the world is to you.

PS: Please leave your comments and share your views. Thank you.

Entering listen mode … Krishna Pisupat

Robotic Process Automation – How robotic it is and how novel the technology is? Are “bots” really software robots? What RPA means to Business personnel, Technical people and Corporations. Where does it meet Artificial Intelligence today? How well would it be married with Artificial Intelligence tomorrow? If you are on Business side or Technical side, how exposed are you to RPA disruption and how can you be prepared for it and leverage it?

There has been a lot of buzz around Robotic Process Automation (RPA) off late. If you are new to this concept and technology, you would wonder what it is. From the name you may tend to think it’s something to do with Robotics. From all the buzz around Artificial Intelligence in conjunction to RPA, you might even think it’s related to Artificial Intelligence. Let’s see what is myth and what is fact.

What is RPA?

To understand what RPA is one needs to understand what a process is. Any sequence of steps that are performed to fulfill a business need is a process. Generally a process includes the real recipe of the process – steps to achieve what is really intended to achieve, a few best practices, a few regulatory and compliance stuff, creating audit trail etc. For easier understanding let’s take something more concrete.

You are applying for a credit card with a credit card provider. You fill the application either online or through a paper application. In either case, an associate of credit card provider has to validate all the furnished information for completeness and correctness – whether you provided your first name, last name, address, annual income and finally whether you signed the form or not. Then run a bunch of verifications and validations such as background and credit checks. Finally enter all these details in a system and run a risk model that determines your eligibility and credit limit. The whole sequence of steps is a business process.

In a non-RPA world, all or some of these steps are performed by a human. Of course, in a digital world, most or all of these tasks can be done programmatically. You can build a web application so that customers can apply online and a business process can be built with one of those well known BPM (Business Process Management) systems. If all the process can be automated by a BPM system, what’s the need and role of an RPA system?

That’s where things get interesting. Let’s jump to the real world. Unless we are talking about a new organization that’s completely built ground up for this use case, the above automation is often an integration project among several in-house and third party systems. For example, credit check is often provided by a third party application which will be invoked by the credit card provider. Whenever we talk about Integration, there is a lot of complexity, confusion and cost involved. Integration generally requires both the service provider and consumer to agree upon a few protocols and standards. On top of that, there are software development costs for both the ends. Also, not all applications are integratabtle as a few are legacy or extremely complex systems – a few applications won’t even have an API which makes it impossible to integrate with them. Even BPM cannot help in these situations. In some cases even if you can leverage BPM, these projects are so costly that there won’t be any ROI (positive cashflow) after factoring in the software license, development and maintenance costs.

With RPA, most of these issues are solved in an economical way. RPA is NOT a single technology. Instead it’s a collection of tools a few of which have been in use for more than a decade. A few tools that are integrated in RPA platform are

• Record and Play tool – Records what a human performs and repeats it any number of times. Of course you can customize it so that each run can be performed with a different data set. If a human copies a row of excel spreadsheet and pastes in a form on a web page, this tool can simply repeat the same task – it opens the excel, highlight the text, copy it, open browser, log on to the application, navigate to the intended page and paste the content in the correct field of the form
• Web Scraping tool – Reads a web page and extract content out of HTML
• Other content extraction tools – Extract the content from spreadsheets, PDFs and images using OCR (Optical Character Recognition) techniques etc.
• Rule Engine – Allows users to write rules which dictate the conditions to all the above tasks when to run and when not to run. Validations and verifications can also be performed by a rule engine.
• Orchestrator – Helps to build the sequence and flow of tasks to determine execution order

If you are familiar with any of the automation testing tools, record and play and site scraping tools must be well known to you. Using these tools, one can mimic a human being with out doing any integration among disparate applications. As a result, any application – whether it has an API layer or not, it’s developed using a new technology or not, you can integrate it with an RPA application. In fact, even the application provider would be unable to identify whether a human is performing these tasks or a bot is performing them – of course a few sites build captcha and similar techs to avoid bots.

For BPM professionals, rules engine and orchestrators are inevitable tools. These tools help to provide order and conditionality to an RPA bot.

What RPA is NOT?

As it’s today, RPA does NOT leverage much of Artificial Intelligence or Machine Learning. Most of the out-of-the-box RPA products do NOT have this integration yet. If you ask me whether RPA is any Robotic, my answer would be a big NO. Of course, what you build with RPA could be eligible to be called a “bot”. But beyond semantic meaning, it has nothing to do with Robotics.

As it’s today, most of the vendors’ bots are run independently as isolated processes. Probably at some time in future, they have to be invocable from other software products so that they can be launched on-demand and as part of a larger business process that involves non-RPA systems.

What it means to you?

I hope, by now, you got a conceptual view of what RPA is and what it is capable of at a very high level.

Business Personnel – If you are a business personnel who performs any repetitive tasks which are mundane and require a little or no business knowledge, it’s possible you may be replaced by a bot as of today.

If your job needs simple to medium level of business knowledge that can be encapsulated into some kind of structure and logic, you might be taken over by RPA as well. RPA technology as it’s today can perform your role very well.

If you are a Subject Matter Expert in a business area and it takes a lot of learning to reach where you are, then you are safe for now – at least until RPA integration with Artificial Intelligence is improved.

Technical Personnel – If you are a BPM professional, you may need to learn RPA soon. I believe, this is the skill that could be at risk because of RPA to start with. RPA is a natural evolution for you.

If you are a software programmer, you should be worried too. RPA cannot replace all software projects. However, some of the projects that would have been developed in traditional ways would now be developed using RPA. It means less demand for Software Programmers.

What’s the bright side?

Business Personnel – RPA truly empowers business personnel to take the control of automation. Your Subject Matter Expertise could still be appreciated. You don’t have to rely on Technical personnel as much as you used to. Significant portion of RPA implementation requires a little or no technical knowledge. It means, if you are willing to learn RPA, it would be actually a boon to you. Just to clarify, you don’t have to learn writing software code but you can implement at least half of automation yourself.

Technical Personnel – RPA is nothing challenging given your technical background. Learn it today. You can still share half the automation pie. Not all of the automation is programming free. You still need to implement some complex logic through scripts and programming. On top of it, maintaining, monitoring of RPA environment would still require technical expertise. Join all of this with Analytics and insights – you see a bright spot on the other side of the tunnel.

Leadership – There is a lot of cost cutting waiting for you to grab. Jump into RPA and adopt it. It could mean a very fat bonus for you at the year end.

Closing Remarks

I don’t put RPA and Artificial Intelligence in the same bucket as of today – they are two different worlds. On the contrary, RPA has nothing intelligent in it. However, it’s only a matter of time before they complement each other.

Nevertheless, RPA is going to be a disruptor if it’s not already. There is still an early mover advantage on the table if you are ready to adopt it.

PS: I welcome all constructive comments. Please feel free to leave them here. Thank you.

“Is an entity Human or not?” – would this be a classification problem or a regression problem? Classification says either Yes or No where Regression says what percentage of the entity is Human.

In Part 1 the Narrator felt the person who helped him was a Human Being based on Looks, Abilities, Knowledge and Emotions. Let’s see how Looks alone may not be able to distinguish between a Robot and a Human.

If you were to identify a human, firstly you would depend on physical appearance of the person – Legs, Hands, Head etc. Current technology is either already providing alternates to human organs or close to provide them.

We can categorize Human organs into to two types

1. Organs that are required for the body to function but are invisible to others
2. Organs that perform actions and/or are visible to others

For example, heart is a vital organ of human body. However, heart’s role is just a supporting role. Heart purifies the blood and re-pumps it to the other parts of the body. However, if there is no need for blood or there is blood that does not need purification, probably heart would NOT be needed. Similar argument holds good for other inner parts such as Lungs, Intestines etc. All these supporting organs are not visible to outside and hence do not play any role in distinguishing between Humans and Machines.

Most of the inner organs’ role is to produce energy needed by the human body from the food the body consumes. If we can supply the needed energy through some source of energy, then we wouldn’t need any of these organs.

Regarding the outer organs, there are artificial limbs that are already in the market. There is research going on to produce artificial skin – that looks like human skin. It’s simply a matter of time to produce a human look alike Robots. There are already a lot of success that’s achieved. Refer to this News item http://www.telegraph.co.uk/science/2016/03/12/meet-nadine-the-worlds-most-human-like-robot/

Now we saw how a Robot can be made to look like a Human. Is it possible to Augment Humans with Artificial Organs? There are researches going in many Universities and Institutions on 3D Printing of human organs. Using bio-ink filaments – think of these are cartridges filled with Stem cells, we can print human organs. Although this is only a partly proven technology as of now, making fully functional human organs is only a matter of time. On the other hand there are attempts to design chips that perform human organ functions – A Heart on a chip. Check this link https://www.seas.harvard.edu/news/2016/10/3d-printed-heart-on-chip-with-integrated-sensors. Using similar techniques, it would be easy to manufacture human organs like instruments, that perform what these human organs are supposed to perform.

Let’s take a metallic Robotic human like Chassis. Add artificial human organs that are manufactured somewhere on a factory assembly line. You end up with something that looks like a human except that the internal organs are invisible to you and they may be a bunch of wires and circuits. On the other hand, take a human and augment that human’s natural abilities with artificial tools that act and look like human organs.

When a Robot can be designed to look like a Human and a Human can be augmented with Technology produced artificial organs, the result of both would be something that’s between Humans and Machines. Where do we draw the line? Does the baseline that we started off of – a robot chassis vs a human body – defines what the resultant entity should be called?

One thing is certain. The question of answering “whether an entity is a Human or not” has been an Yes or No question – in other words a Classification problem. Soon it will become a Regression problem which says how much percentage of the entity is Human.

If the Looks alone aren’t enough to make the distinctions, can the Abilities – what an entity can and cannot do – or the Emotions make the distinction?