Цифровая трансформация для директоров и собственников. Часть 2. Системный подход

Джимшер Бухутьевич Челидзе

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

Глава 1. Организационная структура и бизнес-процессы

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

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

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

Четкая и визуализированная организационная структура является ОБЯЗАТЕЛЬНЫМ условием. В моей практике не было ни одного случая, чтобы компания работала слажено без описанной организационной структуры, доступной и понятной всем.

Чаще всего я наблюдаю следующее:

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

— Организационная структура есть на бумаге, но в жизни совершенно иначе. Как говорится, «ожидание — реальность».

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

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

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

Типы организационных структур

Сейчас принято выделять несколько типов организационных структур:

— линейная;

— функциональная,

— линейно-функциональная или линейно-штабная

— дивизиональная,

— рыночная,

— матричная

— продуктовая

Разберем каждую из них

Линейная

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

Линейная организационная структура

Плюсы:

— простота и скорость принятия управленческих решений;

— быстрая реакция на указания и распоряжения;

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

— дисциплина.

Минусы:

— перегруженность руководителей;

— концентрация большого количества непрофильной работы на руководителях;

— слабые взаимосвязи между исполнителями;

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

Функциональная

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

Функциональная организационная структура

Плюсы:

— узкая специализация направлений — повышение производительности и качества;

— четкое распределение ответственности;

— освобождение линейных руководителей от функций вне их компетенции;

— отсутствие дублирования функций (если выстроены бизнес-процессы).

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

Линейно-функциональная

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

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

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

Линейно-функциональная организационная структура

Плюсы:

— узкая специализация направлений — повышение производительности и качества;

— простота и скорость принятия управленческих решений;

— быстрая реакция на указания и распоряжения;

— минимизация дублирования работ.

Недостатки:

— высокие, порой неоправданно, затраты на содержание административного персонала;

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

Дивизиональная / рыночная / продуктовая

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

Продуктовая организационная структура

Плюсы:

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

— простота координации и согласования управленческих решений;

— высокая скорость реагирования на возникающие проблемы;

— высокая производительность и качество управления благодаря специализации.

Минусы:

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

— нездоровая конкуренция между структурами и направлениями, рост политических разногласий;

— разная продуктивность;

— низкая эффективность использования бюджета.

Матричная

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

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

Плюсы:

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

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

Недостатки:

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

— низкая производительность;

— дублирование функций.

Приведу пример реализации такого подхода.

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

Центральный аппарат инициирует внедрение сложной ИТ-системы, которая охватывает большое количество бизнес-процессов и требует включение и технического блока, и финансового, и HR. В каждом региональном подразделении назначается ответственный менеджер и начинается веселье… Менеджер отвечает за весь проект, но ресурсов и полномочий для управления чужими (финансовым, HR) блоками нет, а желания у других меняться по собственному желанию тем более. Куратор в центральном аппарате не всесилен и тоже находится внутри функционального подразделения. В общем, реализовать такой проект — тот еще квест.

Матричные структуры можно также разделить на слабые, сильные и сбалансированные.

Слабые

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

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

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

Также возможно наличие «экспедиторов». Это сотрудники функциональных направлений, которые распространяют информацию, но никаких полномочий тоже не имеют, — неформальные лидеры мнений.

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

Сильные

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

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

Сбалансированные

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

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

Резюме

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

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

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

Организационные структуры

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

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

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

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

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

Основные подходы к моделированию и описанию бизнес-процессов

Введение

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

Полный список практически всех подходов к описанию с иллюстрациями, примерами отображения и видео, доступными IT-решениями, представлен по QR-коду и ссылке ниже.

Бизнес-процессы: нотификации и моделирование, что выбрать?

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

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

Основные подходы к описанию бизнес-процессов

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

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

Условно существует несколько подходов к описанию бизнес-процессов:

— Диаграммы цепочки добавленной ценности (value added chain diagram, VAD)

— SIPOC

— Событийная цепочка процессов (event-driven process chain, EPC)

— BPMN 2.0 (Business Process Model and Notation 2.0)

— Flow Charting (нотации Процесс и Процедура)

— IDEF (Integrated Definition Language)

— UML (Unified Modeling Languages)

— VSM (Value Stream Mapping)

— ARIS

— DFD

Диаграммы цепочки добавленной ценности (VAD)

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

То есть это некая «мастер-модель», дающая понимание всей команде, как ее работа влияет на компанию в целом.

Правила построения VAD-модели процесса добавленной стоимости:

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

— Далее выстраивается их логическая взаимосвязь.

— Определяются и указываются владелец и подразделение, отвечающие за процесс.

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

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

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

