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

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

Редактор Александр Александрович Перемышлин

Иллюстратор Александр Александрович Перемышлин

Дизайнер обложки Александр Александрович Перемышлин

© Джимшер Челидзе, 2022

© Александр Александрович Перемышлин, иллюстрации, 2022

© Александр Александрович Перемышлин, дизайн обложки, 2022

ISBN 978-5-0059-4359-0 (т. 2)

ISBN 978-5-0056-6913-1

Создано в интеллектуальной издательской системе Ridero

Предисловие

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

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

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

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

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

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

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

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

Итак, в чем же суть продвигаемого мною системного подхода?

Системный подход к цифровой трансформации

Он построен на сочетании:

– Бережливого производства

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

– Проектного управления

Позволяет минимизировать риски и бюджет.

– Использования продуктового подхода

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

– Теории ограничений системы

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

– Внедрения изменений

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

– Управления коммуникациями между подразделениями

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

Вообще работать с ТОПами очень сложно. Как правило, это люди так называемого «Е-типа» по Адизесу: предприниматели, яркие и сильные личности, авторитарные, не терпящие мнения, отличного от своего.

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

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

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

И теперь представьте, каково такой сильной личности научиться отстраняться от ручного управления?

– Использования цифровых технологий и данных для принятия решений

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

– Практик регулярного менеджмента

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

– Работы со стратегией, организационной структурой и бизнес-процессами

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

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

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

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

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

Возможно ли освоить весь подход одному человеку? При должном упорстве и постоянстве в течение 10—15 лет – да. Разумеется, такого количества времени ни у кого нет, поэтому единственный путь – формировать команду с правильными компетенциями.

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

Глава 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 или EPC) более низкого уровня.

Пример 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 2.0)

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

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

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