Urgent.News

What's breaking now, across thousands of outlets.

AI

AI Won’t Fix a Broken Business Process

Why enterprise AI projects should start with workflow design, not model selection An enterprise AI project often starts with the same question: Which model should we use? Should it be GPT, Claude, Gemini, an open-source model, or a smaller model running privately? That question matters, but it is rarely the best starting point. A more useful question is: Which business process are we trying to…

When enterprise companies embark on an AI project, they often begin by asking what type of model to use. This could be GPT, Claude, Gemini, an open-source model, or a private, smaller model. However, the more pertinent question to ask is which business process they are aiming to enhance. Many existing business processes are already convoluted before integrating AI.

Data may be incomplete, responsibilities may be ambiguous, conflicting information exists across multiple systems, business rules may only reside in people's memories, and exceptions are typically managed manually. Success criteria are often unclear due to a lack of defined process boundaries. Simply adding AI to such a process does not inherently rectify these issues. Instead, it may merely expedite the process, increase size, and complicate understanding.

To illustrate, imagine an enterprise aiming to develop an AI assistant for its sales team. The assistant should recommend the subsequent action for each customer, such as making a follow-up call, identifying an inactive opportunity, or reminding a salesperson about an unanswered request. At first glance, this appears to be a straightforward AI feature.

However, several questions arise immediately: What is meant by "next action"? Who is accountable for defining it? Which data should the AI trust? How should the system handle scenarios like duplicate customer records in the CRM, opportunities with no recent activity, or customers who have already contacted support about the same issue?

How is the success of the recommendation measured? These are not primarily related to model selection but rather to process definition, data ownership, business rules, permissions, and workflow design. A team might spend weeks refining prompts while the fundamental problem remains unresolved. The model might become proficient at generating recommendations, yet the recommendations would still depend on unclear inputs and an ambiguous process, resulting in a refined solution to the wrong problem.

Another example is a typical customer follow-up process. A salesperson records a meeting in the CRM, which subsequently generates a follow-up task. A manager then reviews the opportunity. Another system contains the customer's payment status, and the salesperson is expected to determine the subsequent course of action. Upon introducing AI, the model could summarize the meeting, extract action items, suggest a follow-up date, and automatically assign a task.

While this may offer value, it does not address the underlying process deficiencies. If customer ownership is unclear, the AI may assign the task to the incorrect individual. In case the CRM contains duplicate records, the AI might attach the activity to the inappropriate customer. If the business fails to define an inactive opportunity clearly, the model may provide inconsistent recommendations.

If the payment system and CRM present conflicting information, the AI might confidently interpret the incorrect status. Consequently, the system operates more rapidly but the inherent confusion persists.

This scenario exemplifies a critical enterprise risk known as "chaos in, speed and scale out." AI does not need to be inaccurate in every case to cause harm. It only requires to function within a poorly defined process without adequate controls. Hence, before selecting a model, it is crucial to thoroughly understand the workflow.

Breaking down a business process into five key components - Input, Decision, Action, Validation, and Outcome - provides a useful framework for examining any process. Input refers to the information entering the process, including its source and completeness. Decision denotes the choice that needs to be made, whether based on explicit business rules, interpretation, or judgment.

Action signifies what happens following the decision, such as creating a task, sending a message, updating a record, or initiating a financial transaction. Validation entails checking the action before acceptance, enforcing permissions, limits, approvals, and business constraints. Outcome concerns verifying that the process was successful - whether the customer received the appropriate response, the task was completed, or the action reduced manual labor or improved response time.

This decomposition aids in determining where AI should be incorporated. AI can be beneficial for interpreting unstructured meeting notes, extracting information from emails, classifying customer requests, or suggesting next actions. However, it should not replace deterministic validation, authorization, transaction handling, or business rules.

While AI can help interpret ambiguity, the application must still control what is permissible to occur.

Written by urgent.news from Dev.to's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.

Read the original at dev.to →

More in AI

3 Ways I Use AI to Auto-Generate Playwright Locators

If you've maintained a Playwright suite for more than a few months, you know the real cost isn't writing tests — it's the constant locator rot.

  • AI assists in discovering resilient Playwright locators from the DOM
  • Self-healing locators with fallback chains prevent test suite failures
  • Natural-language test steps are translated into Playwright locators

More from Saturday 12 September →