Матричные структуры можно также разделить на слабые, сильные и сбалансированные.
Слабые
Слабые матричные структуры применяются в случаях, когда проектов много, но они небольшие и не рутинные, не критичны для компании.
В слабой матрице управление членами команды проекта осуществляется функциональными руководителями (начальник промышленной безопасности, отдела планирования ремонтов, отдела закупок), полномочия которых ограничены: каждый отвечает за свое направление.
Тут должен быть менеджер проекта, который подчиняется руководству или, в нашем случае, центральному аппарату, получает от него задачи. Затем задачи декомпозируются на более мелкие и отдаются сотрудникам функциональных подразделений. Но фактически никаких полномочий и ресурсов у него нет. Это плодородная почва для возникновения конфликтов.
Также возможно наличие «экспедиторов». Это сотрудники функциональных направлений, которые распространяют информацию, но никаких полномочий тоже не имеют, неформальные лидеры мнений.
Как мы видим, для нашего масштабного проекта такой подход неприменим. Разве что у нас будут очень харизматичные и сильные менеджеры проектов на местах.
Сильные
Отличаются тем, что в рамках реализации такого проекта может быть не один, а несколько менеджеров, или же менеджер и команда, и полномочий у них гораздо больше. Они теперь могут не просто передавать задачи, но и отдавать распоряжения, требовать исполнения задач и подготовки проектной отчетности функциональных руководителей. Кроме того, эта проектная команда может не являться постоянными сотрудниками функциональных подразделений, то есть возможен вариант, когда они будут заниматься только проектом, плюс они могут искать подрядчиков или заказывать сырье.
Для нашего условного проекта по внедрению ИТ-системы такой подход может быть избыточен. Хотя, возможно, именно он повысит шансы на успех, но подобная реализация выходит очень дорогой.
Сбалансированные
В этом случае менеджер проекта назначается из числа сотрудников, а лучше руководителей функциональных подразделений. Здесь он может ставить задачи и контролировать их выполнение. Однако он скорее всего не освобожден от своих операционных задач и не может сам распоряжаться ресурсами.
Стоит отметить, что это наиболее сложный в реализации вариант, поскольку он предполагает самое большое количество выделенных ролей, более того, здесь тоже могут возникать вопросы с подчиненностью и, как следствие, матричные конфликты.
Резюме
Мы разобрали основные виды орг. структур. Казалось бы, выбери правильную, подходящую под твою компанию, и все будет замечательно. Увы, это не так. Важно правильно распределить функционал и полномочия, определить ключевой продукт деятельности, подобрать на должности людей, которым эта работа подходит психологически, и еще чтобы при этом между ними была выстроена коммуникация. Именно поэтому я всегда говорю о системном подходе: невозможно внедрить какой-то один инструмент нужна интеграция.
Кроме того, как мы видим, уже на уровне орг. структуры прослеживается связь с количеством и масштабом реализуемых проектов, то есть идет тесное переплетение работы с орг. структурами и проектного управления, они становятся неразделимыми.
Чтобы закрепить все практикой, предлагаю посмотреть один реальный пример с двумя структурами одинакового типа, но с совершенно разной сутью. Так как организационную структуру в книге отобразить практически невозможно, то доступно все будет по 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)
Подход, который позволяет описать на самом верхнем уровне ключевые направления деятельности компании и подразделений, показать взаимосвязи между ними. Здесь фокус на графическом отображении бизнес-процессов, создающих ценность для клиента.