Кейс. Как описать бизнес-процессы самому?

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

Шаг 1.

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

Для этого мы воспользовались системным оператором (СО). Системный оператор (рис. 1) включает в себя описание изучаемой системы, ее подсистем и надсистемы, куда изучаемая система входит в качестве элемента в настоящем, в прошлом и в будущем.

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

Рис. 1. Системный оператор.

1. НАСТОЯЩЕЕ.

1.1 Исследуемая система: бизнес-процессы.

Система бизнес процессов, особое внимание сквозным бизнес-процессам (затрагивающим работу 2 и более отделов или групп). Гибкость процессов.

Цитата: «Большинство компаний организованы по функциональному принципу, но они должны работать в условиях межфункционального взаимодействия. …Процессы ломают иерархическую структуру».

1.2. Надсистема.

Стратегический менеджмент, система сбалансированных показателей. Горизонтальное взаимодействие сотрудников. Бережливое производство, система менеджмента качества. Рынок, конкуренция. Частая смена обстановки, динамика среды. Изменения законодательства.

Цитата: «С точки зрения процессного подхода, организация предстает как набор процессов. Управление такой организацией основывается на управлении процессами. Каждый процесс при этом имеет свою цель, которая является критерием его эффективности. Цели всех процессов являются целями нижнего уровня, через реализацию которых достигаются цели верхнего уровня — цели компании».

1.3. Подсистемы.

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

2. ПРОШЛОЕ 30-е гг. 20 века.

2.1. Система.

Человек на рабочем месте, инструкции руководителей (именно «инструкции»).

Одной из самых известных методологий описания организаций как организационно-технических систем, стала методология структурного анализа и проектирования систем SADT (Structured Analysis and Design Technique) . Она была разработана американцем Дугласом Россом (D. Ross) в 1973 г. Особенно широкое применение получило одно из подмножеств SADT — методология функционального моделирования IDEF0 (Integration Definition For Function Modeling). Инициатором ее разработки и дальнейшей стандартизации было Министерство обороны США. Методология IDEF0 успешно применялась в военных, коммерческих организациях для решения широкого спектра задач (от разработки программного обеспечения для оборонных систем до разработки систем материально-технического снабжения и управления финансами). Наличие возможностей и опыт применения IDEF0 в различных предметных сферах, наряду с растущей компьютерной поддержкой, сделало ее еще более доступной в использовании. Это, в свою очередь, также привело к широкому использованию IDEF0 как методологии для описания бизнес-процессов организаций. Во многом популярность методологии функционального моделирования IDEF0 обусловлена простотой нотации, основными элементами которой являются функциональный блок и стрелка.

Также в СССР в начале 70-х годов в СССР внедрялась Комплексная система управления качеством продукции (КС УКП) . Управление основывалось на логике массового производства, экономии на масштабе, централизованном контроле, а также в результате низкой скорости изменений и быстрая потеря актуальности деятельности.

Наследованная от СССР система управления основана на концепции массового производства, доминировавшей во всем народном хозяйстве. Основная цель этой системы — получить экономический эффект от роста масштабов производства. Чем больше объем продукции, тем меньше затрат на единицу выпускаемой продукции. При этом легче стандартизировать и унифицировать процессы, а также проще осуществлять централизованный контроль. Такая система позволяла выпускать огромное количество ТРУ (товаров, работ, услуг), но чтобы что-то изменить приходилось потратить огромное количество ресурсов в связи отсутствием гибкости в управлении и процессах. В итоге, получилось, что на международной арене наши предприятия оказались неконкурентоспособными в силу отсутствия гибкости и невозможности быстро перестраиваться под потребности рынка.

3.2. Надсистема.

3.3. Подсистемы.

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

4. БУДУЩЕЕ.

4.1. Система.

Гибкие карты бизнес-процесса, интегрированные в CRM-системы и системы более высокого уровня (ERP-системы).

4.2. Надсистема.

Саморазвивающийся бизнес (компания), дальнейшее развитие LEAN , CRM-система, ERP-системы с интеграцией , .

4.3. Подсистемы.

Мгновенный доступ к самообновляющейся информации. Гибкая система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, автоматическая отчетность по показателям, гибкое управление эффективностью процессов. Автоматизация, роботизация, система развития компетенций, knowledge management .

Шаг 2.

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

Основные моменты, на которые необходимо обратить внимание при описании бизнес-процессов (результат применения системного оператора):

