Профессия: Бизнес-аналитик

Глава 4 Интервью наблюдение и рабочая встреча

Подготовка разговора

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

До встречи изучите доступные документы. Пустая форма заявки, инструкция, обезличенная запись и пример отчёта помогают задавать точные вопросы. Отмечайте, что известно из документа, а что только предполагается. Если инструкция требует одного действия, не считайте, что сотрудники всегда выполняют именно его.

Составьте небольшой маршрут разговора: начало операции, обычный ход, исключения, завершение и передача результата. На каждый участок подготовьте открытый вопрос и просьбу о примере. «Какие сведения вы получаете от мастера?» полезнее, чем «Мастер ведь передаёт вам номер и цену?». Во втором случае вы сами подсказываете ответ.

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

Вопросы которые раскрывают работу

Начните с конкретного случая: «Покажите, как вы обработали последнюю заявку после диагностики». Затем уточняйте действия, источники и решения. Кто сообщил? Где появился номер? Как нашли контакт? Почему решили звонить именно этому клиенту? Что записали после разговора? Кому стало известно о согласовании?

Вопрос о частоте отделяйте от вопроса о возможности. «Так бывает?» позволяет обнаружить исключение. «Сколько подобных случаев было за последнюю неделю?» помогает оценить масштаб, но ответ по памяти ещё не является статистикой. Если частота влияет на стоимость решения, ищите подтверждение в данных.

Отдельно спрашивайте о неудаче. Что происходит, если клиент не отвечает? Если номер неверен? Если стоимость изменилась? Если два сотрудника открыли одну заявку? Если мастер закончил диагностику после ухода администратора? Именно такие вопросы часто показывают, где обычного описания недостаточно.

Не превращайте интервью в экзамен. Сотрудник может не знать названий статусов и терминов аналитика. Просите показать действие и объяснить выбор своими словами. Затем предложите формулировку: «Правильно ли я понял, что после первого звонка заявка остаётся в ожидании решения клиента?» Участник сможет исправить смысл.

Учебный фрагмент интервью

Администратор Ольга говорит: «Павел пишет, что диагностика готова. Я нахожу клиента в таблице и звоню. Если занят, беру следующего». Аналитик уточняет: «Как вы возвращаетесь к первому?» Ольга отвечает: «Ставлю звёздочку. Но у второго администратора свой список, он её не видит».

В этой реплике есть действие, личный способ напоминания и ограничение совместной работы. Запись «нужны звёздочки» была бы поспешной. Потребность заключается в том, чтобы повторный контакт не терялся при смене сотрудника. Возможные решения включают общую очередь, назначенного ответственного и дату следующей попытки.

Павел говорит: «Я передаю стоимость после диагностики, но иногда ещё не знаю цену детали». Аналитик спрашивает: «Что в таком случае сообщается клиенту?» Ответ: «Администратор говорит приблизительно, а потом перезванивает». Появляется вопрос о различии предварительной оценки и согласованной стоимости. Нельзя хранить обе величины в одном поле без объяснения статуса.

Ирина добавляет: «Главное, чтобы мастер не начал платный ремонт без согласия». Это уже важное правило, но его нужно уточнить. Что считается согласованием? Кто его фиксирует? На какую стоимость оно распространяется? Что делать после изменения оценки? В учебной версии администратор фиксирует решение клиента по конкретной версии оценки; ремонт начинается только при действующем согласовании.

Запись и подтверждение

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

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

Отправляемый участнику протокол должен быть коротким и проверяемым. «Обсудили процессы» ничего не подтверждает. «После диагностики старший мастер передаёт номер заявки и оценку; администратор фиксирует попытку контакта; при отсутствии ответа назначает следующую попытку» уже можно проверить и исправить.

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

Наблюдение за процессом

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

Записывайте время ожидания отдельно от времени действия. Поиск записи занимает три минуты, разговор — четыре, ожидание ответа мастера — сорок. Если сложить только активные действия, получится впечатление, что заявка обрабатывается быстро. Клиент же видит полное время.

Учитывайте влияние наблюдателя. При вас сотрудник может внимательнее заполнять поля и меньше отвлекаться. Один показанный случай не описывает всё подразделение. Сопоставьте несколько наблюдений, документы и данные; обозначьте, какие смены и типы заявок не рассмотрены.

Рабочая встреча нескольких участников

Общая встреча полезна, когда нужно согласовать разрыв между ролями. Например, мастер считает передачей информации сообщение в чате, а администратор — появление строки в своей очереди. Сначала сформулируйте вопрос, затем дайте каждой стороне описать действие и ожидаемый результат. Не начинайте с выбора программы.

