ЧАСТЬ II

НАЦИОНАЛЬНЫЕ ОСОБЕННОСТИ УПРАВЛЕНИЯ ПРОЕКТАМИ

ГЛАВА 6

Особенность 1. А.Н.К.А. Два режима работы: стабильный и мобилизационный

Даже самые большие проблемы можно было решить, пока они еще были маленькими.

Автор неизвестен

Первая особенность построена на древней поговорке, что русский человек на трех сваях крепок: авось, небось и как-нибудь.

• Авось, небось, как-нибудь мы проект сделаем.
• Авось, небось, как-нибудь мы продукт получим.
• Авось, небось, как-нибудь жизнь у нас наладится без всяких сложностей.

Если вдруг эти три сваи не срабатывают, начинает работать четвертая — аврал: «Ночь не поспим, но сделаем».

И акроним А.Н.К.А. (А — авось, Н — небось, К — как-нибудь, А — аврал) — это, с моей точки зрения, злейший враг применения любого системного подхода в России.

Лучше всех эту историю отразил Александр Прохоров в книге «Русская модель управления». Он сказал, что наша модель управления в каждый момент времени существует в одном из двух режимов:

• Стабильном — авось, небось и как-нибудь. Это когда никто не напрягается и все дружат против руководителя, чтобы не нагрузил работой.
• А если выясняется, что это не работает, то отдельное подразделение, вся компания или даже вся страна переходят в режим аврала, мобилизационный режим, когда все напрягаются и делают за ночь / неделю то, что не делалось неделями, месяцами и годами.

Идею Прохорова развил мой друг Владимир Ананьин, преподаватель РАНХиГС и Высшей школы экономики. У него есть большая статья на тему национальных особенностей управления. Он ввел немного упрощенную, но интересную и наглядную теорию, где объединил различные подходы к работе с инцидентами (происшествиями, которые ломают наш план). Идея Владимира строится вокруг представленной схемы (рис. 6.1).

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

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

Разберем простой бытовой пример.

Собрались вы, предположим, поехать на дачу — прополоть грядки, полить рассаду и сделать еще немало накопившихся дел. И вдруг у вас заболел зуб. Причина банальна — кариес. Первопричина — плохо чистил зубы, однако это уже неважно (но чистите зубы тщательнее!).

Итак, если срочно пойти к врачу и оперативно решить вопрос, то вы без потерь реализуете свои планы. Если же затянуть устранение проблемы, то вас постоянно будет отвлекать зубная боль и дачные дела вы вряд ли выполните в срок и с желаемым качеством. Скорее всего, еще и поругаетесь с домашними и соседями.

Кроме того, затягивание решения может привести к удалению зуба. Такая стратегия способна и вовсе довести до полного исчезновения зубов.

Точно такая же ситуация может возникнуть и в проекте. Допустим, вы работаете в компании, которая выполняет проект для внешнего заказчика. И вот случился инцидент: вы вовремя не оплатили счет поставщику за оборудование, необходимое для проекта. При этом вы четко понимаете, что если срочно не оплатить счет, то, скорее всего, ситуация приведет к задержкам в проекте.

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

В примере с задержкой оплаты счета за оборудование: пока ситуация остается внутри организации, можно все исправить — объяснить финансовому директору важность срочной оплаты, быстро провести согласование и протолкнуть платеж; а вот если затянуть устранение инцидента, то сложность решения начинает возрастать.

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

Эту цепочку развития проблем хорошо описывает английский стишок, известный нам в переводе Самуила Маршака:

 

Не было гвоздя — подкова пропала.

Не было подковы — лошадь захромала.

Лошадь захромала — командир убит.

Конница разбита — армия бежит.

Враг вступает в город,

Пленных не щадя,

Оттого, что в кузнице

Не было гвоздя.

 

Такую точку на жизненном цикле инцидента (когда не было гвоздя) Владимир Ананьин называет началом вязкого сопротивления. Это нештатная ситуация, которая порождает целый поток инцидентов и запускает своеобразную цепную реакцию. После определенного момента устранить первоначальный инцидент становится гораздо сложнее. Есть такая поговорка: «Даже самые большие проблемы можно было решить, пока они еще были маленькими». Вот это как раз тот случай. Поэтому менеджер проекта всегда должен понимать причину инцидента и последствия, к которым он может привести. Иными словами, руководитель должен постоянно представлять причинно-следственную цепочку связанных событий. Не устраненный вовремя инцидент может разрушить даже самый проработанный проект.

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

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

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

Владимир Ананьин выделил три национальные модели работы с инцидентами. Посмотрим, в чем их специфика и что мы можем из них заимствовать (рис. 6.2).

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

Американская модель управления. Фокусируется на том, чтобы устранить все нештатные ситуации (их называют инцидентами) как можно быстрее и таким образом не допустить настоящего кризиса. Да, американцам нужно подумать о рисках, недаром риск-менеджмент — американский термин. Но они прорабатывают риски без фанатизма: обсуждается 5–10, максимум 20 ключевых из них. При этом им важно не только продумать самые большие и главные риски. Как только возник какой-то инцидент, лидер и команда должны вместе собраться и быстро его ликвидировать, чтобы вернуться к плану и начать работать по нему.

