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

23.02.17

Архитектура

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

Спагетти

 

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

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

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

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

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

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

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

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

 

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

 

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

Прямой метод

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

 

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

 

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

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

 

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

 

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

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

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

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

 

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

 

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

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

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

 

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

 

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

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

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

 

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

 

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

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

Отвечаем:

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

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

 

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

ingraf.su

Предпроектное обследование отчёт об обследовании предприятия методы исследования бизнес-процессы бизнес-аналитика классификация

См. также

Отчеты и дашборды Бесплатно (free)

После года интенсивной работы в управленческой базе 1С накапливается большое количество информации. Алчные до анализа аналитики загружают разработчиков 1С большим объемом работ по созданию разных отчетов из базы данных. Это нужно, чтобы получить крупицы «золотой» информации, необходимой для принятия правильного управленческого решения. Как результат, загружены разработчики, нагружено железо, перегружены регистры, чешут голову администраторы по железу..... бюджет поддержки такой системы летит к небесам… Расскажем о том, как выгрузить данные из 1С в BI и передать настройку произвольных отчетов в руки аналитиков и юниор разработчиков, чтобы они сами могли вывести отчеты и взаимосвязи с помощью Yandex datalens.

27.05.2025    1130    15    uribur    6    

16

Интеграции Кейсы проектов Бесплатно (free)

На крупных проектах интеграции залогом успеха становится использование грамотных технических решений, инструментов и методик. Расскажем о совместном использовании «Конвертации данных 2» и 1С:Шины, подходах к интеграции НСИ, а также разделении труда в команде исполнителя.

10.04.2025    1544    0    Mick2iS    1    

13

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

14.10.2024    5451    0    comol    29    

31

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    4468    0    Novattor    1    

18

Кейсы автоматизации Проектирование бизнес-процессов Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Бесплатно (free)

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

11.07.2024    1632    0    Ingraf    4    

11

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    2693    0    slavik27    8    

15

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    7046    0    ivanov660    10    

36
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user710706_jupa 14.03.17 20:37 Сейчас в теме
Благодарю, четко подано. Пишите ещё.
2. CheBurator 3230 24.03.17 00:44 Сейчас в теме
3. Steelvan 308 31.03.17 15:41 Сейчас в теме
Промо = это типа за 29 000 ?
4. vova196 31 04.04.17 14:30 Сейчас в теме
Длинные схемы являются вау-эффектом, но сложночитаемые и малоэффективные в анализе.

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

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

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

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

А теперь важный момент о котором вы не знаете - блок-схема (особенно в представленной вами нотации) не позволит оценить загрузку ресурсов предприятия, узкие места процессов
А кто сказал что я этого не знаю? Знаю. Но я не занимаюсь консалтингом по оптимизации бизнес процессов, я занимаюсь их автоматизацией ;) Могу конечно и консалтингом... но мне за это не платят :D
StarsLine; mickey.1cx; +2 Ответить
7. DDA4746 29.08.18 11:51 Сейчас в теме
(4) Предпочитаю упрощенный вариант BPMN, для заказчика он понятнее, особенно в случаях запутанных процессов со множеством шагов (подсмотрел у коллег из PWC). У IDEF все-таки есть ограничение для количества элементов на схеме, после 3-4х схема превращается в сеточку из стрелок - это удобно разработчику, но абсолютно нечитаемо.
VVi3ard; Serg O.; +2 Ответить
11. VVi3ard 53 20.09.21 15:54 Сейчас в теме
(7) Разработчику эта схема вообще не нужна. Максимум проектировщику и как дополнение к текстовому описанию. Сама по себе IDEF0 схема это больше как оглавление у книги и способ согласовать общие принципы на высоком уровне.
10. pro-rok 297 28.05.20 07:32 Сейчас в теме
(4) А так ли важно пользоваться какой либо методологией при описании бизнес-процесса?
На мой взгляд самое важное тут, что бы ваш клиент понял схему без изучения доп. информации и что бы она одинаково понималась клиентом и исполнителем. А уж что выбрать IDEF0 или просто квадраты накидать в visio это дело конкретной ситуации.
8. Serg O. 307 26.11.18 11:08 Сейчас в теме
поддерживаю DDA4746 - "новый" стандарт BPMN 2.0 - уже с 2016г. устаканилась... и достаточно прост для "вхождения"... как со стороны программистов так и менеджеров... как бы "интуитивно-понятен"

а IDEF-ы достаточно сложны и запутанны для "непосвященных". Похоже на планы времен СССР для больших ватманов...
надо долго вкуривать что и откуда идёт... и мозг "выворачивать" под схему
9. valerycho 10.06.19 02:16 Сейчас в теме
Если нет задачи автоматизации БП, то какой смысл это всё описывать?
Оставьте свое сообщение