7П — идеальная бизнес-модель организации

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

Разбирая этот предмет, за десять лет пришел к выводу, что идеальная модель состоит из 7П:

1. Продукты

2. Подразделения

3. Посты

4. Персоны

5. Процессы

6. Процедуры

7. Показатели

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

Опишем каждую из 7 сущностей

Продукты

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

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

Подразделения

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

Как описывать подразделение?

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

1. Ответственный — персона, которая отвечает за это подразделение.

2. Продукт (ЦКП) или Ценный Конечный Продукт. По стандарту ИСО 9000 продукт - это результат деятельности подразделения. Вот правильно определить и сформулировать продукт бывает довольно сложно. Но очень полезно. Сотрудники будут лучше понимать, что и зачем они делают.

3. Посты — какие посты есть в этом подразделении и кто их занимает? Отчасти это похоже на понятие штатного расписания. Мы будем знать сколько сотрудников в этом отделе и кто за что отвечает. 

4. Показатели — важно понимать по каким показателям оценивается это подразделения и за что именно отвечает ответственный?

5. Дочерние подразделения — Если есть.

6. Родительское подразделение — какому подразделению подчиняется это подразделение? Если это головное подразделение, то можно сказать, что оно управляет только дочерними.

7. Контактные данные — как связаться с подразделением?

Примеры

• Отдел маркетинга
• Канцелярия
• Департамент ИТ
• Офис владельца
• Совет директоров
• Управление закупок

Посты

Пост — это участок, за который отвечает сотрудник. Можно сказать, что это должности.

Описание поста очень похоже на описание подразделения, но есть отличия:

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

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

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

Персоны

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

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

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

Запись персоны, как правило, содержит базовые данные:

1. ФИО

2. Контактные данные

Процессы

Процесс — это порядок действий для получения продукта. Продукт — это результат процесса или подразделения. Эти понятия взяты из стандарта ИСО 9000.

Мы используем методику 5Ш для описания каждого бизнес-процесса.

По сути процесс — это инструкция, которая описывает порядок действий в 5 шагов:

1. определение — как определяется событие старта по этому процессу. Как понять, когда начать работу по этому процессу?

2. регистрация — как регистрируются операции по этому процессу? в 1С, в CRM или в ERP системе?

3. подготовка — что мы делаем на этапе подготовки?

4. исполнение — что мы делаем на этапе исполнения?

5. закрытие — как мы заркываем операцию? что нужно нажать в ИС, или куда и как подшить бумажные документы по окончанию?

У процесса указываем, к какому подразделению он относится? Один процесс может относиться сразу к нескольким подразделениям.

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

Процедуры

Вот это еще одна очень интересная и непростая сущность. Я долго не мог найти ей место в нашей базе знаний, и она обычно не встречается в моделях бизнес-процессов. По стандарту ИСО 9000 она звучит примерно так: установленный порядок действий. И она очень похожа в этом плане на определение термина «Процесс». Разница лишь в том, что процесс описывает получение продукта, а процедура нет.

Чтобы понять ее назначение, приведу примеры:

1. Процесс «Закупки». В общем виде он состоит из 5 шагов. Но закупки бывают разные. Например в нашем случае мы можем закупать услуги субподрядчиков, разные виды хостинга и цифровых продуктов (темы, шаблоны, модули) на разных рынках и у разных поставщиков. Часть из которых имеет особенности. Так вот процесс Закупки  всегда выглядит одинаково и описывает общий порядок действий. А процедуры описывают особенности для некоторых конкретных случаев. Например, у нас описаны процедуры закупки на рынке ThemForest и процедура закупки хостингов и доменов на reg.ru.

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

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

Показатели

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

Показатели как правило описываются для следующих сущностей:

• Подразделения — как оно оценивается?
• Посты — как оцениваются посты?
• Процессы — как оцениваются процессы?
• Процедуры — редко, но нужно некторые процедуры тоже оценивать.

Резюме

Вот мы описали 7 сущностей описания организации или оргструктуры. Отмечу, что просто взять и описать это все — довольно сложно. Я долго искал подходящий для этих целей инструмент. И в итоге остановил свой выбор на системе WordPress. Плюс два плагина: Custom Post Maker + AdvancedCustomFields. Плюс ряд своих плагинов.

Сейчас это уникальная разработка, которая в полной мере используется только у нас и частично реализована у наших клиентов. Ее стоимость нам обошлась в 2 дня работы программиста :) А сама платформа бесплатная.

Если описать ее тезисами, то она выглядит так:

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

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

3. Посты — добавляем посты и указываем там соответствующие данные. Включая ответственных.

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

5. Процессы — у нас описаны основные процессы по методу 5Ш. Это существенно снижает затраты на обучение.

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

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

Создание такой системы — не одноразовый проект. Это постоянная работа. Но затраты на ее создание окупаются с лихвой. Даже в базовой версии она уже позволяет существенно снизить операционные затраты компании, повысить качество продуктов и стабильность процессов. И ничего лучше WordPress мы не нашли для этих целей. Если у кого-то есть иной опыт, просьба поделиться в комментариях.

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