The same implementation approach can produce vastly different results at different companies. Through repeated observations during consulting engagements, we have found that the difference usually lies not in the methodology itself, but in four organizational conditions: who leads the initiative, whether leaders are involved, how the AI project team is selected, and whether workflows have been clearly defined first.
These four factors may seem basic, but they directly affect task quality, actual adoption rates, and the speed of cross-functional coordination. No matter how comprehensive the methodology is, differences in execution conditions can lead to significantly different outcomes.
1. The Team in Charge Must Understand the Workflow
The people responsible for leading the implementation must be capable of defining business workflows and have the authority needed to coordinate across departments. From this perspective, the most suitable owners are typically the Corporate Management Office, General Manager’s Office, Business Planning Office, or a project manager from a management function. An IT leader may also be a suitable exception if they are responsible for the ERP system and are familiar with each department’s operating procedures.
One successful approach we have seen is to have a business planning project manager oversee the initiative. Each week, the project manager reviews responsibility lists with department heads and prioritizes tasks according to business value. The IT department is brought in only when data integration or system environment issues arise.
Another common scenario is for a company to send every request directly to the IT department. A department may simply say, “Build us an AI for this report.” The problem is that IT staff may not know how the report is actually used in day-to-day operations, nor do they necessarily have the authority to require upstream and downstream departments to change their handoff formats. The request may appear to have been submitted, but the workflows and rules that truly need to be defined remain unresolved.
If the company does not have a dedicated process improvement function, the general manager can appoint a cross-functional project coordinator and designate the IT department as a co-coordinator. The former is responsible for coordination and task definition, while the latter handles the technical environment and integrations. This prevents IT from having to shoulder business requirements alone. Both parties must reserve a fixed time slot each week to continue advancing the implementation; otherwise, the project can easily be pushed aside by day-to-day responsibilities.
2. Leaders Do Not Need to Build It Themselves, but They Must Use It
When leaders personally use AI, the organization receives two clear signals: this is genuinely a company priority, and mistakes made during experimentation are acceptable. Executives do not necessarily need to build tasks themselves, but they should regularly use at least one or two management-focused tasks to assess whether the data is accurate and whether the results can support decision-making.
For example, a general manager might use the same task every week to review orders or exception summaries. If the data definitions are incorrect, the general manager can immediately ask the responsible department to revise the rules. This kind of involvement shows the team that someone will actually use the task after it is completed—and make decisions based on its output.
By contrast, if the chairperson only gives a speech at the kickoff meeting and then disappears, only to ask at the monthly meeting, “Why is usage so low?” employees will struggle to determine whether the company is genuinely committed to the initiative or whether it is just another short-term project.
If the leader truly cannot make time to use the system personally, they can appoint a senior executive with decision-making authority to serve as the business sponsor. This executive should lead a monthly performance review, supported by a one-page dashboard prepared by staff that shows task usage, failure counts, hours saved, and issues awaiting decisions. At a minimum, the leader must still personally make three decisions: approve the scope of implementation, resolve cross-functional disputes, and confirm the resources for the next phase.
3. The AI Project Team Should Pair Experimenters with Experienced Employees
Younger employees are often more willing to try new tools, making them good candidates for the first implementation team. However, team selection should not be based solely on age, nor should experienced employees be excluded. A more reliable combination is to pair an employee who is eager to experiment with a senior colleague who understands the workflow. The former is responsible for building the task, while the latter provides the rules and participates in validation and testing.
For example, for engineering drawing reviews, a department can select an engineer who already uses AI regularly and pair them with a senior employee who has extensive experience reviewing drawings. During the workshop, the two can use actual drawings to build the first version of the task and then give it to other colleagues for testing. A task is far more likely to reflect real-world work when tool expertise and frontline experience are brought to the same table.
The most problematic approach is for a manager to assign “whoever has the most free time” to the project team. These employees may attend every training session on time and complete all classroom assignments, but once they return to their departments, the task may never be run again. They may not understand the workflow well enough, and they may have no interest in maintaining it.
If suitable candidates are not immediately available, the company can hold an open call for participants across all job levels, asking each applicant to bring a recurring task they want to improve. The company can also adopt a two-person model, with a technically oriented member responsible for the tool and a process-oriented member responsible for the content. Whichever approach is used, time for building, sharing, and maintenance must be included in formal working hours and incorporated into project evaluations. The company cannot rely on team members to contribute only after work.
4. Map the Workflow Before Choosing the Tool
If a department cannot yet clearly describe its own workflow, it should not rush to build an AI Agent. At a minimum, the team should first document the trigger conditions, inputs, main steps, outputs, recipients, and exceptions. Once the workflow has been laid out, the team can determine whether it requires document recognition, knowledge-based Q&A, spreadsheet queries—or whether the work needs AI at all.
A procurement department’s quotation process is an easy-to-understand example. Start by mapping the workflow into five stages: receive quotations, standardize fields, compare terms, flag differences, and obtain a manager’s pricing approval. Next, determine which stages are suitable for AI. The final decision might be to have AI handle the first four stages while leaving pricing approval to the manager. This creates a clear division of responsibilities while preserving managerial accountability.
Another approach is for the company to purchase an automation tool first and then ask each department to “find use cases.” If input formats and ownership have not yet been confirmed, frontline employees will still need to reorganize the data manually even after the system has been completed. The tool may appear to be live, but the original workload has not actually been reduced.
If the workflow is truly too disorganized, there is no need to begin by trying to overhaul every policy and procedure. Instead, arrange a 90-minute process workshop and select one recently completed real-world case. Map the actual path that case followed, then identify waiting times, rework, and decision points. Finally, select one part of the process with the clearest rules and assign an AI Agent to assist with it.
The Four Conditions Are Interdependent—One Weak Link Can Bring Everything to a Halt
These four conditions are closely interconnected. If the team leading the initiative does not understand the workflow, it is likely to choose the wrong tasks. If leaders do not participate, no one will make the final call on cross-functional disputes. If the wrong people are selected for the project team, no one will maintain the task after it is built. If the workflow has not been clearly mapped out, the tool may still go unused even after it has been purchased.
Before implementing AI, companies can use these four conditions to assess their readiness. Identify the weakest link and decide where improvements should begin. This helps ensure that the implementation does not stop at tool deployment but becomes genuinely integrated into each department’s daily workflow.
This article is excerpted from Intellicon Solutions’ Agent-Ready: AI Application White Paper for Taiwan’s Manufacturing Industry. The white paper explains how companies can assess their AI readiness across four dimensions—turning knowledge into organizational assets, connecting workflows, enabling governance, and building organizational momentum—and includes a 12-question self-assessment.