Одна история не взлетевшего проекта внедрения корпоративной ИТ-системы

Просмотров: 3358
Автор:
Фролов Борис Александрович Рейтинг3690

Фролов Борис Александрович

Директор ИТ — АвтоСпецЦентр

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

Ниже  краткое описание основных проблем, которые у нас возникли с момента старта проекта до его отмены.

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

Мы не понимали, что проектная команда будет делать завтра, через неделю, через месяц. Первые полгода у нас не было ни плана работ на ближайшие 1-2 недели, ни плана на 2-3 месяца, ни стратегического плана до момента внедрения. После первых изменений сроков у нас появился план из нескольких тысяч задач с микроменеджментом, что выглядело как на рисунке ниже, впоследствии план опять исчез под прикрытием модного слова Agile. В обоих случаях руководитель проекта не мог внятно ответить на вопросы по срокам и ресурсам.

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

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

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

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

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

Плавно переходим от внешнего руководителя к проблемам на стороне Заказчика. Понятно, что если внутренняя ИТ-команда способна выполнить проект своими силами и имеет достаточный кредит доверия от руководства, то нанимать внешнюю команду никто не будет. В нашем случае локальное ИТ было не готово к новой системе. Большинство ошибок можно было бы предотвратить, если бы на тот момент у меня был достаточный опыт работы с внешними компаниями при внедрении, и я бы знал основные моменты, на которые необходимо обращать внимание. Следует отметить, что к моменту запуска мы себя планировали и сумели модернизировали и усилить. На нашей стороны было четкое понимание, если локальная ИТ не готова будет поддерживать и развивать внедренную систему, то либо через непродолжительное время компания выполнит возврат к существующей системе, либо придется платить за каждое изменение бизнеса деньги внешним подрядчикам. Если для вспомогательных систем это приемлемо, то для стратегической системы предприятия это было бы слишком дорого и содержало высокие риски зависимости работы предприятия от внешней компании. Указанный отмененный проект мы смогли запустить через 1,5 года своими силами с минимальным привлечением внешних подрядчиков (бюджет нового внедрения составил 2% от бюджета первоначального проекта).

И последняя причина провала проекта важная, но, с моей точки зрения, не критическая — неготовность рядовых сотрудников и руководителей низшего уровня к новой системе. Почему некритическая? — если руководство хочет, ИТ-команда умеет и может, внешний подрядчик  адекватный — то внедрение, хоть и болезненное, но будет. И такие внедрения на практике у меня были. На что здесь следует обратить внимание: если рядовой бизнес не верит в запуск системы, то большая часть требований будет забыта, тестирование будет выполнено формально и реальную картину работы вы поймете только после запуска. Если локальная ИТ команда готова существенно увеличить свой рабочий день и обладает силой, авторитетом и компетенций, ТОП-менеджмент поддерживает проект, то за 2-3 месяца основные проблемы будут решены и система полноценно заработает.

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

1. Слабый руководитель проекта со стороны подрядчика, что вылилось в:
     a. Отсутствие внятного плана проекта
     b. Необоснованные переносы сроков
     c. Некорректную последовательность выполнения задач
2. Отсутствие опыта на стороне ИТ аналогичных внедрений
3. Неготовность бизнеса к внедрению новой системы.

В заключение хочется сделать следующий вывод: цифровые технологии играют всю большую роль в успешной работе предприятия и выводить ключевую функцию внедрения и развития информационных систем и сервисов на внешних подрядчиков – очень высокий риск для организации. Последние 5-6 лет серьезные предприятия консолидируют ИТ компетенции и экспертизу у себя, используя внешних подрядчиков как руки, оставляя функцию мозга за собой. И перед большим внедрением начинать нужно с создания сильной ИТ-команды у себя и только после этого запускать проекты внедрения. Вначале понять с КЕМ идти, и только потом — КУДА.

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

Насколько приведенная выше история падения проекта коррелирует с вашим опытом? Что общего, какие отличительные признаки грядущего провала вы можете выделить в своей практике?

