Do not design AI around the people doing the work

Last issue named the ownership layers for AI: business leadership, capability leadership, process ownership, and the employees doing the work. Clear ownership tells you who answers for a result. It does not show how the work changes when a customer calls, a record is incomplete, or a handoff breaks.

Consider a manufacturer adding an AI-assisted production scheduling tool. Leadership wants it to flag schedule risk and recommend better job sequences. The vendor connects it to the ERP, where it can see due dates, standard run times, material status, machine capacity, and open work orders. The setup looks clean.

Then the assistant makes recommendations that are logical in the data and wrong on the floor.

It moves a job forward because a machine appears available, without knowing the only operator qualified for that setup is committed elsewhere. It recommends a material lot marked received, though quality has it on hold. It fills a gap with work for a machine that is intermittently failing, a problem not yet captured in maintenance. It treats an order as fixed while sales handles a customer change through calls and texts.

The schedule looks better. The work does not.

The planner starts ignoring alerts. Supervisors maintain a side spreadsheet. Operators text exceptions. Sales calls the planner directly. The official AI-assisted schedule becomes one version of reality; the operating plan lives somewhere else. That is not automatic proof that employees resist AI. It is evidence to investigate.

The cause may be missing data, weak configuration, unclear override authority, added friction, or a design that trusted clean ERP fields over the knowledge people use to keep work moving.

ERP fields are necessary for a scheduling assistant. They are not the whole process. A planner may know where qualification coverage is thin; a supervisor may know a machine is running but unsuitable for a tight-tolerance job; quality may know a lot is not releasable; sales may know an order has changed before the record does.

Not every workaround deserves to survive. A spreadsheet, text thread, or verbal handoff can expose bad information, unclear responsibilities, or a broken process. Do not defend it automatically; ask what problem it solves before replacing it. If removing it would stop the work, that failure belongs in the design discussion.

Employee involvement is not a vote on every operating change. It is not veto power for one employee, and it is not leadership avoiding a hard call by asking the team to “buy in.”

Leadership still decides the business purpose, acceptable risk, resources, and boundaries. The process owner decides how the work should run. Employees provide the operating knowledge needed to make those decisions credible: exceptions, missing handoffs, practical constraints, and evidence of whether the new process fits.

For an AI-assisted scheduling process, that involvement has five practical parts.

Do not start with the SOP and assume it describes the work. Watch how the schedule changes during a normal week. Follow a job from order release to the floor. Ask the planner where missing ERP information comes from. Notice the whiteboard, spreadsheet, sticky note, hallway conversation, and text message.

Then ask: What would go wrong if this workaround disappeared tomorrow?

The answer may reveal a weak data field, an unclear handoff, a staffing constraint, or a customer-communication gap. It may also identify a workaround that should be retired. Design from the work that exists, not only the process diagram.

Most AI demonstrations run on a clean example. Operations do not stay clean for long. Ask the people closest to the work what makes a normal job stop being normal.

For scheduling, useful questions include:

Capture the condition, who sees it first, where it is recorded now, and what decision it changes. “Machine availability can be complicated” is not useful configuration input. “Machine 4 can run standard jobs, but do not schedule the aerospace-tolerance job there after it starts showing the temperature-drift pattern” is useful.

An AI tool changes work even when it does not eliminate a job. A planner may receive a morning risk alert. A supervisor may verify an exception before accepting a sequence. Sales may log a customer change in a defined place instead of calling the planner directly.

Define:

If the tool adds a screen, an alert, and a review step while removing nothing, people will find a faster path around it.

Do not judge a scheduling assistant by an orderly schedule with complete records. Reuse the real exceptions already collected: incomplete routing, a qualification conflict, a quality hold, an informal customer change, or a sequence that damages a downstream handoff. Add conflicting priorities and known edge cases.

Let the planner, supervisor, quality lead, and sales coordinator explain why a recommendation is wrong or unhelpful. Record the explanation; do not dismiss it because it is inconvenient for the implementation timeline.

Sort each finding. The fix may belong in data, system configuration, process design, training, or management policy. This prevents a polished demo from being mistaken for an operating system.

Employees stop reporting problems when feedback disappears into a project channel nobody owns. Name who receives it, set a review cadence, distinguish a one-off error from a recurring failure mode, and show people what changed because of their input.

If recommendations repeatedly ignore qualification constraints, someone must determine whether the qualification data is missing, unreliable, or unavailable to the assistant. If it cannot be fixed yet, set a clear safe rule for handling it. “Thanks for the feedback” is not a response plan.

Feedback should have an owner with authority to convene the right people, not merely collect comments. The capability lead can track patterns across tools; the process owner must decide whether the operating procedure changes. Leadership steps in when the finding changes risk, staffing, customer commitments, or investment. Employees should be able to see the disposition: fixed, deferred with a safe workaround, or declined with a reason.

The official system plan can diverge from the plan people actually run in any small business. A customer-service representative can spot a generated reply that promises what operations cannot deliver. A bookkeeper knows which supplier documents are misclassified. A technician knows what the knowledge base leaves out for older equipment. Office staff know which intake details require a follow-up call. A project coordinator can see when an AI-generated schedule puts the same person in two places. These are design inputs before configuration, not objections to work around afterward.

Pick one AI-assisted process you are considering or already using. Name three employees who understand its exceptions best. Do not choose only managers; choose people who see the work change when a customer calls, a record is incomplete, a machine fails, a document is wrong, or a handoff goes sideways.

Ask each person one question:

What is this proposed system likely to miss?

Record where their answers overlap and where they disagree. Overlap shows recurring operating conditions. Disagreement can reveal that roles are working from different information, priorities, or assumptions. Do this before alerts are ignored and side spreadsheets multiply.

Pick one AI-assisted process. Name the employee role that understands its exceptions best. If that role is not involved yet, reply and tell me which one it is.

In Issue #11, once the real work, exceptions, and risks are visible, leadership must decide what AI is allowed to draft, recommend, approve, send, change, or execute.