When a company decides to implement artificial intelligence, there is a strong temptation to start with something impressive.
Choose a model.
Connect a fashionable service.
Show a presentation filled with trendy phrases such as “AI-powered transformation.”
And then discover that employees are still manually moving data between three spreadsheets, a manager checks CRM statuses twice a day, accounting receives documents in five different formats, and the CEO still asks:
“What’s the status?”
Because AI implementation in business processes does not begin with choosing a language model. It begins with understanding how the company actually works.
Not how the process is beautifully illustrated in the official procedure.
Not how the head of the department describes it during meetings.
But how people actually receive requests, check data, make decisions, hand over tasks, correct mistakes, search for documents, and rescue the process when the latest file is called final_v8_really_final_NEW_2.xlsx.
Do Not Simply Add an AI Service to an Existing Process
One of the most common mistakes is treating AI as a separate feature that can simply be attached to an existing workflow.
There was a process without AI.
Then someone added a “Do it with AI” button.
They connected an online AI service that creates a summary in yet another spreadsheet.
Now, formally speaking, the process has become innovative.
But if the process was chaotic, slow, or incomplete before that, artificial intelligence will not necessarily save it.
More precisely, it definitely will not save it.
…
A proper implementation therefore begins with three questions:
- how does the process work now;
- where does it hurt — where are time, money, resources, and people’s attention being lost;
- how should it work so that it no longer hurts.
First, the process needs to be broken down into its components.
Then, where necessary, some order needs to be introduced.
Only after that should the company decide where it needs an algorithm, an integration, a simple automation, or actual artificial intelligence.
Every Company Has Its Own Business Processes
Two companies may sell the same products, operate in the same city, and employ approximately the same number of people.
But internally, they may work in completely different ways.
In one company, an order automatically moves from the website to the ERP system, and notifications are sent to the responsible employees.
In another, a manager first receives the order by email, copies it into Excel, checks availability in a chat, calls the warehouse, and only then adds it to a Google spreadsheet.
In one company, discounts are calculated according to clearly defined rules.
In another, a more sophisticated formula applies:
“Ask Sergey. If Sergey does not reply, ask Olena. But for long-term clients, it is better not to change anything without the director. And it is better to call him because he does not read the group chats.”
This is exactly why a universal ready-made solution is simply impossible.
It is designed around a typical process.
Real company processes are rarely typical.
They include:
- their own rules;
- exceptions;
- roles and levels of responsibility;
- legacy systems;
- informal agreements;
- specific data formats;
- logic that has developed historically within that particular company and may now be impossible to rebuild completely.
A company’s business process should not have to adapt to the limitations of an off-the-shelf AI service.
The solution should be built around how the company actually works — or how it should work after optimisation.
An Off-the-Shelf Product Often Solves the Wrong Problem
Off-the-shelf SaaS solutions can be useful.
Especially when the process is standard, the requirements are simple, and the company is willing to work exactly as the service developer intended.
And when the total cost over the next couple of years, including all additional components and users, is not frightening.
But questions appear very quickly:
- what should we do with our non-standard statuses;
- how do we connect our legacy ERP;
- can the system check data across several systems at once;
- how do we account for our exceptions;
- can we change the orchestration logic;
- how do we restrict access for different roles;
- where will the additional data be stored;
- what happens if our process has ten steps but the service supports only three.
At that point, the company either starts rebuilding its process around the service or creates dozens of manual workarounds around it.
As a result, the automation that was supposed to eliminate routine work creates new routine work.
I have seen companies with more than 150 IT systems.
Once again.
MORE THAN ONE HUNDRED AND FIFTY SYSTEMS.
They appeared gradually.
Each new system partially solved something the previous one had failed to solve.
The right approach works the other way around.
First, the target process is designed.
Then the components required to support that process are identified.
Only after that are the technologies selected.
The First Stage Is to Understand How the Company Really Works
This is similar to medicine. The first step is diagnosis.
First, you need to understand the problem.
For that purpose, we study:
- how the process starts;
- what data it receives as input;
- who participates at each stage;
- what decisions are made;
- where people wait for information;
- where data is transferred manually;
- where mistakes occur;
- what is most frequently returned for revision;
- which systems are used;
- what a successful process result should look like.
And so on.
The Client’s Team Knows Where It Hurts
Managers see the process from above.
Employees see it from the inside.
And the people who perform the work every day usually know very precisely where it hurts:
- which actions are repeated dozens of times;
- which data constantly needs to be copied;
- where errors occur most often;
- what causes the most frustration;
- which tasks consume a lot of time while creating almost no value;
- where the process regularly stops;
- what could have been automated a long time ago, but nobody ever had the time to do it;
- and so on.
That is why the client’s team should not be involved only at the end, when they are formally presented with the finished system.
They should be involved from the very beginning.
This creates a double effect.
First, the team identifies the real bottlenecks with a high degree of accuracy.
Not the ones that look attractive in a presentation, but the ones that consume time and energy every day.
Second, people see that they have been heard and become highly motivated to work with solutions they helped design.
And when the new solution removes exactly the work that has frustrated and demotivated them for years, their attitude towards the implementation changes dramatically.
Instead of:
“Management has invented another new system.”
You hear:
“Finally, we do not have to do this manually anymore.”
This is one of the strongest factors behind a successful implementation.
Not Every Routine Task Should Be Given to AI
One sign of genuine AI expertise is not trying to insert AI into every step. Like in that joke about apples…
If a task can be solved reliably with a simple rule, there is no need to ask a language model to make a ceremonial decision.
If data can be transferred through an API, a “smart agent” is not required.
If the result is determined by a formula, it is better to use the formula.
AI should be used where the system needs to:
- understand unstructured text;
- work with documents;
- classify non-standard requests;
- extract entities and conditions;
- summarise large volumes of information;
- communicate with users in natural language;
- “communicate” with data;
- compare complex contexts;
- help people make decisions.
In other parts of the solution, ordinary algorithms and rules may be more appropriate.
Sometimes only around 20% of a good solution is “pure AI.”
And that is perfectly normal.
The rest is what makes the system manageable, reliable, and suitable for real business operations.
Why an AI Solution Is Often 80% Not AI
Suppose a company wants to automate the processing of incoming orders.
AI can:
- understand the content of an email;
- extract product names;
- understand the customer’s requirements;
- determine urgency;
- prepare an initial response.
But for the process to actually work, the system must also:
- check the customer in the CRM;
- verify prices;
- retrieve stock availability from the ERP;
- apply discount rules;
- check the credit limit;
- create the order;
- send it to the warehouse;
- record every action;
- notify the responsible manager;
- handle exceptions and errors.
So AI is important here.
But without a proper system architecture, it remains little more than a very intelligent email reader.
What it needs to become is the conductor of several important functions.
That is why AI implementation is not only about working with a model.
It also includes:
- improving processes;
- systematising data;
- cleaning data;
- designing algorithms;
- building integrations;
- security;
- quality control;
- user preparation;
- post-launch support.
Start Where the Business Will Receive the Greatest Benefit
Not all processes are equally important.
And not everything should be automated simply because it can be.
A company can spend several months building an attractive AI assistant that answers three simple questions once a week.
Or it can use the same time to eliminate a manual operation performed every day by twenty employees.
Or automate first-line customer support responses 24/7/365.
That is why scenarios need to be evaluated according to several factors:
- how much time is currently being spent;
- how many people participate;
- what an error costs;
- how frequently the process is performed;
- how strongly it affects the customer;
- whether the necessary data is available;
- how complex the integration will be;
- how quickly a measurable result can be achieved.
The first scenarios to launch should combine:
- a large volume of manual work;
- frequent repetition;
- a high cost of delay or error;
- sufficient data quality;
- a clear business benefit.
Do not start where it looks most fashionable.
Start where the company will genuinely feel the difference.
The Technology Stack Should Depend on the Company, Not the Contractor
Another common problem arises when a contractor knows how to work with only one technology stack and tries to explain why it is the perfect choice for absolutely everyone.
The company uses Microsoft 365, Azure, SharePoint, Dynamics, and corporate Active Directory?
It is advised to move everything to another cloud because “that is more convenient for us.”
The company has strict requirements for local data storage?
It is offered an external SaaS product because “it can be launched quickly.”
The company needs a simple workflow?
It receives a complex AI platform because the contractor’s team likes complex AI platforms.
That is not how it should work.
Technologies should be selected according to the client’s infrastructure, processes, security requirements, budget, and internal competencies.
A solution can be built:
- on Google Cloud if the company already uses the Google ecosystem;
- on Microsoft Azure if the business operates in a Microsoft environment;
- on AWS if the company’s main infrastructure is already hosted there;
- with n8n or other workflow platforms for suitable scenarios;
- on local infrastructure where security or regulatory requirements demand it;
- using a hybrid architecture where some data remains local and some is processed in the cloud;
- using different AI models depending on the task.
Real expertise is not about selling the same technology stack to everyone.
It is about building the right architecture for a specific company.
The AI Model Is a Replaceable Component, Not the Entire Product
Models change quickly.
Today, one model may work better with documents.
Another may perform better with code.
A third may be cheaper for high-volume requests.
A fourth may be able to run locally.
A strong architecture should therefore not make an entire business process dependent on one specific model simply because it was popular when the solution was launched.
It is better to build the system so that:
- models can be replaced;
- different tasks can use different models;
- critical business logic does not depend on an AI-generated text response;
- results pass validation checks;
- usage costs remain controlled;
- data stays within the permitted environment.
Because the goal is not to build a monument to one particular technology.
The goal is to create a system that continues to deliver value even as the technology changes.
Implementation Does Not End on Launch Day
After launch, real users very quickly discover scenarios that nobody considered during the design stage.
They ask unexpected questions.
They use the system slightly differently from how it was intended.
They find new exceptions.
They show where an answer is not accurate enough.
Sometimes they even accidentally discover a more useful scenario than the one the system was originally built for.
That is why the post-launch stage requires:
- monitoring;
- request analysis;
- result quality evaluation;
- error control;
- source updates;
- rule adjustments;
- development of new scenarios.
AI implementation is not a one-time installation.
It is the ongoing development of a new operational environment for the company.
This Is Not About Replacing People
The strongest effect often appears not when a system replaces an entire position.
It appears when the system removes from that position the work that should no longer require a person.
Searching for information across ten systems.
Transferring the same data.
Checking the same fields.
Combining spreadsheets.
Copying statuses.
Preparing standard responses.
Reconstructing context.
People remain responsible for the areas where the business needs:
- accountability;
- negotiation;
- risk assessment;
- non-standard decisions;
- empathy;
- understanding of the business context;
- final control.
The system takes over the mechanical part.
And this does more than improve productivity.
It often gives people back the feeling that they are doing meaningful professional work rather than maintaining an endless conveyor belt of copied data.
Conclusion
AI implementation in business processes is systematic work.
The company needs to examine its real processes, identify pain points and routine work, revise the logic of the process where necessary, prepare the data, involve the team, and identify the scenarios with the greatest business impact.
Only after that should technologies be selected, remembering that different models and tools are suitable for different tasks.
Because the technology stack is a means.
The goal is to build a process that works faster, more accurately, and more effectively for a specific company.
In some solutions, AI itself may account for only 20%.
The rest consists of data, algorithms, integrations, rules, controls, and proper engineering work.
That is exactly what separates a real implementation from an attractive demonstration.
Learn more about the SOLARA service: AI Implementation in Business Processes.
FAQ: AI Implementation in Business Processes
Where Does AI Implementation in a Company Begin?
It begins with analysing the company’s real business processes, data, systems, and the problems experienced by its team. The company first needs to understand where time is being lost, where manual work occurs, and where errors appear. Only after that should AI technologies be selected.
Can a Company Buy One Ready-Made AI Solution for All Its Processes?
Ready-made services can work well for standard tasks. But complex processes usually have their own rules, exceptions, roles, and integrations. The solution therefore needs to be adapted to how the company actually works.
Is Google Cloud Required?
No. The architecture can be built on Google Cloud, Microsoft Azure, AWS, local infrastructure, or a hybrid environment. The choice depends on the company’s existing technology environment, security requirements, budget, and business needs.
Can the Solution Run Locally?
Yes. If the company has strict confidentiality requirements or cannot transfer certain data to external cloud platforms, it can use a local or hybrid architecture together with suitable AI models.
Why Might AI Account for Only 20% of an AI Solution?
Because stable operation also requires data preparation, algorithms, integrations, APIs, business rules, validation, access permissions, monitoring, and error handling. The model is an important component, but it is not the entire system.
How Should a Company Choose the First Process to Automate?
It is best to begin with a process that is repeated frequently, consumes a large amount of working time, has a high cost of error, and can produce a clear and measurable result.
Why Should Employees Be Involved in the Design Process?
Employees understand the real problems, recurring routine work, and informal exceptions within the process better than anyone else. Their participation helps create a more useful solution and significantly increases the team’s motivation to use it after launch.
Does AI Replace Employees?
In most cases, the solution does not replace a person completely. Instead, it takes over searching, data transfer, checks, material preparation, and other mechanical work. People retain control, responsibility, and the authority to make critical decisions.