BiModal RPA

BiModal RPA
Operations Intelligent Automation Ops Dev/Enterprise
Intelligent Dev Ops – A New Intelligent Automation
Paradigm?
The Struggle to Transition through Cultural Ambivalence to an Intelligent
Operations

Table of Contents:
Introduction
Authors and Key Contributors
The Evolution of Operations IA Ops Dev
Ambivalence - Irreconcilable Tension Between Two Types of RPA Deployment
Understanding the Ambivalence Through the Lens of Matrix Organizational Structures
What is Operations IA Ops Dev?
The Relationship Between, BiModal IT, Dev Ops, Enterprise IA Dev Ops, and Operations
IA Ops Dev
BiModal RPA and the COE
Bringing It All Together and Recommendations
Conclusion – Culture Driven Business Models are Key
Sneak Peek at What’s Next?
Introduction:
Market expectations for acute client focus generated by “Born in the Cloud”, fully Digital Power
Houses the likes of Google, Amazon, Netflix, and now Uber and Airbnb created a crisis for
existing Third Industrial Age enterprises unable to coop with the need for change and adaption
with speed and agility; especially among those tied to Legacy Mainframe ERPs. In 2014, the
world’s most highly rated and esteemed IT advisory firm, Gartner, developed the concept of
BiModal IT. It was a response to most large enterprises IT departments, as well as, the Business’
inability to coop with the massive change management necessary to fully convert to new agile IT
methodologies such as Dev Ops.
While there are many reason why existing Third Industrial Age enterprises are desperately
struggling to make this necessary transition, one note resounds louder and more often than any
other “Culture”! Neither this Paper, nor my full-blown automation methodology “Marine
Robotics” is a solution to the issue of “Culture”. “Culture” is a life or death issue that only the
highest, most gifted leadership can address.
BiModal RPA, as well as, Marine Robotics, a full blown BiModal cultural automation
methodology, like Gartner’s BiModal IT are transitional solutions that buy time for enterprises to
formulate more strategic, long terms, comprehensive solutions based on Fourth Industrial Age
technologies. Business model/culture solutions like HfS’ Digital One Office, as well as, save the
capital necessary to kick start the transformation process 4
.

BiModal RPA’s Author – John
Slagboom
Managed Health Care (MHC) Automation and
Analytic Architect Technology Innovation / Robotic
Automation/Data Mining & Analysis/Organization
Development. Over twenty-five year’s
Claim/Operations/Automation/Analytics experience
with a proven record of innovation leadership. I
possess an aggressive ability to adapt new
technologies to the front-line processes through
comprehensive personnel development,
organization and work system redesign: specializing
in Robotic Process Automation (RPA) to automate
MHC claims. An honor graduate of UCLA and
University of Redlands with a Master in
Management in addition to various military,
volunteer, and operations leadership assignments,
gives me the theoretical frame work and practical
ability to envision and construct advanced
generation of robotics and analytics capable of fully
automating MHC claims processing. I seek to
partner with a major MHC to sponsor a three-year
project to develop the world’s first hybrid
Operations/IT robotic claims processing unit, along
with the leadership, training, and management
system via a doctoral program began in 2016.
https://www.linkedin.com/in/john-
slagboom-a5180b69/
BiModal RPA’s Co-Author:
Deepak Sharma
is a seasoned consultant with over 15 years of
experience in UI Automation for Test and RPA. He
focused on Enterprise Applications such as SAP,
Siebel, PLM, Custom Wealth & Asset Management
platforms, Healthcare Claim Processing systems,
etc. He has worked with major global enterprises in
the UK like as Barclays, IFDS, Department of
Works and Pensions, RWE Npower and in the US
at Motorola & UnitedHealth Group. Deepak is
passionate researcher who writes about market
trends, adoption challenges, and implementation
approaches for the RPA Industry. He is an
evangelist of a Design Centric approach to RPA that
focuses on top-down development, object-
orientated implementation, and collaborative
processes between operations and IT. This holds
tremendous potential for enterprise customers to
reach the next level in business process
optimization and to act as a catalyst for digital
transformation & business model innovation.
Deepak holds a bachelor in Computer Science &
Engineering degree and a Masters in Strategy &
Innovation from the SAID Business School,
University of Oxford. He achieved distinction in
Innovation Strategy focused on market evolution &
implementation of nascent technologies such as
Robotics, 3D printing, AI and Big data.
https://www.linkedin.com/in/deepak-
sharma-304b2b7/

