Про спагетти, или как исследовать бизнес-процессы организации

Управление - Техническое задание

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

Спагетти

Если уйти от аллегории, то "скрученные спагетти" в масштабах предприятия это:

  • Невозможность анализировать себестоимость продукции. Даже если система учёта ведётся с пономенклатурной детализацией, то эти цифры не имеют никакой адекватности. Следовательно, прибыль может быть самопроизвольным процессом, который не зависит от действий руководства и работников.
  • Отсутствие оперативного состояния, а это отсутствие ответов на вопросы:
    • В какой стадии находятся заказы (клиента, на производство, на сборку)?
    • Чем занят штатный персонал?
    • Какая производительность организации? и др.
  • Отсутствие фактических значений материальных запасов, НЗП и готовой продукции.

Доказательства из практики. Руководитель организации знает, что в штате числится 6 технологов и 4 сотрудника в отделе контроля качества. Если разделить общий объём работы на указанных сотрудников, то получаются адекватные нагрузки. После обследования выяснилось, что 2 технолога и 1 контролёр занимаются исключительно низкомаржинальной продукцией. Про малую прибыль данного вида производства знают экономисты и руководство, но они не знают разделение труда в подразделениях. В совокупности затрат на оплату труда персонала, производственных и общепроизводственных затрат результат для категории продукции оказался убыточный.

Возможно это демпинг по вытеснению конкурентов, но руководство этого не знает :)

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

Минимальный результат исследования:

  1. Классификация бизнес-процессов организации
  2. Описание каждого целевого БП в текстовом виде и блок-схеме.

Самый простой и рабочий вариант классификации:

Классификация бизнес-процессов

Обследование бизнес-процессов

Прямой метод

Прямой метод соответствует со-направленному исследованию процессов и порядку процедур в деятельности.

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

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

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

Анкета интервьюирования по бизнес-процессу

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

Обратный метод

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

Например, конечным пунктом деятельности по продаже продукции является передача водителю заказчика "Универсального передаточного документа" , ТТН, Материального пропуска. Они созданы в программе 1С ERP менеджером по продажам для отпуска продукции. Сигналом для их оформления служит событие оплаты заказа клиента. И т.д.

Обратный метод исследования бизнес-процесса

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

Смешанное использование

Стоит заметить, что прямой и обратный метод можно использовать одновременно. Это допустимо и рекомендовано в обследовании сложных процессов, к которым трудно подойти с одной стороны, либо в командном исследовании (2 человека на один БП).

Смешанный метод исследования бизнес-процесса

Разветвление и объединение бизнес-процессов

Операция бизнес-процесса может рождать и завершать второстепенный процесс (подпроцесс). К примеру, операция ввода заказа требует расчет стоимости продукции (для уникальных изделий), процедуры оплаты, формирование заказа в производство. Это рождение подпроцессов.

Это пример реального сквозного БП, затрагивающий несколько подразделений предприятия.

Схема сквозного бизнес-процесса

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

Получили классификацию, описание и блок-схему - что делать?

Отвечаем:

  1. Добавляет ли ценность продукту данная операция БП?
  2. Готов ваш клиент оплачивать данную процедуру?
  3. Оптимально ли движутся ресурсы предприятия? Нужно ли это движение?
  4. Какие каналы связи самые длинные и почему? Для чего они нужны?
  5. Передача информации между сотрудниками - это потеря во времени и в затратах. Есть излишние каналы связи?
  6. Где и почему происходит больше всего брака, издержек, длительных ожиданий?
  7. Чем регламентируется операция БП, каков её стандарт?

+100 вопросов...

Сергей Куканов 

ingraf.su

См. также

