Моделирование бизнес-процессов: доступно о сложном | Executive.ru

СОДЕРЖАНИЕ

Введение

1. Моделирование бизнес-процессов

2. Классификация бизнес-процессов

3. Стандарты моделирования бизнес-процессов

Заключение

Список используемых источников

ВВЕДЕНИЕ

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

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

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

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

1. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

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

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

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

моделирование бизнес-процессов — это эффективное средство поиска возможностей улучшения деятельности предприятия;

моделированиебизнес-процессов — это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;

моделирование бизнес-процессов — это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности [1].

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

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

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

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

Рисунок 1 — Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

изменение организационной структуры;

оптимизацию функций подразделений и сотрудников;

перераспределение прав и обязанностей руководителей;

изменение внутренних нормативных документов и технологии проведения операций.

Целью моделирования является систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации. Модель должна отражать структуру бизнес-процессов организации, детали их выполнения и последовательность документооборота [4].

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

существующая организационная структура;

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

структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

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

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

Детальная модель бизнес-процесса должна включать:

набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

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

диаграммы взаимодействия, отражающие схемы документооборота.

Бизнес-операция — совокупность действий, процедур, составляющих содержание одного акта бизнес-деятельности.

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

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

Бизнес-Модель — это то, что делает компания и благодаря чему она зарабатывает деньги (Том Мэлоун)

Бизнес-стратегия есть теория, бизнес-модель — гипотеза (Николас Карр)

Бизнес-модель — это представление набора связанных модельных элементов, определяющих внутреннюю и внешнюю среду компании в рамках единой системы [2].

2. КЛАССИФИКАЦИЯ БИЗНЕС-ПРОЦЕССОВ

Выделяют следующую классификацию [5]:

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

горизонтальные процессы – процессы, отражающие взаимодействие по горизонтали;

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

межфункциональные горизонтальные процессы – процессы, выполняемые многими работниками (организационными единицами);

вертикальные процессы – процессы, отражающие взаимодействие работников (организационных единиц) по вертикали;

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

В зависимости от степени их сложности выделяют:

монопроцессы – односложные процессы;

вложенные процессы — монопроцессы, входящие в состав более сложного процесса (макропроцесса);

связанные процессы – выделенные и последовательно реализуемые по определенному алгоритму монопроцессы.

В зависимости от их предназначения:

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

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

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

В зависимости от их места в иерархии целей организации:

бизнес-процессы верхнего уровня – процессы, направленные на реализацию стратегических целей компании, наиболее значимые для компании;

бизнес-процессы среднего уровня – бизнес-процессы, направленные на реализацию тактических целей;

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

В зависимости от степени их детализации [4]:

макропроцессы – укрупненные бизнес-процессы имеющие степень детализации необходимую чтобы описать бизнес-процессы верхнего уровня;


Перейти на главную страничку сайта (список статей, файлы для скачивания)

ФОРУМ (здесь можно обсудить эту статью, а также любые проблемы программирования на различных макроязыках и в скриптовых средах)

Содержание

Моделирование бизнес-процессов

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

Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации.

Описываем бизнес-процессы организации

Целью реорганизации может быть внедрение информационной системы, сокращение затрат, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций и т.п., а детальное описание процессов само по себе не представляет ценности. Реинжиниринг бизнес-процессов (англ. Business process reengineering) — это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимальной эффективности производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Бизнес-инжиниринг состоит из моделирования бизнес-процессов (разработка модели «как есть», её анализ, разработка модели «как надо») и разработки и реализации плана перехода к состоянию «как надо».

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

  • Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов – стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.
  • Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.
  • Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.
  • Прочие методологии.

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

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

Бизнес-модель — это формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов. Основная область применения бизнес-моделей — это реинжиниринг бизнес-процессов.

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

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

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

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

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

  • Определение целей описания.
  • Описание окружения, определение входов и выходов бизнес-процесса, построение IDEF0-диаграмм.
  • Описание функциональной структуры (действия процесса), построение IDEF3-диаграмм.
  • Описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм.
  • Построение организационной структуры процесса (отделы, участники, ответственные).

IDEF0

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

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

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

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

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

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

IDEF3

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

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

