Проектное управление как методика постоянного развития бизнеса

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

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

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

Найдите консультанта
для ваших целей

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

Подобрать

Проектное управление как методика постоянного развития бизнеса.

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

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

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

Например, любимые 99% предпринимателями малого и среднего  бизнеса, функциональные оргструктуры (это когда мы все в компании делим на функции) были придуманы давно и созданы для решения конкретны задач того времени. У таких структур есть серьезные минусы:

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

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

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

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

Правда в реальном бизнесе есть задачи направленные не только на RUN, но и CHANGE (изменения) и это кто-то должен делать.

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

Представьте, вот мы разделил всю работу на функции, все вроде как лежит "по полочкам". Но кто будет отвечать за развитие бизнеса ? Кто будет запускать и вести новые проекты ? Как вообще все это организовать ? А если у нас в компании нет каких-то серьезных проектов, а нужно просто повысить эффективность какого-то внутреннего участка работы, что-то улучшить в системе, но не понятно, как и самое главное "кем" это делать.

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

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

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

Суть методики очень проста:

Определяете проблему, которую будете решать.
Выберите менеджера проекта - это тот, кто будет организовывать и координировать всю работу, тот кто всех будет вести к решению проблемы, к достижению цели проекта.
Найдите заказчика - тот, кто будет пользоваться результатами проекта или его еще называют продуктом проекта.
Выберите куратора из топ-менеджмента - этот тот, кто будет "крышевать" проект, снабжать ресурсами и помогать преодолевать внутренние барьеры, а они будут.
Официально запустите проект и создайте документ, где будет описано какую проблему решаете, как будут выглядеть результаты проекта, кто за что ответственен, какой срок решения проблемы, какой бюджет вы выделили и так далее.
Реализуйте проект предварительно установив дедлайны по сроку и бюджету на проект. Менеджер проекта постоянно планирует-перепланирует проект, координирует всю работу, вдохновляет команду, следит за рисками, вовремя реагирует на изменения.
Команда проекта собирается на периодические встречи, чтобы отследить ход проекта по системе план/факт (срок, бюджет), принимаете различные корректирующие решения.
По мере завершения проекта официально завершаете проект. Менеджер проекта создает итоговый отчет, где описываются все отклонения и делаются выводы.
А теперь представьте, что у вас в компании создана система, когда сотрудники направляют проблемы в единую базу данных, а затем по мере приоритетности запускаются различные проекты по методике, описанной выше.

Получается что-то вроде самообучающейся организации.