На доске покажите одну заявку по шагам. В каждой передаче задавайте два вопроса: что отправитель считает завершением своей работы и что получатель должен получить для начала следующей. Часто конфликт возникает именно между этими определениями.

Если участники спорят о редком исключении, запишите его отдельно и завершите основной сценарий. Затем вернитесь к исключению с пониманием частоты и риска. Иначе встреча может закончиться подробным обсуждением одного необычного случая без общей модели процесса.

Задание и разбор

Составьте двенадцать вопросов администратору и восемь мастеру. Для каждого укажите, какое решение зависит от ответа. Уберите вопросы, которые только подтверждают уже выбранную функцию. Затем проведите учебное интервью с человеком, который сыграет роль участника по описанию проекта, или письменно ответьте от имени роли с явной пометкой о симуляции.

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

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

Глава 5 Проверка сведений и выводы исследования

Сравнение источников

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

Заведите реестр наблюдений. Запись включает утверждение, источник, способ получения, пример, степень подтверждения и следующий шаг. Например: «Результат диагностики передаётся в чат; источник — интервью Павла; подтверждение — показанный обезличенный пример; нужно проверить вторую смену». Такая запись позволяет понять, почему вывод ещё ограничен.

Не приписывайте оценке точность, которой нет. Слова «половина заявок» могут означать субъективное впечатление. Запишите их как оценку участника. Если цифра влияет на цель или обоснование затрат, запросите выборку и уточните, как она сформирована.

Сравнивайте разные источники вокруг одного действия. Инструкция говорит, что мастер фиксирует диагностику в таблице. Наблюдение показывает, что он пишет в чат. Данные содержат пустые даты. Возможные объяснения: инструкция устарела, интерфейс неудобен, доступ отсутствует или операция происходит на другом этапе. Каждое объяснение требует проверки.

Противоречие как рабочая задача

Противоречие не нужно скрывать аккуратной формулировкой. Если администратор утверждает, что заявку закрывает мастер, а мастер считает это обязанностью администратора, запишите обе позиции. Затем установите действующее правило или организуйте принятие нового.

Полезная карточка противоречия содержит предмет, варианты, последствия каждого и человека, который может принять решение. Для закрытия заявки варианты различаются: «Ремонт завершён» относится к работе мастера, «Выдана» — к передаче устройства клиенту. Возможно, участники просто используют слово «закрыть» для разных событий.

После уточнения добавьте термины в словарь. В нашем проекте ремонт завершён после контрольной проверки, а заявка завершена после выдачи либо окончания отказного сценария. Это устраняет конфликт без лишнего выбора одного сотрудника виновным.

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

Работа с учебной выборкой

Исходные 240 заявок позволяют потренироваться с показателем. Сначала проверяем единицу учёта. Одна строка должна соответствовать одной заявке, а не одному звонку. Несколько контактов по одной заявке иначе раздуют знаменатель. Отдельно проверяем дубликаты номеров и пропуски даты диагностики.

Затем делим записи по пригодности к расчёту. Пригодная запись содержит время окончания диагностики, идентификатор заявки и время первой попытки либо отсутствие попытки после наступления срока. Если дата диагностики неизвестна, просрочку невозможно определить корректно. Такую запись учитывают в показателе качества данных, а не произвольно относят к своевременным.

Допустим, из 240 записей двадцать имеют неполные даты. Тогда расчёт по всем строкам и расчёт по 220 проверенным строкам отвечают разным вопросам. Нельзя оставить прежнее значение 30% и скрыть изменение состава. В учебном базовом сценарии дальнейшие числа 240 и 72 считаются проверенными, чтобы сосредоточиться на анализе процесса. Альтернативная выборка используется только в этом упражнении.

Ищите распределение задержек: по смене, дню недели, типу устройства и этапу. Однако различие между группами не доказывает причину. Вечерняя смена может получать более сложные случаи. Перед выводом о сотрудниках сравните условия работы и полноту записей.

От причины к варианту изменения

Для каждого обнаруженного разрыва предложите несколько способов. Если задача теряется между сменами, можно ввести общий журнал передачи, назначать ответственного или сделать общую очередь в системе. Первый вариант дешевле для проверки, второй меняет организацию, третий требует разработки. Их полезность зависит от масштаба и ограничений.

Составьте небольшую матрицу вариантов: влияние на цель, стоимость изменения, риск и зависимость. Оценки на раннем этапе могут быть качественными, например «низкая», «средняя», «высокая», но с объяснением. Число 7,4 выглядит точнее, хотя основано на тех же предположениях. Не маскируйте неопределённость арифметикой.

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

Отчёт исследования

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

Учебный вывод: «Передача результата диагностики зависит от сообщений и личных списков. При смене администратора повторный контакт может потеряться. Предлагается единая очередь с назначением ответственного и фиксацией попыток. До проектирования нужно подтвердить правила изменения стоимости и завершения отказной заявки».

В таком выводе виден путь от наблюдения к предложению. Фраза «необходимо внедрить инновационную систему управления» этого пути не показывает. Избегайте обещаний экономии, пока не выяснены затраты, загрузка и достоверность исходного времени.

Практикум по проверке

Возьмите десять утверждений из своих заметок. Для каждого определите, является ли оно наблюдением, правилом, мнением, гипотезой или предложением. Затем выберите три, от которых зависит архитектура процесса, и укажите дополнительный способ подтверждения.

Разберите фразу: «Все клиенты хотят получать сообщения в мессенджере». Одно интервью с администратором не подтверждает интерес всех клиентов. Нужны сведения о доступных каналах, согласованных правилах контакта, предпочтениях и доставке. В первой версии можно оставить ручной звонок, а исследование нового канала выделить отдельно.

Подготовьте отчёт исследования на две-три страницы. Завершите его решением, которое требуется от заказчика, и перечнем вопросов, которые можно исследовать позже. Это будет первый связный документ портфолио, показывающий вашу способность отделять доказанное от предполагаемого.

Глава 6 Описание текущего процесса

Что является процессом

Процесс имеет начало, действия и результат. «Работа сервисного центра» слишком широка для полезной первой схемы. «Обработка принятой заявки от регистрации до выдачи» уже задаёт границу. При этом диагностику и ремонт можно раскрыть отдельными подпроцессами, если их внутренние действия важны для задачи.

Сначала опишите процесс словами. Назовите событие начала, участников, входные сведения, основные решения и результаты. Затем рисуйте. Если вы не можете объяснить, почему после действия возникает следующий шаг, линия на схеме не устранит непонимание.

Текущий процесс часто называют AS IS, то есть «как есть». В нём фиксируют подтверждённый порядок, включая неудобные обходы. Не улучшайте процесс незаметно при описании. Если сотрудник переносит данные в личный список, покажите этот факт. Предложение об общей очереди относится уже к целевой модели.

Пошаговое описание

В нашем сценарии администратор регистрирует принятую заявку, прикрепляет номер к устройству и сообщает старшему мастеру. Старший мастер выбирает исполнителя. Мастер проводит диагностику и передаёт результат. Администратор пытается связаться с клиентом. При согласовании мастер выполняет ремонт и проверку. После сообщения о готовности администратор выдаёт устройство и завершает заявку.

У каждого шага уточните основание перехода. «Клиент согласен» должно иметь источник и фиксацию. «Диагностика готова» должно означать достаточный состав сведений. Иначе команда не сможет понять, завершён ли шаг и кто вправе начинать следующий.

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

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

Уровень подробности

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

Не помещайте все подробности в одну схему. Если на ней десятки действий, длинные условия и множество пересекающихся линий, читатель перестаёт видеть смысл. Выделите подпроцесс «Согласование ремонта» и раскройте его отдельно. Сохраните связь: номер подпроцесса, вход, выход и место вызова.

Проверяйте гранулярность. «Принять устройство» и «Нажать кнопку сохранения» находятся на разных уровнях. В одной модели их сочетание допустимо только при явной цели, например исследовании ошибки конкретного интерфейса. Для общего процесса такая смесь мешает сравнивать шаги.

Передача ответственности

Разрыв между участниками часто скрыт в слове «передать». Установите, какие сведения получает следующая роль и где они доступны. Для мастера важны устройство, описание неисправности и номер заявки. Для администратора после диагностики нужны оценка, описание результата и ограничения согласования.

Результат передачи должен быть наблюдаемым. Если мастер отправил сообщение без номера, администратор может не связать его с заявкой. С точки зрения отправителя работа завершена, с точки зрения получателя — ещё нет. В текущей модели отметьте этот риск, а в целевой задайте обязательный состав передачи.

Не делайте разные подразделения отдельными пулами BPMN только потому, что они сидят в разных комнатах. Пул представляет участника взаимодействия, а дорожки внутри него могут отражать роли. Для нашего центра администратор и мастер находятся в одном пуле; клиент показан отдельным внешним участником. Правила соединений разобраны в следующей главе [1].

Проверка модели на одной заявке

Выберите заявку S-017. Устройство принято во вторник в 10:00, диагностика завершена в 15:00, попытка звонка выполнена в среду в 10:30. По учебному календарю срок истекает в среду в 10:00: три часа во вторник и один в среду. Значит, попытка просрочена на тридцать рабочих минут.