Российская модель управления. Нацелена на борьбу с возникающими кризисами. Мы на мелочи не размениваемся. Инциденты? Да зачем ими заниматься? Может, само рассосется? И часто, надо сказать, рассасывается. Авось, небось и как-нибудь. А вот если кризис — то да! Фокус внимания постоянно удерживается не на системной работе, а на том, чтобы предотвратить катастрофу. В России нередко проекты запускаются в условиях приближающегося кризиса, когда нет ни времени, ни желания провести проработку и планирование. А проекты, которые приводятся в действие не в условиях кризиса, часто затягиваются до того момента, пока он не наступит.

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

Давайте рассмотрим эти модели на примере реального кейса.

Кейс: внедрение CRM в компании «Кварк»

Одна из ключевых ИТ-систем компании — CRM-система (система управления работой с клиентами, Customer Relationship Management), которую написал в свободное от работы время один из сотрудников службы сервиса много лет назад. Ему в рамках саморазвития было интересно разобраться с языком программирования Delphi, и он с использованием этого инструмента автоматизировал сначала свою работу, потом работу коллег. А далее как-то так оказалось, что вся ключевая информация по клиентам содержится в данной системе.

Сотрудник уже устал заниматься поддержкой и развитием системы и просит освободить его от этой задачи. Но, кроме него, никто в ней не разбирается (в CRM работают около 150 сотрудников компании).

Функции, реализованные в текущей CRM-системе:

• ведение информации по клиентам;
• отчеты по клиентам;
• оформление командировок;
• почтовая рассылка;
• сервисные напоминания;
• заявки клиентов;
• задачи сотрудникам сервисной службы;
• сервисные договоры;
• обратная связь;
• план / факт платежей клиентов;
• ведение актов;
• постановка задач по несоответствиям и корректирующим действиям.

Достоинства и недостатки системы показаны в табл. 6.1.

Таблица 6.1. Плюсы и минусы CRM-системы

Плю­сы	Не­до­стат­ки
Ис­поль­зу­е­мая CRM по­кры­ва­ет все клю­че­вые про­цес­сы про­даж и об­слу­жи­ва­ния уста­нов­лен­ных ап­па­ра­тов	Ин­тер­фейс и удобст­во ис­поль­зо­ва­ния у сис­те­мы низ­кие (сред­няя оцен­ка по ре­зуль­та­там опро­са — 2 из 5 бал­лов)
Поль­зо­ва­те­ли к ней при­вык­ли, по­ни­ма­ют, что и как де­лать	Сис­те­ма ра­бо­та­ет мед­лен­но и не­ста­биль­но
	В сис­те­ме от­сут­ст­ву­ют раз­вер­ну­тые управ­лен­чес­кие от­че­ты
	Ин­фор­ма­ция для при­ня­тия ре­ше­ния ру­ко­водст­вом вы­гру­жа­ет­ся в файл Excel и об­ра­ба­ты­ва­ет­ся вруч­ную. За по­след­ние по­лго­да в сфор­ми­ро­ван­ных от­че­тах най­де­но семь су­щест­вен­ных оши­бок и опе­ча­ток

Руководство компании обсуждает вопрос о запуске проекта по замене существующей CRM на более функциональную и современную промышленную систему. Первые лица уже несколько недель не могут прийти к компромиссу — мнения разделились. Обсуждаются три основных варианта действий.

1. «Не стоит чинить то, что не сломано». Вводить новую систему CRM слишком дорого, хлопотно и рискованно. Лишних денег у компании нет. Давайте оставим старую, просто предложим разработчику доплату за администрирование и обновление — пусть он продолжает ее развивать. Если что-то произойдет, будем оперативно решать. А пока пусть все остается как есть. Уже много лет так работает — и ничего, все нормально.

2. «Семь раз отмерь, один раз отрежь». Мы категорически не можем работать с системой, которая из-за сложности обработки данных приводит к ошибкам. Если что-то случится с сотрудником, который занимается поддержкой и развитием, у нас произойдет крупное ЧП! Наша задача — не бороться с кризисами, а сделать все возможное, чтобы такого ЧП не допустить. Нельзя рисковать репутацией. К тому же новая CRM ускорит и сделает более продуктивной работу персонала на всех уровнях. Но поскольку это одна из ключевых систем компании, торопиться не надо. Давайте проанализируем рынок CRM-систем, детально проработаем все риски, оценим затраты, наши возможности по финансированию и лишь после этого запустим проект.

