Over the past year the request has arrived in the same shape: “we need AI.” Not “our managers are drowning in email,” not “closing the monthly report takes a week of manual work,” but “we need AI.” That is a conversation about a tool rather than a job to be done, and it almost always ends with a burned budget and the conclusion that “this isn’t for us.”

Where the money actually goes

Not on models. It goes on three things you only see from inside the project.

• Starting from the tool. The platform gets picked first, then someone looks for work to give it. That is buying a machine and then inventing a part to mill on it.
• A pilot with no metric. “Let’s try it and see” is not a pilot, it is spending. If nobody wrote down what is measured and what the number was before, the result can be neither defended nor disproved.
• Data that is not ready, discovered in month three. Reference tables disagree, half the knowledge lives in two people’s heads, documents live in email. A model does not rescue you from disorder; it amplifies it.

The rule for the first project

Your first AI project is chosen not by how interesting it is, but by three properties at once: the process repeats daily, it is measured in hours or money, and a mistake in it is not fatal.

Daily repetition gives you statistics in weeks instead of years. Measurability gives you an argument in front of the owner. A non-critical error earns the right to experiment: if a human checks the output before it reaches a customer, the cost of a miss is a minute of attention, not your reputation.

A good first project is boring. It saves one department two hours a day and never appears in an innovation deck.

What a healthy pilot looks like

1. Four to six weeks. Not a quarter — over a quarter the context shifts and you can no longer tell what worked.
2. One metric. Hours per task, share of requests handled without a human, time to first response, data entry error rate — pick one.
3. A manual baseline. Spend the week before the start measuring how things stand today. Without that number the whole project is a matter of faith.
4. A kill threshold agreed in advance. “If after six weeks we save less than N hours, we close it.” A project that cannot be closed will live forever and cost forever.

What pays off first

The list is shorter than you would expect. Triage and routing of inbound requests. Search across internal documents and policies — the case where an employee burns twenty minutes on “what are we supposed to do here.” Drafts of routine documents and replies. Data quality control: duplicates, anomalies, required fields left empty.

They share one property: a human stays in the loop and owns the final call. The most expensive failures start where AI was put in charge of a decision on a process nobody had properly described.

What not to do

• Don’t start with an “AI strategy.” A forty-page document will be stale before the budget is approved. Strategy is written after the second or third working project, out of experience rather than slides.
• Don’t buy a platform before the pilot. A pilot runs on what you already have. A platform is chosen for load you have measured, not load you hope for.
• Don’t hide the experiment from the people whose work it touches. An implementation a department learns about after the fact gets sabotaged quietly and professionally.
• Don’t count savings in abstract hours. Count in the units the company actually lives by: shifts, orders, shipments, days to close the month.

What to do on Monday

Take one department and write down ten routines it repeats every day. Next to each, put hours per week and the cost of an error. Pick the one with the most hours and the cheapest errors. That is your first project. At this stage you need neither a vendor nor a budget — you need an hour of the department head’s time and an honest list.

The typical picture six months in: the system is bought, licences are paid, the integrator is gone, and deals still live in a file called clients_final_FINAL2.xlsx. People open the CRM on Fridays to “fill it in for the report.” Formally the system exists. In practice the company pays twice: for licences and for double data entry.

Excel is not the enemy, it is the symptom

A salesperson does not stay in Excel out of spite. They stay because the file opens instantly, asks no questions, does not demand eight mandatory fields, and lets them do in a minute what takes ten clicks in the CRM. While that is true, no policy will help: people always pick the tool that solves their own problem faster.

An implementation succeeds not when Excel is banned, but when the CRM became the faster way to work.

Three reasons implementations fail

The reasons are almost always the same, and none of them is technical.

• Built for the manager, not for the rep. The system is designed backwards from reports: which slices the director wants to see. The rep ends up serving the report rather than the deal — and takes revenge through formal, meaningless data entry.
• Porting the chaos as-is. If the sales process is not described, the CRM will not invent it. It will encode the disorder and make it faster, which, contrary to expectations, is not an improvement.
• No process owner. There is a sponsor who signed the budget and a vendor who delivered the milestones, and no one inside the company accountable for the process still working six months later.

