Тестовое задание бизнес-аналитика

Блок 1. Анализ данных по просрочкам

1.1. Сформулируйте 3 вывода, которые эти данные позволяют сделать, и 2 вывода, которые сделать НЕЛЬЗЯ (хотя их часто делают).

1. Основные просрочки на участке КУ.

КУ — 8 из 14 случаев, то есть 57,1%, и 78 из 94 дней просрочки — 83,0% всех дней.

2. Зафиксированные причины объясняют меньше половины общей просрочки. Из 94 дней просрочки причины указаны только для 42 дней. Вывод:

• объяснено причиной: 42 / 94 = 44,7%;
• не объяснено: 52 / 94 = 55,3%.

То есть более половины дней просрочки не имеют указанной причины.

3. Среди зафиксированных причин лидирует отсутствие комплектующих — платы.

Причина «нет комплектующих (плата)» встречается 3 раза и связана с:

8 + 7 + 12 = 27 днями просрочки.

Это:

27 / 42 = 64,3% всех дней просрочки, для которых причина вообще указана.

При этом нельзя утверждать, что именно эта причина является главной причиной, поскольку 52 дня остались необъяснёнными.

2 вывода, которые делать НЕЛЬЗЯ

1. Нельзя утверждать, что отсутствие комплектующих является главной причиной всех опозданий. Неизвестно, какие причины скрываются за 52 днями без указанной причины.

2. Нельзя утверждать, что КУ работает хуже других участков или что именно КУ является причиной задержек.

Мы видим, что на КУ приходится 83% дней просрочки, но не знаем объём работы каждого участка.

Нужен знаменатель: количество заказов/позиций, проходящих через каждый участок, и их нормативные сроки.

1.2. Приведите расчёты: распределение по участкам — в позициях и в днях просрочки; доля строк без указанной причины; доля дней просрочки, не объяснённых причиной. Числа обязательны.

Всего:

• 14 случаев опоздания
• 94 дня суммарной просрочки

Распределение по участкам

Здесь особенно заметно расхождение: КУ — 57,1% случаев, но 83,0% дней просрочки. Значит, задержки на КУ в среднем существенно длиннее.

Строки без причины

Без указанной причины — строки:

3, 6, 9, 12, 13, 14.

Итого:

6 из 14 = 42,9% строк без причины.

Дни просрочки без объяснения

По этим шести строкам:

14 + 16 + 7 + 2 + 9 + 4 = 52 дня.

Доля:

52 / 94 × 100 = 55,3%.

То есть 55,3% всех дней просрочки без причины.

1.3. Постройте диаграмму Парето по причинам опозданий — или обоснуйте, почему на этих данных её строить нельзя.

Полноценную диаграмму Парето по причинам всех опозданий строить нельзя, потому что у 6 из 14 случаев причина отсутствует. Эти строки дают 52 из 94 дней, то есть 55,3% всей просрочки.

Если построить обычное Парето только по заполненным причинам, получится:

1.4. Предложите 3 первоочередных действия. По каждому: что именно делаем, кто владелец, что изменится и как мы это увидим в цифрах.

1. Разобрать задержки КУ и проблему с платами

Разбираем все случаи задержек КУ, начиная с отсутствия плат: где возникает дефицит, почему комплектующая отсутствует к плановой дате, кто должен её обеспечить и на каком этапе возникает ожидание.

Владелец: начальник производства / руководитель КУ совместно с ответственным за снабжение.

Что должно измениться: количество задержек КУ из-за отсутствия комплектующих должно снижаться.

Как увидим в цифрах:

• количество случаев «нет комплектующих»;
• дни просрочки по этой причине;
• доля заказов КУ, отгруженных вовремя;
• среднее время ожидания комплектующих.

2. Ввести обязательную классификацию причин просрочки

Для каждого опоздания сделать обязательным указание причины из справочника: комплектующие, переналадка, брак, ОТК, ожидание решения, планирование и т. д. Отдельно предусмотреть «прочее» с обязательным комментарием.

Владелец: начальник производства / владелец процесса управления производством.

Что должно измениться: исчезнет ситуация, когда больше половины дней просрочки невозможно объяснить по реестру.

Как увидим в цифрах:

• доля строк без причины: 42,9% → целевой уровень, например, <5%;
• доля необъяснённых дней: 55,3% → <5–10%.

Целевые значения здесь являются предложением.

3. Анализировать не только факт просрочки, но и время ожидания между этапами

Что делаем:

Для проблемных заказов восстановить фактический маршрут: когда заказ передан на участок, когда принят в работу, когда ожидал комплектующие, когда передан в ОТК, когда возвращён и т. д.

Владелец: начальник производства / владелец производственного процесса.

Что должно измениться: станет видна реальная структура 94 дней: работа, ожидание, возвраты, согласования.

Как увидим в цифрах:

• среднее и медианное время ожидания;
• дни просрочки по каждому типу ожидания;
• количество возвратов;
• доля заказов с ожиданием между операциями;
• фактическое время выполнения против времени ожидания.

1.5. Назовите 5 вопросов начальнику производства и 3 источника данных, которые вы запросите до того, как делать выводы.

Что спросить у начальника производства

1. Что означает «—» в поле причины?

Это действительно отсутствие причины, причина не выяснена, забыли внести или существует другой журнал?

2. Почему восемь из четырнадцати случаев относятся к КУ и 78 из 94 дней — к КУ?

Это связано с высокой загрузкой КУ, особенностями продукции, дефицитом комплектующих или КУ действительно является узким местом?

3. Как планируется дата отгрузки и насколько часто она меняется уже после запуска заказа?

Без этого нельзя понять, являются ли указанные «планы» первоначальными обязательствами или уже пересмотренными датами.

4. Что конкретно происходит с заказами, где указано «—»?

Особенно интересны 3-1055, 3-1071, 3-1085, 3-1093, 3-1097 и 3-1099 — вместе они дают 52 дня необъяснённой просрочки.

5. Есть ли нормативное время между этапами, и кто отвечает за передачу заказа с одного участка на другой?

Это позволит проверить гипотезу, что существенная часть потерь находится не внутри операций, а на стыках между ними.

3 источника данных, которые я запросил бы

1. Производственная система / ERP / 1С

Нужны:

• дата создания заказа;
• плановая дата;
• фактическая дата;
• этапы производства;
• даты начала и окончания операций;
• статус заказа;
• переналадки;
• возвраты.

2. Система/учёт снабжения

Нужны:

• заявки на комплектующие;
• даты заказа;
• плановые и фактические даты поставки;
• наличие/дефицит;
• конкретная комплектующая;
• время ожидания.

Особенно важно проверить историю по платам.

3. Журналы ОТК / входного контроля / качества

Нужны:

• дата передачи на контроль;
• дата начала проверки;
• дата завершения;
• результаты контроля;
• возвраты;
• повторные проверки;
• брак.

Блок 2. Процесс обработки рекламаций

Процесс существует, но не описан. Три участника описывают его так:

Руководитель сервисной службы: «Рекламация принята, когда клиент прислал акт с фото. Регистрируем в CRM, дальше передаём в ОТК. Срок ответа клиенту — 30 дней, но по факту ждём заключение ОТК и не укладываемся.»

Начальник ОТК: «Мы начинаем разбор, только когда пришёл сам прибор. Пока прибора нет — заявка у нас не в работе. В CRM мы не заходим, у нас свой журнал в Excel.»

Руководитель отдела продаж: «Менеджер обычно закрывает вопрос сам — меняет прибор из подменного фонда, чтобы не терять клиента. В CRM это часто не попадает, потому что вопрос уже решён.»

2.1. Определите границы процесса: стартовое событие, конечное событие, клиент процесса, выход. Назовите владельца и обоснуйте выбор должности.

Границы процесса

Стартовое событие

Поступление от клиента обращения/рекламации с достаточным набором исходных данных для её регистрации.

Из интервью видно, что сервис считает стартом акт с фото. Но это уже локальное правило одного участника, а не граница всего процесса.

Конечное событие

Клиент получил решение по рекламации, а результат зафиксирован в учётной системе.

Например: ремонт, замена, отказ с обоснованием или другое принятое решение.

Клиент процесса

Клиент, поскольку именно он инициирует рекламацию и получает результат процесса.

Выход

Решённая рекламация + предоставленное клиенту решение + зафиксированный результат.

Владелец процесса

Я бы назначил руководителя сервисной службы.

Почему: именно сервис отвечает за обработку рекламации целиком и за результат для клиента. ОТК является участником/экспертом, а продажи могут самостоятельно решать отдельные случаи, но ни ОТК, ни продажи не контролируют весь процесс от обращения до закрытия.

2.2. Опишите AS-IS — BPMN-фрагмент или таблица «Шаг — Роль — Система — Вход — Выход — Срок», минимум 8 шагов, участники: Клиент, Продажи, Сервис, ОТК.

2.3. Назовите 5 разрывов. По каждому: в чём риск и как он проявляется в отчётности.

1. Нет единого определения старта процесса

Разрыв: сервис считает началом акт с фото, ОТК — поступление прибора.

Риск: разные подразделения считают срок от разных дат.

В отчётности: невозможно корректно посчитать полный цикл рекламации и SLA 30 дней.

2. ОТК работает в отдельном Excel

Разрыв: CRM используется сервисом, ОТК ведёт собственный журнал.

Риск: информация теряется при передаче между системами, появляются задержки и ручные операции.

В отчётности: CRM показывает только часть пути. Невозможно точно определить, сколько времени рекламация находилась в ОТК.

3. Рекламация фактически начинается для ОТК только после получения прибора

Разрыв: между регистрацией обращения и физическим поступлением прибора возникает неопределённый период.

Риск: значительная часть 30-дневного срока может уходить на ожидание, которое никто не контролирует.

В отчётности: период ожидания прибора может отсутствовать, поэтому его нельзя нормально анализировать как причину просрочки.

4. Продажи решают часть рекламаций вне процесса

Разрыв: менеджер заменяет прибор из подменного фонда без прохождения стандартного процесса.

Риск: процесс становится неконтролируемым, а правила обслуживания клиентов различаются.

В отчётности: реальные рекламации не попадают в CRM; количество обращений и фактическое время решения занижаются.

5. Нет единой точки ответственности за весь результат

Разрыв: сервис, ОТК и продажи отвечают каждый за свой участок.

Риск: при задержке между подразделениями сложно определить, кто отвечает за нарушение клиентского срока.

В отчётности: можно видеть «просроченную рекламацию», но не видеть, на каком этапе и почему она задержалась.

2.4. Предложите ОДНО изменение ТО-ВЕ с максимальным эффектом при минимальных затратах. Обоснуйте, почему именно оно первое.

Ввести единую карточку рекламации в CRM как обязательную точку учёта всего процесса — от обращения клиента до закрытия, включая ожидание прибора, работу ОТК и решение через подменный фонд.

Клиент → CRM-рекламация → Сервис → ОТК/ожидание прибора → заключение → решение → клиент → закрытие

При этом для каждого состояния фиксируется дата.

Блок 3. Карточка процесса для пользователя

Фрагмент действующего регламента:

В целях обеспечения своевременного и надлежащего реагирования на поступающие от потребителей продукции обращения, содержащие сведения о выявленных несоответствиях изделий установленным требованиям, ответственным работником сервисной службы осуществляется приём указанного обращения и его регистрация в информационной системе с последующим направлением соответствующего уведомления в адрес заинтересованных структурных подразделений в срок, не превышающий одного рабочего дня, исчисляемого с момента поступления обращения, при этом в случае отсутствия в составе обращения сведений, необходимых и достаточных для идентификации изделия (заводской номер, дата выпуска, дата ввода в эксплуатацию), ответственным работником в адрес потребителя инициируется запрос недостающих сведений, а течение срока рассмотрения обращения приостанавливается до момента представления указанных сведений.

4.1. Перепишите этот фрагмент как инструкцию для исполнителя: не более 10 строк, глаголы в повелительном наклонении, конкретные сроки, системы и действия. Смысл менять нельзя.

Приём и регистрация рекламации

1. Примите обращение потребителя о несоответствии изделия установленным требованиям.

2. Проверьте наличие данных для идентификации изделия: заводского номера, даты выпуска и даты ввода в эксплуатацию.

3. Если данных не хватает, запросите недостающие сведения у потребителя.

4. Приостановите срок рассмотрения обращения до получения недостающих сведений.

5. После получения обращения с достаточными данными зарегистрируйте его в информационной системе.

6. Направьте уведомление заинтересованным структурным подразделениям.

7. Выполните регистрацию и направьте уведомление не позднее 1 рабочего дня с момента поступления обращения.

8. Если сведения были запрошены, отсчитывайте срок рассмотрения после их получения.

Блок 4. Каталог процессов и поиск

4.1. Перечислите обязательные атрибуты карточки процесса (не менее 8). По каждому — одна строка: зачем он нужен.

4.2. Как сотрудник найдёт нужный процесс? Сформулируйте 3 запроса так, как их реально введёт кладовщик или менеджер (не терминами аналитика), и покажите, за счёт чего поиск сработает.

Главный принцип: поиск должен понимать язык пользователя, а не требовать от него знания BPMN и терминологии процессного управления.

Запрос 1 — кладовщик

«Как оформить возврат товара на склад?»

Поиск должен найти процесс «Возврат товара на склад».

За счёт чего сработает:

в карточке процесса должны быть поисковые ключи/синонимы: возврат, вернуть товар, товар обратно, приём возврата, склад.

Запрос 2 — менеджер

«Что делать, если клиент пожаловался на брак?»

Поиск должен найти «Обработка рекламации».

За счёт чего сработает:

поиск учитывает пользовательские слова жалоба, брак, клиент, рекламация, претензия, связанные с карточкой процесса.

Запрос 3 — менеджер

«Как оформить замену прибора клиенту?»

Поиск должен найти процесс, связанный с заменой изделия по обращению клиента / рекламацией.

За счёт чего сработает:

в индекс поиска попадают не только официальное название процесса, но и синонимы, типовые пользовательские формулировки, роли и связанные документы.

4.3. Опишите структуру каталога, которая останется удобной при 200 описанных процессах. Покажите верхний уровень — он должен помещаться на один экран.

Я бы не делал дерево из десятков подразделений. При 200 процессах оно быстро превратится в неудобную структуру.

Лучше использовать верхний уровень по направлениям деятельности:

КАТАЛОГ ПРОЦЕССОВ

1. Стратегия и управление

Основной процесс

2. Продажи и работа с клиентами

3. Производство

4. Закупки и снабжение

5. Логистика и склад

6. Качество и рекламации

Вспомогательные процессы

7. Финансы и бухгалтерия

8. Персонал

9. ИТ и информационные системы

10. Административные процессы

Далее вложенность, например: Качество и рекламации → Обработка рекламации → Карточка процесса

Дополнительные фильтры

Чтобы при 200 процессах не приходилось ходить по дереву, нужны фильтры:

• подразделение;
• роль;
• статус;
• владелец;
• система;
• тип процесса;
• актуальность.

И обязательно единая строка поиска.

4.4. Как поддерживать актуальность: версионирование, срок пересмотра, кто инициирует изменение, что происходит с устаревшей версией.

Версионирование

Каждое изменение процесса получает новую версию:

v1.0 → v1.1 → v2.0

Незначительные изменения — новая минорная версия, существенное изменение процесса — новая основная версия.

Срок пересмотра

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

Но пересмотр проводится раньше срока, если изменились:

• законодательство;
• ИТ-система;
• организационная структура;
• ответственность;
• регламент;
• сам способ выполнения работы.

Кто инициирует изменение

Инициировать изменение могут:

• владелец процесса;
• руководитель подразделения;
• сотрудник, обнаруживший проблему;
• аналитик при выявлении несоответствия.

Но утверждает изменение владелец процесса либо другой установленный орган управления процессами.

Что происходит со старой версией

Она:

1. получает статус «Архив»;
2. сохраняется с датой действия;
3. становится недоступной как текущая инструкция для обычного пользователя;
4. остаётся доступной для истории и аудита;
5. новая версия становится единственной актуальной.

Например:

Обработка рекламации — v2.0 — АКТУАЛЬНА

Обработка рекламации — v1.2 — АРХИВ, действовала до 31.08.2026

Ключевой принцип

В каталоге должна быть одна актуальная версия процесса.

Блок 5. Метрики и управление

5.1. Предложите 4 метрики процесса обработки рекламаций: название, формула, источник данных, целевое значение, периодичность.

Целевые значения здесь — предлагаемые управленческие ориентиры, поскольку в кейсе фактические целевые значения компании не заданы. Если в компании установлен SLA 30 дней, первая метрика должна оценивать именно соблюдение этого SLA.

5.2. Кто владелец процесса и что конкретно он вправе менять без согласования.

Владелец процесса

Владелец — руководитель сервисной службы.

Он отвечает за весь процесс от поступления рекламации до её закрытия и результата для клиента.

Что он может менять без отдельного согласования

В пределах утверждённых полномочий и бюджета он вправе менять:

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

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

5.3. Как через 6 месяцев доказать руководству, что описание процессов дало эффект? Назовите 2–3 измеримых доказательства.

Сравнить показатели до и после описания/изменения процесса.

1. Сокращение времени обработки

Например:

Было: средний срок — 26 дней

Стало: 18 дней

То есть срок сократился примерно на 31%.

Лучше дополнительно смотреть медиану, чтобы отдельные экстремальные случаи не искажали результат.

2. Рост доли рекламаций, закрытых в SLA

Например:

Было: 72% рекламаций закрывались ≤30 дней

Стало: 95%

Это напрямую показывает улучшение управляемости процесса.

3. Снижение количества «невидимых» рекламаций

Например:

Было: 20% обращений решались вне CRM

Стало: 2%

Это доказывает не просто наличие описания процесса, а то, что сотрудники действительно работают по единому процессу и данные стали полнее.

Обязательный финальный раздел

«Вопросы, которые я задал бы заказчику»: перечислите всё, чего вам не хватило для корректного ответа, и укажите, какое допущение вы приняли вместо этого.

Вопросы, которые я задал бы заказчику