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

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

1. Продукты
2. Подразделения
3. Посты
4. Персоны
5. Процессы
6. Процедуры
7. Показатели

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

Теперь давайте пройдемся по каждому пункту и поймем что важно описывать в каждом из них.

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

Продукты

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

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

Идеальный пример продуктового каталога: это различные Интернет-магазины, сайт услуг связи типа Мегафон или портал Госуслуги.

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



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

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

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

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

• Ответственный — персона, которая отвечает за это подразделение
• Продукт (ЦКП) или Ценный Конечный Продукт этого подразделения. По стандарту ИСО 9000 продукт это результат деятельности подразделения. Вот правильно определить и сформулировать продукт подразделения бывает довольно сложно. Но очень полезно. Сотрудники будут лучше понимать что и зачем они делают.
• Посты — какие посты есть в этом подразделении и кто их занимает? Отчасти это похоже на понятие штатного расписания. Мы будем знать сколько сотрудников в этом подразделении и кто за что отвечает?
• Показатели — важно понимать по каким показателям оценивается это подразделения и за что именно отвечает ответственный?
• Дочерние подразделения — какие подразделения входят в это подразделение? Если есть.
• Родительское подразделение — какому подразделению подчиняется это подразделение? Если это головное подразделение, то можно сказать что оно управляет только дочерними.
• Контактыне данные — как связаться с подразделением?

Примеры

Приведу лишь короткий список как пример подразделений:

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

Посты

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

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

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

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

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

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

Персоны

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

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

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

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

• ФИО
• Контактные данные

Процессы

Процесс — это порядок действий для получения продукта. Продукт — это результат процесса или подразделения. Эти понятия взяты из стандарта ИСО 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 дня работы программиста :) А сама платформа бесплатная.

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

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

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

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