Матричные структуры можно также разделить на слабые, сильные и сбалансированные.
Слабые
Слабые матричные структуры применяются в случаях, когда проектов много, но они небольшие и не рутинные, не критичны для компании.
В слабой матрице управление членами команды проекта осуществляется функциональными руководителями (начальник промышленной безопасности, отдела планирования ремонтов, отдела закупок), полномочия которых ограничены: каждый отвечает за свое направление.
Тут должен быть менеджер проекта, который подчиняется руководству или, в нашем случае, центральному аппарату, получает от него задачи. Затем задачи декомпозируются на более мелкие и отдаются сотрудникам функциональных подразделений. Но фактически никаких полномочий и ресурсов у него нет. Это плодородная почва для возникновения конфликтов.
Также возможно наличие «экспедиторов». Это сотрудники функциональных направлений, которые распространяют информацию, но никаких полномочий тоже не имеют, неформальные лидеры мнений.
Как мы видим, для нашего масштабного проекта такой подход неприменим. Разве что у нас будут очень харизматичные и сильные менеджеры проектов на местах.
Сильные
Отличаются тем, что в рамках реализации такого проекта может быть не один, а несколько менеджеров, или же менеджер и команда, и полномочий у них гораздо больше. Они теперь могут не просто передавать задачи, но и отдавать распоряжения, требовать исполнения задач и подготовки проектной отчетности функциональных руководителей. Кроме того, эта проектная команда может не являться постоянными сотрудниками функциональных подразделений, то есть возможен вариант, когда они будут заниматься только проектом, плюс они могут искать подрядчиков или заказывать сырье.
Для нашего условного проекта по внедрению ИТ-системы такой подход может быть избыточен. Хотя, возможно, именно он повысит шансы на успех, но подобная реализация выходит очень дорогой.
Сбалансированные
В этом случае менеджер проекта назначается из числа сотрудников, а лучше руководителей функциональных подразделений. Здесь он может ставить задачи и контролировать их выполнение. Однако он скорее всего не освобожден от своих операционных задач и не может сам распоряжаться ресурсами.
Стоит отметить, что это наиболее сложный в реализации вариант, поскольку он предполагает самое большое количество выделенных ролей, более того, здесь тоже могут возникать вопросы с подчиненностью и, как следствие, матричные конфликты.
Резюме
Мы разобрали основные виды орг. структур. Казалось бы, выбери правильную, подходящую под твою компанию, и все будет замечательно. Увы, это не так. Важно правильно распределить функционал и полномочия, определить ключевой продукт деятельности, подобрать на должности людей, которым эта работа подходит психологически, и еще чтобы при этом между ними была выстроена коммуникация. Именно поэтому я всегда говорю о системном подходе: невозможно внедрить какой-то один инструмент нужна интеграция.
Кроме того, как мы видим, уже на уровне орг. структуры прослеживается связь с количеством и масштабом реализуемых проектов, то есть идет тесное переплетение работы с орг. структурами и проектного управления, они становятся неразделимыми.
Чтобы закрепить все практикой, предлагаю посмотреть один реальный пример с двумя структурами одинакового типа, но с совершенно разной сутью. Так как организационную структуру в книге отобразить практически невозможно, то доступно все будет по 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 описывается с конца:
Определите заказчика бизнес-процесса;
Опишите итоговый продукт (выход), который нужен заказчику;
Выделите 57 ключевых операций бизнес-процесса;
Определите необходимые ресурсы (вход) для бизнес-процесса;
Определите поставщиков этих ресурсов
Ключевое преимущество скорость описания, возможность выявить лишние шаги, которые не создают ценность. Этот подход чем-то похож на VAD и является верхнеуровневым описанием. Позволяет выявить самые явные потери.
Событийная цепочка процессов (EPC)
Данный подход описывает бизнес-процессы в виде отдельных этапов/шагов процесса и событий, которые инициируют эти шаги, то есть получается структура «событие функция событие». Этот метод хорошо подходит для стандартизации бизнес-процессов и анализа потока документов и необходимой информации в рамках всего бизнес-процесса.
Основные элементы описания:
Событие то, что создает необходимость действия.
Функция это действие для получения нужного результата, в ответ на событие.
Исполнители те, кто реализуют функцию, в том числе утверждают, согласовывают и т. д.
Ресурсы это все то, что необходимо для реализации функции: деньги, информационные системы или отдельные модули, документы, операционные риски.
В отличие от предыдущего подхода, где начало было слева и финиш справа, здесь все стартует сверху и идет вниз.
Алгоритм описания:
Определяем, что у нас есть и чего мы хотим граничные события.
Описываем промежуточные события, которые есть внутри этого процесса и какие необходимо выполнить задачи / реализовать функции.
Добавляем всю необходимую информацию об исполнителях и ресурсах.
Анализ полноты и качества схемы, учитывает ли она все вариации и подпроцессы. При необходимости делаем дополнительные схемы для подпроцессов. Однако тут я рекомендую всегда помнить правило из первой книги одна схема, один лист или экран.
Плюс подхода возможность потом создать понятный регламент в виде текста или таблицы. Эта нотация довольно распространена, особенно в крупных организациях, так как с одной стороны стандартизует описание, а с другой достаточно гибкая. Например, ее часто используют для настройки ERP-систем.
BPMN 2.0 (Business Process Model and Notation 2.0)
BPMN на сегодня некий стандарт де-факто в описании бизнес-процессов с широким набором графических элементов для моделирования. Если для рядовых пользователей и руководителей это не самый удобный подход, то для бизнес-аналитиков это обязательный инструмент: описать в рамках этого подхода довольно большой процесс на одном листе будет трудно, кроме того, подход довольно строг, однако здесь более высокая детализация и легче выявить локальные ошибки.
Пример описания в этой нотации ниже.
Пример упрощенной BPMN-схемы
Что я наблюдаю в жизни и применяю сам
К сожалению, в 99% компаний или нет никакого описания бизнес-процессов, ни верхнеуровневого, ни тем более детализированного, или оно формально и сделано для галочки, а в жизни все работает иначе. И пока организация маленькая, 510 человек, это не страшно. Но после того, как она начинает расти, хаос становится все более дорогим удовольствием.
В своей жизни я подстраиваюсь под задачу, уровень зрелости компании и сотрудников. В основном это некий гибрид EPC и нотации Процедура (о ней подробнее по QR-коду в начале раздела), а иногда и простые блок-схемы.
Резюме 1 главы и рекомендации
Что важнее: организационная структура или описанные бизнес-процессы? С чего начинать? Это извечная дискуссия. Лично мое мнение: пока компания небольшая, идет ее становление или перестройка, подбор той бизнес-модели, которая будет давать результат, можно обойтись без бизнес-процессов. Если у вас есть организационная структура, четко прописаны функции, ключевой продукт и, желательно, метрики (я не вывожу это в обязательное условие, потому что видел единичные случаи качественно проработанной системы ключевых показателей), то вы не утонете в хаосе. Люди смогут между собой общаться и договариваться, а это ключевой элемент. Я бы даже сказал, что это полезное упражнение сначала научить людей работать сообща, разделив между ними полномочия, ответственность и ресурсы, а затем внедрять процессное управление. В итоге работа с орг. структурой позволит создать скелет системы управления, в том числе:
обеспечить эффективное использование ресурсов;
повысить производительность;
минимизировать потребность в регламентах, правилах, детализированных описаниях каждого бизнес-процесса, в общем, в работе с бумагой;
минимизировать риски для компании, особенно связанные с зависимостью от отдельных людей;
снизить перегруз людей и уровень текучки. Вместо одной-двух универсальных «рабочих лошадок» появится распределение задач, снизится неопределенность, из-за которой возникает стресс и выгорание;
разгрузить себя как руководителя: вам не придется часто вмешиваться в процессы и разбираться в конфликтах, так как система станет прозрачной, каждый будет понимать свою зону ответственности. Станет проще подбирать людей и готовить описания вакансий.
Кроме того, на ранних этапах, в том числе при запуске цифровизации, ваши бизнес-процессы будут меняться слишком часто, и постоянно их переделывать и актуализировать слишком дорогое удовольствие. А если описать и «заморозить», то вы теряете главное преимущество молодой команды ее гибкость. Исключение критичные процессы с высокими рисками и процессы бэкофиса, они зачастую стабильны и заниматься ими лучше изначально.
Однако после того, как первичный этап пройден, заниматься бизнес-процессами нужно. Необязательно фиксировать все и детализировано, но наиболее критичные процессы, где высоки риски, где начинают наблюдаться проблемы, описать хотя бы верхнеуровнево обязательно. У верхнеуровневых подходов есть главных плюс скорость и простота. А это уже даст эффект, а значит, ресурсы и мотивацию на углубленную работу.
У взрослых компаний возникает другая проблема бюрократия. Там уже нужен обратный подход упрощение бизнес-процессов. В общем, как всегда, поиск точки баланса, между хаосом и предпринимательством, и порядком с бюрократией.