Как попросить CAPA по-китайски: когда нужен не «сорри», а план, чтобы брак не повторился

Мы часто видим одну и ту же историю у людей, которые учат китайский “под работу”. Ситуация неприятная: партия пришла с браком, срок сорван, процесс у поставщика явно хромает — и начинается переписка на эмоциях. В ответ прилетает вежливое «извините», обещание «усилим контроль» и… через месяц повторяется то же самое.

Эта заметка — для тех, кто общается с китайскими партнёрами по качеству и срокам и хочет говорить не “громче”, а точнее. CAPA (Corrective and Preventive Actions) — тот случай, когда язык становится инструментом управления риском.

Коротко по делу

• После дефекта важнее не извинение, а причины и действия, чтобы проблема не вернулась.
• Хороший запрос держится на простой логике: что случилось → impact → просьба RCA+CAPA → срок → формат ответа.
• В CAPA ценится конкретика: root cause + corrective + preventive + owner + date.
• Если проблема повторяется, полезно отдельно попросить контроль следующей партии (например, QC gate / PP sample) — это снижает вероятность сюрприза “на входе”.

Почему «извините» не лечит процесс

В русской рабочей культуре иногда кажется, что признание ошибки — уже половина решения. Мы привыкли считывать тон письма: если человек виновато пишет и обещает исправиться, значит “всё под контролем”.

Но в цепочках поставок тон вообще вторичен. Поставщик может быть максимально вежливым — и при этом жить в режиме тушения пожаров. Без разборки причин (RCA) он будет исправлять симптом: где-то подкрутят проверку, где-то заменят сотрудника на линии… пока ситуация снова не сложится так же.

CAPA ценна тем, что переводит разговор из «кто виноват» в «что в системе сломано». И тут язык очень помогает: правильно сформулированный запрос задаёт рамку — не эмоциональную, а процессную.

Когда CAPA действительно нужна (а когда можно обойтись)

Мы просим CAPA не “для галочки” и не каждый раз, когда что-то пошло не идеально. По смыслу она нужна там, где есть риск повторения и цена ошибки высока:

• повторяющийся брак;
• серьёзный дефект;
• срыв сроков, который выглядит как системная проблема;
• ошибка процесса, которая проявляется снова и снова.

Если это единичный человеческий промах без признаков системы — иногда достаточно корректирующего действия. Но как только вы ловите себя на мысли «мы это уже обсуждали» — пора переходить на язык RCA+CAPA.

Формула запроса: простая структура вместо длинных писем

Хороший запрос CAPA редко бывает длинным. Он скорее похож на короткую записку инженера: факты → последствия → ожидания → дедлайн → как именно отвечать.

Вот скелет (не шаблон ради шаблона — просто порядок мыслей):

1. Что случилось
2. Impact (чем это ударило по вам/проекту/клиенту)
3. Просьба RCA + CAPA
4. Срок
5. Формат ответа (что именно вы хотите увидеть внутри)

И здесь важно то, на чём многие спотыкаются: они пишут “пришлите CAPA”, но не уточняют состав. В итоге получают письмо уровня «усилим контроль», которое формально похоже на ответ — но управленчески бесполезно.

«Данные на салфетке»: что должно быть внутри CAPA

Минимальный набор из практики качества:

• Root cause (корневая причина)
• Corrective actions (корректирующие действия — что сделали сейчас)
• Preventive actions (предотвращающие действия — что изменят в процессе)
• Owner (ответственный)
• Date / timeline (сроки)

Это ровно та конкретика, которую мы советуем прямо перечислять в письме. Тогда у партнёра меньше шансов “уйти в туман”.

Пример фразы по-китайски (и почему она звучит нормально)

Ниже формулировка из нашего датасета — рабочая и достаточно нейтральная по тону:

RU:
Просим RCA+CAPA по дефекту: root cause, корректирующие и предотвращающие действия, owner и сроки. Желательно до завтра 12:00.

ZH:
请提供该缺陷的根因分析和CAPA（原因、纠正措施、预防措施、负责人和时间）。最好明天12:00前。

Pinyin:
qǐng tígōng gāi quēxiàn de gēnyīn fēnxī hé CAPA (yuányīn, jiūzhèng cuòshī, yùfáng cuòshī, fùzérén hé shíjiān). zuìhǎo míngtiān shí'èr diǎn qián

Почему это работает:

• Начинается с 请提供… — “пожалуйста предоставьте”, без давления и обвинений.
• Есть точное слово для RCA: 根因分析 (“анализ корневой причины”).
• Скобками перечислен состав ответа — вы заранее фиксируете ожидания.
• Дедлайн оформлен мягко через 最好…前 (“желательно до…”), но при этом он ясный.

Если вам нужно дополнить запрос контролем следующей партии (то самое “не только разобраться задним числом”), логика та же: просите конкретный контрольный шаг — например PP sample или QC gate перед отгрузкой. Важно не расплываться в «усильте проверку», а обозначать точку контроля как действие процесса.

Где ученики чаще всего ломают коммуникацию

Мы замечаем два перекоса.

Первый — попытка выиграть спор тоном. Человек учит пару жёстких фраз на китайском и начинает давить ими как молотком. Партнёр внешне соглашается… но внутри защищается и минимизирует ответственность.

Второй — противоположный: слишком мягкое письмо без структуры. Там много слов про сотрудничество и понимание сложности производства — но нет списка того самого root cause / corrective / preventive / owner / date. Партнёр отвечает так же мягко — и всё остаётся “на словах”.

CAPA-запрос хорош тем, что позволяет быть одновременно корректным и требовательным. Требовательность тут выражается не эмоцией, а форматом.

Типичные ошибки

1. Оставлять проблему устной договорённостью
   «Созвонились, они сказали “исправим”» — звучит успокаивающе ровно до следующего инцидента.

2. Просить CAPA без состава
   В ответ приходят общие обещания вместо root cause и preventive actions.

3. Не просить ответственного и сроки
   Без owner/date любая мера превращается в намерение.

4. Путать корректирующее с предотвращающим
   “Перепроверили эту партию” — корректирующее действие. А вот “изменили входной контроль сырья” или “добавили QC gate” — предотвращающее. Если вы не разделяете эти уровни в запросе, вам их тоже смешают.

5. Не запрашивать контроль следующей партии при повторяющемся дефекте
   Даже идеальная презентация CAPA мало значит без ближайшей проверки на практике.

Как мы подходим к этому в Бонихуа

Мы смотрим на деловой китайский как на набор рабочих сценариев: конфликтных тоже. Не “выучить слова про качество”, а научиться удерживать структуру разговора там, где ставки высокие.

Когда разбираем тему CAPA с учениками на Бонихуа, мы обычно делаем три вещи:

• собираем нормальную русскую формулировку (без лишних эмоций), чтобы стало понятно что именно вы хотите получить;
• подбираем китайские конструкции так, чтобы они звучали естественно для деловой переписки (вроде 请提供…, 根因分析…, 最好…前);
• тренируем короткий формат ответа партнёра глазами заказчика качества: есть ли root cause? есть ли preventive? указан ли owner? понятны ли сроки?

Так появляется ощущение контроля над ситуацией даже тогда, когда сама ситуация неприятная.

Кому подойдёт / кому не подойдёт

Подойдёт тем, кто:

• ведёт переписку с китайскими поставщиками/подрядчиками;
• сталкивается с повторяющимися дефектами или сбоями процесса;
• хочет говорить о качестве без лишней агрессии, но с результатом в виде плана действий.

Скорее не подойдёт тем, кто:

• ищет разговорный китайский “для путешествий” без рабочих кейсов;
• ожидает универсальную волшебную фразу вместо работы с фактами (без описания дефекта и impact даже идеальный китайский не спасает).

Частые вопросы

Q: Чем RCA отличается от CAPA?
A: RCA — это разбор корневой причины (почему случилось). CAPA — пакет действий: что исправляем сейчас (corrective) и что меняем в процессе навсегда/надолго (preventive), плюс ответственные и сроки.

Q: Можно ли просто попросить «улучшить контроль»?
A: Можно, но это почти всегда слишком расплывчато. Лучше просить конкретику уровня QC gate или проверочный образец следующей партии — так контроль превращается в действие процесса.

Q: Дедлайн «до завтра 12:00» звучит грубо?
A: Нет сам по себе дедлайн не грубый; важнее конструкция. Вариант с 最好 (“желательно”) сохраняет нейтральность тона при ясном ожидании по времени.

Q: Нужно ли упоминать impact?
A: Да, коротко. Impact помогает партнёру понять приоритет задачи внутри их очереди проблем. Это часть структуры запроса наряду с RCA+CAPA.

Q: Что делать, если прислали ответ без preventive actions?
A: Возвращать в рамку формата: уточнить preventive actions отдельно вместе с owner/date. Иначе риск повторения остаётся тем же самым — просто вы получили документ вместо решения.