Комментарии (15)

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

  • Скрыть ветвь
    Рейтинг76210

    Зам. начальника управления информационных технологий

    АО МПО им.И.Румянцева

    11.02.2019 12:18
    Блестящее описание! Собственно, это калька неуспеха большинства проектов.

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

    В корне не соглашусь с посылом " Вначале понять с КЕМ идти, и только потом КУДА." Все-таки, распределение должно быть такое:
    1. Что
    2. Как
    3. С кем.
    А не наоборот. Под ЧТО и КАК уже создают команду.

    Указанный отмененный проект мы смогли запустить через 1,5 года своими силами с минимальным привлечением внешних подрядчиков (бюджет нового внедрения составил 2% от бюджета первоначального проекта).

    То есть, бизнес стал готов? Рядовые исполнители повернулись лицом? И бизнес, наконец, выступил в роли заказчика?

    По своей практике. Налетал и на такие кочки тоже, но в меньшей степени. Но теперь выведено правило :
    1. Пока задачу не поставит бизнес и не определит своего представителя, принимающего работы - не делать ничего. Т.е., сначала скажите, а кому это надо.
    2. Своя команда на проект д.б. обязательно.
    3. Выбор внешнего подрядчика - штука очень тонкая и интимная. Предыдущий опыт обязателен и должен быть предъявлен. Проектная команда подрядчика предварительно тестируется и всячески экзаменуется. Обычно, сразу видно кто чего стоит, кто что знает.
    4. Система оплаты подрядчику должна быть выстроена так, чтобы не было "финтов" влево-вправо. Только от результата без ссылок "мы не так поняли", " мы это забыли", "мы это потом допилим". Есть результат - есть деньги за этап. Все это прописывается. нюансы возможны любые, но общий подход должен быть таким.
    3
  • Скрыть ветвь
    Рейтинг3690

    Директор ИТ

    АвтоСпецЦентр

    12.02.2019 22:39

    Ответ на « Блестящее описание! Собственно, это калька неуспеха... »

    Спасибо за комментарий. Не со всем написанным вами согласен - но у каждого свой путь и свой опыт )))
    0
  • Скрыть ветвь
    Рейтинг70

    Главный специалист Управление Информационных технологий ОАО

    ОАО «АК «Транснефтепродукт»

    13.02.2019 17:47

    Ответ на « Блестящее описание! Собственно, это калька неуспеха... »

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

    Вот, к сожалению, выбор подрядчика на проект происходит в результате процедуры торгов, так что заранее узнать, кто собирается прийти на конкурс, и всех протестировать - нереально. Да и даже если подрядчик не пройдет наше тестирование - ему же по закону нельзя запретить участвовать в конкурсе.
    Так что влиять можем только на внутренние ресурсы. А подрядчик - это зачастую лотерея.
    2
  • Скрыть ветвь
    Рейтинг3690

    Директор ИТ

    АвтоСпецЦентр

    13.02.2019 18:43

    Ответ на « 3. Выбор внешнего подрядчика - штука... »

    Именно. Более того, есть опыт, когда выбираешь подрядчика за конкретных консультантов, которые в течение 2-3 месяцев после старта проекта уходят из компании подрядчика. А договор уже заключен и проект идет. А ключевую компетенцию, за которую выбирали команду - не по вашей вине команду покинула.
    1
  • Скрыть ветвь
    Рейтинг76210

    Зам. начальника управления информационных технологий

    АО МПО им.И.Румянцева

    14.02.2019 09:04

    Ответ на « Именно. Более того, есть опыт, когда... »

    Чтобы такого избежать, уже давно придуман выход. После знакомства с командой подрядчика и с их компетенциями, в договоре отдельно прописывается условие, что замена РП, консультантов может происходить только по согласованию с заказчиком. Указать, что в случае ухода из команды лиц - носителей ключевых компетенций, они могут быть замены на других, но только после тестирования заказчиком. И согласования с ним. В противном случае договор автоматически расторгается.. Это старый прием, его давно многие с успехом используют.
    3
  • Скрыть ветвь
    Рейтинг3690

    Директор ИТ

    АвтоСпецЦентр

    14.02.2019 21:26

    Ответ на « Чтобы такого избежать, уже давно придуман... »

    Но это не спасет от остановки проекта, потери времени и как следствия денег. А с учетом того, что нужен будет повторный конкурс - минимум полгода компания потеряет.
    0
  • Скрыть ветвь
    Рейтинг76210

    Зам. начальника управления информационных технологий

    АО МПО им.И.Румянцева

    15.02.2019 12:37

    Ответ на « Но это не спасет от остановки... »

    Да. не спасет. Это называется форс-мажор и от него никто не застрахован. Но значительно снизить риски от неуспеха проекта таким образом можно.
    Да и не станет нормальная компания (если она нормальная) на серьезном проекте вот так просто менять команду и идти на конфликт с заказчиком. Можно ведь еще и на ровном месте заработать ярлык "недобросовестный поставщик". Тогда вообще ни в один приличный дом не пустят больше.
    1
  • Скрыть ветвь
    Рейтинг76210

    Зам. начальника управления информационных технологий

    АО МПО им.И.Румянцева

    14.02.2019 08:59

    Ответ на « 3. Выбор внешнего подрядчика - штука... »

    Да, Вы правы, конечно. Но лишь отчасти :).

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

    1. Не надо тестировать всех. Имея опыт работы и общения, в принципе, специалист знает примерно , какие компании обладают необходимым опытом. Или имел с ними дело. или работал там когда-то. Варианты различны. Потому и надо ограничить сразу круг поставщиков - 2-3 претендента. Или, если стопроцентно уверен - сразу брать одного.
    2. И его всячески проверять и тестировать до конкурса. Убеждаться в компетентности специалистов, задавать вопросы. причем, делать это должен бизнес-заказчик совместно с ИТ-руководителем. И принимать решение. Чтобы потом избежать выражений типа "кого вы наняли", "где вы их нашли?". Пардон, но выбирали Вы !
    3. Только после всего этого можно писать ТЗ на конкурс. Сам претендент и напишет. Как , что там должно быть, и как все прописать - думаю, люди искушенные сами прекрасно понимают. Не хочу тут слишком уж крамольные мысли излагать :).
    4. Проводить конкурс и выбирать подрядчика.

    Отмечу еще одну вещь. Лучше прописать в ТЗ и условиях участия как можно больше граблей, препонов, условий и требований. Это поможет на первом эе этапе отсечь аферистов, действующих по демпингу. Да и просто некомпетентных людей. Не бояться переборщить.
    На мой взгляд, пусть лучше ФАС по возможной жалобе потом вас одернет и укажет на некоторые несоответствия, чем вы получите у себя на подряде "не пойми кого", кто сдерет деньги, ничего не сделает и исчезнет. Имхо, в 8 случаях из 10 никто жаловаться не будет, только если это не профессиональные жалобщики (есть и такие).

    4
  • Скрыть ветвь
    Рейтинг90
    Долго терпели. К сожалению Аджаилом многие прикрывают сейчас собственное раздолбайство и некомпетентность.
    4
  • Скрыть ветвь
    Рейтинг70

    Руководитель проектов

    ООО "Стройтрансгаз Трубопроводстрой"

    13.02.2019 21:06
    Чем меньше звеньев между заказчиком и исполнителем, тем выше вероятность успешного завершения проекта.
    Приходилось наблюдать схему взаимодействия заказчика с исполнителем из 6-8 ми (звеньев), заказчик заканчивается на функциональных требованиях, далее только ИТ. В схеме четко поделены зоны ответственности и функциональные роли. После пересмотра сложившейся схемы и сокращения до двух – трех звеньев, существенно снизились затраты и время выполнения работ.
    0
  • Скрыть ветвь
    Рейтинг850

    ИТ-директор

    Элком-Электро

    14.02.2019 00:45
    Очень важно разделять такого рода проекты на собственно "внедрение ИТ системы" и "изменение бизнес процессов под эгидой внедрения ИТ системы". Зачастую Бизнес Заказчик хочет именно второй вариант, система не рассматривается как инструмент для людей, а скорее как их заменитель. Щас вложимся, все автоматизируем, а потом через ФОТ отобъем. Т.е. бизнес может и готов, но не к тому что нужно. В итоге оказывается, что ИТ команда должна за бизнес подразделения "придумать" как им теперь работать и какую выгоду от системы получить. И это тупик, если РП не меняет границы проекта или не договаривается с бизнесом о других правилах игры.

    Внешний подрядчик не будет в этом разбираться. Раз позвали, значит понимаете зачем, а если не понимаете - ваши проблемы.
    Поэтому в таких проектах как минимум половину пути надо пройти внутри компании и только потом уже с конкретикой выходить на тендер.
    3
  • Скрыть ветвь

    Эксперт по цифровой трансформации

    Независимый эксперт

    14.02.2019 09:59
    Хорошая статья. Был и на стороне заказчика и на стороне подрядчика и сам знаю, насколько сложно найти действительно квалифицированных исполнителей за той шелухой, которой прикрыты завлекательные предложения. Сейчас, мне кажется, с этим стало еще хуже. Есть масса людей, ловко оперирующих популярными словами и хорошо пускающих пыль в глаза. а работать никто из них не умеет. Выбор крупного и известного подрядчика - тоже не гарантия. У меня, по итогам проекта, были очень серьезные претензии к компании, занимающей одну из первых строчек в списке российских интеграторов (компания претензии признала). С другой стороны, когда сам выбирал, кого из сотрудников поставить на проект, понимал, что клонировать 20% тех, кто действительно хорошо работает, я не могу.
    Проблема, наверное, в том, что низкая квалификация консультантов не только не стала препятствием к выполнению ими работы, но перестала пугать и исполнителей и заказчиков и самих консультантов. Свыклись...
    2
  • Скрыть ветвь
    Рейтинг76210

    Зам. начальника управления информационных технологий

    АО МПО им.И.Румянцева

    14.02.2019 10:46

    Ответ на « Хорошая статья. Был и на стороне... »

    Дело не только в низкой квалификации консультантов. Есть и люди с высокой. И довольно умные и талантливые. Но, к сожалению, подавляющее большинство из них всегда работали только по одну сторону прилавка. Знают систему, знают методологию, законы, нюансы. Т.е., знают "как надо". А у нас есть еще и жизнь. И как на конкретном предприятии воплотить все свои теоретические знания, подогнав их под реалии действительности - знают единицы. Только те, кто работал и с другой стороны. Вот в чем основная беда.
    0
  • Скрыть ветвь
    Рейтинг70

    ИТ сервис менеджер

    АО ИЛЬ ДЕ БОТЭ

    14.02.2019 12:37
    Спасибо большое за статью!
    Полностью соглашусь с тем, что на стороне ИТ Заказчика должна быть сильная позиция со способностью оценить Исполнителя, его Предложение, сопоставить с требованиями и в случае непокрытых рисков завернуть всё еще до подписания договоров.
    Считаю, что в ИТ проекте должны всегда быть три ответственных (примерно одного уровня авторитета): (1) со стороны бизнеса заказчика; (2) со стороны ИТ заказчика; (3) со стороны исполнителя. Уровень компетенции у них должен быть не ниже Менеджера (либо старшего аналитика). Эти люди должны знать, за что отвечают, и понимать границы их зон ответственности и немного понимать друг друга, чтобы договориться и следовать общему регламенту взаимодействий.
    2
  • Скрыть ветвь
    Рейтинг910

    Директор по информационным технологиям

    Globaltrans(новая перевозочная компания)

    15.02.2019 00:01
    Рассказать о неуспешном проекте смелый, я бы даже сказал вызывающий ход. А по сути соглашусь с первым комментом, все диспозиция описанная в статье видится так.
    - кто-то и зачемто инициировал проект
    - бизнесу он не нужен был
    - ИТ демонстративно отстранилось (причины могут быть самые разные) - запаслось попкорном и смотрело как подрядчик умрет в проекте
    - потом ИТ торжественно проект терминировал.

    Вчера в Сколково Алферов про такие проекты говорил: если в случае успеха проекта вам НИЧЕГО не будет, и в случае неудачи проекта вам НИЧЕГО не вменят, то и в результате проекта вы НИЧЕГО получите.
    Смотрите тут пока не закрыли: в видео точка 1ч 37м 40сек Эффективность проектного управления - вопрос из зала про систему мотивации при внедрении проекта - она должна быть и как минимум отвечать на два ключевых вопроса.
    3

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