Key Contributor – Pavel Gimelberg:
An Agile and RPA Evangelist with over 15 years of experience in the field of Business Process
Automation. He has been involved in Software Engineering since the early ‘00s and made his
career path from a Systems Analyst in pharmaceuticals to the Head of IT Applications in a federal
mortgage agency. Pavel has broad experience transforming businesses through automation using
21st
century concepts and tools. He constantly pushes the limits of the achievable by the tenacity
of an innovative mind. Pavel creates strategic competitive advantages for his clients and he is eager
to share his knowledge and experience. With a Computer Science degree with honors from one
of the best Russian Technical Universities and an honors MBA graduate with distinction,
specializing in IT Process Management; Pavel is one of the authors of Managing Distributed
Teams online course from Berkeley X and is the founder and one of the leaders of Robotic Process
Automation community in Australia.
https://www.linkedin.com/in/pavelgbg/
In Collaboration with Nirmalya Shome:
Nirmalya is an RPA and Cognitive Intelligence Consultant with Tata Consultancy Services. He is
a part of a rare breed of management consulting individuals who has worked across the value chain
of the IT & BPS industry (front- back). He brings to the table over 11 years of international
experience across multiple industry verticals. He current focus is on building an enterprise
cognitive intelligence capability at Tata Consultancy Services, He has worked extensively on
projects using various ICR, NLP, Text Mining, RPA and Decision Management (Rules and Events
Engines) with P&C and Life insurance providers and administrators, retail banks, payment service
providers, retail chains and shipping corporations, successfully helping them realize their business
imperatives. His strong business acumen coupled with his excellent presentation & communication
skills have led him to build key relationships among clients.
https://www.linkedin.com/in/nirmalyashome/
In Collaboration with Satya Raju Mantena:
is an experienced automation practitioner with 19+ years of experience working with automation
tools, Quality functions (Quality assurance & Process Excellence) and Robotics & Smart
automation. With his expertise he has demonstrated RPA & Lean methodologies, Six Sigma
competency, process re-engineering to lead revenue generation, strategic cost reduction, improve
efficiency & productivity, fixing revenue leakages and finally setting and up and advising on
Centers of Excellence in automation (RPA and QA). His current focus is to lead and build
organizational project teams to achieve corporate goals and to ensure customer satisfaction
through timely and quality deliverables. His specialty is adaptable design and processes to drive
continuous improvements through lean methodologies and best practices. He is a natural leader,
influencer and maintains a sincere and eternal passion to learn (new technologies and old
philosophies) and to share knowledge and thought with others.
https://www.linkedin.com/in/smantena1/

The Evolution of Operations IA Ops Dev
After publishing the initial instalment of my automation methodology “Marine Robotics” in
early April 2017, which is a book in progress, scheduled for completion next month; I took about
a month break from research and writing. When I returned around mid-May, I noticed that a
post-hype phase had begun in RPA articles after a very enthusiastic “Year of the Robot” in 2016.
Several articles caught my attention about why RPA projects were failing in significant numbers.
One article that went viral, “Why RPA Implementations are Unsuccessful?” 1
pointed out the
susceptibility of organizations to rush into Cognitive solutions for complex processes that experts
can solve with non-intelligent technologies.
Later in June, I read a brilliant article, “RPA – Center of Excellence or Business Embedded” 2
that questioned the value of an RPA COE? What caught my attention here was the serious
tension between local Operations base RPA and centralized Enterprise RPA! I already felt this
tension, yet hadn’t had that “aha” moment. In July, I implemented a complex, custom RDA
attended automation with its own rules engine. It required daily face to face interactions between
the Developer, Operations Supervisor, and Myself to implement and then provide extensive
“Hyper-Care” to fine tune it. It was an expensive automation in terms of development and
maintenance, yet it was also the only automation to date that was a game changer in an already
mature automation environment. In no time, it eliminated overtime and allowed a position
vacancy to remain unfilled.
More importantly, it transformed the Developer, Operations Supervisor, and her Manager right
before my eyes into what I had been preaching about for years: Operations taking direct
ownership and control of their automations, with the developers and designers working face to
face with Operations leadership in an Agile style to build and maintain game changing, complex
automations. You know the story, prior to this, if an automation broke, even a key production
one, it could be months, before IT got around to fixing it. In the meantime, overtime through the
roof! Still, what was unique here, was to see Operations Supervisors empowered directly and
then engaged to take direct ownership of their own automations.
The “Light Bulb” of insight was starting to burn!
Late in July, these events led to the first article in what became a three-part series on Operations
IA Ops Dev titled “Adaptive RPA aka Expert RPA– The Technical Side of Marine Robotics”;
where I first identified Ops Dev as an RPA Operations led variant of Dev Ops. This first article
was followed shortly by “The Inverse Stack Fallacy – A Case for Ops Dev” that vividly
demonstrated why under certain conditions, only an Operations IA Ops Dev approach can
provide the responsive support necessary once an Intelligent Operations becomes fully
automation dependent. And then a third article, “Operations IA Ops Dev Part III” inspired by
SSON’s “Managing Disruptive Change. A New Operations Model – Embedded and Built by
Intelligent Automation – Global Intelligent Automation Market Report” 3
that finally triggered
the “aha” moment!

