Introduction
Seven years have already passed since 2016, when "work style reform" became the focus of public attention, the terms virtual workers and digital labor were defined, and it was called the first year of RPA.
As someone who has been in this industry all along, through consultations with various clients, what I have particularly felt recently is that "polarization is progressing in how companies are advancing automation."
This would still be fine if it were simply a matter of insufficient budget or personnel, but the problem is not there—it lies in the direction they are heading.
In other words, the reason polarization is progressing is, to put it bluntly, which mountain is the organization trying to climb in advancing automation?
If you're climbing the wrong mountain in the first place, no matter how much human resources you deploy, you will never reach the destination you should be aiming for, and rather you will continue heading in the wrong direction.
Due to the power dynamics in this industry, many companies fall into this trap, so seven years after 2016, which was called the first year of RPA, and now with the piece called generative AI emerging, I would like to reconsider what automation initiatives should be.
The Polarization of Corporate Automation Initiatives
First, regarding how corporate automation initiatives are polarizing, the most notable difference lies in how they perceive RPA.
Specifically, polarization is progressing between "companies that advance automation with RPA as the sole focus" and "companies that advance automation treating RPA as merely one of the means."
In other words, the former companies have RPA front and center with "automation advancement = RPA," while the latter companies aim for the worldview of HyperAutomation, treating RPA as merely one of the means, seeking an efficient form of automation advancement that has also become a top trend in Gartner's strategic technology.
This is not a matter of small companies with limited resources being the former and large companies being the latter; there are small companies that are leapfrogging and already advancing automation with awareness of the HyperAutomation worldview, and there are large companies deploying resources and continuing to create large numbers of RPA robots.
And if anything, the biggest problem is large companies that continue to advance automation with RPA as their main focus.
What Was RPA in the First Place?
What I would like to reconsider here is "what was RPA in the first place?"
RPA is an abbreviation for "Robotic Process Automation," which is essentially not about any specific tool or technology, but about a philosophy.
In other words, toward solving the deepening labor shortage and realizing a society where humans don't have to do boring work, it is an initiative to have virtual workers (digital labor) take on tasks that humans used to do, and furthermore, to raise the level of virtual workers and increase their productivity.
At the time called the first year of RPA, discussions were actively held about the worldview of having virtual workers as subordinates to handle work, and the evolutionary theory that divided RPA levels into automation of routine tasks (Class 1), automation of partially non-routine tasks (Class 2), and autonomous automation including decision-making (Class 3).
However, at some point, when people hear "RPA," the image of so-called tools like UiPath, Automation Anywhere, and Blue Prism has become established in many people's minds.
While this was inevitable to some extent to create a market, I think there are both merits and demerits to the marketing of tool vendors that said "If you want to advance RPA, please buy this package (if you buy this product, you can easily advance RPA)."
Originally, there should have been strategic discussions within companies about how to create an optimal automation environment for the organization, but it has become a very simplified story of just buying an RPA tool (package) and creating more and more robots to automate immediate tasks.
Due to the remnants of this trend, there are still many companies that perceive automation advancement as "creating robots with RPA tools."
On the other hand, polarization is progressing with companies that perceive the use of RPA tools as merely one means of automation, identify the characteristics of RPA tools, and shift toward building an efficient automation environment, aiming for the worldview of HyperAutomation.
In other words, it would be fine if it were a matter of the pace of progress, but since the direction they are heading is different in the first place, unless they make a course correction, this polarization will only continue to widen.
※Since the image of "RPA" = "RPA tools such as UiPath and Automation Anywhere" has become so established, and it is difficult to rewrite the image of many people here again, hereafter I will use the term RPA to mean "RPA tools."
Why Creating Robots with RPA Is the Worst Approach in Automation Advancement
So why is it a problem to advance automation with RPA as the sole focus? To put it bluntly, it's because automation with RPA is the worst approach as a means of automation.
To say it more correctly, GUI operation automation with RPA is the worst approach.
When it comes to automation with RPA, in many cases, it takes the form of having RPA learn and execute the system screen operations that humans were doing before (operating UI elements). However, basically, mechanical operation of GUI should be a last resort.
This is because GUI is a UI designed to be easy for humans to use, and is not intended for machines to interact with.
The biggest problem with RPA is that the UI of the system that RPA was operating changes; when the UI changes due to system version upgrades, etc., RPA immediately errors, requiring RPA to be rebuilt each time.
If it's an internal system, the timing of screen changes and version upgrades is often known in advance, so it can be dealt with in advance, but in this era of SaaS prevalence, external system screens are updated at arbitrary times to make them more user-friendly, causing RPA to error each time.
External systems are particularly notable, but in any case, as long as you are operating GUI, you cannot avoid the cat-and-mouse game of system screen changes and RPA modifications.
Also, with GUI, screen rendering can be delayed or the screen can freeze altogether, so RPA operations themselves are not very stable.
The reason RPA is said to have lower development costs compared to general system development but higher operational maintenance costs is due to this GUI operation.
To put it another way, creating a large number of robots that operate GUI with RPA is close to planting a large number of small time bombs that you don't know when they will explode.
So is RPA bad? Not at all—tools are only as good as how they are used, so it's important to understand the characteristics of the RPA tool and handle it accordingly.
However, as a principle, GUI operation with RPA is destined to constantly be affected by system modifications, so it is not a means you want to actively utilize in realizing automation.
In other words, it should basically be avoided if possible, and it should be positioned as a last resort in automation considerations.
The Basic Policy Should Be to Aim for Departure from RPA
Based on the discussion so far, some people occasionally say "Shouldn't we abolish all RPA immediately?" but that is too short-sighted and shows a low resolution on automation. This is an important point, so I would like to return to it later.
However, the stance to take based on the characteristics of RPA is to use RPA appropriately where it fits while aiming for departure from RPA as a basic policy.
To put it more concretely, in organizational automation advancement, the key is how much you can minimize GUI operations with RPA.
GUI operation with RPA is only a last resort, and in the automation domain that has been scoped by RPA so far, the main options to consider preferentially are: ①API utilization, ②DB connection, ③ETL utilization, ④BI utilization.
I will explain them in order below.
①API Utilization
API utilization is a matter of course—if the target system has an API, let's properly use the API instead of GUI operation.
Just as GUI is a UI created for humans to operate, APIs are mechanisms created for systematic operation, so the correct entry point for automation is actually this one.
With APIs, you are not affected by screen changes, and backward compatibility is often maintained during version upgrades, greatly increasing the robustness of automation.
Also, compared to operating GUI in order while matching screen rendering timing, APIs are more stable and faster in processing, and implementation becomes very simple, greatly improving not only stability and processing performance but also maintainability.
In automation considerations, the first step is to check "Can't we use an API for this?" once the target system is decided.
Recently, many SaaS provide APIs, so it is extremely inefficient to implement GUI operations with RPA when APIs are available.
When APIs are available, it's fine to have RPA call the API for automation, or if the target automation task can be closed within API scope, using iPaaS is one option.
Many provide connectors that can be used intuitively without being conscious of API specifications, so I think implementation will be easier.
If system operations can be handled with APIs instead of GUI, the man-hours for development and operational maintenance would be roughly 1/5 to 1/10.
The transition from GUI-first to API-first is a mandatory matter in automation advancement.
②DB Connection
Next is DB connection.
This is also essentially another method with the motivation of wanting to avoid GUI operation, but ultimately what's behind the system is the database, so instead of extracting target data via GUI, it means retrieving data directly from the database with SQL.
This is particularly effective when the target data volume is large or when there are many condition selections in GUI operations; once you set up the SQL statement with conditions, you can retrieve data quickly and stably.
Implementation also becomes very simple like APIs, and most RPA tools have standard methods for retrieving data with SQL via ODBC or JDBC connection, so this is also a powerful option alongside APIs.
However, from the standpoint of each system administrator, they basically don't want DB connections to be made, so unlike APIs provided as standard functions, whether access permissions can be opened is a major point of discussion in DB connection.
It has difficult aspects to open to an unspecified number of people, so while limiting usage to people who understand these technologies well (CoE development, etc.), I think it's good to actively utilize DB connections in building an automation environment.
Multiple screen operations and various processes such as data joining via GUI can sometimes be completed with a single SQL statement, so like APIs, development and operational maintenance become very easy.
Also, like APIs, this is not affected by system screen changes, greatly improving the robustness of automation.
Write operations would be difficult, but if it's read-only, it doesn't put much burden on the system, so this is an option to actively consider.
③ETL Utilization
Next is ETL utilization, which is more of an organizational initiative.
For example, if there are many tasks that use the same data from a specific system, and many people implement GUI operations with RPA to retrieve that data, let's retrieve the data from the back end and place it in a location (shared storage, etc.) where everyone can use it.
As for ETL tools, there are various ones like Informatica, Asteria, and DataSpider, but what's important is not the tool, so in some cases, you could individually program batch processing.
In other words, by placing data that many people want to use in their work in a shared folder, etc., in CSV format, rather than having them retrieve it via RPA GUI, each automation person in charge no longer needs to develop RPA that operates GUI to retrieve data individually.
In the DB connection section, I said it's quite difficult to open access rights to the DB, but if it's prepared with ETL, it can be controlled organizationally, so this form is rather more desirable.
From an automation CoE perspective, using ETL tools to create an environment where main data can be easily accessed is essential for building an efficient and robust automation environment.
④BI Utilization
Next is BI utilization.
Perhaps the most common RPA automation task is to retrieve data from a specific system, transcribe and format the data in Excel, etc., and distribute it to related parties for reference.
However, this is basically an area that should be dealt with by BI. There is no need to bother transcribing retrieved data into Excel and compiling it; if you create a report by connecting BI with the data source and share it with related parties, they can always reference the latest data whenever needed.
This is related to ②DB connection and ③ETL utilization, but if BI can directly reference the target system's database, GUI operation can be avoided, and if it's difficult to have BI directly connect to the DB, by taking the form of having BI read CSV, etc., linked to a shared folder through ETL utilization, GUI operation can also be avoided here.
In addition to the merit of avoiding GUI operation, using BI also has the advantage that implementation of data processing and formatting becomes very easy.
Those who have used PowerQuery, etc., will understand, but BI has standard functions necessary for data processing and formatting in a library-like form, but RPA basically processes programmatically, so trying to do the same processing in RPA as BI is quite laborious.
With BI, processing that can be completed in just a few steps, such as type conversion, name change, table joins, and deletion of unnecessary columns, if you try to do it with RPA, you need to loop individually, making readability poor all at once, and processing becomes slower.
When considering automation of so-called report creation tasks, you should first consider whether it can be converted to BI.
I have introduced several examples so far, but in any case, RPA never becomes the first option in automation considerations.
Now, I have written so far that RPA does not become the first option when considering automation, but should all RPA be abolished? It's not such a simple story, and I would like to mention that point.
Basically, it is certainly correct that GUI operation should be avoided and processed with APIs or DB connections, but in the first place, systems that have APIs or can connect to DB are not currently that many.
For example, regarding APIs, if you inventory the systems used internally, probably only 10-20% have APIs, at best 30%.
While APIs should be actively used when considering automation, there are still not many systems that can be processed with APIs.
This is inevitable when you think from the standpoint of service providers; after all, the majority of service users are users (humans), so service providers prioritize developing GUI, and APIs are gradually developed later as needed.
For service providers, there is no point if many users cannot use it in the first place, so it is natural to develop GUI first, and the fact that the range that can be handled by APIs is limited compared to GUI will probably not change for a while, especially in the business domain.
While actively using APIs where they can be used and avoiding GUI operations with RPA as much as possible, in cases where GUI operation is the only means of automation, RPA automation will be implemented with awareness of RPA characteristics (pros and cons).
In this way, it does not become departure from RPA in one leap, but it is important for the organization to aim for departure from RPA in the medium to long term while combining various automation solutions appropriately, and to build an automation environment with efficiency and robustness.
What Should Be Done First to Transition from RPA Promotion to Full-Scale Automation Promotion
Now, I would like to pick up several things that should be done first to transition from an RPA-only state to full-scale automation promotion.
The first thing to do is to remove the word "RPA" from organizational names and activity names such as "RPA Promotion/RPA-CoE" and change it to "Automation Promotion/Automation-CoE."
This may seem like just a matter of naming, but there is a big difference between pushing "RPA" to the forefront and advocating "Automation."
On the other hand, by sublimating into "Automation" without bringing "RPA" to the forefront, the awareness of related parties changes to the effect that the purpose is automation, and RPA is just one of the means.
In this way, it is possible to switch from the mindset of "Can it be done with RPA or not?" when considering business automation to the awareness of "How can we automate most efficiently?"
I presented it first this time, but if you can pose the question "How can we automate most efficiently?", the answer that GUI operation with RPA should be a last resort is naturally derived.
Next, what should be implemented is organizing and visualizing the automation architecture.
From the perspective of how to automate most efficiently, map the systems used internally and automation solutions. Here, organize and visualize where APIs can be used, where DB connections can be made, where it would be better to process with BI in the first place, or where data should be linked with ETL.
Of course, there will be places where you have no choice but to rely on RPA, but in the process of organizing this automation architecture, you can minimize the places where RPA operates GUI.
By making this organized automation architecture an asset of the Automation CoE and creating a common understanding within the team, it becomes possible to make decisions that in this case, automating with this pattern is most efficient.
Robot development with RPA cannot be a goal, so it is important to properly utilize automation solutions including RPA for the purpose of business automation and aim for the world of HyperAutomation.
No matter how much you step on the accelerator of creating robots with RPA, you will never reach the world of HyperAutomation. Since you're climbing the wrong mountain, it's more accurate to say you're moving further away.
The Direction to Further Advance in the Future
Now, assuming we have transitioned to Automation promotion that is conscious of HyperAutomation, I would like to examine the direction we should further advance in the future.
In this examination, it is important to return to the initial discussions when the concept of RPA emerged.
So what was RPA in the first place? It was not about tools like UiPath and Automation Anywhere, but about philosophy.
In other words, it is the philosophy itself of having virtual workers and digital labor take on operations that humans were doing, and furthermore, by raising their level, expanding the scope of what they can handle and increasing productivity.
Originally, what RPA should aim for is the domain of autonomous automation in Class 3, which was also mentioned in the evolution theory of RPA, that is, the domain corresponding to AI agents.
There was a long period when automation of routine tasks was the main focus, but with the piece called generative AI emerging here, we are now entering the world of full-scale Class 3.
Generative AI is still used in a reactive way (responding when asked), which can be said to be like a passive person waiting for instructions.
On the other hand, what kind of talent is excellent talent? Not so-called passive people waiting for instructions, but talent that can move on their own and make proposals, or even more so, talent that can go one step ahead of the other party's requests and meet needs that the other party has not verbalized or noticed.
In other words, from now on, what will be crucial in DX promotion and Automation promotion is how strong AI agents you can create.
This is not a direction of preparing an IT environment that is easy for users to use in the first place, but a worldview where AI agents autonomously make necessary moves and support employees, and in specific domains, handle things while making their own decisions.
Probably the strongest companies from now on will be companies where most of their subordinates are AI agents. If all employees are positioned like managers and planners, running operations while using excellent virtual workers who are AI agents, companies that run operations while recruiting, training, and managing humans will not be able to compete at all.
The rest is a matter of in what time frame this shift will occur, but comparing the situation a year ago with the current state, it may come faster than expected.
Advanced companies have already started moving, but since AGI is not a zero-one story, isn't it also an important decision to work on this domain now while advancing grounded Automation promotion?
The Increasingly Important Existence of Solution Architects
So far, I have written about sublimating from an RPA-only state to Automation promotion, and that the key will be whether you can create AI agents, but what becomes increasingly important here is the existence of the role of solution architect.
Even if you generally understand the direction you should go after hearing the discussion so far, if you cannot concretize it to the image of actually moving your hands, the discussion will not move forward.
It is the same story that even if top management loudly says only "Do DX promotion" or "Use AI to make work more efficient," nothing will progress if there is no one who actually knows the How.
It is the existence of solution architects who will play the core role in this driving force, and the specific personnel requirements are as follows:
- Can program in the first place (has professional development experience)
- Has practical experience not only in development but also in operational maintenance
- Understands technology stacks such as RPA, BI, cloud, API, SQL, and can actually use them
- Has an AI background and can do concrete implementation themselves
- Possesses high-level soft skills (communication ability for smooth interaction with stakeholders, logical thinking, facilitation, documentation ability, etc.)
In reality, the very troublesome point is that such talent is hard to find in the market.
The reality is that so-called IT consultants can talk up to the upstream concept level, but many do not actually have programming experience or cannot move their hands.
In a world where the traditional large V-shaped process is becoming agile, the key is whether you can show prototypes and demos early and involve related parties, so the value of people who can only talk about desk concepts with PowerPoint is steadily declining. To put it bluntly, if it's just saying plausible things, ChatGPT is better at it, so it can be said that it is people at this layer whose value is most declining due to ChatGPT.
On the other hand, for solution architects, being able to program and knowledgeable about AI is naturally insufficient, and because communication and coordination ability with various stakeholders such as business owners, business departments, IT departments, and cooperating development companies are necessary, soft skills at the professional consultant level are needed.
The ability to organize issues and structures, the ability to advance projects while controlling the expectations of related parties, and additionally, documentation ability to create common understanding among related parties are necessary. This is more about business skills than whether you are excellent as an engineer.
Such talent has very high market value and is sought by every company, but the major issue is that there is not much of a development path for such talent at specific companies.
In other words, since people who have both high soft skills and understand technology are rare in the first place, there are not many people who can develop them, and they tend to be biased toward either the side of IT consulting firms where soft skills are high but concrete implementation level is not well understood, or the side of SIers and tech companies where they are knowledgeable about technology but do not have the soft skills to stand at the center of each stakeholder.
Of course, one form is to organize a team by breaking down each skill and having people who can handle each, but in any case, talent who can direct is necessary, and this talent needs to be able to talk to everyone, so it ultimately becomes close to the above solution architect personnel requirements.
In many companies, because there is no one who corresponds to this solution architect role, automation promotion ends up in a state like RPA-only.
In realizing the worldview of HyperAutomation and AI-first automation, how to secure this solution architect role, or how to organize it as a team, can be said to be one of the most important issues in automation promotion.
So What About Citizen Development After All?
Finally, I would like to touch on a theme that has been at a stalemate since 2016, which was called the first year of RPA.
That is the point of "So what about citizen development after all?"
This story is simple—it is the story of a gap between the assertion of RPA vendors who want to promote citizen development (increase the user base) in the form of "anyone can easily develop," and the expectations of companies that say "You said anyone could do it easily, but when we actually tried it, it's more difficult than we thought."
The conclusion is that if someone with good aptitude invests time properly, they can naturally acquire it, and if not, it will be difficult.
Since this varies from person to person and cannot be quantified, some people with good aptitude and also business flexibility can acquire it in a month, while others with not-so-good aptitude and being too busy with work can hardly acquire it even after a year.
However, if anyone could do it easily, the occupation of RPA engineer would not exist, but the fact that RPA engineer job postings are still being made is proof that not anyone can do it easily, I think.
As a premise to consider when thinking about citizen development, what you need to keep in mind first is that RPA vendors have an incentive to increase the base of RPA developers.
This is a natural stance for RPA vendors, because RPA vendor revenue comes from licenses, so it is most welcome if more people buy RPA licenses, that is, if users increase through citizen development.
Just as you should not consult a salesman about whether to buy that product, it is fundamentally wrong to ask RPA vendors about the truth of whether citizen development should be done.
So what about the perspective of consulting firm people whose revenue is not from RPA tool licenses? Basically, they will almost never recommend citizen development. From an objective standpoint where there is no incentive for utilizing specific tools, the general consensus is that citizen development should be avoided, or at least should not be approached carelessly.
By the way, even on the RPA vendor side, many people think in their hearts that citizen development should be avoided, and many people are in a dilemma with the business model.
So why is citizen development better avoided? The reasons are simply two: "citizen development has no future" and "because it accelerates RPA-only."
Why Citizen Development Has No Future
In considering whether to do citizen development, in most cases, "Can business users easily create RPA?" is the point of discussion.
However, that is not the point to be discussed, and what should truly be asked here is "Where do you ultimately aim to go?"
This also becomes clear if you consider that what you should aim for is not RPA-only but Automation promotion (the worldview of HyperAutomation).
In other words, it is naturally insufficient to just acquire RPA as a technology stack, and in addition to being able to use APIs and SQL, there is a need to constantly catch up and acquire new technologies like BI, cloud, and even generative AI.
Furthermore, new technologies will continue to emerge, and the shelf life of acquired technologies will become shorter and shorter.
In essence, the problem with citizen development is whether citizen developers who are struggling to acquire RPA can be continuously tasked with acquiring these new technology domains, and whether there is an image of that.
If "RPA can somehow be created with difficulty, but honestly I can't imagine having them acquire not only APIs and SQL but also new technologies such as BI, cloud, let alone AI..." then it must be said that citizen development has no future.
The term citizen development is problematic in the first place, and the point is ultimately whether professional-level talent can be developed.
Since it is difficult for DX to progress if only people in the IT department understand technology, the policy of developing talent who can promote DX even in business departments is a very important option.
However, this should not be advanced with broad citizen development, but should take an approach of developing as strategic talent through selection, and as a development roadmap, it is necessary to include acquisition of various technology domains including not only RPA but also other automation solutions (BI, ETL, cloud, etc.) as well as AI from the beginning.
This is essentially not citizen development, but developing professionals.
While it is easy to just distribute licenses and have interested people create RPA first, if you cannot provide a clear answer to the question "What will you do after having them learn RPA?", you should avoid careless citizen development.
In the first place, engineer productivity is non-linear, so it often happens that what a citizen developer was worrying about for 3 days is solved by a professional engineer in a few minutes. Increasing the number of people involved is not uniformly good, and what's important is the depth of each person's proficiency.
Since business department people should focus on their main business in the first place, while understanding what can be done with IT, they do not necessarily need to be able to create it themselves.
Smartphones just need to be usable, and not everyone needs to be able to create smartphones.
If you think backward from "Where do you ultimately aim to go?" to the necessary personnel requirements, rather than advancing broad citizen development, it should converge to the form of developing a small number of elite professionals through selective personnel development.
Why Citizen Development Accelerates RPA-Only
Another problem with citizen development is that "RPA-only accelerates."
There are two aspects to why citizen development accelerates RPA-only.
First is the citizen developer aspect.
As I also wrote earlier, basically citizen developers can only use RPA. In other words, since the only weapon is RPA, in business automation considerations, the approach becomes almost entirely RPA.
Originally, where it should be processed with APIs or SQL, or where it would be better to visualize with BI or link data with ETL, they basically try to automate by force with RPA GUI.
Since they only have the weapon of RPA, this is naturally inevitable, but as a result, robots that operate system GUI keep increasing, so automation efficiency and robustness are low, it is not very stable, and it is always affected by system changes.
In this way, if it is not development based on ultimately where you are aiming, but if you only teach RPA broadly, the situation of RPA-only will accelerate more and more.
The second is the automation CoE (promotion organization) aspect.
As a common case, after RPA-CoE advances automation with RPA from easy places and achieves certain results, it enters the phase of considering what to do next.
Here, what should originally be focused on is the perspective of solution sophistication and expansion of target business scope.
Regarding solutions, as already mentioned, it is an activity to sublimate RPA-CoE into Automation-CoE, incorporate new technology domains, and raise the level of automation, that is, aim for the world of HyperAutomation.
It is necessary to advance discussions and acquisition of each technology while raising various issues such as how to create an efficient and robust automation environment that avoids GUI operations, and how to raise the level of virtual workers and get closer to realizing AI agents.
The other is the perspective of expansion of target business scope. While back-office business automation has been the center so far, can we expand the automation scope to the front-office domain, can we realize automation of cross-departmental business in combination with business consolidation and standardization rather than individual business automation, can we automate company-wide common business with the most impact, etc.—there are many issues that should be considered regarding business domains as well.
However, there are cases where they shift toward citizen development as is, keeping the RPA-CoE in the situation where they should originally advance evolution from both solution and business perspectives.
In other words, because the man-hours of the CoE organization that should be used to raise the solution and business level are allocated to development and development support of citizen developers, the overall automation level remains low while only the base of related parties increases.
Since utilization and maintenance of automation solutions other than RPA have not progressed, the organization's weapon as an organization remains mainly GUI operations with RPA, and CoE development and citizen development are advanced, so the state of RPA-only accelerates further.
To summarize so far, what should be advanced is not promotion of broad citizen development in an RPA-only state, but improvement of automation level aimed at realizing the worldview of HyperAutomation, and if aiming for in-house development, development of selective talent (professional talent) conscious of the final destination.
What kind of automation future to envision, and in order to realize that future, how to advance selection and concentration of limited resources—this is what becomes important after all.
Summary
Seven years have already passed since 2016, which was called the first year of RPA, and with the emergence of generative AI technology, I think we will enter a phase where the tide of Automation promotion will further change and accelerate.
Since the seeds of polarization are already quite visible due to differences in the automation image that each company envisions, I would be happy if this could be an opportunity to once again discuss your company's future automation promotion. We support automation initiatives from strategy design through building the team to run them.
