Подводные камни технологизации компании
Мои первые 3 года работы в управленческом консалтинге позволили разобраться, как использовать стандартные инструменты: моделирование бизнес-процессов, PMBoK, система KPI и т.д. Мы говорили много умных слов, внедряли SAP, 1C, Project получали за это деньги и уходили. Реальных результатов своей работы я не видел. С тех пор заработал аллергию на прилизанных консультантов в галстуках.
Кто-то, наверное, так всю жизнь и проработал, мне же хотелось реальных дел. Сдал на PMP и пошел технологизировать строительного девелопера «изнутри». Сначала все шло как по маслу, проблемы нашли, решения внедрили, даже все закрутилось, завертелось. Но через полгода оказалось, что сильного эффекта нет: подрядчики косячат, тендеры вовремя не проводятся, сроки срываются.
Выходит, неправильно/недостаточно глубоко диагностировали проблемы. Стандартные технологии диагностики типа метод McKinsey, поиск дублирующихся функций, привлечение экспертов, опросы и т.д. – оказались бесполезны. Причины:
- в стройке отследить все взаимодействия строительных менеджеров, тендерного отдела, проектировщиков, подрядчиков, технадзора – не реально
- принимаемые решения сильно влияют на все элементы системы. Например, корректировка проектной документации влечет изменения проектной документации, графика проекта, бюджета, договоров с подрядчиками
Учетные системы позволяли определить симптомы и локализовать проблемную область. Мы знали в какой момент какая заявка была задержана, сколько подрядчик простаивал без денег, имели статистику на сколько по каким видам работ произошел сдвиг. Но громадное количество «подводных» взаимосвязанных процессов не давали возможность найти объективную причину. И тут пришлось «генерить».
Идея 1. Залп их всех батарей по всем возможным проблемам. Не сработало. Этот подход оказался слишком трудозатратен. Решение несущественной проблемы создает новые реальные проблемы в других местах. Например, попытка детализировать график проекта и усилить контроль, привели к тому, что он перестал был рабочим инструментом принятия решений и превратился в чисто «отчетный» инструмент.
Идея 2. Статистика типовых причин. Все срывы сроков в графике проекта классифицировались типовыми причинами:
Оказалось. что исполнители сообщали наиболее «удобную причину». Даже если она отличалась от видения смежных подразделений, то смежники, как правило, молчали. Чаще всего во всех бедах винили подрядчика. Когда предлагали штрафовать подрядчика, находилось 10 причин, почему этого подрядчика штрафовать не стоит (решение о штрафе принимал строительный менеджер). В итоге стало понятно, что эти причины не объективны и идея умерла.
Идея 3. Управляемый конфликт. Раз объективной информации напрямую мы получить не можем, то давайте сделаем так чтобы исполнители сами ее нам давали. Призывы типа «Мы же команда», «Давайте сделаем компанию мечты» и даже денежные премии за предложенные идеи по технологизации эффекта не дали.
Тогда решили действовать по «плохому». Ввели рабочую систему штрафов. В случае нарушения регламента, повлекшего за собой срыв сроков по графику проекта, вводился штраф в течение 2-ух дней. Штрафовали того, в чьей зоне ответственности произошел срыв сроков, в виде фиксированного процента от годового дохода. Если исполнитель считает, что срыв сроков произошел из-за другого смежника, то в его интересах предоставить факты, которые это подтверждают.
Отдельно пришлось наладить систему штрафования подрядчиков, когда штраф выписывался подрядчику автоматически, если менеджер не указывал на ошибки, допущенные заказчиком. Подрядчики, разумеется, на такой расклад согласны не были и выкатывали кучу информации, которая раньше была скрыта. В итоге был создан поток объективных фактов, который позволил нам копать глубже и решать проблемы, которые глубоко скрыты.
Суть
Как и в сериале «Доктор Хаус», вся соль технологизации сводиться к правильной диагностике. Иногда приходиться менять систему только лишь для того, чтобы обеспечить объективной информацией о возникающих проблемах, но это того стоит.
Для проектной деятельности, когда нельзя, да и вредно все фиксировать регламентами, получить объективную информацию напрямую — не реально. Как один из способов получить объективные факты — создание управляемых конфликтов.
Автор: dchasovskoy