1. Что потеряли из прошлого (а это интересно и эффективно)?
2. Что изменится в перспективе? Что можно оставить без изменений, а в каких аспектах нужно заложить фундамент уже сейчас?
3. На что седует обратить внимание при разаработке алгоритма описания бизнес-процессов?

При анализе системы описания бизнес-процессов с помощью системного оператора мы увидели следующее:

1. Подсистемы: Быстрый доступ к информации. Система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, отчетность персонала, автоматизация процессов, управление эффективностью процессов. Мы видим, что бизнес-процессы должны иметь возможность быстро извлекаться из информационной среды, иметь высокую гибкость, иметь реперные точки, которые покажут, что изменится в надсистеме при изменении бизнес-процесса на уровне конкретной должности.
2. Стратегический менеджмент, система сбалансированных показателей. Бережливое производство, система менеджмента качества. Рынок, конкуренция… Относительная стабильность, постепенная, плавная смена обстановки (существенное отличие от НС «Настоящее» ).Действующее законодательство. При проектировании бизнес-процессов должна быть разработана система показателей: KPI (ключевые показатели эффективности) и управленческие индикаторы, по которым мы отслеживаем эффективность достижения KPI. Будущее показывает нам, что бизнес-процессы должны быть включены с систему управления знаниями, то есть должна быть разработана система показателей, завязанная на модель компетенций. Предусмотреть здесь отсутствие разрыва! Автоматическому сбору статистики по показателям следует уделить особое внимание, развивать культуру работы с цифрами, постепенно подготавливая систему управления к применению методов машинного обучения в будущем.

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

1. Учесть, что чувство времени у людей хоть и развилось со времен А.К. Гастева, но все же далеко от идеала, поэтому бизнес-процессы должны быть автоматизированы в CRM-системе с функцией автоматического уведомления, но в любом случае, перед тем как готовить ТЗ для CRM, куда в конечном итоге попадет описание БП, создается бумажный документ. Важно учесть, что пытаться все подряд регламентировать глупо, а в небольших компаниях такое внимание к администрированию чревато потерей бизнеса. Поэтому перед регламентацией процессов следует определить положение компании на S-кривой (удобнее всего по И. Адизесу) и исходя из этого назначить «масштаб» регламентации, то есть определить степень детализации процесса. Также важно определить степень свободы принятия решения сотрудника в изменении бизнес-процессов с целью повышения их эффективности. Как было указано выше, предусмотреть возможность оперативного изменения процесса, но с простановкой маркеров, какие из смежных процессов будут невольно затронуты. Следует предусмотреть разграничение прав доступа по изменению процессов.

1. Изучение успеха IDEF0 показывает нам, что для представления бизнес-процессов необходимо стараться максимально уходить от текстовых инструкций в пользу графики — инфографики, рисунки с короткими пояснениями. Если необходимо более подробное разъяснение, его можно дать в качестве примечания к соответствующему пункту инфограммы. Такие инструкции воспринимаются и запоминаются гораздо лучше, но здесь есть и подводные камни. Хорошая инфографика — лучший вариант с точки зрения восприятия инструкции пользователем, но у нее есть огромный минус в том, что рисовать схемы очень дорого и долго по времени. Не все сотрудники могут этим заниматься. Сегодня указанная проблема решена. В 2016 - 2017 годах происходит настоящий бум по интеграции графического отображения бизнес-процессов в CRM-системах согласно рекомендациям IDEF0. Отсюда понятно, что стоит обратить внимание на CRM-системы, обладающие именно такими возможностями и использовать их. При этом важно учесть мониторинг по показателям, указанным выше, разграничение прав доступа, сигнализацию по реперным точкам при внесении изменений.

1. Комплексная система управления качеством продукции (КС УКП) СССР может быть интересна только в случае масштабного реинжиниринга бизнес-процессов в крупных корпорациях. В остальных случаях к ней обращаться не стоит. Следует обратить внимание на принятый в компании стандарт обозначений и корпус понятий. Корпус понятий должен быть единым для всех в компании и максимально унифицирован с практикой, принятой в мире. «Переводы» терминов внутри компании слишком дорого обходятся. Поэтому вместе с разработкой бизнес-процессов следует заниматься стандартом, принятым в компании. Лучше сразу заложить стандартизованные понятия и обозначения, чем потом затратить уйму времени и сил на исправление.

