Моделирование бизнес-процессов может показаться скучной темой. Я надеюсь, что, прочитав данную статью, уважаемый читатель, уже имеющий свой бизнес, или решающий открыть свой бизнес, или разработчик it- продуктов, расширит горизонты своего понимания этой важной темы. Кроме этого, я вписал вкрапления в техническую терминологию своего личного эмоционального восприятия и историю познания этой темы, чтобы повысить интерес читателя. Данный формат статьи не имеет возможности разместить десятки схем, описывающих бизнес-процессы, их взаимосвязи и блок-схемы алгоритмов. Прошу представить, что они имеются, но возможно, это усложнило бы восприятие и значимость темы.
Первой причиной написания данной статьи стало желание автора поделиться своим опытом и авторскими приемами по построению, описанию, моделированию процессов на основании которых, существует, работает, добивается результатов любая организация (коммерческая, общественная, государственное предприятие, медицинская или научная организация и т.д.).
Вторая причина написания статьи— это наличие некорректного подхода многих потенциальных заказчиков к описанию бизнес- процессов, при разработке IT- технологий, регламентов в бизнесе. Часто собственники бизнеса, топ-менеджеры, разработчики-программисты, не обращают внимание на это, считая, что процессная модель бизнеса нужна только для бумаги («для галочки»).
«Ввяжемся в бизнес, а там посмотрим»- или «Начнем программировать, а там доработаем» - эта философия наблюдается мною в восьми компаниях из десяти. Хотелось бы в этой статье предупредить уважаемых читателей от пагубного нашего «российского авось», что построение современного эффективного управления бизнесом, не возможного без глубокого осмысления, формализации, детализации и декомпозиции бизнес-процессов.
Представим строительство высотного здания или даже простого дома без архитектурного плана, чертежей, расчетов. «Извините, уважаемый, - спрашивает хозяин дома у прораба- строителя- А почему для того, чтобы пройти на второй этаж по лестнице я должен на карачки встать?» Смешно? Но именно так часто происходит при отсутствии понимания необходимости процессной модели бизнеса.
Описание бизнес-процессов, как они существуют в компании сегодня (As is) и моделирование БП как должно быть (To bi), позволяет компаниям минимизировать затраты, убрать лишний персонал, повысить эффективность каждого менеджера, повысить качество продукции и точность операций, проанализировать и внедрить взаимосвязанность и прослеживаемость всех процессов, убрать зацикленность, ненужный дубляж и тупиковые процессы, реализовать конкурентные преимущества, и в итоге достигнуть тактических и стратегических целей в бизнесе.
Понятие бизнес-процессы (БП) относится к коммерческим организациям, которые действуют в условиях рынка и выстраивают свой бизнес в конкурентной среде. Построение процессов важно для любой организации для того, чтобы управление организацией было эффективным. В данной статье мы не будем рассматривать весь спектр оценочных параметров эффективности управления, а остановимся на понимании, что любая бизнес-организация имеет свои KPI (Ключевые показатели эффективности (англ. key performance indicators, KPI) — это числовые показатели деятельности, которые помогают измерить степень достижения целей или оптимальности процесса, а именно: результативность и эффективность. Детализацию, важность и как работают KPI в рамках общей системы мотивации автор опишет в отдельной работе. Общие подходы, место системы мотивации и бизнес-процессов автор описывает в статье «Программа для бизнеса КОМП- КАМП (http://proza.ru/2022/09/05/1322)
Для более четкого понимая, что такое БП, напомню уважаемым читателям два «скучных и заезженных понятия», без которых будет тяжело воспринимать управление своим бизнесом.
Субъект управления – это предприниматель, его команда, или группа отделов, или даже управляющая компания, которые занимаются эффективным управлением производственными, торговыми, логистическими и т.д. компаниями, которые производят конечный продукт, товары или услуги. Субъект управления осуществляет эффективное управление бизнесом, т.е. объектом управления. Я надеюсь, что вы поняли различие и взаимосвязь с Субъектом управления (Управляет) и Объектом управления (находится под управлением).
И когда мы описываем БП важно понять, что мы обязаны воспринимать, моделировать Управляющие БП и Управляемые БП. Типовой пример в движении самолета, когда летчик (или автопилот) является субъектом управления, а самолет с пассажирами является объектом управления. Слово «пассажир» на бизнес-сленге не очень хорошее понятие. И если рассмотреть любую компанию, которая активна на рынке, любой сотрудник должен гармонично быть вписан в общий бизнес-процесс компании, а не быть «пассажиром», только наблюдающим за полетом.
Пришло время дать более четкое определение бизнес- процесса (БП). Прошу не путать описание БП со схемой алгоритма БП, хотя из модели БП вытекает вся логика детализации алгоритмических схем (блок-схем). Есть несколько типовых определений, которые связаны с различными принятыми стандартами или нотациями описания БП. Для более полного отражения процессной (функциональной) модели организации (бизнеса) и бизнес-процессов в США в конце 70-х годов была предложена и реализована Программа интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing), направленная на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.
«Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология моделирования IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем. Общая методология IDEF состоит из трех частных методологий моделирования, основанных на графическом представлении систем»
По мнению автора статьи методология (нотация) IDEF0, представляющая графический язык описания (моделирования) систем и ее бизнес-процессов, до сих пор является наиболее эффективной, с широкими возможностями, позволяющими осуществлять декомпозицию от общей логики процессов до необходимого уровня детализации, а так же возможность реализации и описания БП для группы разработчиков-программистов.
Описание методологии IDEF0 содержится в государственных рекомендациях по стандартизации Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».
В рамках этой методологии БП– это действие, которое осуществляется, инициируется входной информацией и (или) входными ресурсами и в результате их обработки БП выдает выходную информацию и (или) измененные (доработанные до необходимого уровня) материальные потоки. На БП влияют общая информационная среда-Управление (законы страны, рыночная обстановка, регламенты компании, отраслевые стандарты, управляющие воздействия и т.д.) и наличие у субъекта и объекта управления необходимых ресурсов- Механизмы (постоянных активов- станков, зданий, складов, техники; переменных активов- денежных средств, запасов сырья, материалов, товаров; опытного персонала, it-технологий, и т.д.)
IDEF0 как стандарт был разработан в 1981 году департаментом Военно-воздушных сил США в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).
Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того, существуют правила сторон:
• стрелка входа всегда приходит в левую кромку активности,
• стрелка управления — в верхнюю кромку,
• стрелка механизма — нижняя кромка,
• стрелка выхода — правая кромка.
Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того, чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку. ( https://ru.wikipedia.org/wiki/IDEF0)
Когда состоялось мое личное знакомство со стандартом IDEF0? Итак, уважаемый читатель, в 1981 году данная методика появилась в ВВС США, и надо же так случится, что я после окончания высшего военного инженерного училища по специальности АСУ в 1984 г. был направлен в секретный военный НИИ, вместе с группой «отличников». Нам была поставлена очень дерзкая (другого слова не подберешь) задача – разработать за полгода современный комплекс программного обеспечения, позволяющего…(извините, секретно)…управлять тем, от чего сухопутных войск НАТО не осталось бы, в случае начала войны.
Когда нас молодых лейтенантов вызвал к себе в кабинет высокий, красивый профессор-полковник и объявил, что каждому из нас выдается персональное задание по автоматизации и разработке программного комплекса, и что на это дается полгода. Мы молча восприняли это как приказ (офицер-профессия героическая!), до конца не понимая сложность, необходимое время для программирования и как вообще, это сделать.
Мы все были классными программистами, но с проектированием сложным программных комплексов столкнулись впервые.
Когда до меня дошла очередь отвечать на вопрос нашего руководителя: «Ну что, лейтенант, справишься? И что для этого нужно?»
- Товарищ полковник, справляюсь! Мне нужно десять программистов-, ощущая по своей развитой интуиции: проси больше, дадут меньше, ответил я.
- Тебе в группу дадим еще двух программистов- «отрезал» полковник.
Почему я привожу этот пример из своей начальной практики программирования? Прошло с того момента почти 40 лет, и подобные диалоги о неопределенных сроках, необходимых ресурсах и стоимости на разработку программных продуктов, остались почти сегодня такими же. Появились более современные языки программирования и сверхмощные компьютеры, креативные программисты «с полтычка» разрабатывающие и внедряющие сложные программы, правда потом еще тратящие столько же времени, иногда и больше, на доработку. И при этом проблемы отсутствия комплексной проработки и описания процессов (процессная модель), на ее основе детальной разработки блок-схем (алгоритмов), остались в 80% случаев неизменными. Некоторые разработчики программного обеспечения (ПО) даже открыто кичатся – мы разрабатываем без технического задания (ТЗ).
Привожу недавний диалог с руководителем одной из групп разработчиков ПО:
- Вы сможете разработать ПО для данной модели нейро-гарнитуры, позволяющей переводить сигналы ЭЭГ в звуковые сигналы с определенным звуковым рядом? – мой вопрос.
- Да, сможем! Примерно год работы. Но Вы представляете, что стоимость будет цифра с шесть нулями? – ответ и вопрос разработчика.
- А как же вы определи сроки и стоимость разработки, если Вы даже не получили исходных данных для ТЗ и описание основных процессов?
- …., а зачем нам ТЗ?
Вернемся к моему первому опыту знакомства с методикой IDEFO. Столкнувшись с проблемой проектирования сложного программного комплекса, я просто не понимал за какую ниточку дернуть и с чего начать. Хорошо, что имелось первичное понятие о структурном программирование (об этом было несколько лекций в военном училище), но дальше не двигалось. Как сделать взаимосвязь входной и выходной информации с учетом сквозной связи через весь программный комплекс.
Время шло, вопрос уже не стоял- разработать через полгода. Каждый из нас разрабатывал отдельные программы, которые надо было совместить. Комплекс рушился как карточный домик.
Если что- то не получается, значит ты плохо информирован, я углубился в научную библиотеку. Моя неплохая математическая подготовка позволила обновить данные в голове об «агрегативном подходе при моделировании». При агрегативном подходе модель представляется в виде нескольких взаимосвязанных математических объектов – агрегатов, отображающих различные части моделируемой системы и внешней среды и задаваемых в виде устройств, преобразующих поступивший на него входной сигнал в выходной сигнал и изменяющей своё состояние. По этому принципу работают и микросхемы.
Это был военный НИИ, и библиотека имела самые свежие секретные материалы из-за рубежа, «случайно» оказавшиеся у нас. И надо же я натолкнулся на схему, описывающую процессы проектирования и разработки военной техники в одной из структур США в стандарте IDEFO, с учетом детальной декомпозиции процессов. «Эврика!»
Мне потребовалось около двух недель описать на больших склеенных листах весь программный комплекс в стандарте IDEFO, и еще около месяца детальное описание блок-схем алгоритмов. Да, тогда не было еще программ описания в данной нотации, но подход сработал. Я смог со своей группой программистов спроектировать комплекс программ, состоящий почти из 500 отдельных программ. Отладка, «прошивка» и испытания ПО еще заняли дополнительное время, но ПО работало.
C начала получения задания до запуска и приемки ПО очень высокой комиссией прошло 4 года! И если бы изначально я и мои коллеги-офицеры владели данной методикой, мы могли бы сделать ПО за полтора года.
Прошли годы. Вскоре прекратил существование Советский союз, пришлось получать и накапливать опыт в бизнесе, но полученный опыт системного подхода и построения бизнес-процессов не прошел даром. Вот одна из зарисовок: «Опыт разработчика программного обеспечения очень пригодился. В короткий срок я нашел двух «сумасшедших парней-программистов», заточенных на творчество, которые через 6 месяцев по моему техническому заданию написали первую версию учетной системы управления дистрибуцией. С помощью этой программы я смог многое контролировать. Моя компания стала желательной не только для «Марса», но и для многих западных компаний рынка FMCG, которые искали дистрибутивные компании по «западному типу», а находили на тот момент на рынке только оптовиков.» (http://proza.ru/2022/03/11/1640)
И что сегодня?
Если Вам нужна оптимизация бизнес-процессов, дальнейшее внедрение (корректировка) CRM (Битрикс24, AMO,…) и ERP -1С,… без построения процессной модели не обойтись. Вы потенциальный Заказчик и Вы испытываете потребность в синхронизации процессов нескольких направлений, бизнесов, компаний, сделать более эффективные продажи, повысить точность логистических операций и прочее. Вам необходимо поставить управляемость, прозрачность бизнеса на новый уровень, ввести новые компьютерные технологии и получить в итоге финансовый эффект от всего этого.
Если Вы на отдыхе, дома или в офисе, то для того, чтобы оценить результаты бизнеса вашей компании или группы компаний, после открытия экрана ноутбука, Вам потребуется не более 10 сек. Далее только уточнение деталей (Где «просели»? На чем? Кто виноват?)- еще 30 сек. У Вас всегда под рукой оперативная и точная информация, Вы всё и всех контролируете, и для этого Вам не нужно как прежде тратить огромное время и нервы. И такой же сервис запускаем на каждом уровне компании, где каждый сотрудник управляет своим процессом.
Работа состоит из нескольких этапов. Формализуется в специальных схемах, с учетом нотации (использую BPWIN, EDIF0) процессную модель: «As is- как есть» и «To bi - как должно быть». Выбираются основные дизайны «дашбордов», которые будут отражать необходимую контрольную информацию для управления бизнес-процессами. Далее разрабатываю ТЗ с детализацией алгоритмов (BPMN, Microsoft Visio) , до уровня понятного каждому программисту. Разрабатываются необходимые регламенты для компаний, подразделений, сотрудников.
Далее внедряем CRM (Битрикс-24 или AMO) и 1С.
Кажется, все просто, но это надо уметь и очень любить!
Александр Цуварёв.