Типы связей IDEF3:

  • Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.
  • Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.
  • Нечеткое отношение (Relationship), пунктирная стрелка.

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

  • «И», блок со знаком &.
  • «Исключающее ИЛИ» («одно из»), блок со знаком Х.
  • «ИЛИ», блок со знаком О.

Если действия «И», «ИЛИ» должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно — одной.

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

DFD

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

Также, как и в других моделях, поддерживается декомпозиция.

Основными компонентами диаграмм потоков данных являются:

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

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

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

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

При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации.

ARIS

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы:

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, UML.

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

Основная бизнес-модель ARIS — eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты — «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.

Основные объекты нотации eEPC:

  • Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
  • Событие. Служит для описания реальных событий, воздействующих на выполнение функций.
  • Организационная единица. Например, управление или отдел.
  • Документ. Отражает реальные носители информации, например, бумажные документы.
  • Прикладная система.
  • Кластер информации. Характеризует набор сущностей и связей между ними.
  • Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.
  • Логический оператор. Оператор «И», «ИЛИ» или исключающее «ИЛИ», позволяет описать ветвление процесса.

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

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

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

Людоговский Александр

Перейти на главную страничку сайта (список статей, файлы для скачивания)

© 2007 http://www.script-coding.com При любом использовании материалов сайта обязательна ссылка на него как на источник информации, а также сохранение целостности и авторства материалов.

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

С чего начать

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

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

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

Виды бизнес-процессов

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

— К операционным относится все, что мы делаем регулярно. Это основа жизнедеятельности нашей компании — клиенты, маркетинг, производство (товаров и услуг), снабжение (делопроизводство, логистика), администрирование (АХД, поиск и подбор кадров).

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

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

Как описать процессы

Сама механика по описанию бизнес-процессов выглядит так:

1. Разделите все ваши направления на 3 рукава по типам. Для визуализации лучше использовать сервисы для создания карт.

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

3. Берите направления поочередно и делите его на шаги.

Пример

4. Каждый шаг распишите по схеме:

название шага — длительность — вход — выход — комментарии.

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

Пример

Описываем каждый шаг и этап. Это не быстро, но выполнимо.

Зачем компании нужны описанные бизнес-процессы

Что получает компания по факту хорошо выполненной работы:

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

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

Моделирование бизнес-процессов: доступно о сложном

У персонала есть четкая картина норма/час.

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

— Ясная картина для компании по устранению узких мест и последующих шагов развития. Например, разработка модели по работе с клиентом, автоматизация бизнеса в частности или полная.

В итоге у компании есть готовая база для оценки текущей ситуации и дальнейшей оптимизации деятельности.

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

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

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

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

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

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

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

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

Совет 2: Как описывать процессы

Бизнес процессы компании #8212; как правильно составить список процессов

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

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

«А у всех по другому…», «Ну так не принято…». «А почему так?», «А у нас за это другой отвечает…» #8212; примерно такие вопросы будут возникать и у вас и у вашей команды при подготовке списка процессов.

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

Еще раз. Создавайте свою модель бизнес процессов! К черту нормы! Делайте так, как удобно вам!

Бизнес процессы компани и подготовка полного списка

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

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

  • Подготовка макетов
  • Согласование макетов
  • Предпечатная подготовка
  • Подготовка ТЗ на изготовление печатной рекламы
  • Поиск типографий
  • Заключение договоров с типографиями
  • Документальное оформление заказов
  • Контроль исполнения заказов

Вы должны составить список всех дел (функций) которые происходят в отделе.

Далее необходимо проверить себя – не упустили ли вы что то.

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

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

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

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

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

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

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

Закончили? Переходите к следующему отделу. До тех пор пока у вас не будет согласованного списка функций всех отделов со списком дел всех сотрудников.

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

Построение системы процессов в среде Business Studio

Продолжение

Похожее

Источник: http://rzbpm.ru/knowledge/prosto-o-slozhnom-kak-pravilno-sostavit-spisok-processov-kompanii.html

Описание бизнес процессов

Понятие «бизнес» и «хаос» #8212; несочетаемые и недопустимо их совместное существование. Бизнес – это тщательно спланированный процесс, который руководится методом контроля и управления. Управление бизнес-процессом – это некое искусство, владея которым, вас ждут большие коммерческие взлеты.