Комментарии
1. Руслан Шайдуллин (user710706_jupa) 14.03.17 20:37 Сейчас в теме
Благодарю, четко подано. Пишите ещё.
2. Сергей (Che) Коцюра (CheBurator) 3382 24.03.17 00:44 Сейчас в теме
3. Игорь Steelvan (Steelvan) 30 31.03.17 15:41 Сейчас в теме
4. Владимир Ильич (vova196) 16 04.04.17 14:30 Сейчас в теме
Длинные схемы являются вау-эффектом, но сложночитаемые и малоэффективные в анализе.

IDEF0 в помощь. Позволяет в удобной (и для себя и для заказчика) форме описать процессы любого объема и степени вложенности. Явнsй плюс методологии: с уровнем зам.директора - обсуждается верхний уровень. С начальниками отдела - средний. А вот уже последний нижний уровень заполняемый/обсуждаемый непосредственно с исполнителями - это и есть фактически перечень объектов к доработке. Очень удобно. После перехода на IDEF0 реально упростил себе жизнь по созданию эффективных ТЗ

Явный минус: софт (ErWin) - желает лучшего. А использовать viso для IDEF0 все равно что Paint вместо Photosop
5. Сергей Куканов (Gavrik) 336 05.04.17 19:18 Сейчас в теме
(4) Судя по комментарию вы создаёте блок-схему ради её существования. зачем? какой эффект? назначение? цели блок-схемы вы представляете. Тем более длинной схемы. И уж тем более не представляет директор что с ней делать. А теперь важный момент о котором вы не знаете - блок-схема (особенно в представленной вами нотации) не позволит оценить загрузку ресурсов предприятия, узкие места процессов, временные интервалы - именно это важно владельцу бизнеса/процессу.
6. Владимир Ильич (vova196) 16 06.04.17 12:18 Сейчас в теме
(5)
зачем? какой эффект? назначение? цели блок-схемы вы представляете..

Более чем представляю. Я делаю блок схемы не для "красивого ТЗ", а использую их как эффективный инструмент. Основных целей 3:
1. Описавши в схемах получаю удобный визуальный инструмент для общения с заказчик по вопросу "А все ли Ваши процессы мы исследовали"
2. Именно при создании полноценных схем описываю и проверяю все связи между подсистемами в целом и отдельными бизнес-процессами. Тем самым избежать "дублирования" и "пустых связей". Опять таки повторюсь если делать качественные максимально детализированные схемы. Рисуночки типа "Заказ => Реализация => Оплата" которые зачатую встречаю в чужих ТЗ - такой информации естественно не дадут.
3. Именно блок схемы на IDEF0 - являются основой для содержания ТЗ и предлагаемым планом доработки/внедрения. Именно так. Я не создаю даже вордовского файла ТЗ пока у меня нет более менее корректного черновика IDEF0.

Естественно если проект выглядит как "Добавить учет путевых листов" - то это не тот уровень которым я обычно занимаюсь. Здесь зачастую вполне можно обойтись парой скриншотов. Но большие (50-150 пользователей) сложно-структурированые предприятия, где порой два соседних кабинета не знают кто что делают... Собрать. проанализировать, спроектировать и согласовать доработки. И не для "одного кабинета", а для всего предприятия. А потом ещё просчитать объем, согласовать бюджет. "Напилить" задач программистам, протестировать, внедрить. обучить... И потом ещё ломать копья что "сделаны все подтвержденные задачи в объеме зафиксированном в ТЗ"... Я бы хотел познакомиться и пообщаться с тем человеком кто сможет все это делать не опираясь на четко структурированную информацию которую дают ПРАВИЛЬНЫЕ блок-схемы.

А теперь важный момент о котором вы не знаете - блок-схема (особенно в представленной вами нотации) не позволит оценить загрузку ресурсов предприятия, узкие места процессов
А кто сказал что я этого не знаю? Знаю. Но я не занимаюсь консалтингом по оптимизации бизнес процессов, я занимаюсь их автоматизацией ;) Могу конечно и консалтингом... но мне за это не платят :D
mickey.1cx; +1 Ответить
Оставьте свое сообщение