Ключевые бизнес процессы пример

В чем цель автоматизации? Какие виды процессов существуют в BPM? Как границы процесса создают конкурентное преимущество компании? Как не надо проводить в компании проект внедрения и моделирования процессов? Внедрение BPM как таковое вообще нужно?

Разложили по полочкам основное о процессах.

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

Чтобы начать разговор про бизнес-процессы, сначала надо разобраться, что такое BPM.

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

Из книги BPM CBOK 3.0

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

Из книги «Моделирование бизнес-процессов в нотации BPMN» Владимира Репина

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

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

Из книги BPM CBOK 3.0

Другими словами, BPM сводит воедино стратегию, цели, культуру и структуру организации: регламенты, нормативы, методологии и инструменты.

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

Из книги BPM CBOK 3.0

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

Рассмотрим два вида человека-заказчика: внутренний и внешний.

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

Но где бизнес-процесс начинается и, что важнее, должен заканчиваться, согласно BPM?

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

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

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

Как определить границы процесса в BPM и почему это важно

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

Для примера рассмотрим бизнес-процесс закупки в разных компаниях.

• Компания №1.
  В компании №1 бизнес-процесс закупки заканчивается по факту проведения тендера. Результат (ценность) процесса: протокол выбора конкретного поставщика.
• Компания №2.
  Компания №2 зашла чуть глубже в выстраивании цепочки получения ценности. Для нее процесс закупки заканчивается подписанием договора с поставщиком. В этом случае результат (ценность) — это договор, по которому поставщик выполнит поставку.
• Компания №3.
  Компания №3 пошла еще дальше. Там посчитали, что бизнес-процесс закупки заканчивается в момент исполнения обязательств поставщиком. Результат (ценность): поступление материалов на склад / получение активов / выполнение услуги.

Вероятно, кейс Компании №3 самый полный, так как его ценность на порядок выше конкурентов из Компаний №1 и 2. Однако дробление сквозного процесса в организации на более мелкие части имеет смысл в случаях, когда важно измерять эффективность процесса по мере его прохождения и разделять зоны ответственности по разным руководителям. То есть в случае дробления владельцами отдельных процессов выступают руководители среднего звена, когда в Компании №3 владелец процесса — это высокоуровневый топ-менеджер организации, который отвечает не только за закупку, но и за работу склада, оприходование материалов и подписание договоров.

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

Схема бизнес-процессов в организации

Схема бизнес-процесса в организации или другими словами — архитектура бизнес-процессов организации.

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

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

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

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

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

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

Из книги APQC PCF, автор перевода на русский язык компания ELMA

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

Ценность основного процесса формируется на протяжении всей цепочки создания ценностей. Одно дело, если компания произвела продукт, и он лежит на складе, а другое дело, когда этот продукт находится на полке магазина. Человек готов переплатить, нежели ехать на склад.

Приведем несколько примеров бизнес-процессов построенных в системе ELMA365:

Рекомендации при создании схемы бизнес-процессов в организации

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

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

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

Моделирование процессов — это создание статических и динамических визуальных иллюстраций.

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

Моделировать бизнес-процессы — необходимо. Но почему? В чем ценность и цель? Проект описания на самом деле достаточно ресурсоемкий и его стоимость в средней компании может в прямых или косвенных издержках стоить несколько миллионов рублей. А продлиться — от 3 месяцев до 1 года.

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

1. Самая очевидная цель — это автоматизация. Перевод процесса в исполняемый вид внутри автоматизированной системы. Внутри компании процесс может функционировать и без ИТ-системы, он будет «прописан» в головах сотрудников. Соответственно процесс точно будет иметь узкие места, повторяющиеся действия с лишней коммуникацией и обилием рутины. Отсюда вытекают вариативность временных слотов на одну и ту же задачу и непредсказуемость результата. Важность автоматизации сложно переоценить.
2. Улучшение процесса. Прописанный процесс легко улучшить — это ценность. Это хорошая практика, потому что бизнес-процесс — это один из активов компании, за счет отлаженных бизнес-процессов можно создать конкурентное преимущество. Самый простой пример: конкуренты обрабатывают заказ за неделю. А что будет, если вы будете это делать за 3 дня? Обгоните ли вы конкурентов? Какую дополнительную прибыль вы получите? В BPM-системе автоматизация и реинжиниринг (улучшение) процесса могут идти параллельно — это ценность. Другой инструментарий цементирует процессы, забирает гибкость. На это бизнес, как правило, не идет. Если есть цель сделать структурный бизнес-процесс автоматизированным и при этом гибким, то есть иметь возможность менять его быстро и без дополнительных затрат, стоит использовать BPM-систему.
3. Оптимизация процесса. Ключевые преимущества, которые дает оптимизация:
4. снижение себестоимости прохождения процесса;
5. ускорение процесса;
6. повышение ценности для конечного потребителя.

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

Рекомендация по моделированию бизнес-процессов

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

Примеры бизнес-процессов

И почему их тут не будет.

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

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

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

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

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

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

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

«Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»

Источник: elma365.com

Описание бизнес-процессов: методы и инструменты

10 июля 2019

Описание бизнес-процессов: методы и инструменты

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

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

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

Определение и суть бизнес-процессов

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

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

Бизнес-процессы – это взаимосвязанные и последовательные действия, отвечающие следующим опциям:

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

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