Описание бизнес процесса

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

Существует три основных правила описания бизнес-процессов:

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

Переходим к пошаговой инструкции описания бизнес-процесса предприятия:

  1. Сначала определитесь с четкой и краткой формулировкой названия процесса. Это может быть «Обслуживание посетителя в кафе». В данном случае нам понятно касательно чего создан наш бизнес-план.
  2. Второй шаг описания бизнес-процесса заключается в определении точки «входа» и точки «выхода» в процесс. Таким образом, получается формулировка обслуживание посетителя в кафе от встречи до выставления счета.
  3. Следующий этап представляет собой определение цели процесса. В нашем примере, это может быть получение максимальной удовлетворенности клиента и максимально высокая прибыльность от каждого клиента.
  4. Очень важно к каждому этапу процесса назначить менеджера процесса, который бы исполнял управленческие функции и руководил.
  5. Обязательно определите «выход» из процесса, он может иметь как материальную, так и нематериальную форму. Материальный результат – это прибыль компании или кафе в нашем случае, а нематериальный – это максимально удовлетворенный клиент с широкой улыбкой на устах. Это два альтернативных «выхода», которые вы можете применить у себя в компании.
  6. Если существует «выход» с процесса, очевидно должен быть и «вход» #8212; это все те необходимые блага и материальные ценности, которые нужны, чтобы определенный процесс заработал.

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

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

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

Источник: http://business-ideal.ru/opisanie-biznes-processov

Источники: http://www.kakprosto.ru/kak-37858-kak-opisyvat-biznes-process, http://rzbpm.ru/knowledge/prosto-o-slozhnom-kak-pravilno-sostavit-spisok-processov-kompanii.html, http://business-ideal.ru/opisanie-biznes-processov

Комментариев пока нет!

Cистема бизнес-процессов

.

10 причин провала проектов по описанию бизнес-процессов

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

1. Невнятные цели и нечёткие сроки

Деятельность по описанию бизнес-процессов необходимо рассматривать как проект. А у проекта должен быть руководитель, этапы, чёткие сроки и конкретные измеримые задачи (цели). Само по себе «описание процессов» — не может являться конечной целью проекта.

Несколько хороших примеров постановки целей проекта:

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

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

Первично оценить выполнение таких целей достаточно просто (речь пока что не идёт об эффективности): вы либо сформировали набор документов, либо нет; требования к вакансиям либо определены, либо нет.

Примеры плохих целей:

  • Устранить узкие места в деятельности предприятия
  • Повысить конкурентоспособность предприятия на рынке
  • Улучшить взаимодействия между сотрудниками

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

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

2. Отсутствие вовлечённости руководства

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

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

3. Перекладывание ответственности на консультантов

Даже опытные руководители зачастую не желают вникать в нюансы, выделять и обучать специалистов, которые должны заниматься проектом описания бизнес-процессов на предприятии. Они рассуждают так: «Почему бы не поручить данную задачу консультантам или привлечённому со стороны бизнес-аналитику? Ведь они построили уже множество процессов и наверняка справятся с этой работой лучше нас».

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

Модель процессов строится не навсегда. Для наилучших результатов рекомендуется постоянно совершенствовать модель с применением цикла Деминга.

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

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

4. Недостаточный уровень зрелости предприятия

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

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

Какая мораль данного кейса?

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

5. Построение модели под конкретных людей (родственников/друзей и т.п.)

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

  • Перевести сотрудника на другую должность, которая соответствует его навыкам и личным качествам;
  • Оправить сотрудника на дополнительное обучение;
  • Уволить сотрудника;

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

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

6. Нежелание руководства делегировать ответственность

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

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

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

7. Саботаж со стороны наёмных сотрудников

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

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

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

8.

Перфекционизм и стремление к совершенству

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

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

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

9. Ложные надежды и ожидания

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

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

Как выстроить бизнес-процессы? Краткий экскурс в эффективный менеджмент

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

10. Нежелание обучаться/читать руководство пользователя и методики

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

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

Вывод: описывать или не описывать процессы?

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

Автор: Петров Дмитрий
Руководитель отдела разработки и совладелец
ГК «Фокс Менеджер»

Copyright © 2007-2018 Fox Manager. Все права защищены

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *