Подход SAP к ведению проектов
Антон Пранов, SAP
Подход SAP к ведению проектов
Докладчик: Антон Пранов, SAP
Я представляю «Project Delivery Office SAP СНГ», работаю в основном с крупными металлургическими предприятиями. У меня были проекты в самых разных направлениях на «ОМК», «НЛМК», на «Северстали» и так далее, сейчас занимаемся «Металлоинвестом». Я начал свою IT-карьеру в Siemens еще в Канаде, прошел путь от программиста до руководителя проектов в Siemens Canada. Затем работал в других канадских компаниях, в том числе Canada Post, тоже занимался управлением проектами. Потом вернулся в Россию и опять попал на немецкую волну, работал в Zeppelin. Эта компания занимается дистрибуцией техники Caterpillar. В начале XX века они строили дирижабли, а потом переориентировались на коробки передач. Компания ZF выпускает коробки передач для множества марок техники и автомобилей. В «Zeppelin» я тоже был на руководящих должностях, от руководства программой внедрения SAP до главы IT всего Zeppelin International в СНГ. После этого я перешел в SAP СНГ и здесь занимаюсь руководством проектами и программами, связанными, в основном, с внедрением разнообразных аспектов нашей замечательной системы.
Проекты SAP внедряются с помощью методологии ASAP, ориенттированной непосредственно на использование SAP в промышленном производстве. Это определенные фазы, наборы фаз, на которые мы разбиваем нашу работу, чтобы структурированно внести проект в жизнь. Эта методология не противоречит всем известной методологии PMI PMBoK, наоборот — она с ней взаимосвязана, интегрирована, потому что все проекты ведутся с учетом и с помощью техник, которые в PMBoK описываются. То есть ASAP — это достаточно мощное техническое расширение методологии PMBoK, общее для внедрения любых других проектов, но специализированное для внедрения проектов SAP.
Управление проектами вообще очень важно. Исследователи говорят, что на провальные проекты по информатизации ежегодно тратится 75 миллионов евро, и эта цифра, наверное, сильно занижена: по исследованиям Gartner, которые они собирали в течение последних двадцати лет, порядка 20 % больших проектов являются неудачными. В первую очередь, из‑за своего размера, продолжительности и слабой выстроенной системы управления проектами, следствием чего является демотивация людей. Проект должен быть динамичным, он должен быть разбит на конкретные осязаемые куски с определенными результатами, которые можно показать и тем самым мотивировать команду: и свою, если речь идет о стороннем исполнителе, и команду заказчика, который увидит сразу эти результаты и понимает, что дело движется.
И вот именно основным результатом неправильного построения программ, road-maps, является провал больших IT-проектов. Поэтому их, конечно, надо разбивать на определенные куски осязаемые, и каждый из этих кусков внедрять отдельно в увязке с другими. Вот такая интегрированная должна быть система. Именно поэтому в последнее время уделяется все больше внимания направлению управления проектами. Сначала этому не придавалось большого внимания: считалось, что проект, поскольку он связан с какой‑то автоматизированной системой управления различными областями бизнеса — чисто техническая задача: система просто должна быть каким‑то образом написана и внедрена. И проект зачастую оказывался неуспешным, потому что не было понимания, не было методик управления различными аспектами — как проектной командой, так сказать, непосредственными участниками проекта, так и так называемыми стейкхолдерами — их обычно очень много и на стороне консалтинговой компании, и на стороне заказчика. Все эти люди обязательно должны участвовать в проекте и понимать, о чем идет речь. Важно и управление коммуникациями — все должны обязательно знать, что происходит на проекте в любой момент времени. Очень важно управлением рисками, бюджетом и всеми остальными аспектами наших проектов. Поэтому управление проектом становится все более и более важным и необходимым в последнее время.
Что такое проект? Во-первых, у проекта есть определенные параметры, отличающие его от операционной деятельности. Любой проект — это временное предприятие: у него есть совершенно четкое начало и четкий конец. В этот промежуток времени должен быть создан уникальный результат или продукт, или внедрена система, которая относится к этому конкретному проекту и которой не было до сих пор. То есть выпуск одинаковых автомобилей на конвейере проектом не является. В принципе, можно каждый автомобиль назвать проектом, но поскольку это просто штамповка, то это уже операционная деятельность — и там уже совершенно другие методологии, типа SIX SIGMA, которые направлены на постоянное улучшение качества мониторинга конвейерного производства, чтобы отслеживать качество выпускаемой продукции.
Для уникального проекта мы используем методологию ASAP, и методологии PMBoK, которые позволяют управлять уникальными мероприятиями. И на каждом этапе нашего проекта мы можем последовательно уточнять ожидаемые результаты. В самом начале проекта не всегда можно полностью видеть все аспекты, все грани того продукта, который у нас должен получиться, потому что понимание может приходить постепенно. Поэтому вот таким каскадом проект делается: на каждой фазе происходят последовательные уточнения требований к продукту, сроков, трудозатрат и так далее, необходимых для того, чтобы дело сделать.
У любого проекта есть, безусловно, какие‑то ограничения: например, определенное время, которое отводится на создание, на внедрение системы, либо на создание продукта. Также есть определенный бюджет и объемы того, что должно быть внедрено. Соответственно, вот эти контенты и вот этот треугольник ограничений знаменитый — он абсолютно взаимозависим. То есть при изменении чего‑то одного обязательно изменяется все остальное. Невозможно одно дело оставить неизменяемым, изменив что‑то другое.
Если меняется время, то, наверное, может увеличиться объем. Если сокращается время, отпущенное на проект, то надо объемы соответственно уменьшать. Можно увеличить затраты, сократив время, то есть, прибавив дополнительное количество новых ресурсов, можно проект сделать за меньшее время, хотя не всегда это получается. Поэтому всегда есть компромисс между составляющими треугольника, который достигается на фазе планирования проекта. В частности, управление интеграцией проекта необходимо, чтобы находить баланс между этими тремя составляющими, которые очень важны на каждом этапе.
Что представляет собой методология ASAP? Это набор определенных фаз, которых сейчас шесть, раньше было пять: не было последней фазы эксплуатации — на английском языке она называется run. Теперь у нас шесть фаз, в каждой из которых существует определенное количество рабочих потоков. Для каждого из рабочих потоков обязательно будут на каждой фазе определенные результаты. Например, первая фаза — это подготовка проекта, осмысление, зачем этот проект вообще нужен, как будет выглядеть конечный продукт. В результате этой фазы приходит понимание объемов проекта, того, что должно быть внедрено, как проект будет организован, как он будет разбит на составляющие, какие компетенции должны быть у команды и так далее. Контракт обычно подписывается где‑то в начале фазы подготовки проекта.
На фазе концептуального проекта начинается непосредственная работа, воплощение написанного в контракте. То есть существует еще определенный набор активностей, которые предваряют даже фазу подготовки проекта: так называемый пресейл, то, что происходит при продаже, консалтинг, который сопутствует приобретению лицензий SAP. Компания покупает лицензии, но они сами работать не будут, поэтому систему надо определенным образом настраивать под конкретный бизнес, и каждый раз эти настройки разные.
Именно поэтому, чтобы систему SAP внедрить на конкретно взятом предприятии нужен обязательно профессиональный консалтинг. Существуют, конечно, стандартные наборы решений, но они не всегда подходят под конкретный бизнес. Немногие компании готовы взять коробочное решение и сразу им начать пользоваться. Хотя такие примеры тоже есть. В России это происходит реже, чем за рубежом. Многие зарубежные компании понимают, каким является размер TCO (Total Cost of Ownership), то есть, сколько стоит программа на фазе эксплуатации, и что каждое изменение, отклонение от стандарта должно поддерживаться отдельно, причем эта поддержка не входит в стоимость лицензий. То есть SAP уже не поддерживает расширение, которое сделано. А бывает, что этих расширений сотни. И заказчик должен прекрасно понимать, что эти расширения будут достаточно дорогостоящими для него.
Пример привести из недавней практики: на «ОМК» была внедрена система ERP, проект был достаточно большой, несколько лет длился. Буквально через пару лет после того, как система была запущена в продуктив, мы решили сделать аудит кода и обнаружили колоссальное количество Z-кода — так в SAP называется код расширения, который пишется под конкретные разработки и под нестандартные требования. Клиентом на это были потрачены большие деньги, и надо было посмотреть, что вообще происходит с этим Z, как используются все эти разработки. Благодаря стандартным инструментам SAP мы достаточно быстро провели такой анализ, чтобы посмотреть, как код работает, и выяснилось, что 80 % этих разработок за два года ни разу не включались!
Всегда нужно помнить: если вы заказчики, и вы на своем предприятии устанавливаете SAP, то надо стремиться максимально «прикрутить» свой бизнес, своих бизнес-заказчиков к стандарту SAP. Значительно проще, дешевле и быстрее внедрить SAP в стандартном виде, посмотреть, как это работает, посмотреть, как бизнес на нем держится. И потом уже включать или записывать дополнительные расширения. Обычно, когда мы начинаем собирать требования, то все, естественно, бегут со своими хотелками: «Я хочу красную кнопочку; я хочу здесь желтый обязательный экран, чтобы у меня вылезал дополнительный», миллион дополнительных проверок, которые никогда не используются, и так далее. Так как все это стоит трудозатрат при внедрении и поддержке, это очень важный момент. При каждом проекте в боевом, так сказать, консалтинге мы каждый раз набиваем вместе с заказчиком огромное количество шишек. На самом начальном этапе никто и слушать про это не хочет, все хотят все, а потом выясняется, что это «все», оказывается, никому нужно не было.
Итак, мы собираем требования, затем их уточняем и начинаем реализовывать в документации — она описывает, как все эти требования будут выглядеть в системе. Далее на фазе реализации все это реализуется уже в системе SAP, тестируется. На этой заключительной фазе подготовки готовятся данные — ведь бизнес на предприятии не останавливается на время проекта, все идет, имещиеся системы работают, данные накапливаются.
И вот на этой фазе заключительной подготовки мы должны перенести все данные аккуратно из старых систем в новые так, чтобы в «час Ч» отключить старую систему, включить новую — и чтобы люди после этого рубежа на продуктивном старте начали работать в новой системе, отключив старые. Это очень важный момент, который всегда стрессовым является для любого предприятия: люди должны быть обучены, служба поддержки должна быть в полной боеготовности на «низком старте», все данные должны быть аккуратно перенесены, все справочники и все остатки должны быть перекинуты в новую систему, чтобы люди смогли прямо с понедельника прийти на работу и начать работать в SAP вместо своих предыдущих систем.
Собственно, на этой фазе продуктивный старт. Она почему такая большая, потому что продуктивный старт — это просто отсечка. В пятницу вы ушли с работы, работая в старых системах, в понедельник вы пришли работать в SAP. Вот это все продуктивный старт. Но на самом деле проходит несколько месяцев, пока вал проблем и ошибок, которые обычно возникают на первых этапах, переходит в относительно стабильное русло. Всегда очень много вопросов, проблем, люди не понимают или забывают, даже пройдя обучение, как в определенной транзакции действовать, что нужно, что необязательно и так далее. Здесь ведется большой объем поддержки.
Когда система стабилизировалась, начинается фаза эксплуатации. Она очень важная. Ее раньше как бы не было, и было понятно — продуктивный старт, и все, мы встали и ушли. А на фазе‑то эксплуатации как раз надо смотреть, что действительно нужно дополнительно, чего не хватает в системе конкретно для данного клиента не хватает. Здесь правильно начинать составляеть список дополнительных требований.
И вот так в течение какого‑то периода времени собирается реестр задач, которые потом можно реализовать, дополнительно пригласив консультанта либо свою службу поддержки — к этому времени она может вырасти в достаточно мощную организацию, которая будет в состоянии реализовывать такие небольшие проекты. На этой фазе происходит дополнение и развитие дальнейшее системы.
Теперь давайте перейдем к более детальному рассмотрению фаз методологии ASAP, и что в каждой фазе происходит. Все работы у нас структурированы, разбиты на определенные потоки. Вот эти рабочие потки, семь штук, они в каждой фазе присутствуют. Давайте каждый из них рассмотрим сверху вниз.
Вот первая фаза управления проектом. Это общий интегрированный взгляд сверху и усилия, которые предпринимаются для того, чтобы ничего не расползалось. Чтобы все понимали, что происходит, чтобы команды работали слаженно, чтобы все необходимые участники были вовлечены в процесс, все всё знали, чтобы риски отрабатывались, а правильные статусы по проекту выпускались и все видели статус в достаточно регулярном виде, и так далее и тому подобное. То есть вот это все управление проектами — в этом первом потоке, и оно на всех фазах, безусловно, существует.
Управление организационными изменениями — это вещи, которые происходят в любой компании с приходом SAP. Если внедряется продукт SAP — например, система ERP, компания клиента реформируется, в ней происходят организационные изменения. Не бывает такого, чтобы компания осталась неизменной: могут какие‑то отделы упразднить или объединить, обязательно возникнут какие‑то новые должности. Эти изменения надо обязательно планировать, координировать, надо людей обучать и переводить на новые должности, чтобы к моменту продуктивного старта новая организационная структура предприятия была готова и могла заработать в том виде, в каком она должна быть сразу. В этот поток обязательно интегрируется следующий поток обучения, который тоже очень важен.
Обучение необходимо не только проектной команде, но и бизнес-пользователям — тем, кто получает новые должностные обязанности. У нас в SAP СНГ есть мощный учебный центр, который может организовывать обучение — как на нашей территории, так и на территории клиента. Это обучение происходит сначала для членов проектной команды, потому что проектная команда формируется зачастую с нуля. На предприятиях, которые внедряют SAP с нуля, обычно не существует проектного офиса. Есть бизнес-пользователи, люди, которые хотят этим заниматься, которым интересно, которые готовы перейти в проектный офис на новые должности и сделать такой поворот в своей карьере. Они становятся бизнес-заказчиками или консультантами, непосредственно разрабатывают вместе с консультантами SAP бизнес-требования, принимают результаты проекта. И постепенно они сами проникаются, пропитываются духом системы, понимают, как она работает, становятся ключевыми потом пользователями этой системы. И они тоже обязательно должны проходить обучение. То есть для них нужен общеобразовательный курс SAP. У нас есть разнообразные курсы, которые позволяют, во‑первых, получить общее представление о том, как работает система, как она управляется. И по специализированным функциональным областям можно дополнительно набраться знаний, взяв определенное количество курсов, даже получить сертификацию.
Отдельный поток посвящен именно обучению и его планированию: уже в самом начале проекта надо спланировать, как всех людей обучать, когда и на каких курсах. Достаточно часто эти курсы происходят с отрывом от производства — в частности, курс TERP10, который у нас преподает замечательный преподаватель Иван Новиков. Это двухнедельный курс, и я советую всем, кто не обучался, но планирует когда‑либо внедрять SAP, обязательно это курс пройти, потому что он затрагивает все модули. Там можно попробовать, прямо создавать транзакции, потренироваться по всем задачам в системе SAP: создать сотрудников, модули HR, и так далее, потрогать просто вживую, как работает система, как она выглядит. Вот этот курс — две рабочие недели, десять дней. После него выдают сертификат, но это такой серьезный отрыв от производства, поэтому это тоже надо планировать.
Управление данными. Данные — это кровь предприятия, которая по вот этим жилам, которые мы выстраиваем в виде архитектуры системы, течет внутри нее. Данные бывают двух видов: мастер-данные и транзакционные данные.
Мастер-данные — это наборы справочников, которые не меняются на лету: определенные материалы, контрагенты, поставщики, клиенты, и так далее и тому подобное. Эти мастер-данные должны быть определенным образом изучены на самом начальном этапе проекта, и мы должны понять, каким образом эти мастер-данные должны трансформироваться, чтобы им попасть в новую систему SAP, потому что они просто так, копипейстом, не переносятся. Другая структура, другая файловая система, и так далее и тому подобное.
В SAP есть набор инструментов, который позволяет трансформировать массово данные из одного формата в другой, переносить данные в SAP, вытаскивать, в частности, из системы Oracle. Но, опять же, чтобы это дело делать, надо обязательно провести достаточно большое количество встреч и исследовательской работы вместе с представителями заказчика, чтобы понять, какие конкретно параметры по каждому виду данных должны быть перенесены и в каком виде. Потому что далеко не все переносится всегда целиком. Плюс к тому, мы не переносим все данные, которые сидят в системах, так как не все они нужны. Поэтому надо определиться, какие данные будут горячими, так сказать, hot data — быстро доступными, чтобы формировать оперативную отчетность и видеть, как живет бизнес. Обычно это данные за два года.
Есть данные, которые называются cold data — данные достаточно удаленного прошлого, больше двух лет, эти данные обычно архивируются. Нам надо понять, каким образом эти данные будут архивироваться, как мы будем их доставать в случае, если еобходима отчетность больше, чем за два года, как быстро они должны доставаться, где они должны храниться, как будут работать бэкапы, и так далее и тому подобное. То есть вот это все здесь происходит вот на этом потоке. Плюс, естественно, мы смотрим на транзакционные данные: данные, которые наполняют непосредственно ежедневную работу. Это просто числовые значения, остатки на счетах и так далее. Вот эти все вещи, они должны быть подготовлены. Это целый большой отдельный мир. Пишется стратегия миграции данных, проводятся исследования большие. И зачастую заказчик понимает, что данные у них не готовы к переносу в SAP. Во-первых, непонятно совершенно, какие есть аналитические показатели для того, чтобы формировать определенные отчеты, то есть не хватает каких‑то параметров у этих данных, и каким образом иерархическая структура у этих данных работает вообще. Зачастую бывает и такое. И тогда приходит понимание, что эти данные надо перелопачивать. А если там два миллиона материалов в справочнике, то возникает понимание, что работа эта не на один день и даже не на один месяц, а зачастую она занимает времени до года.
Для этого нанимается дополнительный подрядчик, который начинает заниматься зачисткой этих данных. Во-первых, нужны методологи, которые говорят, как эти данные должны выглядеть в системе, с какими параметрами они должны быть, как они взаимозависят друг от друга и так далее и тому подобное. Огромная работа может быть проведена только для того, чтобы просто подготовить данные, очистить их для размещения в систему.
Основной поток, которым все занимаются и который наиболее видим для всей команды бизнес-пользователей — это, безусловно, управление бизнес-процессами. Именно это вы делаете каждый день, будучи пользователями систем в своих компаниях. Эта ежедневная деятельность должна быть каким‑то образом отображена в системе.
Эти бизнес-процессы формируются в виде определенных диаграмм. Они детализируются постепенно, методом drill down: сначала верхнеуровневые шевроны и диаграммы, которые потом углубляются и превращаются в разветвленные схемы — workflow определенных процессов. И доходят уже до уровня конкретного транзакционного, где на каждой операции ставится ярлык с SAP-транзакцией. Тогда вы смотрите, действительно ли стандартная система SAP соответствует вашим бизнес-процессам, и какие есть функциональные разрывы — многие слышали, в SAP они называются «гэпы» (от английского слова gap) и как раз на этой стадии и появляются. В этот момент приходится часто принимать трудные решения: либо писать Z-код, чтобы заполнить этот разрыв, либо корректировать бизнес-процесс, чтобы все‑таки в прокрустово ложе стандарта уложиться. Обсуждения этого выбора происходят как раз на этой фазе: SAP Consulting или другой подрядчик, работающий с данным клиентом, специалисты заказчика и консультанты, которые очень хорошо знают индустриальные особенности применительно к каждой конкретной компании и отрасли, начинают рассказывать, как это работает в SAP, и как мы подобные расширения делали на других проектах, и как эти расширения сработали или нет.
Все зависит еще от воли спонсора: это обычно человек, который проект заказывает — IT-директор либо финансовый директор. Если человек достаточно плотно вовлекается в проект, понимает, что влечет за собой разрастание объема, тогда этот человек просто говорит своим сотрудникам: «Ребята, давайте стараться уложиться в максимальные стандарты с минимальными потерями, лучше систему будем развивать потом». То есть это очень важно, и обязательно нужно обеспечить поддержку со стороны спонсора проекта.
Что такое управление техническим решением? Это техническая архитектура: серверы, сети, дисковые массивы, системы бэкапа, системы безопасности, системы доступа к системам, то есть все то, на чем, собственно, система живет. Это как скелет металлический, железки, на которых все воплощается в жизнь. Здесь тоже огромный объем работ, причем базисных, потому что в SAP очень много внимания уделяется безопасности, разделению обязанностей, вот этому segregation of duty: чтобы одни и те же люди не могли делать разные процедуры, обязательно по ролям должна быть разбивка. И доступ к разным транзакциям у разных пользователей должен быть совершенно разный.
То есть обязательно создается так называемая концепция ролей и полномочий: каждая роль получает определенные полномочия и доступ к определенным функциональным частям в системе. Разрабатывается целая методология. Рядовой бухгалтер не может видеть высокоуровневую аналитическую финансовую отчетность, у него просто нет доступа к этой транзакции. Кладовщик не может посмотреть зарплаты, когда он входит под своим логином, у него есть доступ к определенным транзакциям — складским, логистическим.
И вот последний поток — это интеграция всего решения, тестирование разных уровней. Мы тестируем систему несколько раз. Сначала система тестируется, естественно, самими консультантами и разработчиками. Потом, когда система складывается воедино, уже делается определенный тест по функциональным частям: функциональное тестирование. Например, финансовый модуль может отдельно тестироваться с заглушками по сторонам, и так далее. И когда система уже более или менее готова, делается интеграционное тестирование: определенный набор, выборка данных, которые загружаются в тестовую систему. Она является, скажем так, уменьшенным прототипом продуктивных данных, чтобы не загромождать основную систему. Интеграционное тестирование делают не те, кто систему настраивал и внедрял, а те, кто ею будет пользоваться. Приходят бизнес-пользователи — те самые члены проектного офиса, вновь созданного, ключевые, садятся и полностью все транзакции системы прогоняют, через все точки от А до Я. Для этого пишутся тестовые сценарии. И вот в самом начале проекта начинается уже стратегия тестирования создаваться.
Понятно, для чего эти потоки? Они распределяют и структурируют работу по областям. Поэтому на проекте SAP достаточно большое количество разнообразных специалистов участвует. Мы всегда делаем некую матрицу, в которой мы расписываем, на каком этапе, с какой загрузкой, какой специалист будет нужен. Приблизительно уже зная, исходя из нашего опыта работы, что бизнес-пользователи не стопроцентно везде будут вовлечены. Например, на этапе реализации они достаточно мало участвуют, только на тестировании. А вот на этапе концептуального проекта бизнес-пользователи нужны очень плотно, чтобы собрать данные и формализовать с ними, утвердить.
Вот такой пример матрицы ответственности. Мы всегда договариваемся с заказчиком, кто что делает, и распределяем наши обязанности. Например, обучением обычно всегда управляет сам заказчик: мы можем дать наши списки курсов, порекомендовать, как вы будете обучать на внешних курсах ваших сотрудников, но внутренне обучение конечных пользователей, тех, кто будет работать в системе, обычно организует заказчик. А ключевые пользователи обычно ходят на курсы для того, чтобы набраться знаний и потом учить конечных пользователей. Такое распределение обязанностей расписывается и в контракте обычно утверждается. Мы всегда договариваемся, как мы эти работы проводим, кто что делает. Опять же, как вы видите, управлением проектом занимаются и те, и другие. Потому что не бывает такого, что пришел подрядчик внешний и начал управлять вашими собственными людьми на предприятии. Это не очень приятно, когда приходят внешние люди и начинают говорить, что делать.
Поэтому всегда внутри назначается обязательно свой PM, который работает в связке с внешним PM-ом: они управляют своими командами, но работают одной, единой интегрированной командой. То есть мы понимаем, что у нас должны быть проектные решения созданы, написаны функциональные спецификации определенного вида, технические спецификации написаны на разработки, должны быть проектные документы: устав проекта, план проекта, статус-отчет по проекту. И если нужно план проекта нарисовать, достаточно сложный, значит, делаем это мы вместе с РМ-ом заказчика и набираем туда вот эти работы, то есть делаем так называемую WBS, Work Breakdown Structure. И фамилиями она наполняется с его стороны, а у РМ заказчика — своими: он выбирает людей, которых он знает, как они будут работать. Он занимается трансляцией РМ заказчика и пропагандой идей проекта внутри предприятия.
Всю эту оболочку управления проектом обычно, конечно, мы строим: во‑первых, даем уже готовые наработки того, что в SAP накоплен благодаря долгим годам опыта, и во‑вторых, берем часть опыта предприятия, которую хотят видеть бизнес-пользователи. Все это вместе называется «стандарты проекта». И далее мы договариваемся о взаимодействии. Одна из частых проблем руководителя проекта со стороны заказчика: обычно этот РМ, уже находясь в проектном офисе, имеет 10‑15 проектов, или два-три больших. У него физически времени не хватает заниматься этими проектами. Есть проект типа ERP, там может быть и три, и четыре РМ-а у заказчика на full time. Тут все зависит оттого, как это все выстраивается. Ну да, тут каждый индивидуальный проект по‑разному.
Если на стороне заказчика слабый РМ — это, конечно, риск, но не такой, то есть проект еще может хорошо закончиться. А если слабый РМ на стороне исполнителя, то это практически стопроцентный неуспех. Недавно я наблюдал такой расклад на одном проекте. На стороне исполнителя РМ был, мягко говоря, никакой — но РМ заказчика все брал на себя и достаточно энергично рулил ситуацией: было понятно, что если он это не сделает, никто не сделает. Такие ситуации бывают. Но это каждый раз по‑разному, тут же невозможно никаких предсказаний сделать. Но, конечно, когда РМ подрядчика — профессионал, то это практически 100 % дает хороший результат всегда. И в SAP у нас других нет, мы стараемся таких людей культивировать как раз.
Перейдем к фазе подготовки проекта. Что представоляют из себя фазы? Это набор результатов. В каждом потоке есть что‑то, что мы должны сделать. Первая фаза — это подготовка проекта: мы начинаем формировать понимание и план проекта разрабатывать. То есть на этой фазе мы выстраиваем roadmap, по которой будем жить всю оставшуюся проектную жизнь: планируем, определяем объем здесь, хотя в первом приближении объем, конечно, определяется раньше — иначе контракт заключить невозможно. Если мы не знаем объем проекта, мы не можем обсчитать стоимость трудозатрат и заключить контракт. Поэтому здесь объем детализируется внутри того, который был определен еще на фазе пресейла или продажи, когда мы продавали консалтинговые услуги.
И здесь же нам обязательно нужно сформировать команду, то есть тех людей, которые будут этот проект внедрять. Необученные люди его делать не могут, и поэтому здесь очень важно составить план обучения и это обучение начать проводить как можно быстрее — для того, чтобы люди смогли просто физически этот проект выполнять.
Фактор успеха на фазе подготовки проекта — полностью осознать, что мы должны делать на этой фазе. Потому что дальше начинается четкая работа по срокам, по графику, когда начинаются семинары с бизнесом, про которые я чуть попозже скажу, когда начинается уже непосредственно разработка бизнес-решений и так далее. Очень интересный момент установления авторитета руководителя проекта — видите, здесь даже вынесено. Как, вы думаете, это происходит? Как руководитель проекта может установить своей авторитет? С помощью спонсора проекта. Обязательно должен быть какой‑нибудь kick-off meeting — он проводится в начале проекта, когда собирается вся команда, бизнес-участники со стороны заказчика, собирается команда подрядчика, все садятся в одной комнате, и спонсор проекта — руководитель предприятия — представляет руководителя проекта.
И потом руководитель проекта делает презентацию: представляет себя, рассказывает о своем опыте и пытается с людьми наладить непосредственный контакт уже с самого начала. Безусловно, его полномочия фиксируются в уставе проекта, в этом документе, который подписан спонсором — обязательно там должна быть прописана фамилия человека, который проектом управляет. Соответственно, ему даются уже формальные полномочия, и дальнейшие действия руководителя проекта — когда он плотно, нормально, дружелюбно и адекватно работает