Ambivalence - Irreconcilable Tension Between Two Types of RPA
Deployment
There is an inherent irreconcilable tension or “ambivalence” between Operations owned and
control RPA with IT assets embedded that maximize automation speed, agility, and productivity
to create and maintain complex, custom automations that approach Cognitive performance and
an Enterprise controlled, project based, IT centric RPA concerned with standardization, scaling,
and code reusability necessary for the control, efficiency, and consistency, needed to support the
optimization of large scale ERP, CRM, etc. projects.
The SSON white paper timing could not have been more perfect for context to understand this
“Ambivalence” with several critical “truths” it brought to the table:
1. A virtual workforce must be controlled by the same entity that controls the human
workforce: Operations (IT needs to play a substantial role of course)
2. A completely new business model and culture are needed to optimize Fourth Industrial
Age Technologies (continuous learning and fail fast, etc.)
3. At its current 95% accuracy rate, Machine Learning is not ready for many applications
and it will take three to five years to reach the 99% necessary for many commercial uses
The other service the SSON white paper provided was to drive home that all industries are going
to face their “Uber Moment” soon; where small, upstart new entrant using Forth Industrial Age
technologies can take large chunks of almost any market in several months! In other words, to
fail to take these “truths” to heart is not an option, which is a thoroughly detailed truth in “What
to do When Machines do Everything – How to get ahead in a world of AI, Algorithms, Bots, and
Big Data”! 4
The tension between a “locally controlled, embedded RPA” and “centralized,
Enterprise COE RPA” is not an either/or proposition; rather a both/and paradox that creates the
“Ambivalence” and as we will see, requires a BiModal solution.
Why is this important?
I have heavily suspected since early 2016 that over managed and under led American
Corporations 5
were going to be susceptible to “Cognitive Hype” in a desperate attempt to avoid
the extensive business model and cultural change management necessary to engaged and
empower Operations to take automation to the next level. In my own vertical, Managed Health
Care Operations, I encountered this stiff resistance several years earlier. When you put those
three bullets together with the high failure rate of RPA projects in the face of New Digital
Disruptor breathing down Corporate America’s neck, perhaps a different approach is suggested
to save the day?
Until Machine Learning based Cognitive Automation matures to the required accuracy in three
to five years, most large organizations are going to need some form of Operations IA Ops Dev
harmonized with an Enterprise IA Dev Ops to optimize Intelligent Automation that will stave off
these New Barbarian Digital Disruptors long enough to develop a more unified strategic solution
that is based on Cognitive Automation 4
.

Understanding the Ambivalence Through the Lens of Matrix Organizational
Structures
So, I pose the problem to Deepak Sharma, an Intelligent Automation consultant and Oxford
graduate in Strategy & Innovation: how do you conceptualize this need for two different
automation approaches and he recommended a “Matrix” structure.
“The basic idea behind matrix type of organization structure is to implement
strategies that require business to be excellent simultaneously at two or three
things. The main driver behind choosing a matrix structure is the pursuit of a dual
or a multiple priority strategy.” 6
Matrix structures exist along a continuum between Pure Functional and Pure Project, with
various factors that contribute to which end of the continuum the “Locus of Control” lies. If a
high degree of functional specialization and standardization is needed, then control needs to lean
heavily to the functional management side and if interdependence, local responsiveness,
customization, and similar other factors come to play; control moves toward the project
management side. It would appear from a business perspective, that the only significant factors
that argues for a Functional or in this case Operations locus of control is a high degree of
specialization, aka, “Expert” input is needed and standardization. Indeed, in standard RPA
programs this is true. However, as those programs mature, requirements become increasingly
complex and fluid, so a high degree of customization and rapid change ability is needed.
The Business is then faced with a choice, limit further large-scale ROI savings, implement
expensive Machine Learning Cognitive, if operationally viable, or restructure Operations and IT
assets to push the threshold capabilities for the rapid capture and implementation of complex,
fluid process requirements in a cost-effective manner. This means customization and local
responsiveness, key conditions from the project management side need to shift to the Functional
matrix organizational side aka Operations, which effectively creates Operations IA Ops Dev.
However, organizations are structurally composed typically of client facing and other support
functions than Operations, where ERPs, CRMs, and other Enterprise level software dominate
and RPA is used to integrate these systems (swivel chair) or fill out capabilities quicker and
cheaper. Typically, time and money tends to run out on multi-year major, Enterprise wide
application implementations, etc. This use of RPA, where it is a secondary technology, naturally
become part of the project managed approach used; matrix or otherwise, effectively becoming
Enterprise IA Dev Ops; hopefully, and not a more traditional IT approach like “Waterfall”.
Enter Design Centric Thinking
In further discussion with Deepak Sharma concerning these findings, the following diagram and
other material from his article “What Defines Dominate RPA Product Designs” 7
led to the
conclusion that Operations IA Ops Dev is “Ops led RPA supported by IT” and Enterprise IA
Dev Ops is “IT led RPA supported by Ops” (see diagram below).

