Что такое операционный анализ
Практическое определение операционного анализа: что он исследует, чем отличается от описания процессов и какие результаты даёт предприятию.
Операционный анализ — это исследование того, как работа выполняется в реальных условиях.
Его задача состоит не только в том, чтобы описать последовательность действий. Необходимо понять, что происходит между формальными этапами: где сотрудники ожидают, ищут ресурсы, переключаются между задачами, исправляют чужие ошибки, повторяют действия, обходят ограничения системы и компенсируют недостатки организации ручным трудом.
Именно эти действия часто определяют фактическую производительность процесса.
Контекст
Большинство организаций уже располагают описаниями процессов.
Есть регламенты, должностные инструкции, карты маршрутов, положения о подразделениях, формы документов и отчёты.
При внедрении информационной системы дополнительно создаются схемы AS-IS и TO-BE, пользовательские сценарии и функциональные требования.
Эти материалы необходимы. Однако они не дают полной картины.
Формальное описание обычно фиксирует:
- что должно быть сделано;
- кто отвечает;
- какой документ создаётся;
- в какой системе выполняется действие;
- какой результат должен быть получен.
Оно редко показывает:
- сколько времени сотрудник ищет необходимые данные;
- где он ждёт другого участника;
- как часто система не принимает действие;
- какие ресурсы фактически недоступны;
- какие шаги выполняются повторно;
- какие правила конфликтуют между собой;
- какие операции существуют только из-за недостатков предыдущих этапов;
- как сотрудники обходят ограничения, чтобы сохранить работоспособность процесса.
Поэтому два процесса с одинаковой схемой могут иметь совершенно разную фактическую производительность.
Что исследует операционный анализ
Рабочую ситуацию
Для каждого действия определяется контекст:
- где оно выполняется;
- кто его выполняет;
- что должно быть доступно;
- какое состояние имеет объект;
- какие ограничения действуют;
- от кого зависит продолжение;
- что происходит при исключении.
Поток работы
Исследуется реальное движение задач, документов, материалов, оборудования, данных, решений и ответственности.
Операционные потери
Фиксируются действия, которые потребляют ресурсы, но не создают полезный результат:
- ожидание;
- поиск;
- повторный ввод;
- повторная проверка;
- лишнее перемещение;
- ручное согласование;
- восстановление контекста после переключения;
- исправление последствий несогласованной работы;
- обход неудобного интерфейса;
- перенос данных между системами.
Ограничения
Ограничением может быть не только оборудование или производственная мощность.
Ограничением становятся неполные данные, отсутствие полномочий, противоречивые правила, недоступный интерфейс, зависимость от одного сотрудника, задержка решения, слабая интеграция и неясная ответственность.
Фактические правила
В любой устойчивой системе возникают неформальные правила.
Сотрудники знают, кого спросить, где искать правильную версию файла, какой шаг можно пропустить, когда система выдаёт ошибку и какую информацию безопаснее продублировать в мессенджере.
Эти правила являются частью реального процесса, даже если отсутствуют в документации.
Чем операционный анализ отличается от бизнес-анализа
Бизнес-анализ отвечает на вопрос, какое изменение необходимо организации и какие требования должна удовлетворить система.
Операционный анализ уточняет, как фактически работает исследуемый контур и какие условия определяют результат.
Один подход не заменяет другой.
Операционный анализ предоставляет бизнес- и системному анализу более точную исходную модель.
Без него требования могут формироваться на основе официального регламента, представления руководителя, интервью с отдельными участниками, статистики без причин и текущей логики информационной системы.
В результате новая система закрепляет существующие ограничения.
Чем операционный анализ отличается от аудита
Аудит проверяет соответствие установленным требованиям.
Операционный анализ исследует причины результата.
Аудитор может установить, что сотрудник не выполнил действие в установленный срок.
Операционный аналитик должен определить, было ли действие доступно, располагал ли сотрудник необходимыми данными, ожидал ли он решение, исправлял ли ошибку предыдущего этапа и могла ли система принять результат.
Цель состоит не в поиске виновного, а в понимании конструкции процесса.
Основные этапы
- Определение границ процесса.
- Сбор регламентов, форм, отчётов и журналов событий.
- Наблюдение за фактическим исполнением.
- Интервью по конкретным ситуациям.
- Сопоставление документов, наблюдений и данных.
- Формирование карты операционной реальности.
- Приоритизация проблем по влиянию на время, стоимость, качество и риск.
Практический пример
На схеме складского процесса может существовать действие «Получить задание и начать размещение товара».
Формально оно занимает несколько секунд.
Фактически сотрудник может ожидать выдачу терминала, искать исправный аккумулятор, проходить авторизацию, ожидать назначения задания, искать свободную тележку, находить груз и повторно сканировать объект после ошибки.
Если система измеряет только время от назначения задания до завершения размещения, часть внешних потерь может быть отнесена к производительности сотрудника.
Операционный анализ разделяет полезную операцию, подготовку, ожидание, поиск, системные задержки, организационные задержки и повторную работу.
Что получает предприятие
- карту фактического процесса;
- перечень потерь;
- модель причин;
- список ограничений;
- требования к процессу;
- требования к информационной системе;
- перечень быстрых организационных изменений;
- план измерения эффекта;
- приоритеты автоматизации.
Что делать
Для первичной диагностики достаточно ответить на семь вопросов:
- Какой полезный результат создаёт процесс?
- Какие действия реально выполняются?
- Где участники ожидают?
- Что они ищут?
- Какие операции повторяют?
- Какие ограничения компенсируют вручную?
- Что измеряют текущие показатели?
Если ответы неизвестны, процесс ещё не изучен в достаточной степени для автоматизации.
Вывод
Операционный анализ делает видимой работу, которая скрыта между формальными этапами.
Он позволяет проектировать изменения на основе фактического исполнения, а не только регламентов, интервью и текущей логики программных систем.