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

Как только вы столкнетесь с процессным подходом, вам потребуются навыки моделирования бизнес-процессов.

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

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

После долгих поисков метода работы по проекту я в конечном итоге я пришел к тому, что наиболее близкой мне является методология IDEF и BPMN. Когда я начал изучать эти инструменты IDEF уже существовала многие годы, а BPMN только набирала популярность. За 15 лет я глубоко изучил эти инструменты, и теперь решил поделиться своими знаниями с читателями.

Я расскажу, как на практике пользоваться BPMN, когда и почему нужно пользоваться этим инструментом. Поговорим об истории вопроса. Отдельно я расскажу о распространенных заблуждениях, с которыми сам не единожды сталкивался на практике. И обсудим очень важную тему – что не нужно делать, т.е. поговорим о тех ошибках и «граблях», на которые наступают практически все, кто начинает заниматься моделированием бизнес-процессов, и которых можно избежать, если знать о них заранее.

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

Если говорить о BPM, как о конкурентном преимуществе, здесь самое главное – скорость внедрения новых технологий и принципов работы. В своих публикациях я не раз повторял, что бизнес-консультант в современных условиях – это обязательно IT-специалист, т.е. специалист по внедрению информационных систем. Сейчас невозможно себе представить работу организации без использования IT-систем, это просто анахронизм.

Даже если руководитель бизнеса не считает нужным работать с компьютером, что сегодня в наших реалиях еще иногда встречается, сама организация все равно использует различные IT-системы. Иначе бизнес просто неконкурентоспособен.

На практике я понял, что скорость внедрения – очень важна, в первую очередь, для меня, как для бизнес-консультанта. Если над каждым проектом работать месяцами, это будет штучный товар, который вы каждый раз создаете, по сути, с нуля. Поначалу я и сам так работал. Но потом понял, что на самом деле, внедрение IT-системы возможно успешно реализовать за 2—3 недели. Причем, мы выполняли такую работу для сравнительно крупных компаний, в которых работает более 100 человек. Само собой, это выгодно мне, как бизнес-консультанту, привлеченным IT-специалистам. Но это также выгодно бизнесу.

И здесь BPMN оказалась тем самым инструментом, который помогает закрывать проекты быстро и одновременно качественно. Как это реализовать на практике, читайте в книге.

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

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

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

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

Моделирование бизнеса. Основные подходы

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

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

Основные подходы

Сегодня существует множество различных инструментов для разработки бизнес-моделей, они используют различные языки моделирования, как стандартные, так и какие-то собственные разработки. Но все их можно объединить по принципу работы в три основных подхода:

– Функциональный;

– Процессный;

– Ментальный (с применением ментальных карт).

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

Функциональное моделирование

Пример функционального моделирования в формате IDEF0

Функциональное моделирование рассматривает деятельность в организации через призму функций (лат. functio – совершение, исполнение). В функциональной модели функция не имеет временной последовательности, а только точку ввода и точку вывода.

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

Например, компания разрабатывает CRM-систему для своего бизнеса. В случае применения функционального подхода к моделированию уже сама выбранная среда для работы подсказывает, с чего начинать. Точка ввода – «вводящий интерес клиента или лид», точка вывода – желаемый результат: «покупка и получение лояльного клиента», «получение постоянного клиента», «получение максимум информации о потенциальном клиенте» и т. д.

Таким образом, в функциональной модели изначально известны точка ввода и желаемый результат, а последовательность действий и является объектом разработки. При этом использование функциональных моделей как «черных ящиков» позволяет детализировать каждый этап по мере необходимости. А вся работа при моделировании направлена на поиск оптимального решения для достижения цели.

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

Процессное моделирование

Пример процессного моделирования в формате BPMN

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

Процесс с точки зрения бизнес-модели – это последовательность событий и действий, которые имеют начало и конец. В этом кроется основное отличие процессного моделирования от функционального. Функциональное моделирование рассматривает бизнес-модель с точки зрения ввода и вывода (имеющихся ресурсов и желаемого результата). А процессное основано на последовательности действий в определенных границах, в случае BPMN это будут начало и конец события. Все процессы могут разбивать (детализировать) на подпроцессы вплоть до задач, т.е. действий, дальнейшая детализация которых невозможна.

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

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

Есть и еще одно очень важное отличие. Функциональную модель невозможно использовать при реализации какой-то либо системы, только для проектирования. А процессный подход позволяет создавать исполняемые модели, т.е. описания последовательности действий, которые мы можем в дальнейшем перевести в какую-то среду для создания системы совместной работы предприятия, основанной на процессном подходе.

Ментальный подход (ментальные карты)

Пример ментальной карты

При создании ментальных моделей специалист подходит к моделированию не как к процессу или набору функций, а как к некому набору связанных между собой понятий. Для наглядности я приведу пример – ментальная карта понятия «Процедура снабжения» (см. рисунок). Такой вариант подхода применяется, прежде всего, для себя. Рисование схемы в свободной форме помогает структурировать свои знания, так сказать, «разложить по полочкам» в свободной форме полученную информацию.

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

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

– Не нужно знать какие-то специальные языки;

– Нет строгих рамок и ограничений при создании схемы;

– Ментальная карта в большинстве случаев интуитивно понятна;

– Создавать такие схемы просто.

Минусом подхода является отсутствие устоявшегося подхода и стандартизированной методологии. Если в нотациях функциональных и процессных имеется некоторая вариативность, но все же она ограничена строгими рамками языков моделирования, то ментальные карты создаются в произвольной форме. И даже специализированные программы для их создания также почти не ограничивают человека в процессе моделирования. Т.е. какие-то правила могут вводиться в рамках определенного программного продукта, но стандарта не существует. В результате для понимания модели и заложенных в ней идей требуется присутствие и комментарии ее разработчика (аналитика).

Бесплатный фрагмент закончился. Хотите читать дальше?