Deepak and I both agree that a unified solution is best, i.e. an “Ops and IT co-led RPA” in the
middle; however, only the best leadership of “Good to Great” caliber and can pull it off;
especially in Legacy based organizations. Truly viable Cognitive Automation solutions will
lower the leadership threshold considerably and operational AI will make it the de facto
Automation model, which is another paper. However, for now and the next three to five years at
least, most organizations will need to figure out how to support both approaches to Intelligent
Automation.
So, matrix structures give a name to and various conditions that lend to an Operations IA Ops
Dev (functional) verses an Enterprise IA Dev Ops (project) base utilization of RPA. However, as
far as I can tell, matrix structures do not provide insight into how both types of matrix structures
can exist in one organization or in this case one area of an organization, i.e. two uses of RPA in
one Center of Excellence, arguably considered best practice for mature RPA deployment and
governance?
Enter “Service Automation - Robots and the Future of Work”
Going back to one of the most authoritative works on Intelligent Automation, “Service
Automation – Robots and the Future of Work” 8
; this “Ambivalence” phenomenon is clearly
discussed in chapter 6 “The IT Function & Robotic Process Automation”. The danger of
Operations led initiatives developing a “Shadow IT” with attended data security risks and non-
scalability was contrasted to IT’s need to focus on stability and efficiency, yet maximizing
experimentation, speed, and agility. One authority featured advocated the concept of “Bimodal
IT” developed by Gartner in 2014; with its “Heavy Weight IT” and “Light Weight IT” as a
solution for the tension between traditional IT and a new, more agile IT that can support RPA.
Bimodal IT appears to be a concession to Traditional IT, i.e. legitimizing its continued existence
to provide the Enterprise with stability and efficiency through a “Water Fall” or other existing IT
SDLC methods, while a new “Light Weight IT” focuses on tight co-operation with business units
to increase agility and speed to market”. This “BiModal IT” approach seems to be a substitute

for a full-blown IT makeover such as Dev Ops and has serious critics of the apparently
compromised solution. Jason Bloomberg in a Forbes article presents an argument that a
BiModal IT will result in the Traditional IT mode unable to attract new blood to sustain it; as the
younger IT generation will flock to the new, more agile mode IT 9
. However, any argument
based on issues that will not materialize for five to ten years or more in today’s fast paced,
disruptive innovation environment, cannot be a priority consideration.
Mark Campbell provides far more convincing arguments that there is nothing new about
BiModal IT. That it is a false dichotomy, which oversimplifies the inherent tension
(ambivalence) between the need for stability and agility. He has you convinced until the end,
where he all but says, if you cannot transition to a new, super agile “Born Digital” IT like
Amazon or Google’s, you are as good as dead 10
! Thankfully, significant work has been done
with BiModal IT on the agile side; especially in regards to RPA, which will be dealt with in
depth later. The following is a very good paper by a BiModal vendor for more details.
https://www.mendix.com/wp-content/uploads/how-to-implement-bimodal-it.pdf
What is Operations IA Ops Dev?
Effectively, Operations IA Ops Dev is Dev Ops with Operations in the driver’s seat and critical
IT assets embedded in Operations. In the main, this is not new. The majority of what this looks
like and how it operates is already being practiced by RPA Agile Experts in places like Australia.
Most of what follows in this section comes straight out of a very popular work by RPA Agile
expert Pavel Gimelberg in his article “Agile Approach to Implement RPA” 11
. It is highly
recommended that this article is read in conjunction with this White Paper, since its contents will
be highly abbreviated here. Also, it is to be noted, that in no way is Operations IA Ops Dev
making a statement that all Agile techniques and processes or a certain combination are required;
this is not a paper about Agile. However, there is an even higher correspondence between Ops
Dev and Agile practices than with Dev Ops. In fact, the implications are that Operations IA Ops
Dev, because RPA is already perhaps the most agile automation technology, that Agile practices
do not go far enough in some respects?
Pavel and I agree, developing the Business Case, Code Development Governance, and Data
Security remains constant with sound practices that are used with other automation approaches,
so these are not discussed in this Paper. The departure from standard RPA programs happens
after the Automation is approved for development. The target process, with its main and
exception paths are screen recorded. Then from day one, the Designer, Developer, SME, and
other Agile Team members meet literally, not virtually, to begin reviewing the process recording,
step by step, ideally to develop a Robot Journey Map (again, remember to get all the detail from
Pavel’s article).
Main steps of the robot’s journey are mapped across the top of the board and then create a
specific User Stories to cover all activities within the steps.

Release Planning
During this step, a robot’s implementation is split into releases. Dr. Alistair Cockburn’s
Knowledge Acquisition Curve can be useful. Its main idea is to split the implementation into 3
phases:
First Phase- exploration of the process and the proposed solution is the goal. A primary
objective is to mitigate the highest risks and to check assumptions about the robot’s ability to
perform a task. For example, can the robot interact with internal systems in a way never built
before? In Phase One, that piece is built to check feasibility, i.e. how fast can the robot be
adapted to that System and what pitfalls might it encounter? The duration of this first phase is
usually a week or a bit longer for real difficult processes or new to automation.
This is “Fail Fast”!
Second Phase- After the main risks are mitigated and assumptions proven, business value can be
delivered; the meat and bones of the robots. Robots are deployed to production under very strict
supervision. This Phase is usually split into a few 1 week iterations of end-to-end robot
developed, testing, and deploy into production.
Third Phase - fine tuning with additional controls, speed optimization, extra security for unusual
situations. It is not going to deliver much business value, if the robot deployment is not robust
and easy to maintain. During this Phase, training and maintenance documentation is developed
and handed over to the Support and Operations teams.
The following are steps of a RPA Development Cycle:
1. Recording user steps per each activity
2. Iteration Planning