The right order of work

The order matters more than the choice of vendor. It is the same everywhere.

1. Process. How a deal is born, who owns it, which transitions exist, where it dies. On paper, before a single setting is configured.
2. Fields. Only the ones without which you cannot move to the next stage. Every mandatory field is a tax on every deal; the list should be painfully short.
3. Integrations. Telephony, email, website, warehouse, accounting. One goal: remove manual re-entry, because manual re-entry is exactly what breeds the second Excel file.
4. Reports. Last. A report is a consequence of data arriving naturally, not the reason people enter it.

What not to do

• Don’t migrate the entire history. Moving ten years of deals is months of work and guaranteed garbage in the new system. Take active customers and open deals; archive the rest.
• Don’t create forty mandatory fields. Every field must answer “what decision do we make based on this data.” No answer, no mandatory field.
• Don’t launch without training on real deals. A demo on invented data teaches nothing. Week one is working in the system next to someone who already can.
• Don’t keep Excel “for the transition period” without an end date. A transition period with no end date is simply the new permanent state.

How to audit an implementation in a week

Sit next to a rep and ask them to run one deal from call to invoice. Time it and count the clicks. Then ask them to do the same thing their own way. The gap between the two measurements is the honest score of your implementation. Everything else is opinion.

I run this loop regularly: my main product, Cehovik ERP, runs at more than 1000 manufacturing sites across Russia and the CIS, and the pattern holds everywhere — the system that sticks is the one that makes the person on the line faster than they were without it.

At most plants I walk into, shop floor data exists in three versions that do not agree: the foreman’s log, the section head’s report, and the chief engineer’s memory. Each version is true in its own way. None of them can carry a decision about money.

Why OEE is more honest than the plan

OEE — overall equipment effectiveness — is the product of three factors: availability (how long the machine could actually run), performance (how fast it ran against the standard), and quality (what share of output was good). Its value is not the absolute number but the fact that you cannot improve it with a story. If availability drops, the machine stood still, and the next question is why.

A plan is either met or missed. OEE tells you where the time went, and that is the only conversation that produces a work list.

Why paper keeps winning

The paper log beats software on three counts: it is always at hand, it works with gloves on, and it forgives. A foreman records a stoppage in one line instead of picking from a twenty-item dropdown. Any system slower than paper at data entry gets filled in at the end of the shift from memory — and you end up with beautiful data unrelated to reality.

MES does not start with sensors

The most common mistake is starting with equipment. Sensors go in, data flows, and then nobody can agree whether a changeover counts as downtime and whose downtime it is. MES starts with two reference lists.

• A single operations list. One operation, one name across the whole plant. While two shops call the same thing differently, there is nothing to consolidate.
• A downtime classifier. The key artefact of the entire project. Fifteen to twenty causes grouped by area of responsibility: equipment, material, people, planning, external. Go past twenty and the foreman starts picking “other,” and the meaning is gone.

Three stages that actually work

1. Manual entry. A tablet or kiosk on the floor, a stoppage logged in two taps: cause and duration. The goal is not precision but habit — and testing the classifier against a live shift.
2. Semi-automatic. Operation start and end come from the system; the human confirms and explains deviations. This is where the first honest OEE numbers appear.
3. Sensors. Signal taken from the machine where it pays for itself. By now you know which stoppages cost the most, so sensors go there rather than everywhere.

What not to do

• Don’t automate the chaos. If the operation standard is not agreed, automated performance figures become a disputed number and people negotiate instead of working.
• Don’t punish the first honest numbers. The moment low OEE costs someone their bonus, OEE becomes high. The data dies in week one.
• Don’t compute OEE for the whole plant. An average across shops hides the bottleneck. Measure the critical equipment.
• Don’t drop paper on day one. Two weeks in parallel is the price of trusting the new numbers.

What the first honest month gives you

Usually an unpleasant but useful picture: a large share of losses turns out to sit not in breakdowns but in changeovers, waiting for material, and shifts that do not hand over cleanly. That is good news — organisational losses are removed faster and cheaper than worn-out equipment. But you only see them once a stoppage stopped being a line in a notebook and became a record with a cause and a timestamp.