3. «Не откладывай на завтра то, что можешь сделать сегодня». Давайте оперативно запустим проект — быстро выберем систему, которая выглядит наиболее подходящей для наших условий, и начнем ее поэтапно внедрять. Будем последовательно запускать ее по разным подразделениям компании. Изучим обратную связь от тех, кто начнет с ней работать. Если с системой окажется что-то не так — быстро устраним ошибки, поправим наши планы по внедрению. Если совсем плохо пойдет, то перезапустим проект, выбрав другую систему.

Вопрос: подумайте, какой из предложенных вариантов решения приняли бы вы на месте руководства «Кварк»? Обоснуйте свое мнение.

В этом кейсе нет правильного или неправильного ответа. Здесь цель — показать систему мышления, в рамках которой вы привыкли действовать.

Первое решение — «Не стоит чинить то, что не сломано». Система функционирует — и ладно. Доплатим нашему сотруднику за администрирование и обновление старой системы CRM. Это позволит сэкономить: не придется тратить время и деньги на поиск подрядчиков, сложные работы, обучение сотрудников и так далее. Однако здесь нужно учесть, что система устарела — как морально, так и функционально. Она нестабильна, медлительна и неудобна. А ведь деятельность всей компании завязана на ее исправной работе.

А что, если с ответственным за систему что-то произойдет?

Такой тест есть у айтишников: что произойдет с вашим продуктом, если ключевого разработчика собьет завтра Большой Красный Автобус (именно так — все с большой буквы; рис. 6.3). И если ответ — «продукт погибнет», значит, у вас как у управленца есть Очень Большая Проблема. Которую надо решать — ведь дело не в автобусе, а в том, что весь продукт завязан на одном человеке, с которым может произойти что угодно.

Возвращаясь к CRM: как вы думаете, что случится дальше? На мой взгляд, из-за какого-нибудь кризиса — сбоя, потери данных, увольнения ответственного — придется в экстренном порядке внедрять новую систему. При таком развитии событий затраты возрастают многократно. Понадобится экстренный поиск исполнителей, срочное внедрение новой системы и перенос данных, авральное обучение сотрудников.

Так что рано или поздно компания придет к необходимости введения новой CRM. Вопрос лишь в том, каким путем? Довести все до кризиса, а потом его героически преодолеть — модель управления, характерная для России. Как говорится, русский народ не имеет плана действий… Он страшен своей импровизацией.

Давайте теперь рассмотрим второе решение.

«Семь раз отмерь, один раз отрежь». Проводим оценку рисков и затрат, просчитываем варианты и принимаем оптимальное решение на основе полученных данных. В компании пришли к выводу неспешно подобрать новую систему CRM с оглядкой на финансовые, людские и временны́е ресурсы. Новая система нужна, но важно максимально точно рассчитать все риски и быть готовыми к любым неожиданностям.

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

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

Есть и третье решение — «Зачем откладывать на завтра то, что можешь сделать сегодня?» — или, как еще говорят, «Менеджер — человек, который никогда не откладывает на завтра то, что он может заставить других сделать сегодня».

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

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

Подводим итог по первой особенности. Вот результаты моих опросов, в которых приняли участие более 5500 человек. Я просил участников распределить 100% времени между тремя режимами работы (рис. 6.4).

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

Кстати, в госкомпаниях тушение пожаров достигает 70% времени. Приведу яркий пример.

Российский институт развития, осуществляющий финансирование нескольких десятков крупных инновационных проектов. В марте генеральный директор дочернего фонда, отвечающего за финансирование проектов, подает заявление об увольнении. Нового месяц не назначали. В мае внезапно (на самом деле нет) приходят деньги, которые нужно довести до проектов. Скорость прохождения денег в бюджетной системе — отдельная тема для иллюстрации модели Прохорова. Внезапно (на самом деле нет) выясняется, что сделать это без генерального директора фонда невозможно — нужны его подписи под целым рядом документов. Начинается гиперактивная работа по поиску и согласованию кандидатуры гендиректора, его оформлению и срочному проведению платежей. Две недели все причастные «тушат пожар», их нормальная плановая работа почти полностью останавливается. В итоге проекты получают финансирование с задержкой в месяц, запланированные работы института развития массово переносятся.

Любой поработавший в государственных проектах расскажет вам не один десяток подобных историй.

В чем проблема такого подхода? Если половину времени тушить пожары, то все планы, которые мы составляем, будут неактуальны. Постоянно повторяется последовательность: планирование — работа по плану — пожар — возвращение и обнаружение, что план неактуален, — опять планирование — работа по плану — пожар… и далее по новой. Если пожары происходят все время, то с какого-то момента люди перестают планировать. Вообще, тушение пожаров к проектному управлению не имеет никакого отношения. Такой подход на пожаре вообще не работает — это другая модель управления.

Так что модель «А.Н.К.А.» — злейший враг любой системной деятельности. Проектное управление, процессное управление, стратегирование строятся на плановом подходе, на системной работе, на планировании и проработке. Но для стабильного режима («авось, небось, как-нибудь») все это слишком муторно. Авось и без этого обойдемся. А для аврала — слишком сложно. Некогда: «Хватай мешки, вокзал отходит».

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

Отправить