1. При выборе CRM-системы и способа подготовки описания бизнес-процессов следует учесть быстрое изменение среды, система должна иметь возможность быстро вносить изменения, лучше — без привлечения IT-специалистов. В противном случае, динамика может быть потеряна, а БП превратятся в пустой хлам и перестанут работать. Следует не заниматься самописными программами, а использовать готовые системы с возможностью расширения, чтобы обеспечить обозначенные выше функции.

1. При описании БП следует учесть взаимодействие между подразделениями. Именно на стыке отделов происходит наибольший дефект коммуникаций, искажение информации и различного рода сбои. Рекомендации - см. выше. Дополнительно: при определении профиля личности место не рассматривать изолировано, а посмотреть в связке с подразделениями и владельцами процессов, с которыми бизнес-процессы переплетены наиболее тесно. Задачу решать на уровне мест, в свойства материала не уходить (см. рекомендации по схематизации)!

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

Шаг 3.

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

Рис. 2. Стадии развития компании по И. Адизесу.

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

• Цели деятельности;
• Системное описание бизнес-процессов (функциональной бизнес-модели бизнеса);
• Организационная структура предприятия;
• Должностные инструкции сотрудников;
• Системы управленческой отчетности;
• Регламенты деятельности (стандартизации);
• Процедуры управления стандартами;
• Механизмы контроля исполнения стандартов на предприятии.

Теперь мы можем описать требования к БП на каждом этапе развития компании в соответствии с выбранными критериями.

1. ухаживание:

Цели: во главе стоит идея и интуиция. Бизнеса как такового еще нет, но есть огромное желание реализоваться.

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

Организационная структура: отсутствует.

Должностные инструкции: отсутствуют, все рабочие отношения строятся на словах. Должностные обязанности не прописаны.

Отчетность: отсутствует. Руководитель не нуждается в отчетности, так как сам “полностью в теме”, а также отсутствует наработанная статистика. Работа в компании не организована должным образом, чтобы учитывать результаты для формирования отчетности.

Регламенты: отсутствуют.

Управление стандартами: отсутствуют.

Отсутствуют.

2. младенчество:

Цели: начинает зарождаться целеполагание, но оно строится не по методике SMART (SMART - это аббревиатура методики целеполагания и постановки задач. Расшифровка S.M.A.R.T.: Specific (цель должна быть конкретна), Measurable (измерима), Achievable (достижима), Relevant (быть релевантной, т.е. соответствовать деятельности и потребностям предприятия, уместной), Timed (определена во времени).

У руководителя не хватает навыка постановки целей и не достаточно рыночной информации, чтобы конкретизировать их. Цели звучат как лозунги: “быть №1 (или просто лучшими) в отрасли (нише)”, “занять максимальную часть рынка”, “стать лидером на рынке”, “добиться максимальной прибыли” и т.д. и т.п.

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

Организационная структура: делегировать руководитель еще не научился, да это и не требуется. В компании работают те, кого он как-то смог найти и удержать (родственники, знакомые…). На данном этапе характерно отторжение организационной структуры, каких-либо инструкций и регламентов. Коллектив — одна семья. Конкретные роли за сотрудниками не закреплены.

Должностные инструкции: отсутствуют. Все отвечают за всё, но никто не отвечает за что-то конкретное. Все друг другу помогают, компания делает все, чтобы не “умереть в младенчестве”. Все распоряжения отдаются устно.

Отчетность: отсутствует. Руководитель по-прежнему не нуждается в отчетности, так как сам полностью “в теме”, а также отсутствует наработанная статистика. Работа в компании не организована должным образом, чтобы учитывать результаты для формирования отчетности.

Регламенты: бизнес-процессы меняются со скоростью мысли, осуществляются бесконтрольно.Формализация бизнес-процессов невозможна.

Управление стандартами: отсутствует.

Контроль исполнения стандартов: отсутствует.

3. Давай-давай:

Цели: цели становятся более конкретными с приходом опыта, побед и ошибок. Становятся видны перспективы развития и накапливается статистика.

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

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

Организационная структура представляет собой один из двух вариантов. Первый — это “руководитель и все остальные”, либо второй — “все руководители” (количество сотрудников-специалистов в разы меньше количества начальников). Структурные подразделения созданы наугад, причем часто с многообещающими названиями. Руководители формальны. Без подчиненных.

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

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

Регламенты: руководители начинают ощущать потребность в создании регламентов деятельности и приступают создавать мини-инструкции, например, как правильно принять заявку клиента, упаковать продукт или построить разговор с клиентом (скрипты переговоров). Инструкции создаются интуитивно, носят характер затыкания “дырок” в работе (локальная стандартизация). Методика регламентации отсутствует.

Управление стандартами: регламенты не проходят в компании процедуры согласования и утверждения, спускаются “сверху” персоналу. Часто воспринимаются сотрудниками как дополнительная нагрузка и вызывают негодования по поводу того, что зачем это все нужно и так “все работают на все 100% и, не покладая рук”. Руководитель проводит стихийные обучения по мере выявления “косяков”. Считает, что сотрудники и так все должны сами знать и понимать самостоятельно.

Контроль исполнения стандартов: отсутствует.

4. юность:

Цели: цели на предприятии определяются в терминах SMART.

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

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

Должностные инструкции: существующие и/или не соответствующие должностные инструкции заменяют новыми, которые созданы самостоятельно в соответствие с бизнес-процессами предприятия.

Отчетность: создаются отчетные формы в соответствие с бизнес-процессами и их владельцами по интересующим руководителя показателям.

Регламенты: приходит осознание того, что бесконечно затыкать “дырки” невозможно и, что отдельными разрозненными регламентами проблему администрирования и стандартизации в масштабе компании не решить, требуется более системный подход к регламентации (стандартизации) бизнеса.

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

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

Контроль исполнения стандартов: с увеличение количества регламентов возникает потребность в регулярном контроле их исполнения (аудите).

5. Расцвет:

Цели: цели на предприятии определяются в терминах SMART с применением системы сбалансированных показателей (финансы, маркетинг, процессы, развитие персонала).

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

Возникает необходимость проведения аналогичной работы с постоянными поставщиками/подрядчиками.

Организационная структура: оргструктура компании стала более оптимальной, а именно: сбалансировалось количество структурных подразделений и бизнес-процессов, которые закреплены за ними. Оргструктура стала более “плоской”, ликвидированы лишние подчинения. Ответственность за бизнес-процессы четко закреплена за соответствующими руководителями.

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

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

Регламенты: процесс создания регламентов поставлен на регулярную основу. При этом в компании четко расставлены приоритеты и осознаются цели стандартизации каждого бизнес-процесса. Начинается осознанная автоматизация бизнеса.

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

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

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

Контроль исполнения стандартов: контроль исполнения начинает проводится в форме аудита в масштабе всей компании. Процесс контроля регламентирован.

6. Стабильность:

Цели: цели на предприятии определены в терминах SMART с применением системы сбалансированных показателей, создана система показателей эффективности деятельности компании. Цели и показатели каскадированы до каждой должности.

Бизнес-процессы: функциональная модель регулярная корректируется с целью оптимизации деятельности и достижения новых целей. Внедрена комплексная автоматизация бизнес-процессов на предприятии и у постоянных поставщиков/подрядчиков.

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

Должностные инструкции: корректируются и улучшаются с целью повышения качества работы персонала.

Отчетность: регулярно корректируется и дополняется создающими ценность показателями и аналитикой.

Регламенты: методиками стандартизации владеют все руководители предприятия и самостоятельно применяют инструменты в своей работе. Бизнес автоматизирован. Оптимизация процессов ведется в системе автоматизации. Самообучающаяся организация.

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

Контроль исполнения стандартов: ведется регулярное проведение аудитов.

7. Аристократия:

Цели: цели перестают пересматриваться и актуализироваться.

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

Организационная структура: не актуализируется. Все привыкли к существующему положению дел.

Должностные инструкции: перестают корректироваться с целью повышения качества работы персонала.

Отчетность: не корректируется и не дополняется создающими ценность показателями и аналитикой.

Регламенты: снижение активности компании в области стандартизации. Владение методикой теряется как навык. Бизнес-процессы и система автоматизации устаревает.

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

Контроль исполнения стандартов: качество проведения аудитов не контролируется.

8. охота на ведьм:

Цели: цели устарели, не актуальны.

Бизнес-процессы: потеря актуальности.

Организационная структура: бесконтрольно обрастает дополнительными должностями (раздувается штат) без согласованности с функциональной бизнес-моделью.

Должностные инструкции: перестают быть актуальными.

Отчетность: перестает быть актуальной.

Регламенты: стандартизацию перестают рассматривать как инструмент улучшения бизнеса и сервиса. Она превращается в инструмент реализации собственных амбиций без создания ценности. По сути, ее больше используют, чтобы максимально “отсечь” задачи, которые ставятся перед отделом, чтобы как можно меньше делать. Менеджмент занимается “перепиныванием ответственности” или как говорят офисные клерки, “футболом”. Начинается неуправляемый рост и потеря актуальности регламентации. Стандарты создаются по функциональному признаку и без ориентации на бизнес-модель компании.

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

Контроль исполнения стандартов: аудиты отменены.

9. Бюрократия:

Цели: цели устарели, не актуальны.

Бизнес-процессы: полная потеря актуальности и структуры бизнес-процессов.

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

Должностные инструкции: устарели, либо создаются без ориентации на бизнес-модель.

Отчетность: потеря актуальности, бесконтрольное сокращение объема отчетной информации. Уход работы “в тень”.

Регламенты: потеря контроля над процессами. Остановка процесса стандартизации и улучшения процессов. Регламенты создаются с нарушением методики самостоятельно руководителями без проведения рабочих групп (вовлечения персонала).

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

Контроль исполнения стандартов: отсутствует.

Шаг 4.

Это инструментальный шаг (берите и делайте).

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

При этом учтите следующее:

• Не забывайте определить положение вашей компании на S-образной кривой и прописывать БП, следуя рекомендациям шага 3. Это поможет вам не только корректно описать БП, но и расставить нужные акценты при управлении регламентированными БП.
• В ходе анализа описания БП с помощью системного оператора, мы выделили ряд важных моментов, которые также следует учесть.

Общий алгоритм описания бизнес-процесса, в соответствии с которым каждый из вас может выполнить задачу на шаге 4:

1. Определить положение компании на S-кривой;
2. Исходя из п.1, сформулировать цели описания БП, поставить акценты;
3. Сформулировать название процесса;
4. Провести работу над видением и целью БП;
5. Определить границы процесса (начало и конец);
6. Определить входы (ресурс) и выходы (результат) процесса в целом;
7. Назначить владельца процесса;
8. Определить состав и последовательность выполнения работ (создать цикл );
9. Определить действия , границы, входы и выходы каждого этапа;
10. Определить сроки каждого этапа;
11. Определить ответственных за каждый этап;
12. Оформить процесс документально (подготовить Стандарт).

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

Таблица 1. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (что должно входить в состав описания БП на различных этапах развития компании):

Сокращения:

Бизнес-процессы (БП)

Организационная структура (Орг.)

Должностные инструкции (ДИ)

Отчетность (Отч.)

Регламенты (Р)

Управление стандартами (Упр. ст.)

Контроль исполнения стандартов (КИС)

Таблица 2. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (кто должен прописывать БП):

Сокращения:

“-” отсутствует;

К — команда;

Ко — консультант (эксперт).

Литература:

1. Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем / Ицхак Калдерон Адизес — М.: Манн, Иванов и Фербер, 2014.
2. Найти идею: Ведение в ТРИЗ - теорию решения изобретательских задач / Генрих Альтшуллер - 3-е изд. - М.: Альпина Паблишерз, 2010.

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

Зачем описывать бизнес-процессы

Любое предприятие сталкивается в своей деятельности с различными потерями (времени, браком, недостатком управления, упущенными возможностями) и несет убытки.

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

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

Зачем это нужно?

1. Когда хаотичное представление о деятельности предприятия складывается в бизнес-процессы и формализуется на бумаге, становится кристально понятно, какие действия выполняются правильно и вовремя, какие нужно откорректировать, а от каких можно и вовсе отказаться. Становятся заметны точки – генераторы ошибок.
2. После формализации на бумаге становится проще их планировать, представлять «как должно быть».
3. У каждого бизнес-процесса есть владелец и каждое действие в нем закреплено за каким-либо сотрудником (группой). При обнаружении ошибки легко будет идентифицировать «виновного» и вместе предотвратить ее повторное появление.
4. По описанным бизнес-процессам в разы проще вводить в курс дела новых сотрудников. И даже если 60% команды сменится, угроза бизнесу будет минимальной.
5. Внедрение интегрированной информационной системы всегда сопровождается написанием бизнес-процессов.
6. Бизнес с описанными процессами несравнимо проще масштабировать. Открытие филиалов (), подразделений, партнерство, продажа франшиз – вам открыты любые возможности.

Что такое бизнес-процесс

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

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

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

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

Бизнес-процессы бывают:

1. Основные.
2. Вспомогательные.
3. Управляющие.

К основным относятся те, которые создают продукт (производится товар, оказывается услуга). Без их выполнения невозможно существование предприятия, поэтому их нельзя ликвидировать, только оптимизировать.

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

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

1. Составление годового бюджета.
2. Планирование денежных потоков.
3. Проверка потенциальных партнеров и т.д.

Они формируют значительную долю управленческих затрат, поэтому они должны быть проанализированы и приведены к оптимальному результату.

Как описывать бизнес-процессы

Начинать описание всегда нужно с составления списка функций «как есть» (то, что реально выполняется). И для предприятия, впервые столкнувшегося с процессным подходом, и для того, где часть процессов уже описана.

Список готовится в три шага:

1. Изучите (создайте) оргструктуру предприятия .
2. Для каждого подразделения запишите функции, дела, в выполнении которых оно участвует. Важно отметить, что для того, чтобы перечислить все процессы выполняемые сотрудниками, нужно с этими сотрудниками пообщаться лично. Только в процессе общения «тет-а-тет» можно получить адекватную картину.
3. Изучите список на предмет задвоения функций или пропуска каких-либо функций. Случаются ситуации, когда одну и ту же работу делают два подразделения, например, расчет KPI сотрудников отдела продаж делает Финансовая служба и сам отдел продаж. Бывает, что функция есть, а сотрудников, выполняющих ее нет.

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

Чтобы из пула функций сформировать бизнес-процессы, нужно определиться, по какому признаку их группировать. Главной целью бизнес-процесса является создание «готового продукта», удовлетворение требований пользователя. Если присмотреться, то целью каждой функции тоже будет создание определенного «продукта». Поэтому из функций создаются бизнес-процессы как показано на рисунке 1.

Рисунок 1 . Как создать из функции бизнес-процесс

Проделав эти действия, вы получите перечень:

• Бизнес-процесс 1 и далее функции
• Бизнес-процесс 2 и далее функции
• И т. п.

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

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

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

Рисунок 2 . Обозначение

Те процессы, которые можно выполнить параллельно, разместите выше и ниже основных.

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

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

1. Для этого на чистом слайде расположите вход и выход из процесса.
2. Разделите лист по горизонтали на области – роли участников.
3. По ролям участников расположите основные блоки – функции процесса. Сохраняйте последовательность выполнения.
4. Добавьте развилки и дополнительные функции.
5. Разместите на схеме документы, которые должны быть сформированы в ходе выполнения. Электронное письмо, excel таблица это тоже документы с точки зрения процесса.
6. Обозначьте используемые программы и базы данных. Желательно писать не название программы, а конкретный блок ПО (например, не 1С а Платежный календарь 1С и т.д.).
7. Добавьте показатели эффективности в процесс там, где они проверяются.
8. Свяжите полученную схему с другими процессами.

Проделав все эти действия, вы получите полную схему (см. рисунок 3).

Рисунок 3 . Пример описания бизнес-процесса

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

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

Первым этапом вы пишете бизнес-процессы «как есть», на втором этапе изменяете их на «как должно быть».

Как найти невыгодные бизнес-процессы

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

Смотрите пошаговый алгоритм, как действовать, чтобы найти и устранить неэффективные бизнес-процессы. Опытом делится финансовый директор производственной компании «СТАН».

Минусы описания бизнес-процессов

Помимо множества плюсов описание бизнес-процессов несет в себе и ряд минусов.

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

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

Третий минус – это длительность внедрения. Проект может занимать от 6 месяцев до 1 года.

Четвертый минус – сопротивление сотрудников и руководителей. Как и все проекты по повышению эффективности, внедрение процессного подхода приводит к оптимизации затрат предприятия, в том числе и к сокращению штата, и к повышению нагрузки на сотрудника.

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

• Описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
• Описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
• Описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

На Рис. 3 представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы нестандартным образом — не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

Тот факт, что название стрелки не зависит от документов, которые к ней привязаны, позволяет именовать стрелки на схеме максимально понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию под названием «Сформировать отчет по инкассации за день». (Заметим, что в методологии компании «СТУ» стрелка после операции процесса — это сущность, а не событие. После блока «Решения» можно показывать возможные результаты решения).

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

На Рис. 6 показан фрагмент схемы процесса, разработанный бизнес-аналитиками вполне конкретной компании в придуманной ими нотации. Схема построена с применением принципов «Простой блок-схемы » — применяется блок «Решение» в своем классическом варианте. Кроме этого, на схеме представлено множество других условных обозначений, использованных не совсем стандартным образом.

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Сегодня общим местом стал тот факт что бизнес-процессный подход к организации работы считается современным, инновационным решением, которое в случае внедрения помогает повысить качество работы и увеличить прибыль предприятия. О бизнес-процессах и системах работы с ними (BPMN, BPMS) я также уже писал и не один раз. Например, в статье «Что такое Бизнес процесс» я описываю основные понятия, особенности и преимущества этого подхода. А сейчас я решил поговорить о недостатках внедрения процессного подхода, о том, какой негативный эффект ждет компанию и ее сотрудников в случае реализации этого подхода.

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

Перед прочтением данной статьи настоятельно рекомендую ознакомиться с моими предыдущими публикациями по данной теме:

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

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

А потому я предлагаю договориться:

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

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

Как создается описание бизнес процесса

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

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

Немного о терминах используемых в данной статье

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

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

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

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

Нотация/бизнес нотация - язык описания бизнес процессов.

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

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

Зачем нужен приглашенный бизнес-аналитик?

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

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

Для составления грамотной нотации необходимы следующие составляющие:

1. Знание бизнес-анализа и умение работать с нотациями.
2. Информация о работе определенного процесса.
3. Требования по оптимизации: к какому результату стремится руководство компании.

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

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

Примеры

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

Пример 1. Автоматизация интернет-магазина

Очень распространенная ситуация – оптимизация работы интернет-магазина.

Изначально на обработке заказов работало несколько человек:

• Операторы, которые вручную переносили заказы, полученные с сайта, в систему учета.
• Складской работник, занимавшийся непосредственно отгрузкой заказов.

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

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

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

На практике оказывается, что ситуация далеко не столь радужная.

Если ранее количество заказов, поступавших к сборщику на склад, было ограничено скоростью работы людей-операторов, то теперь заказы формируются автоматически, практически мгновенно, и скапливаются «на складе».

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

Даже если нет негатива «сверху», человек и сам видит постоянный «завал», работать приходится больше, чем раньше. Конечно, частично это компенсирует повышение зарплаты. Но все равно из-за повышенной нагрузки копится усталость, в том числе, психологическая. Человек – не машина, он не может идеально работать изо дня в день без перерывов. У каждого человека есть определенный максимум – сколько заказов он способен обработать за смену.

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

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

Пример 2. Автоматизация такси

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

В результате можно прийти к следующей схеме:

1. Заказ такси – автоматически, через сайт или приложение без участия диспетчера.
2. Доставка клиента до места назначения
3. Оплата – автоматически, с банковской карты или интернет-денег после поездки на основе GPS-данных.

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

С одной стороны, все получается удобно и выгодно. Нет людей – нет случайных ошибок, затрат на создание рабочих мест и заработную плату.

С другой, если из цепочки полностью исключаются люди, то возникает множество рисков. Что будет, если программа водителя-автомата даст сбой, и человека отвезут не туда? А как робот будет реагировать в случае аварии, особенно, если по причине ДТП повредится какой-то аппаратный узел? А если преступники или террористы решат захватить и использовать робота-такси в своих целях?

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

Основные причины ошибок и проблем

Необходимо понимать что в процессе создания нотации любой бизнес-консультант старается по возможности упрощать нотацию, «сокращая» этапы и действия, которые с его точки зрения – не слишком важны и могут помешать пониманию картины в целом. Ведь он делает процесс который должен быть понятен потребителю и специалистам. Один из принципов так и звучит «Не следует множить сущее без необходимости»(так называемая Бритва Оккама).

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

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

К сожалению, в процессе работы по оптимизации бизнес-процессов обычно основной целью является не столько улучшение работы (как это должно быть), а в первую очередь – сокращение расходов. Руководство компании, обратившейся к специалисту по оптимизации бизнес-процессов, стремится снизить издержки. А это практически всегда означает – сократить штатную единицу. Обычно это звучит как «Уменьшение человеческого фактора».

Примеров подобных выше можно приводить еще много, все их объединяет несколько важных факторов, которые и приводят к печальным результатам:

• Недостаточная компетентность аналитика в вопросах работы конкретного бизнеса;
• Недостаточная компетентность руководителя в понимании бизнес-процессов и нежелание вникать в детали;
• Слишком большое доверие к графическим нотациям (они дают ту степень свободы, которая позволяет охватить процесс в целом и увидеть оптимальные решения, но не учитывают людей, которые в реальности выполняют функции “стрелочек” и “черных ящиков”);
• Излишнее доверие к технологиям (ошибка, свойственная многим современным людям).

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

Еще один важный фактор, который объединяет описанные выше примеры:

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

Простое решение проблемы: цените людей

Самый простой и очевидный выход – берегите сотрудников и относитесь к ним гуманно. Определите адекватные нормы работы, не исключайте полностью людей из бизнес-процесса, сократите им число функций, например, пусть они контролируют, проверяют и распечатывают документы или выполняют другие вспомогательные виды работы. Сократите им рабочий день, например, сделайте смены по 6 часов. Люди не будут переутомляться, будут успевать все делать вовремя, процесс будет под контролем.

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

Впрочем, это вам подтвердит любой опытный руководитель. Если вынудить человека работать 8 часов подряд без перерывов, то работоспособность его значительно падает. Вынуждать сотрудников работать «на износ» не только негуманно, но и, в большинстве случаев, не выгодно. Люди будут увольняться либо, в определенных случаях, вы будете вынуждены их увольнять, так как они начинают выполнять работу очень плохо, как говорят о таких сотрудниках, «выгорают». Придется тратить время и силы на поиск нового человека, его обучение, и так из раза в раз. Постоянные лояльные компании сотрудники принесут много больше пользы и стоить будут меньше, чем регулярно меняющиеся кадры.

Будьте осторожнее с технологиями

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

Вникайте в детали, особенно, если вы планируете на каком-то участке заменить человека программой. Убедитесь, что это не приведет к потере контроля или естественной регулировки нагрузки смежных подразделений. Не стоит «слепо» доверять современным программным и технологическим решениям просто потому, что мы живем в век массовой автоматизации.

Бизнес моделирование и IT-сфера

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

Подобный анализ помогает предложить и реализовать оптимальные варианты решений для работы различных организаций и отдельных подразделений.

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

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

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

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

Инструкция

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

Описать бизнес-процесс можно несколькими способами. Наиболее популярный из них - графический, с помощью , выполненных в различных нотациях (нотация - набор символов для обозначения чего-либо).
Самые распространенные виды нотаций для описания бизнес-процессов - это IDEF0, BPMN, EPC (ARIS) и др.
В качестве примера остановимся на диаграмме, выполненной в нотации BPMN (Business Process Modelling Notation) с помощью CASE-средства PowerDesigner (Рис.1). Главными элементами на диаграмме являются:
1. «Процесс» (функция) - скругленный по углам прямоугольник;
2. «Переход» - стрелка, соединяющая процессы;
3. «Решение» - ромб, содержащий вопрос, на который можно ответить только «Да» или «Нет»;
4. Условия - текстовые выражения, при которых осуществляется переход от функции к другой. Условия всегда заключаются в квадратные скобки. Иногда полезно разбить вашу на «Дорожки» - вертикальные или горизонтальные секции, обозначающие подразделения предприятия или сотрудников, ответственных за выполнение определенной функции. В таком случае этой функции должен находиться в пределах своей секции. Кроме перечисленных элементов, может содержать также перечень данных, которые являются входными или выходными для процесса, а также ссылки на правила или регламент, согласно которым выполняется та или иная функция. Пример описания бизнес-процесса «Контроль производства изделия» показан на рис.1. Нетрудно заметить, что эта диаграмма очень похожа на блок-схему алгоритма решения задачи.

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

Полезный совет

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

Источники:

• М.Рыбаков. Оптимизация бизнес-процессов.
• как составить бизнес процесс

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

Инструкция

Сперва вам необходимо описать суть процесса, иными словами - наблюдаемое вами качественное изменение. Например, загорелась, сгорела, погасла (суть события – процесс горения). Изменение может быть внешне видимым (целая спичка превратилась в стержень), измениться может структура объекта, система связей, в зависимости от того, что именно вы отслеживаете. В любом случае, описывая изменение, вам необходимо будет указать дополнительно время и скорость (например, спичка горела 20 секунд, скорость обугливания - 2 миллиметра в секунду). Иногда к этому добавляют такую характеристику процесса, как «цикличность» (происходит наблюдаемое вами изменение один раз или периодически).

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