Постановка бизнес-процессов на предприятии состоит из нескольких этапов (см. рисунок 1).

Рисунок 1. Этапы постановки бизнес-процессов на предприятии

Недооценка любого из этапов делает бессмысленным проект постановки бизнес-процесса.

1. Выявление и документирование процесса. Важно проанализировать текущую ситуацию, прежде чем приступать к изменениям. В результате этого этапа должна появиться модель «AS IS» (как есть), выявлены узкие места и потенциал возможных изменений.
2. Анализ процесса проводится до и после его внедрения. Этот этап определяет необходимые изменения, инструментарий и ресурсы.
3. Описание бизнес-процесса дает полную информацию по планируемым изменениям. Результатом этого этапа должен стать задокументированный план, обязательный к исполнению. На практике этот этап ошибочно принимают за завершающий. И тогда документ, описывающий процесс, становится «неработающим».
4. Реализация – это исполнение принятых решений. Во время этого этапа формируется дополнительная информация об эффективности бизнес-процесса в целом, его участников и ключевых этапов. Информация, генерируемая в процессе реализации, способна поддержать и усилить конкурентные преимущества компании на рынке.
5. Контроль остается самой недооценённой частью задачи постановки бизнес-процесса. Без последующего контроля и анализа действующих процессов, весь проект по внедрению окажется неэффективным. Недооценка этого этапа отчасти оправдана тем, что от процесса ожидается его самодостаточность. Механизм внедряется для экономии времени и ресурсов. Но любой процесс продолжает требовать внимания.

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

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

Методологии и инструментарий описания бизнес-процесса

Важным, но непринципиальным моментом является вопрос выбора инструментария для описания бизнес-процесса. Эффективность инструмента определяется гибкостью и простотой применения, а также способностью учитывать все парадигмы описания деятельности предприятия. В современной методологии управления чаще всего упоминается инструмента описания бизнес-процессов: BPMN 2.0 (Business Process Model and Notation). Его отличают:

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

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

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

Рисунок 2. Пример графического описания бизнес-процесса в рамках нотации BPMN 2.0

BPMN 2.0 – это своего рода баланс между легкостью восприятия и сложностью описания бизнес-процесса. Инструмент находится в свободном доступе на сайте Object Management Group.

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

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

В литературе и практике встречается несколько видов классификаций. Чаще всего процессы классифицируют по следующим группам:

• основные,
• вспомогательные,
• управленческие.

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

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

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

• выбор направлений развития компания;
• контроль за исполнением поставленных задач.

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

Участники

Участников группируют по-разному, но так или иначе, следующие роли присутствуют во всех методиках:

1. Владелец.
2. Менеджер.
3. Исполнитель.
4. Аналитик.
5. Инженер.

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

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

Кроме разделения по ролям, участников разделяют по степени контролируемости или простым языком – по месту работы.

Внутренние – сотрудники компании, ответственные за выполнение задач.

Внешние – участники, неработающие в компании. При этом они влияют на ход исполнения задач, стоящих перед сотрудниками компании.

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

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

Практика работы с бизнес-процессами

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

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

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

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

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

2. Не стоит внедрять процесс, не имея инструментария и ресурсов для контроля за его исполнением.

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

4. «First things first». Основное внимание следует уделять основным процессам. Если есть критичные сложности в основных, эффективность вспомогательных процессов не будет давать никакой добавочной стоимости.

5. Все участники должны быть осведомлены и мотивированны. Каждый сотрудник должен хорошо представлять:

• свои задачи;
• сроки для исполнения задач;
• формулу и способы измерения результата;
• вознаграждение в случае успешного выполнения поставленных задач.

6. При описании бизнес-процесса используйте простые и распространенные определения. Задача описания процесса – сделать его понятным для целевой аудитории. Самовыражение желательно оставить для других задач.

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

8. «Лучшее – враг хорошего». Оптимизация бизнес-процессов – это цикличная задача, но процесс оптимизации не следует делать вечным. Если же процесс «сбоит», то можно использовать стандартные методы:

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

9. Разные уровни описания. При выборе глубины описания следует ориентироваться на его пользователя. Описание для сотрудника IT подразделения, для исполнителя и для сотрудника генерального директора должны иметь разную глубину.

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

Выводы

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

При этом учитывается способность инструментария автоматизировать процессы. Язык BMPN 2.0 является одним за наиболее популярных среди языков, используемых для описания.

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

Источник: upr.ru

Ключевые бизнес процессы пример

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

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

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

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

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

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

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

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

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

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

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

Как выделить ключевые бизнес-процессы?

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

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

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

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

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

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

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

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

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

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

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

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

Затем каждый бизнес-процесс можно описать детально по функциям. Это можно сделать как графически, так и в текстовом формате. Методика графического описания бизнес-процессов в данной статье не рассматривается. Если интересно, можно кратко ознакомиться в статье «Использование нотации eEPC для описания бизнес-процессов» (в практике IT-проектов графически процессы описывают гораздо реже, чем в консалтинговых проектах, связанных с оптимизацией процессов, организационном проектировании и т.п.).

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

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

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

Таким образом, в результате предварительной обработке информации раздела «Описание выполняемых функций» мы получим еще 2 полезных документа:

• Классификатор бизнес-процессов (предварительный)
• Перечень вопросов для устного опроса (иногда называют «план опроса»).

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

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

Источник: www.crmexperts.ru