Бизнес-процессы: как описать работу и подготовить улучшения

Иванов Дмитрий

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

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

Как отличить процесс от задачи и проекта

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

Это различие используется и в объяснении управления бизнес-процессами IBM: повторяемую сквозную работу отделяют от отдельных задач и проектов. Оно помогает правильно сформулировать поручение. «Обработать обращение» и «изменить порядок обработки обращений» требуют разных действий и ответственности.

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

Зачем описывать работу, если сотрудники её знают

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

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

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

Какие процессы бывают и как выбрать первый

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

Первым выберите процесс с понятной проблемой и доступными участниками. Хороший кандидат — повторяющиеся возвраты заявок из-за неполных данных. Плохой старт — абстрактное «повысить эффективность всех подразделений»: у такой задачи ещё нет границ и проверяемого результата.

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

Как задать начало, конец и границы

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

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

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

Как собрать фактический порядок действий

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

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

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

Пример описания в простой таблице

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

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

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

Как перейти от таблицы к схеме

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

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

Для профессионального моделирования существуют формальные нотации, включая BPMN. Простой рисунок стрелками не следует выдавать за корректную BPMN-модель. На начальном этапе достаточно честно назвать его рабочей схемой и договориться о значении элементов. Формальный язык изучают отдельно, когда он действительно нужен команде.

Как найти задержку, а не придумать её

Возьмём отдельный вымышленный хронометраж: активная обработка стандартной заявки заняла 25 минут, ожидание между действиями — 95 минут. Общее время составило 120 минут. Эти данные относятся только к условному примеру и не являются нормативом для выдачи техники.

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

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

Как выбрать улучшение и не перенести проблему

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

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

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

Как оформить проект изменения процесса

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

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

Именно здесь описание процесса превращается в управленческую работу. Нужно согласовывать требования, учитывать риски, планировать действия и принимать результат. Курс «Менеджер проектов +ИИ» Учебного центра МГУТУ помогает освоить этот проектный контур. Он не подменяет отдельную подготовку по всем методологиям процессного анализа.

Как проверить первую самостоятельную работу

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

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

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

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

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

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

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

Практика вместо теории

Освойте переход от описания проблемы к управлению проектом улучшений.

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

Смотреть программу

Вопросы и ответы

• Чем бизнес-процесс отличается от проекта?

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

• Нужна ли специальная программа для первого описания?

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

• Какой процесс описывать первым?

  Выберите повторяемую работу с понятной проблемой и доступными участниками. У неё должны быть определимый результат и возможность проверить предложенное изменение.

• Любая схема со стрелками считается BPMN?

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

• Когда описание превращается в проект улучшения?

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

По теме