Over the past few years, automation has become an integral part of Shared Services Centers’ (SSCs) growth and evolution. Whether large or small, whether onshore, nearshore, or offshore, SSCs – what we refer to as Global In-house Centers (GICs) – have made strong progress in adopting automation solutions.
Some have only dipped their toe into basic RPA. Others have moved ahead with more advanced automation technologies like machine learning and artificial intelligence. And a handful have started emerging as key strategic and revenue-generating entities for their parent companies. These GICs have built scaled delivery teams with strong domain knowledge around the implementation of automation solutions. There are multiple instances of GICs housing the global automation Center of Excellence (CoE) and driving initiatives across the enterprise. Aggressive adopters have moved beyond automating processes within the center and are now supporting process automation across locations and businesses. And they’re increasingly leading the design and execution of automation strategy, and are influencing decisions on go/no-go opportunities.
Everest Group’s recently published report Scaling Up the Adoption of Automation Solutions – The Evolving Role of Global In-house Centers discusses the key adoption trends and challenges in the GIC and automation space.
Let’s take a quick look at the four key trends.
Some mature GICs have developed multiple offerings to support different businesses. Typical offerings include advisory support, platform or infrastructure support, and end-to-end implementation support. For instance, the India GIC of a leading European insurance firm provides bot infrastructure support to the company’s Singapore entity. With this set-up, the Singapore-based team didn’t have to invest in its own infrastructure to gain full access to the bots’ capabilities.
From developing in-house automation talent to managing vendor resources, SSCs are making major strides in the talent management space. As part of their talent management strategy, many best-in-class GICs are investing heavily in building in-house talent, especially for AI-based solutions. This includes developers, data scientists, and project managers. These GICs are also investing significantly in upskilling/reskilling programs for their resources, and are strongly emphasizing education and awareness of automation’s capabilities and benefits. Some GICs are also training their business/operations resources on automation skills; this helps them scale-up faster.
Many GICs are upgrading their CoE model, roles, and responsibilities as they progress along their automation journey. Many successful centers are moving towards the federated hub and spoke CoE model, wherein the GIC houses the CoE hub and the functions have their own automation team (spokes.) The federated model enables rapid scalability and better opportunity identification than centralized CoEs. But, with either model, there are some pitfalls to avoid. Our blog titled Four Reasons Enterprises Aren’t Getting Full Value from Their Automation CoEs details what they are.
Building on their understanding of automation capabilities, some mature GICs have started exploring the use of custom-built in-house platforms to run automations. While in most cases these are for attended RPA bots, some best-in-class SSCs have developed platforms using advanced technologies such as interactive virtual assistants (IVA) and machine learning. There are even a few examples of GICs adopting a 100 percent in-house development model, meaning no third-party vendor support. While we expect GICs to continue exploring in-house automation tools, we don’t expect that these will replace the use of third-party vendor products in the near future.
What GICs have accomplished over the past few years in scaling up the adoption of automation solutions across businesses and locations is just the tip of the iceberg. Going forward, they are likely to build on this foundation and penetrate deeper into the enterprise with ever more complex automations.
To learn more, please read our report — Scaling Up the Adoption of Automation Solutions – The Evolving Role of Global In-house Centers – or contact us directly at Bharath M or Param Dhar.
The RPA world just got a bit more exciting with the early release of Robin, a Domain Specific Language (DSL) designed for RPA and offered via an Open Source Software (OSS) route. A brainchild of Marios Stavropoulos, a tech guru and founder and CEO of Softomotive, Robin is set to disrupt the highly platform-specific RPA market. Robin is not the first attempt to democratize RPA, so will it succeed at this feat?
RPA democratization isn’t a new concept. Other OSS frameworks, such as Selenium, have been used for RPA. But they weren’t designed for RPA and are best known for software testing automation. And there are other free options such as WorkFusion’s RPA Express, and Automation Anywhere’s and UiPath’s free community licenses. These have certainly lowered the barrier to RPA adoption but come with limits, for example, the number of bots or servers used.
When demonstrating his software environment, Stavropoulos explains that the principles he has applied to Robin are to make RPA agile, accessible, and free from vendor lock-in. This could be very powerful, for example, an RPA DSL could provide more user functionality. Not having to rip out and replace robots when switching to a different RPA software is tremendously appealing. And, availability of OSS RPA is likely to boost innovation as it will make it a lot easier to develop new light programs that simply collect and process data, such as RPA acting as a central data broker for some functions.
There are four main reasons for an RPA vendor to invest in an open source offering.
First, Softomotive will become the keeper of the code. And while it will not charge for the software, not even other RPA vendors that start to support it, it will charge for Robin support and maintenance should customers wish to pay for those services.
Second, many other OSS vendors grew on the back of this model and got acquired by bigger companies. For example, JasperSoft, the OSS reporting company was acquired by Tibco for US$185 million in 2014, and Hitachi Data Systems acquired Pentaho for a rumored US$500 million in 2015. I’m not at all hinting here that Softomotive is looking to be acquired, but these are compelling numbers.
Third, if Robin is successfully adopted, the user community will contribute to the development of the environment and modules to a community library. There will also be community-led support and issue resolution, and so on.
Finally, Softomotive will still have its own products and will continue to generate revenue based on the solutions it wraps around Robin.
Of course, while Robin is a great idea, Stavropoulos needs to ensure it is quickly and widely adopted. For it to become the de facto language of RPA, other RPA vendors must support it. And the only way to get them to support it is by forcing their hands with widespread adoption.
There are two ways Stavropoulos can make this happen; via free online delivery and through classroom-based training in key RPA developer hubs such as Bangalore. He is lucky to have a lot of existing users in small- to medium-sized companies. The developers in those companies are likely to try out Robin and give Stavropoulos a flying start.
Getting Robin onto a major OSS framework is also very important.
An RPA DSL on an OSS ticket is an exciting proposition that could significantly disrupt the market. But success depends on adoption and on Stavropoulos playing his cards right.
Enterprises are increasingly embracing DevOps to enhance their business performance by accelerating their software time-to-market. In principle, DevOps covers the entire spectrum of Software Development Life Cycle, SDLC, activities from design through operation. But, in practice, only ~ 20 percent of enterprises are leveraging DevOps end-to-end, according to our recent research, DevOps Services PEAK Matrix™ Assessment and Market Trends 2019 – Siloed DevOps is No DevOps!
That means the remaining ~ 80 percent that are taking a siloed approach to DevOps are missing out on the many types of values it can deliver.
Instead of adopting DevOps in its intended end-to-end fashion, many enterprises in different verticals and at different stages of maturity are tailoring it to focus on siloed, distinct portions of the SDLC. The most common types of fragmentation are: 1) Apps DevOps, applying DevOps principles only across the application development cycle; 2) Test Ops, using DevOps principles in testing; and 3) Infra Ops, applying DevOps principles only to infrastructure.
Pocketed adoption makes it tough to realize the full value that DevOps can deliver. The primary reason is bottlenecks. First, workflow throughout the SDLC is impeded when DevOps principles and automation are only applied to certain phases of it. Second, lack of end-to-end adoption makes it more difficult for enterprises to gain a full view of their applications portfolio, spot bottlenecks, incorporate stakeholder feedback in real-time, and make the entire process more efficient.
Additionally, when DevOps is used in a siloed manner, it focuses primarily on increasing the technical efficiency of processes. This means that DevOps’ ability to support the enterprise’s broader business-oriented objectives is severely restricted.
Finally, fragmented DevOps adoption creates a disintegrated culture in which teams work independently of each other, in turn leading to further conflicts, dependencies, and stretched timelines. All this, of course, defeats DevOps’ main purpose.
To successfully adopt DevOps end-to-end, enterprises should place automation, culture, and infrastructure at the heart of their strategy.
DevOps has the ability to deliver significant value to enterprises. But implementing it in a siloed manner quickly dilutes a lot of that potential value. To realize all DevOps’ benefits, enterprises should implement it end-to-end, invest in automation, robust and modular infrastructure, and tools and technologies to ensure agility, and develop a culture that helps them improve cross-team collaboration.
What has been your experience in your DevOps adoption journey? Please share with us at [email protected] and [email protected].
© 2011-2022 Everest Global, Inc.
