HomeArticle

Is AI destroying the functional system?

穆胜2026-08-13 10:59
This is yet another kind of delusion that "technology can transcend organizations".

Recently, several knowledge bloggers online hold a view that business AI transformation and agent building should not be based on functional units, and even claim that this way of thinking is too limited and "outdated". In any emerging field, "subversive views" can always arouse widespread resonance, and for a while, many people fully support such ideas.

But what I want to say is that this is another delusion that "technology can transcend organizations". Today we will break down this issue and discuss it in depth.

01

Can technology transcend organizations?

The view of Musheng Consulting and I is that — multiple open-source platforms do provide the possibility of low-code reconstruction of workflows, but the AI transformation effect can only be achieved through repeated reconstruction in functional fields. If AI transcends functions, it is only connected in the form of API interfaces.

This sentence contains three layers of "harsh realities", which are enough to break the delusion that "technology can transcend organizations".

First, the essence of "low-code workflow reconstruction" is that the "threshold" for reconstruction has been lowered, but the "operation" is still inevitable.

Open-source low-code platforms do make building AI applications a "drag-and-drop component" operation just like splicing Lego bricks, but this is only the popularization of "decoration tools", which will not bring about the automatic evolution of organizations. The real difficulty lies in "knocking down the load-bearing wall", that is, carrying out a thorough reorganization of the existing business processes. For example, reconstruct the original "reimbursement approval workflow" transmitted through Excel into a new closed loop of "AI real-time invoice data capture + automatic budget comparison + intelligent risk control". How to achieve this change? Tools only provide possibilities, and the key lies in that designers need to take charge of the workflow reconstruction. This means that people who are familiar with this function must carry out the "operation" step by step, disassemble the existing workflow, and then re-splice it. Low-code cannot solve the decision-making problems of "where to disassemble" and "how to splice after disassembly".

Second, the essence of "repeated reconstruction across functional fields" is that this kind of reconstruction is "brick-moving work" rather than "magic".

The word "repeated" is the result of our careful consideration. This means that the essence of AI transformation is not one-time replacement, but "granular disassembly". For example, an HR recruitment process needs to be split into more than a dozen nodes such as "JD generation, initial resume screening, interview Q&A, background check, salary negotiation", etc. If you want to reconstruct it, you need to AIize each node separately, conduct trial and error one by one, adjust after a failure, and then splice after adjustment. There are no shortcuts in this "brick-moving" process, which can only be polished repeatedly by domain experts and engineers.

Third, the statement that "AI transcends functions and is only connected through API interfaces" describes the underlying logic for AI to generate "agents" or "digital employees".

Many laymen imagine that AI is like a "super brain" that directly manages the whole company, just like many bosses regard AI as a wishing well, imagining that AI can replace all people in the future. But the reality is that AI cannot "digest" functions, but only "call" functions. Behind this is the fact that in the early stage of the AI era, the external audience is not clear about its operation principle.

Let's take another example. When an "intelligent supply chain" AI judges that restocking is needed, it will not write a purchase order by itself, but call the "create purchase order" interface of the ERP (Enterprise Resource Planning System) through API; when it finds an inventory abnormality, it will also call the data of the WMS (Warehouse Management System) through API. AI is the "nerve center" that gives orders, but the "hands and feet" (all functional systems) are still independent old systems, connected through the "nerve fiber" of API.

02

AI? What kind of AI do enterprises need?

At present, many enterprises mention AI at every turn, but in fact they know nothing about what kind of AI they need and how AI can solve problems. What enterprises buy is not a model, not even a digital employee, but a "lightweight and agile system" that solves problems in business scenarios.

Even if we go back to the simple idea that most enterprises believe that "AI transformation" means "AI replaces human", we can still sort out the principle behind it.

An "agent" or "digital employee" is generally built based on an open-source large model. The development of large models is originally a "money-burning game", which is more suitable to be used as the infrastructure in the AI era (the same as computing power), and completed by enterprises such as OpenAI, Anthropic, and Deepseek with the help of capital. Of course, many enterprises have begun to try closed-source large models, but their prospects are still uncertain.

A large model is a smart brain, but it cannot solve the practical problems of enterprises, because it "has a brain but no hands". This means that to develop "agents" or "digital employees" based on this brain, a low-code development platform is required. It is like a set of "standardized limb components", allowing the "brain" (large model) to quickly "grow hands and feet" to perform specific tasks. These platforms usually provide a visual, drag-and-drop development environment, enabling developers (even business personnel) to connect the capabilities of the large model with the existing systems and data of the enterprise without writing code from scratch.

At present, there are mainly three forces providing such tools:

The first type is large model vendors, such as OpenAI, which will provide low-code development platforms as attached services;

The second type is vendors with cloud service genes, such as Alibaba Cloud and AWS. Due to the business attributes of cloud services, they are naturally strong competitors to provide low-code development platforms;

The third type is third-party low-code platforms, such as OutSystems and Mendix, which are deeply engaged in business scenarios, can integrate with multiple models and cloud vendors, and are the enterprises with the most prominent low-code development platform genes.

For most enterprises, they only need to reshape their own business processes based on the "brain" provided by the open-source large model and the "limbs" provided by the low-code development platform, just like splicing Lego bricks. While reshaping the business process, it naturally involves the transformation of the organization. This is where "AI transformation" is more technically promising than the traditional "digital transformation".