3. Daily standups
4. Train the robot
5. Test the robot
6. SMEs acceptance
7. Iteration Demo
8. Iteration Retro
Development of a robot is an iterative process. Cycle starts from Iteration Planning and finishes
with Iteration Retro and then looping again until all phases of the development are completed.
Again, you can use Pavel’s Agile techniques or not; however, what is not optional, is that
automation development from day one, is a face to face, team effort that involves the Designer,
Developer, and Business SME as a minimum and perhaps even ideally according to BiModal IT
theory. However, whether these three or more (not too many more), Operations IA Ops Dev
effectively eliminates the traditional business analysis between the business and developers. In
effect, the Designer, Developer, and Business SME all share the BA’s role in determining,
documenting, testing, and implementing the automation requirements.
In the most aggressive forms of Operation IA Ops Dev, where the automation levels are very
high, 50% plus of all department functions, and with ancillary technologies, such as Enterprise
grade OCR, Computer Vision, and Natural Language Programming set to push automation
toward the 80% mark in the near-term future, Operations leadership should become directly
involved in the automation development, deployment, and ongoing maintenance process.

Obviously, not all current Operations leadership will be geared for this; however, not all will be
needed, so as part of an intentional HR automation strategy, either those current leaders or up
and coming ones, need to be vetted for Intelligent Operations leadership.
In an automation mature environment, this aspect of Operations IA Ops Dev is not as radical as it
seems. I know of one client that developed a Shadow IT automation solution that automated
67% of the entire departments function going on six or seven years successfully. Yes, it has
Business Leadership and IT very nervous on many legitimate counts; too solo expert dependent,
obsolete, brittle technology, not scalable, etc. However, this and countless other successful
“Shadow IT” automation programs started and maintained by Operations, demonstrates its
leadership’s ability to take direct charge of their automations. In such an arrangement,
Operations leaders and SME’s begin to think like IT and IT like the Business. I have other
stories like this and so do most of you, because they have the same ultimate source: a traditional
IT service that couldn’t meet the pressing needs of Operations.
So, the solution to Business Leadership and IT legitimate concerns with “Shadow IT” is not to
take away Operations’ control of its automation assets, rather to provide up to date tools and
professional IT assets that adhere to standardized governance, and data security protocol.
Operations IA Ops Dev is not about Business verse IT Centric RPA, which is legitimately a
tension that revolves around the level of Cognitive technologies involved, i.e. the more Cognitive
dependent the automation program, the more IT centric it will need to be (more on that later.
Nor, is this about Operations taking over an IT based software development process; Operations
IA Ops Dev assumes full blown developers are needed for the level of automation sophistication
that warrants it in the first place. Dev Ops (IT in the driver seat) is still preferable for new
automations and significant structural enhancements. Rather, in a highly automation dependent
Intelligent Operations, “Light On” must be as close to “Real Time” as possible. So, for break
fixes or minor to moderate enhancement to capture new automations opportunities as real time as
possible, some IT assets need to report directly to an automation savvy Operations Leadership.

Based on these considerations, an Operations IA Ops Dev is neither necessary or suitable for all
RPA programs. The following factors are indicators that Operations IA Ops Dev might be the
indicated approach:
1. The Industry is Operations Heavy
2. Quality and Accuracy standard are in the very high 90’s ruling out general use of ML for
the next 3-5 years
3. Automation environment is mature, i.e. there is no low hanging fruit
4. Operations has a high automation dependence, resulting in the need for extremely tight
SLA’s for “Lights On”
5. Extreme cost pressures from smaller competitors that makes the creation of complex,
customized, high maintenance automations to generate ROI a pressing reality
Issues of leadership and change management capability, operations readiness, cultural resistance,
etc. are other factors to take into consideration, which will be address toward the end of this
Paper.
The Relationship Between, BiModal IT, Dev Ops, Enterprise IA Dev Ops, and
Operations IA Ops Dev
BiModal IT concept cited earlier is based on the intrinsic difference between “System of Record”
and “System of Engagement” software development. System of Record software applications
are designed to hold large amounts of data and/or handle large volume transactions with high
reliability and stability, which trends to one or two major enhancement implementations a year
that SDLC processes like “Water Fall” are geared for. However, Systems of Engagement that
clients directly interact with are intensely focused on users and must rapidly adapt to their needs
and preferences, i.e. speed and agility are emphasized, which indicates a Dev Ops approach.
If an enterprise’s System of Record applications are based in a legacy mainframe and are not
going to be migrated to a Cloud based solution anytime soon, it is quite probable, depending on
many factors; especially Culture, that it will be governed by a traditional IT approach, while
Systems of Engagement will be transitioned to a Dev Ops approach, resulting in a BiModal IT.
If the enterprise’s System of Record applications are based in the Cloud, both the System of
Record and the System of Engagement applications will most likely have a more unified Dev
Ops approach 12
.
However, whereas System of Engagement applications are often connected to System of Record
applications, so that a significant level of integration governance is required, the control of
software development must remain on the IT side, with Operations in support, albeit Dev Ops.
Not so with RPA. It can have direct interaction with either the System of Record or System of
Engagement applications without the need for integration governance. RPA is non-invasive,
where Code is concerned 8.
This is ultimately why Operations IA Ops Dev is even possible and
under certain circumstance recommended.
For example, unlike Dev Ops, which requires a test environment to be as close to Production as
possible to speed development, yet Production itself would never be used for test validation.
With RPA, it can be safe to use actual Production for limited requirement development and code

validation. Of course, only Operations Experts have this access and are qualified to safely use
Production in this way. Where regulatory compliance does not prohibit these techniques, the
level of automation, speed, agility, and complexity possible when Production is used in these
ways results in substantially increased ROI. Operations IA Ops Dev, because of intimate
ownership and control allows for this and other unconventional automations methods that can
reach near Cognitive levels of productivity safely and with great accuracy.
Still, as indicated previously, in most verticals and certainly in the earlier stages of the formation
of an Intelligent Operation, to opt for an Enterprise IA Dev Ops or according to Deepak’s matrix
IT Led RPA supported by Ops is a sound course. Rather than to default to an IT centric model,
which will lose significant speed and agility advantages inherent in RPA.
The following is one Austrian Bank’s version of Enterprise IA Dev/Ops that results in very high
automation performance. Service delivery times for various aspects of RPA discovery,
development, and implementation in this LinkedIn slide share were hours, days, and weeks; not
months, which should meet most enterprises’ needs for speed and agility? 13
.
BiModal RPA and the COE
A helpful article about RPA COEs titled “Developing an RPA Center of Excellence: The Role of
IT” was earlier this year 14
. The diagram that follows, taken from that article, depicts IT’s role
from none in the “Federated”, supportive in the “Hybrid”, and dominate in the “Centralized”
COE model. The “Federated” corresponds to the left side of Deepak’s chart; the “Centralized”
to the right side; and the “Hybrid”, depending on the exact details can be left of the middle
(Ops/Dev), middle, or right of the middle (Dev/Ops). I do not believe that this Article had

BiModal RPA in mind; however, it is a very useful article; especially at the end, where it
emphasized indeed that “Culture” is the hardest challenge to RPA programs. The diagram below
and article do a good job describing common approaches to RPA programs today; such as
described in Everest Group’s coverage of the famous ANZ Bank RPA program. Using
Automation Anywhere, it is clear that ANZ Bank had a large “Federated” component that was
decentralized throughout its organization composed of Operations staff using recorder based
RPA and a smaller team of power users in some form of a hybrid COE; presumably with IT
support 15
.
RPA programs that become an automation dependent Intelligent Operation, which increasingly
incorporates Cognitive based technologies to deal with complex, fluid requirements, require
significant IT support. However, until ML Cognitive bring “decision judgement” capabilities to
the mix, extremely tight integration of automation assets with Operation is necessary to push the
ROI envelop. This dual tension leads to a BiModal RPA.
BiModal is also termed “Ambidextrous” in “Organizational Ambidexterity in Action: How
Managers Explore and Exploit” 16
. In this Paper, five conditions are identified that predict the
need and potential for success when a BiModal approach is used to address a potentially
disruptive challenge. Three of them are very pertinent to the subject of a BiModal COE 16
:
1. A compelling strategic reason that intellectually justifies it (AI based, agile competitors)
2. A separate, yet aligned organizational architectures (BiModal COE?)
3. A senior leadership that tolerates and resolves the tensions inherit in a separate
architecture (COE Head?)

Bringing It All Together and Recommendations
The following is the result of the grand master of Design Centric RPA, Deepak Sharma’s
interaction with the concepts of Operation IA Ops Dev and Enterprise IA Dev Ops over the
course of this White Paper’s development:
The Ops led RPA implementation, coming from left in the dominant RPA design model, with
proven technology such as pureplay/rule based RPA like Automation Anywhere, Blue Prism,
UiPath, etc. These implementations are more standardized, governed by Ops using low code
tools with very little IT involvement. Ultimately, the need is to hit economies of scale as high-
volume transactions from a process execution standpoint, to achieve cost savings and efficiency
improvements beyond outsourcing strategies.
The themes here are efficiency, stability, reliability, consistency, and short-term gains.
The IT led RPA implementation, on the contrary, coming from right to left, concern IA
technologies such as AI, ML, NLP that are radically new. These require a high degree of
experimentation to further tailor and adopt with highly agile, iterative methodologies executed
by cross functional teams taking risks to discover “What’s Next?”
The themes here are innovation, experimentation, learning and development, and long-term
gains.
I see those two left and right ends as today/tomorrow, exploit/explore, survive/disrupt,
incremental change/discontinuous change.
Organizations need to do both to be “ambidextrous”. The contradictions (ambivalence) come
from older, historically profitable, cash generating, functionally structured Ops organization on
the left and young, innovative, highly agile and decentralized, cash absorbing IT organization on
the right 17
.
Ambidextrous organizations build in contradictions (ambivalence) as they operate for both today
and tomorrow, incremental innovation and radical innovation, incremental change and
discontinuous change.
Existing functional Ops organizations are well suited for adopting stable and proven RPA
technologies, where changes introduced are small and controllable/tolerable. Their current
structure and culture makes it difficult to implement discontinuous changes needed for more
radical RPA technologies such as AI, ML (my experience, pretty much anything beyond RPA).
Culturally, as well, given organizational age, success, shared expectations 17
over time about how
things were done in largely outsourced operations strategies; this very culture acts as a barrier to
embrace discontinuous technology change. Culture for short term success in the past creates
obstacles to innovation and change needed today for long term success.
While structural inertia is more easily discussed and dealt with, cultural inertia seems to be much
more difficult to deal with 17
. Actively managing organizational cultures that can handle both

incremental and discontinuous change is the most demanding aspect of managing strategic
innovation and change.
How do you achieve both – Ops-Dev and Dev-Ops RPA strategies to exploit stable RPA
technologies and explore newer radical RPA technologies?
The challenge for leaders in organizations implementing enterprise scale RPA is to create a co-
existing integrated, yet differentiated (ambidextrous) Ops-Dev RPA org and at the same time a
Dev-Ops RPA org.
How can senior leadership achieve this –
1) Define RPA strategy that combines both aspects – efficiency and scale to adopt stable
RPA technologies for incremental change, yet also experimentation, innovation, and risk
taking to bring in radical RPA technologies to embrace discontinuous change
2) Building Core team that has diverse competencies – homogenous at the top, yet
heterogenous at the lower level (split level COE structure)
3) Develop processes that allow integration between the two sides- for e.g. keeping Dev-
Ops RPA team composition relatively young and separate from larger organization to
allow them to experiment freely with more independence, yet rotating team members for
e.g. taking members for Dev-Ops to Ops-Dev team to offer fresh outlook on existing
Ops automation challenges that can be resolved by adopting more radical RPA
technologies.
The following is Deepak’s RPA Design Centric Matrix that puts concrete detail to his approach:

Conclusion – Culture Driven Business Models are Key
While Deepak’s conclusions are flavor by a career in IT, even as mine are by a career in
Operations, from different directions, our theoretical minds lead us to the same place; the middle,
i.e. the perfect fusion of Operation and IT. This is where Cognitive Automation will eventually
take the whole affair, to finally resolve the “ambivalence” once and for all, with a unified
business model and culture that will eliminate the need for a BiModal compromise.
The key to this evolution; however, is not the technology, which always seem to get the
attention. Rather the business model created to capture and exploit the intrinsic essence of
disruptive Fourth Industrial Age technologies: speed, agility, and eventually, decision making.
The ability to create and shape business models is determined significantly by organizational
culture. Deepak already covered some of the issues with Third Industrial Age business models
and cultures. To further elaborate, it is not just that outsource strategies help to create a short
term, incremental savings mentality among organizational leadership. It created a contract
management leadership culture, enforced by a M&A emphasis over the past few decades. This
is ultimately why Kotter concluded that US corporations are over managed and under led.
However, in the face of massive technological disruption of the Fourth Industrial Age, which
threatens the extinction of 50% of the current Fortune 500 Enterprises over the next ten years,
the need for leadership innovations that fully engages and empowers small, cross-functional
teams of Operations and IT experts has never been a more life and death priority! This necessary
shift from Third Industrial Age bureaucratic, multi-layered, hierarchical business model, and a
culture that locks in stability and consistency, to Fourth Industrial Age, collaborative, cross-
functional, flatten business model that promotes speed and agility by pushing leadership to the
front-lines is captured in the following analogy by Kotter:
“Consider a simple military analogy: A peacetime army can usually survive with
good administration and management up and down the hierarchy, coupled with
good leadership concentrated at the very top. A wartime army, however, needs
competent leadership at all levels.” 5
To truly engage and empower leadership at all levels requires not just a certain type of business
model, i.e. one that creates and facilitates small teams of cross-functional professionals. It
requires a “Culture of “Trust”. If you have been involved in automation for any length of time, it
is hard to miss the usual secretive nature of communications around it, i.e. to be careful what you
say, to whom. Do not use the “F” word “FTE”, etc. What this atmosphere betrays is the lack of
a “Culture of Trust” and is not only a practical hindrance to the communications and
collaboration between Operations and IT necessary for maximum automation effectiveness,
rather, more importantly, the unwillingness or inability to engage and empowers season veteran
experts to mentor promising, up and coming hard charging Millennials; the future of every
Enterprise.

