Меня зовут Кристина Маланюк, я заместитель директора по организационному развитию и руководитель проектов внедрения в компании «Внедренцы и Программисты».
В компанию я пришла как стажер-аналитик, доросла до руководителя проекта, кроме этого, занимала должности руководителя отдела аналитики, руководителя отдела внедрения и коммерческого директора.
Наша компания работает в корпсегменте – за плечами 25 проектов внедрения, более 2000 автоматизированных рабочих мест, более 100 тысяч часов, наработанных проектной командой. Мы приходили на проекты третьей командой, спасали совсем утопающие проекты – учились, набивали шишки и прорабатывали этот опыт.
И сейчас я хочу рассмотреть причины провалов проектов – как их можно сразу увидеть, и что с ними делать.
Кейс №1. Заказчик – производитель электрооборудования
Первый кейс – автоматизация компании по производству электрооборудования. У заказчика был запрос – переход с SAP на 1C:ERP.
Рассчитали проект, заключили контракт, проговорили с заказчиком, что им не надо готовить большие бюрократические документы. Пошли делать.
Все идет по плану. Проводим встречи-интервью, сделали себе пометки, получили ответы на вопросы и казалось бы можно переходить на следующий этап – формирование контрольного примера.
Но тут заказчик заявляет, что не видит результата этого этапа и не понимает, что происходит на проекте – какие были сформированы решения. Говорит, что ему нужны протоколы, и без этого двигаться дальше невозможно.
При этом согласованный бюджет на этап обследования – примерно 160 тыс. руб.
Давайте посмотрим на основные статьи, которые мы обычно указываем в КП с заказчиком:
-
Проведение обследования
-
Формирование контрольного примера
-
Проведение моделирования
-
Проведение показа
-
Формирование ТЗ на функциональные разрывы
-
и т.д.
Но дело в том, что кроме очевидных статей в бюджете есть неочевидные статьи:
-
Риски. Это ситуации, когда заказчик сначала считает, что определенные вещи ему не нужны, а потом меняет свое мнение. Приходится идти заказчику навстречу.
-
Менеджмент. У любой команды есть руководитель – руководитель проекта, администратор, менеджер. Оплату его труда также нужно закладывать в бюджет проекта.
-
Подготовка документов. Аналитики проводят интервью с заказчиком, ведут протоколы встреч, структурируют полученные данные. Это тоже время, которое нужно включать в бюджет.
-
Тестовый прогон, пользовательское тестирование.
В итоге из-за того, что нам пришлось готовить протоколы, бюджет на этап обследования в этом кейсе вырос со 160 тыс. до 200 тыс. руб. Но у нас это изначально было заложено в риски.
Что делать, чтобы избежать проблем с бюджетом?
-
Проговариваем, какой результат нужен заказчику:
-
зрелый заказчик: он уже понимает, что входит в бюджет, интересовался предложениями по рынку, поэтому мы просто проговариваем с ним все статьи расходов;
-
незрелый заказчик: с ним нужно более детально проговорить, что входит в каждый этап выполнения проекта, и что будет на выходе.
-
-
Прямо указываем в КП или в договоре, какой пакет документов получит клиент по результатам работы.
-
Всегда включаем в оценку риски.
-
Всегда включаем в оценку менеджмент.
Мы у себя в компании разработали калькулятор, по которому удобно считать стоимость проектов внедрения. Там есть статьи технического характера, и на каждую статью мы закладываем 30% на риски, и 20% на менеджмент. И прямо в таком виде отправляем КП заказчикам. И еще не было такой ситуации, чтобы он говорил, что он не понимает, зачем мы эту наценку закладываем.
Кейс №2. Компания с трубопрокатным производством
Второй кейс – трубопрокатное производство. У компании 7000 сотрудников, 300 автоматизированных рабочих мест.
Цель проекта: переход с 1С:УПП на 1С:ERP.
С нашей стороны есть команда из руководителя проекта, архитектора, 5 аналитиков, 1 разработчика.
Со стороны заказчика: руководитель проекта – ИТ-директор с опытом автоматизации, 10 представителей компании от разных блоков.
Бюджет на моделирование был согласован. Но после того как мы проработали над проектом 6 месяцев, проект закончился провалом, ограничившись этапом моделирования – на реализацию просто не выделили денег.
Почему так произошло?
В проекте был заинтересован ИТ-директор, которому дали возможность делать то, что он посчитает нужным.
Но когда пришло время подписывать акты, ИТ-директор не смог защитить этот проект перед генеральным директором компании, доказать, что эти изменения нужны.
Кроме того, пользователи не захотели переходить с 1С:УПП на 1С:ERP и устроили саботаж – ИТ-директор тоже не смог на них повлиять.
Мы получили свою прибыль, но на это потребовалось много сил и нервов.
Давайте разберемся, как собирать команду, чтобы проект в итоге не провалился.
Если вы строите проект на стороне заказчика:
-
Перед началом проекта задайте себе вопрос – нужен ли он вам? Готовы ли вы вкладывать в него немалые деньги? Если ответ «да», то идем дальше.
-
Выбирайте эффективного РП внутри организации:
-
этот человек должен заниматься только проектом и не иметь параллельных задач (если говорим именно про крупные внедрения);
-
имеет поддержку высшего руководства, есть авторитет среди коллег, его слышат – он сможет отстоять непредвиденные ситуации на проекте;
-
давно в компании, имеет авторитет и контакты с руководителями подразделений;
-
верхнеуровнево знает все бизнес-процессы в компании, понимает, как все устроено.
-
-
Назначайте ответственных по каждому блоку (продажи, закупки, производство, склад, регучет и т.д.) – таких, которые:
-
наделены полномочиями принимать и утверждать решения по своему блоку (по этой причине ответственные обычно – это руководители подразделений, потому что они должны не бояться это делать);
-
хорошо знают бизнес-процессы своего блока и все стыковки с другими отделами.
-
-
Назначайте в помощь ответственным линейных исполнителей: нижестоящих сотрудников, которые реально знают бизнес-процессы в своем подразделении.
Теперь давайте подумаем, кого лучше всего назначить руководителем проекта от заказчика. Есть три варианта:
-
Главный бухгалтер: давно работает в компании, знает все бизнес-процессы, сам собирает и сдает отчетность.
-
Финансовый директор: давно работает, знает все бизнес-процессы, участвует в стратегическом планировании, знает цели и задачи компании, его уважают в коллективе.
-
ИТ-директор: работает недавно, но знает, как устроено производство, есть опыт внедрения, самостоятельно решает технические вопросы в компании
Кого выберем?
-
Главный бухгалтер нам не подходит, потому что он может быть загружен, например, квартальной отчетностью, ему некогда заниматься проектами. Поэтому мы либо снимаем с него обязанности главного бухгалтера и погружаем в проект, либо этот вариант вообще не рассматриваем.
-
Финансовый директор – подходит. Это самый очевидный и правильный выбор. Он знает, как все устроено, он участвовал в стратегическом планировании, и он понимает, зачем ему внедрять эту программу.
-
ИТ-директор – неудачный вариант. У него не получится уделить должное внимание проекту, будет отвлекаться на текущие рабочие задачи. А если он еще и работает недавно, у него нет должного авторитета в компании.
Следующая проблема, которая вытекает из этого кейса – пользователи не хотят сотрудничать.
Почему:
-
Первая причина – страх выйти из зоны комфорта. Это нормально, наш мозг так устроен, он просто не хочет ничего менять. Он привык всю жизнь собирать отчеты в Excel, и его не интересуют никакие другие программы.
-
Страх показаться некомпетентным (это больше свойственно руководителям). Это тоже нормально.
Как решить эти проблемы?
-
Личный контакт. Пользователя нужно успокоить, что вы не контролеры, а помощники:
-
чем более открытыми вы будете в процессе общения, тем меньше вероятность, что вам будут строить препятствия;.
-
а если закрыться от пользователей, проект дальше не пойдет – пользователи сильно влияют на ход проекта.
-
-
Административное влияние высшего руководства – только руководитель может сказать своим подчиненным, что им нужно смириться с тем, что бизнес-процессы поменяются. Поэтому решением может быть:
-
документальная фиксация изменений в бизнес-процессах (неизбежность);
-
назначение KPI ответственным за внедрение – тогда у них будет собственный интерес участвовать в этом проекте;
-
пропаганда изменений.
-
Кейс № 3. Компания по продаже мебельной фурнитуры
Переходим к третьему кейсу – внедрению 1С в компании по продаже мебельной фурнитуры.
Цель: Хотят внедрить 1С по совету знакомого генерального директора хлебобулочного производства.
Запрос звучит так: У моих знакомых стоит 1С. Им пришли и все сделали, теперь генеральный директор видит все цифры по своей компании. Мы можем посмотреть, как у них, и сделать так же?
Почему ничего не получится?
-
«Сделать, как у друга» – это не цель. Не получится «взять у кого-то и просто перенести в другую компанию.
-
Хлебобулочное производство и продажа мебельной фурнитуры – это разные масштабы компаний, разные сферы деятельности, разные бизнес-процессы, разные бюджеты.
В начале проекта важно поставить цель. Цель внедрения должна быть конкретная, понятная, ограниченная по времени – только тогда она приведет к результату. Если мы поставим цель, которая ни к чему не приведет, все будут недовольны – результата не будет.
На слайде указаны три цели, но только вторая из них может быть достигнута:
-
Первая цель – нереалистичная.
-
А третья – слишком абстрактная и ни к чему не приведет. Мы не понимаем, что за показатели, какая кнопка, где она находится, и в каком формате директор хочет эти показатели видеть.
На схеме показано, по каким характеристикам нужно формулировать цели проекта при постановке по методике SMART. И какие вопросы себе нужно задать, чтобы сформулированная цель была конкретной, измеримой, достижимой, актуальной и ограниченной по времени.
Кейс № 4. Компания по производству электрооборудования
Перейдем к четвертому кейсу – компания по производству электрооборудования.
Цель: Переход с SAP на 1С:ERP за месяц – необходимо к Новому году перенести в программу остатки и историю данных.
Почему в такие сроки эта цель невыполнима?
Проект состоит из нескольких этапов:
-
Обследование (1-6 месяцев). Цель этапа: выяснить, какая структура компании, какие бизнес-процессы и функции выполняются, что необходимо реально переносить. Результат: мы общаемся, проводим интервью, получаем оцифрованную картину по бизнес-процессам в компании. После этого этапа обязательно необходимо собрать и задокументировать контрольный пример с реальными данными, используемыми в компании. Пользователи должны понимать, что они там увидят – иначе они не поймут, зачем им нужен переход на новую систему. Важно настаивать на контрольном примере.
-
Моделирование (1-6 месяцев). Цель этапа: показать, как бизнес-процессы заказчика будут выглядеть в новой программе, выявить функциональные разрывы. Результат: получаем смоделированный бизнес-процесс на новом ПО. Здесь также рождается документ «Функциональные разрывы», который выходит на следующий этап в виде ЧТЗ. Это верхнеуровневое техническое задание, написанное пользовательским языком – важный документ, который у нас должен быть.
-
Разработка (2-9 месяцев). Цель этапа: доработать ПО, разработать инструменты переноса остатков и данных. Результат: мы получаем программу-прототип – это та ваша ракета, с которой вы дальше пойдете.
-
Обучение (1 месяц). Цель этапа: подготовить пользователей к работе с программой. На этапе обучения мы записываем видео, пишем инструкции, проговариваем, пока все не начнут понимать, как работает новая система и что с ней делать. Результат: Обученные сотрудники = спокойные сотрудники. А спокойные сотрудники = спокойное руководство.
-
Подготовка к запуску (1-3 месяца). Цель этапа: протестировать функциональность, перенести остатки и данные. Результат: мы ведем сотрудников «за руку», помогаем разобраться, протестировать систему
-
Запуск системы (до 1 месяца): Цель этапа: ввести систему в эксплуатацию. Результат: переход на этап сопровождения. Оно может длиться бесконечно – если заказчик доволен, то он остается с вами на долгие годы, готов и дальше что-то дорабатывать, улучшать. Здесь тоже мы ведем сотрудников «за руку», отвечаем на вопросы сотрудников и помогаем им.
Мы рассмотрели несколько проблемных кейсов и теперь подытожим риски, с которыми можно столкнуться на проектах:
-
Неправильно просчитанный бюджет
-
Незаинтересованность руководства
-
Нежелание пользователей сотрудничать
-
Нереализованные ожидания заказчика
-
Непрочное целеполагание
Вопросы от слушателей
Почему бы заказчику не нанять опытного РП с рынка на конкретный проект? Если это сильный управленец с опытом, такие проекты обычно завершаются успешно.
Если руководство заинтересовано в проекте, то да, можно взять человека со стороны, у которого есть опыт, и его поддерживает руководство. В этом случае, даже если пользователи и начнут сопротивляться, руководство даст указание, и им придется смириться.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.