According to this logic, bosses certainly hope that "deploying AI" can solve all problems, but the problem is that this "AI" is not a "one-stop full-solution", but more of a "complex system with continuous iteration". It comes from the segmentation, transformation and splicing of each function. No matter how mature the system is, it needs continuous iteration as the market changes.

03

No matter how powerful AI is, it must follow organizational principles

The reality is that if an "AI system" transcends functions, it means that each function has completed "AI transformation" first, and then these functions are combined into a "system" in the most reasonable way.

Horizontal division of labor still exists, collaboration still exists; vertical centralization still exists, authorization still exists; processes still exist, nodes still exist; assessment still exists, incentives still exist... The logic of the organization has not changed. Just like from the mammoth in ancient times to the modern leopard, agility has improved, but biological knowledge has not been subverted, and cells and organs are still the basic components. Talking about "technology transcending organizations" is a bit unwise.

It is certainly acceptable to say that AI promotes organizational restructuring, but it is only a "driving force". The department walls, insulation layers, process silos, and KPI blind covers in the pyramid organization should have been reformed in the first place. It has long been a trend we mentioned that enterprises need to break away from the pyramid organization and move towards a Platform-based Organization. AI only provides technical convenience, and the power of this technology makes organizational transformation easier. But it is still a bit rash to delude that AI will automatically bring about organizational transformation.

We can cite countless examples that loading AI in a pyramid organization still cannot improve organizational efficiency. Our previous research also drew a clear conclusion — "Platform-based Organization + AI Technology = Agent Organization". But up to now, a large number of bosses still want to use AI technology to bypass the organizational transformation that they are unwilling to face, which is really puzzling and ridiculous.

Back to the question at the beginning of this article. We insist that — AI will not replace functional systems, AI only equips functional systems with a pair of "smart glasses". It can see more accurately, but it is still the people in each function who do the work, and the only connection method is API.

Of course, we also need to emphasize that although the functional system will not change, the business processes of enterprises will become more flexible. API connection only means "read and write" permissions, and the core barrier in the future lies in "event-driven". In the procurement example above, after AI writes the purchase order through API, whether the "approval workflow" automatically triggered by the ERP system can call back AI through API for "multiple rounds of negotiation". This is the advanced form of "transcendence", but its essence is still API-to-API interaction.

04

Are functional experts still valuable?

If the functional system will not be abolished by AI technology, then "AI transformation" requires the reconstruction of each function, which even starts from reconstructing each "sub-function" in the function. Therefore, I proposed before that the output of functional departments in the future should be "agents" or "digital employees".

This leads to another key issue. Since reconstructing the functional field is so "arduous" and "slow", which way is faster: "veteran employees who understand business learn to use low-code" or "AI-savvy geeks go deep into the business to fully figure out the business pain points"? This determines where CTOs or CIOs should allocate the budget in the "AI transformation" project: training or recruitment.

My suggestion is that if the budget is only enough to support one side, please do not hesitate to bet on "people who understand business". The reason is extremely simple: AI technology is being rapidly popularized at low cost, but the "barrier" of business cognition is getting thicker and thicker. I have three specific reasons:

First, tools are equally accessible to all, but business intuition cannot be equalized.

The performance gap between OpenAI, DeepSeek and Llama 3 is narrowing sharply, and low-code platforms make "calling API" as simple as "turning on and off the light". This means that "how to call AI" is no longer a valuable capability. But issues such as "which node should call AI", "what specific pain points to solve by calling AI", and "how to explain the output results to the boss" completely depend on the in-depth understanding of the supply chain, financial statements and customer psychology. This kind of "intuition" cannot be given by AI, and can only be obtained through years of immersion in related fields.

Second, people who understand AI will only ask "whether it is feasible", and only people who understand business can judge "whether it is necessary".

Let an AI geek stay in the finance department for three months, he can indeed understand terms such as "invoice verification" and "three documents matching", but it is difficult for him to perceive "the extreme anxiety of the financial director when closing accounts at the end of the month", and it is also difficult for him to predict "which data are the real red lines during tax inspection". However, a veteran employee who understands business, even if he only uses the most basic low-code drag-and-drop functions, the workflow he builds is "equipped with bulletproof vests", which can be truly implemented without compliance accidents. The products made by AI geeks often work well in the laboratory, but crash when encountering the "dirty data" in the complex real world.

Third, the resistance to transformation is not technology, but "people's inertia".

This is the most easily overlooked point. The most difficult part of promoting AI transformation is not writing code, but making the "old hands" in the sales department willing to fill in the customer follow-up records into the system, and making the production line monitor allow AI to adjust the scheduling. People who understand business know who are the loud speakers, who are the key decision-makers, and who to invite to dinner to promote the pilot. It has to be said that this kind of "organizational lubrication" ability cannot be learned by AI geeks even after ten years of effort. This is also the core competence of consulting institutions like us that are deeply engaged in organizational transformation.

Of course, I must add that — the "business-savvy" people we reuse must be those who "understand digital business" rather than those who "only understand paper-based business". Those business experts who resist digitalization and AI should be excluded from the future organization list in the first place.

This article is from the WeChat official account "Musheng Firm" (ID: hrm-yun), the author is Mu Sheng, and it is released with authorization from 36Kr.