Пример VAD-схемы

SIPOC

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

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

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

— Process (процесс) — все те задачи, которые позволяют в результате работы преобразовать сырье в конечный продукт;

— Output (выход) — продукты деятельности бизнес-процесса;

— Customer (заказчик) — получатели услуги, те, кто пользуется продуктом бизнес-процесса.

Бизнес-процесс по SIPOC описывается с конца:

— Определите заказчика бизнес-процесса;

— Опишите итоговый продукт (выход), который нужен заказчику;

— Выделите 5—7 ключевых операций бизнес-процесса;

— Определите необходимые ресурсы (вход) для бизнес-процесса;

— Определите поставщиков этих ресурсов

Ключевое преимущество — скорость описания, возможность выявить лишние шаги, которые не создают ценность. Этот подход чем-то похож на VAD и является верхнеуровневым описанием. Позволяет выявить самые явные потери.

Событийная цепочка процессов (EPC)

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

Основные элементы описания:

— Событие — то, что создает необходимость действия.

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

— Исполнители — те, кто реализуют функцию, в том числе утверждают, согласовывают и т. д.

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

В отличие от предыдущего подхода, где начало было слева и финиш справа, здесь все стартует сверху и идет вниз.

Алгоритм описания:

— Определяем, что у нас есть и чего мы хотим — граничные события.

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

— Добавляем всю необходимую информацию об исполнителях и ресурсах.

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

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

BPMN 2.0 (Business Process Model and Notation 2.0)

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

Пример описания в этой нотации ниже.

Пример упрощенной BPMN-схемы

Что я наблюдаю в жизни и применяю сам

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

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

Резюме 1 главы и рекомендации

Что важнее: организационная структура или описанные бизнес-процессы? С чего начинать? Это извечная дискуссия. Лично мое мнение: пока компания небольшая, идет ее становление или перестройка, подбор той бизнес-модели, которая будет давать результат, можно обойтись без бизнес-процессов. Если у вас есть организационная структура, четко прописаны функции, ключевой продукт и, желательно, метрики (я не вывожу это в обязательное условие, потому что видел единичные случаи качественно проработанной системы ключевых показателей), то вы не утонете в хаосе. Люди смогут между собой общаться и договариваться, а это — ключевой элемент. Я бы даже сказал, что это полезное упражнение — сначала научить людей работать сообща, разделив между ними полномочия, ответственность и ресурсы, а затем внедрять процессное управление. В итоге работа с орг. структурой позволит создать скелет системы управления, в том числе:

— обеспечить эффективное использование ресурсов;

— повысить производительность;

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

— минимизировать риски для компании, особенно связанные с зависимостью от отдельных людей;

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

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

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

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

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

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

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

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

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

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

Я рекомендую следующий алгоритм:

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

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

— Оценить доступные технологии и ресурсы, в том числе цифровые.

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

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

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

Еще одна рекомендация: по достижении целей или после внедрения и освоения новых технологий пересматривайте вашу орг. структуру. Или возьмите за правило это делать каждые 6—12 месяцев.

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

— изначально сделайте VAD-схему по всей компании;

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

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

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

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

— описывайте бизнес-процессы так, чтобы они умещались на одном листе А4, если надо запустить процесс, и в нотации BPMN если нужно проанализировать и оптимизировать процесс. И только после оптимизации занимайтесь IDEF, чтобы автоматизировать;

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

По QR-коду и ссылке ниже вы можете перейти на статью с большим количеством иллюстраций и полезных ссылок на эту тему:

Организационные структуры

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

В целом тут, как я считаю, необходимо отталкиваться от:

— вашего масштаба и доступности ресурсов;

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

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

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

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

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

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

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

Ну, а если вы — топ-менеджер корпорации с ресурсами, то лучше всего выделить отдельное подразделение во главе с CDTО (руководителем цифровой трансформации), которое будет выстраивать методологию системного подхода и выступать центром компетенций по работе с цифровыми технологиями, процессами, ведением проектов, созданием продуктов. Состав команды должен обязательно включать: специалиста по процессам / бизнес-аналитика (лучше парочку), специалиста по данным, системного аналитика/архитектора, специалиста по ИБ (этому мы посвятим следующую книгу), руководителя портфеля проектов (если вы будете обучать персонал, то хватит одного, если нет, то по руководителю проекта в каждое подразделение). Если вы их будете размещать в разных подразделениях, то этим людям придется выстраивать горизонтальные связи и матричное взаимодействие. А это дольше и подходит только зрелым компаниям, с уважением в коммуникациях. Если компания менее зрелая, то это выльется в увеличение сроков. В слабой системе нужно централизованное управление.

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

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