Пройдите эту заявку по модели. Где появилось время диагностики? Кто узнал о нём? Где заявка ожидала до звонка? Что могло сделать её видимой раньше? Такие вопросы проверяют модель лучше, чем оценка её внешней аккуратности.

Затем возьмите отказную заявку и заявку с отсутствием ответа. Убедитесь, что они могут завершиться или продолжить ожидание по понятному правилу. Если модель заканчивается только успешным ремонтом, она описывает лишь часть работы центра.

Практикум по текущему процессу

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

Выпишите пять исключений и проверьте их прохождение. Если сведений не хватает, добавьте вопрос к исследованию. Например, книга пока не задаёт условия длительного хранения невыданного устройства. Вы должны обозначить границу, а не сочинять правовое правило.

Сохраните исходное описание отдельно от будущих улучшений. Оно понадобится, чтобы показать в портфолио, какое изменение вы предложили и почему. На следующем этапе вы переведёте смысл процесса в BPMN, сохранив установленные действия и развилки.

Глава 7 BPMN на практике

Минимальный набор элементов

BPMN — нотация моделирования бизнес-процессов. Она задаёт значения графических элементов и связей между ними. В книге используется небольшой набор для описательных моделей: события, задачи, шлюзы, пулы, дорожки и соединения. Исполняемая модель для конкретного движка потребует дополнительных настроек и проверки поддерживаемых элементов.

Событие показывает, что произошло или ожидается. Задача показывает действие. Шлюз управляет разветвлением или объединением потоков. Пул обозначает участника взаимодействия; дорожки помогают показать роли внутри его процесса. Не пытайтесь выразить каждый смысл одной универсальной фигурой.

Стартовое событие обычно рисуют окружностью с тонкой границей, конечное — с толстой. Задача изображается прямоугольником со скруглёнными углами [14]. В названии задачи используйте действие и объект: «Зафиксировать диагностику», «Связаться с клиентом». Название «Диагностика» может означать этап, результат или документ и поэтому менее однозначно.

Шлюз рисуют ромбом. Метка X указывает на исключающий шлюз, знак плюс — на параллельный. В учебных схемах метки оставлены явно, чтобы начинающий читатель различал поведение. Не выбирайте шлюз по тому, какая фигура лучше выглядит на странице.

Потоки и границы

Поток последовательности представляет порядок действий внутри процесса. Он рисуется сплошной линией со стрелкой. Поток сообщений показывает обмен между разными участниками и рисуется пунктиром с открытой стрелкой. Ассоциация связывает пояснение или данные с элементом и не задаёт порядок выполнения [1].

В пределах пула поток последовательности может переходить между дорожками. Между пулами его проводить нельзя. Если клиент отправляет ответ центру, используйте поток сообщения. Если администратор передаёт заявку мастеру внутри процесса центра, последовательность может пересекать границу дорожек. Сообщение между этими дорожками не требуется [1].

На первой схеме показан учебный фрагмент приёма. Клиент представлен закрытым пулом: его внутренний процесс не исследуется. Из него приходит сообщение к старту процесса центра. Администратор регистрирует заявку, затем старший мастер назначает исполнителя. Завершение фрагмента означает передачу к диагностике, а не завершение всей заявки.

Рисунок 1 Учебный фрагмент приёма и назначения

Проверьте, что подпись конечного события соответствует масштабу. Если схема описывает только приём, конец «Заявка завершена» будет неверным. Подпись «Исполнитель назначен» точнее отражает результат рассматриваемого фрагмента.

Исключающий шлюз

Исключающий шлюз, часто называемый XOR, выбирает одну из альтернативных ветвей. В учебном согласовании ответ клиента может быть «согласен», «отказ» или «ответа нет». Это три взаимоисключающих результата одной попытки связи. Их условия нужно назвать явно.

Нельзя оставлять условия «сумма больше 5000» и «сумма меньше 5000», если значение ровно 5000 допустимо. Модель не определит, куда идти. Используйте непересекающиеся условия, покрывающие все значения, либо явно предусмотренную ветвь по умолчанию. Техническое выполнение условий зависит от движка; в описательной схеме прежде всего проверяют смысл [2].

Объединяющий XOR пропускает пришедший поток дальше и не ожидает остальные альтернативы. Это удобно, когда ранее была выбрана только одна ветвь. Если несколько параллельных действий придут к XOR независимо, последующее действие может начаться несколько раз. Для синхронизации применяют другой элемент.

В учебной схеме согласования после отсутствия ответа назначается повторная попытка, затем процесс возвращается к контакту. Для реального процесса необходимо дополнительно определить календарь повторов и правило длительного отсутствия ответа. Книга не задаёт юридических условий прекращения взаимодействия с клиентом.