У меня есть группа в Facebook, в ней уже около 7 тысяч подписчиков. И время от времени я выкладываю в ней диаграммы функциональных моделей и бизнес-процессов. Само собой, что в комментариях к этим постам я получаю обратную связь, на основании которой я заметил, что люди, когда критикуют и обсуждают диаграммы, совершают множество ошибок.
По отзывам я обнаружил, что многие люди просто не понимают, как оценить правильность или неправильность диаграммы. О диаграмме судят исключительно с точки зрения эстетики или на основе чисто формального подхода. В результате вместо обсуждения правильности или неправильности построения диаграмм, начинается обсуждение внешнего вида диаграммы и соответствия ее правилам построения моделей с точки зрения той или иной нотации, даже если об этой нотации в описании диаграммы не было сказано ни слова. Само собой, что мнения расходятся и это нормально. К сожалению, при этом обсуждение уходит в сторону, и я практически не вижу комментариев по существу.
В этой статье я решил поговорить о том, как правильно оценивать построение диаграммы, своей или чужой с точки зрения правильности построения. Само собой, что речь идет именно о функциональной или процесной графической модели бизнеса. Для лучшего понимания сути, разбираться с этим вопросом мы с вами будем на двух примерах.
Эту диаграмму я создавал для оптово-розничной компании, которая столкнулась с проблемой высокой затоваренности на складе. Владелец компании обратился ко мне с проблемой постоянной нехватки средств. Товара, судя по остаткам в программе, товара много, а как выразился заказчик “продавать нечего”.
Итак, поставлена задача: выявить причины проблемы затоваренности, исправить ситуацию (да, да так обычно и ставят задачи).
Я провел ABC-анализ продаж и анализ оборачиваемости склада. В результате я выяснил, что оборачиваемость склада составляла порядка 5-6 месяцев. Это очень долго. По сути, получается, что даже без постоянных закупок товара на складе хватило бы на полгода месяцев продаж.
Мое предложение было таким: давайте наведем порядок, и будем закупать только то, что реально необходимо. Для этого нужно создать продуманную систему работы закупок.
По факту в компании вопросами закупок занимались продавцы. Они заказывали товар по телефону, один из продавцов ездил на закупки, все это было организовано неудовлетворительно, постоянно случались накладки, т.е. в закупках царил хаос. Ведь от закупок продавец не получал своего процента в отличии от продаж. И даже то что продавец продавал то что он до этого закупил, все равно получилось не то что требовалось.
По итогам изучения работы компании, я предложил описать бизнес-процесс. Представленная диаграмма и является таким описанием.
В то время я еще не работал с BPMN, это было более 12 лет назад. Описание я выполнил на основе собственного опыта и знаний, полученных из тематической литературы. Эту диаграмму вместе с текстовым описанием мы раздали сотрудникам, отвечающим за работу со снабжением.
После обсуждения было реализовано:
В результате удалось уменьшить количество остатков, в первую очередь, избавились от неликвидных остатков. Например, было выявлено, что на складе лежит долгое время 3 двигателя для грузовых автомобилей. В результате наведения порядка они были проданы со скидкой, и компания высвободила деньги. Оборачиваемость товара снизилась с 5-6 месяцев до 2-3 месяцев. Т.е. цель составления диаграммы была достигнута: разобрались в причинах и высвободили средства.
Когда я выложил эту диаграмму в группе, основная критика состояла в том, что эта диаграмма не рабочая, и вообще, это все не более, чем «рассуждение на тему, можно было бы и текстом описать». На самом деле, диаграмма на 100% рабочая, так как именно на ее основе были реализованы поставленные цели. При этом текстовые «рассуждения на тему» воспринимаются намного сложнее в сравнении с графикой. Именно диаграмма помогла быстрее достичь взаимопонимания с клиентом и его сотрудниками.
Кроме того, критики этой диаграммы указывали на несоблюдение правил работы с нотациями. Но при создании диаграммы никакая нотация не использовалась. И нигде не сказано, что это пример работы с той или иной нотацией. Потому суждения с точки зрения каких-либо правил здесь не корректны.
Также критики упоминали об отсутствии декомпозиции. Но декомпозиция – это также часть работы с нотациями, о ней я писал в других публикациях. В данном случае декомпозиция даже не планировалась. Наоборот, для наглядности был показан весь процесс на одной диаграмме. Цель создания диаграммы состояла не в том, чтобы по всем правилам создать какую-то модель бизнес-процесса, а наглядно показать предложение, донести все нюансы до людей. И практика показала, что эта цель также была достигнута, так как по итогу обсуждений схема работы была принята и реализована.
Что касается эстетики самой диаграммы, о ней можно спорить вечно. Эстетика – не более, чем дело вкуса. Лично я не вижу смысла обсуждать всерьез этот параметр.
В этом случае компания собиралась внедрять 1С. Управление производственным предприятием, и также нужно было навести порядок, чтобы каким-то образом стандартизировать и автоматизировать работу.
Поставленная задача: разобраться с тем, как работает производственная компания, предложить решения для автоматизации, стандартизировать работу, повысить ее эффективность.
Я запросил описание работы компании, получил документы, в том числе, описание структуры, но из них также было сложно понять, как на самом деле работает организация.
По итогам предоставленной информации я понял, что автоматизация невозможна. Нет целостной картины, да и сами сотрудники работают очень по-разному, т.е. кому как удобнее. В результате была создана диаграмма, на основе которой проводилась автоматизация.
Также была задача уменьшить срок рассмотрения заявки на производство от клиента.
Я создал модель, разделил все этапы работы на функции. Далее каждую из них мы с клиентами рассматривали с точки зрения процессов и возможности автоматизации. Например, выбиралась функция «Проектирование производства», и для нее выполнялась автоматизация.
Данную диаграмму в группе не критиковали, но я сам напишу что в ней не так с моей точки зрения.
В принципе, цель была достигнута, и диаграмма свою роль в этом сыграла. Но здесь я уже стремился сделать функциональную модель IDEF0. И с этой точки зрения диаграмма неправильная:
С другой стороны, несмотря на ошибки, диаграмма – рабочая. Проект длился около 2,5 лет, все этапы были автоматизированы успешно. В результате ответ на запрос о возможности выпуска продукции стал приходить не через 2,5 месяца, а в течение 10 дней, что для этого вида бизнеса – очень короткий срок. Были достигнуты и другие цели, в частности, опираясь на эту диаграмму.
Вывод: формально диаграмма неправильная, с точки зрения достижения цели – правильная.
На основе описанных примеров и их критики можно сделать следующие выводы:
Потому не бойтесь использовать любые варианты диаграмм, пользуйтесь теми инструментами, которые быстрее приведут вас к цели. Не бойтесь ошибаться, избежать ошибок может только тот, кто вообще ничего не делает. Ставьте перед собой ясную цель, и следуйте к ней с максимальной энергией. Что же касается критики, всегда найдутся те, кто будет вас критиковать. Не стоит относиться к этому с негативом. На самом деле, критики выполняют за вас часть работы по анализу вашей деятельности. Обращайте внимание на критику, учитывайте подобные замечания, они помогут вам развиваться и в будущем избегать тех или иных ошибок. Но не вся критика конструктивна. Потому любое замечание сверяйте с самым главным фактором – достижением цели. И если исправление ошибки поможет ее быстрей и проще достичь, принимайте с благодарностью.
Рамиль Кинзябулатов — бизнес-консультант с большим практическим опытом работы в России и в зарубежье (США, Италия, Германия). Автор многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса.
Рамиль является одним из первооткрывателей бизнес-моделирования в России с опытом работы бизнес-консультантом более 17 лет. Так же является автором перевода стандарта IDEF0 на русский язык под собственной редакцией.