Sneak Peek at What’s Next
We have come full circle. Prior to the first Industrial Age, the Master/Apprentice was the
business model and culture of production. In the near future, six to ten years from now, one
autonomous automation technologist can facilitate the productivity of hundreds, even thousands
of people. To find, vet, mentor, engage, and empower these new actors will create a whole new
industry. They will require an educational process equal to a neuro-surgeon and will be paid as
much or more. They will be mentored in both Domain and Technologies. The fusion of
Operations and IT will ultimately be in a person, with a support team built around him or her.
Using another military analogy, I call the new technologist a “Robot Pilot” (RP). My next paper
will go into detail how this is next, so you will have to wait a couple weeks to get the details.
However, in the meantime, I have modified Deepak’s Design Centric chart to demonstrate
visually, how a Culture of Trust that empowers Operations and engages IT leads to the RP as
automation teams become smaller and more specialized. For the next three to five year via a
BiModal RPA based Intelligent Operations, which matures into a Hybrid Ops/IT co-led, full
blown Cognitive Intelligent Automation, that morphs eventually into the guided, autonomous AI
automation of the “Robot Pilot” in six to ten years depending on the vertical.

References:
1. Nirmalya, S. (2017, Jan 26). Why RPA implementations are unsuccessful? [web log], LinkedIn. Retrieved
from https://www.linkedin.com/pulse/why-rpa-implementations-unsuccessful-nirmalya-shome/
2. Balazs, A. (2017, June 14). RPA – center of excellence or business embedded [Web Log], LinkedIn.
Retrieved from https://www.linkedin.com/pulse/rpa-center-excellence-business-embedded-attila-balazs
3. Coulter, L., Hodge, B., Hood, R.A., & Jones, W.A. (2017, July 31). Managing disruptive change - a new
operations model – embedded and built by intelligent automation – global intelligent automation market
report, SSON. Retrieved from https://www.ssonetwork.com/global-intelligent-automation-market-
reportH12017
4. Frank, M., Pring, B., & Roeing, P. (2017). What to do when machines do everything – how to get ahead in
a world of AI, algorithms, bots, and big data. Hoboken, New Jersey, John Wiley & Sons, Inc.
5. Kotter, J. P. (2001). What leaders really do. Harvard Business Review, 79(11), 85–96.
6. Galbraith, J.R. (2009). Designing matrix organization that actually work, how IBM, proctor & gamble, and
others design for success. Hoboken, NJ, John Wiley and Son. Ltd.
7. Sharma, D. (2017, Aug 31). What defines a dominate RPA design [Web Log], LinkedIn. Retrieved from
https://www.linkedin.com/pulse/what-defines-dominant-rpa-product-design-deepak-sharma
8. Willcocks, L & Lacity, M. (2016). Service automation – robots and the future of work. Warwickshire,
United Kingdom, Steve Brookes Publishing
9. Bloomberg, J. (2015, Sept 26). BiModal IT: gartner’s receipe for disaster, Forbes. Retrieved from
https://www.forbes.com/sites/jasonbloomberg/2015/09/26/bimodal-it-gartners-recipe-for-
disaster/3/#1b1ca21b73a7
10. Campbell, M.A., (2016, Jan 13). Saying goodbye to bimodal IT, CIO Insight. Retrieved from
http://www.cioinsight.com/it-management/innovation/saying-goodbye-to-bimodal-it.html
11. Gimelberg, P. (2016, June 23). Agile approach to implementing RPA [web log], LinkedIn. Retrieved from
https://www.linkedin.com/pulse/rpa-support-challenges-pavel-gimelberg/
12. Sharma, S. & Coyne, B. (2017, Sept 12). IBM devops for dummies, TechTarget. Retrieved from
http://www-01.ibm.com/common/ssi/cgi-
bin/ssialias?subtype=BK&infotype=PM&appname=SWGE_RA_VF_USEN&htmlfid=RAM14026USEN&attac
hment=RAM14026USEN.PDF
13. Anley, S. (2017, Aug). 5 ways to use ITIL & dev ops for RPA operational success [web log], LinkedIn
Slide Share. Retrieved from https://www.slideshare.net/SarahAnley/5-ways-to-use-itil-and-devops-for-rpa-
operational-success?trk=v-feed
14. King, R. (2017, Mar 4). Developing a RPA center of excellence: the role of IT [web log], LinkedIn.
Retrieved from https://www.linkedin.com/pulse/developing-rpa-centre-excellence-role-rob-king/
15. Simonson, E (2016). A conversation with Simen Munter and Pankajan Sridevi, ANZ global hub, Everett
Group. Retrieved from https://www.automationanywhere.com/images/guides/practicioner-perspectives-
anz.pdf
16. O’Reilly, C.A. & Tushman, M. L. (2011). Organizational ambidexterity in action: how managers explore
and exploit. California Management Review, 53(4), 5-22
17. O’Reilly, C.A. & Tushman, M. L. (1997). Winning through innovation: a practical guide to leading
organizational change and renewal. Boston, MA: Harvard Business School Press, (pp. 28, 30, 171)

BiModal RPA

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to BiModal RPA

Similar to BiModal RPA (20)

Recently uploaded

Recently uploaded (20)

BiModal RPA