hero-bg

Правильные «неправильные» диаграммы и почему так важно помнить о цели

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

Проблематика

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

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

Пример диаграммы управления снабжением

Эту диаграмму я создавал для оптово-розничной компании, которая столкнулась с проблемой высокой затоваренности на складе. Владелец компании обратился ко мне с проблемой постоянной нехватки средств. Товара, судя по остаткам в программе, товара много, а как выразился заказчик “продавать нечего”.

Цель

Итак, поставлена задача: выявить причины проблемы затоваренности, исправить ситуацию (да, да так обычно и ставят задачи).

Я провел ABC-анализ продаж и анализ оборачиваемости склада. В результате я выяснил, что оборачиваемость склада составляла порядка 5-6 месяцев. Это очень долго. По сути, получается, что даже без постоянных закупок товара на складе хватило бы на полгода месяцев продаж.

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

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

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

Описание процесса Управление снабжением

Для просмотра полного изображения перейдите по ссылке

Описание

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

После обсуждения было реализовано:

  1. Оргструктура. Из описания понятно, что должен быть отдел закупок. Он был создан, а в самом отделе были выделены две роли – «операторы» и «менеджеры этажа». Так это тогда называлось. В компании было два «этажа» - по грузовым и легковым автомобилям.
  2. Доработки в учетной системе. В соответствии с этой диаграммой была доработана учетная система. Программисты получили задание, выполнили нужные доработки. В системе была реализована возможность работать в соответствии с бизнес-процессом.
  3. Обучение. По этой же диаграмме было проведено обучение сотрудников.

В результате удалось уменьшить количество остатков, в первую очередь, избавились от неликвидных остатков. Например, было выявлено, что на складе лежит долгое время 3 двигателя для грузовых автомобилей. В результате наведения порядка они были проданы со скидкой, и компания высвободила деньги. Оборачиваемость товара снизилась с 5-6 месяцев до 2-3 месяцев. Т.е. цель составления диаграммы была достигнута: разобрались в причинах и высвободили средства.

Критика

Когда я выложил эту диаграмму в группе, основная критика состояла в том, что эта диаграмма не рабочая, и вообще, это все не более, чем «рассуждение на тему, можно было бы и текстом описать». На самом деле, диаграмма на 100% рабочая, так как именно на ее основе были реализованы поставленные цели. При этом текстовые «рассуждения на тему» воспринимаются намного сложнее в сравнении с графикой. Именно диаграмма помогла быстрее достичь взаимопонимания с клиентом и его сотрудниками.

Критика диаграммы

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

Критика диаграммы 2

Также критики упоминали об отсутствии декомпозиции. Но декомпозиция – это также часть работы с нотациями, о ней я писал в других публикациях. В данном случае декомпозиция даже не планировалась. Наоборот, для наглядности был показан весь процесс на одной диаграмме. Цель создания диаграммы состояла не в том, чтобы по всем правилам создать какую-то модель бизнес-процесса, а наглядно показать предложение, донести все нюансы до людей. И практика показала, что эта цель также была достигнута, так как по итогу обсуждений схема работы была принята и реализована.

Что касается эстетики самой диаграммы, о ней можно спорить вечно. Эстетика – не более, чем дело вкуса. Лично я не вижу смысла обсуждать всерьез этот параметр.

Модель работы швейного предприятия

В этом случае компания собиралась внедрять 1С. Управление производственным предприятием, и также нужно было навести порядок, чтобы каким-то образом стандартизировать и автоматизировать работу.

Цель

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

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

Описание

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

Также была задача уменьшить срок рассмотрения заявки на производство от клиента.

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

Описание работы швейной фабрики

Критика

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

  1. Мы видим 7 блоков. IDEF0 по стандарту требует максимум 6 блоков.
  2. В диаграмме используются такие фразы, как «исследование рынка», «проектирование». Это также ошибки. Если вы ознакомитесь с моим переводом стандарта IDEF0 на сайте Хабр, то там описывается, что функции должны называться глаголом в совершенной форме, т.е. давать ответ на вопрос «что необходимо сделать». В данном случае вместо «Исследование рынка» правильно написать «Исследовать рынок. Не «Проектирование продукции», а «Спроектировать продукцию». Не «Проектирование производства», а «Спроектировать производство» и т.д. Есть и другие ошибки в названиях. Например, при декомпозиции хорошо видно название «Производство и реализация швейных изделий». Здесь не должны объединяться два разных действия союзом «И». Должно быть либо производство, либо реализация, точнее – «произвести» или «реализовать», так как по правилам нотации не должно быть союза «и», каждый блок описывается фразой с одним глаголом, который выражает функцию.

С другой стороны, несмотря на ошибки, диаграмма – рабочая. Проект длился около 2,5 лет, все этапы были автоматизированы успешно. В результате ответ на запрос о возможности выпуска продукции стал приходить не через 2,5 месяца, а в течение 10 дней, что для этого вида бизнеса – очень короткий срок. Были достигнуты и другие цели, в частности, опираясь на эту диаграмму.

Вывод: формально диаграмма неправильная, с точки зрения достижения цели – правильная.

Выводы

На основе описанных примеров и их критики можно сделать следующие выводы:

  1. Всегда соотносите свои инструменты и результаты работы с целями, которых вы хотели достичь. Если у вас нет четко поставленной цели, то, в принципе, сама ваша работа не нужна. Это будет бесцельная работа, т.е. «мартышкин труд».
  2. Если при помощи выбранных инструментов вы достигли нужного результата, можно считать, что вы все сделали как надо. Как говорится, победителей не судят. И любые ошибки с формальной точки зрения оказываются не так важны, главное – результат. Конечно, изучать свои ошибки необходимо, формальная сторона также важна для вашего собственного развития. Но упираться в только формальную сторону – не стоит. Результат намного важнее.
  3. Диаграммы создаются для того, чтобы передать их другим лицам, т.е. их можно считать формой передачи информации. И если получатель информации все правильно понял, значит, диаграмма выполнила свою функцию. Например, если вы работаете сами, и диаграмму создаете также для себя, все ошибки с формальной точки зрения не имеют значения, главное, что вы понимаете, что и зачем нарисовали. Если диаграмма передается руководителю, программисту, другим сотрудникам, важно, чтобы она читалась и понималась однозначно. Правила нотаций в этом очень сильно помогают, но далеко не всегда есть необходимость ограничиваться одной из нотаций.
  4. Форма диаграммы – важна, помогает лучшему пониманию. Содержание – еще важнее. Но самое главное – это цель. Если у вас есть четко поставленная цель и понимание, как прийти к результату, никакие ошибки в форме, а часто и ошибки в содержании, вам не помешают. Главное, не как вы описываете достижение цели, а владеете ли вы нужными для ее реализации инструментами, и хватит ли у вас энергии довести работу до успешного результата.

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

Об авторе
authorКинзябулатов Рамиль

Кинзябулатов Рамиль Хибатуллович, бизнес консультант и it консультант. Опыт автоматизации более 17 лет. Занимаюсь управленческим консультированием и разработкой it решений в составе команды Trinion. Автор 3-х книг и множества статей на тему организации труда.

Оставить комментарий

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