Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.
«Упра­вле­ние сложными ли­чно­стя­ми в проектной группе»
Татьяна Шаньгина:
Управление сложными личностями в проектной группе – тема интересная, актуальная, хотя и довольно амбивалентная. Практический опыт доказывает справедливость концепции Уильяма Зиска о...

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

Подход 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 — он проводится в начале проекта, когда собирается вся команда, бизнес-участники со стороны заказчика, собирается команда подрядчика, все садятся в одной комнате, и спонсор проекта — руководитель предприятия — представляет руководителя проекта.

И потом руководитель проекта делает презентацию: представляет себя, рассказывает о своем опыте и пытается с людьми наладить непосредственный контакт уже с самого начала. Безусловно, его полномочия фиксируются в уставе проекта, в этом документе, который подписан спонсором — обязательно там должна быть прописана фамилия человека, который проектом управляет. Соответственно, ему даются уже формальные полномочия, и дальнейшие действия руководителя проекта — когда он плотно, нормально, дружелюбно и адекватно работает с проектной командой на ежедневной основе, его авторитет укрепляют. То есть принести авторитет с собой и установить не получается, его надо зарабатывать. Поэтому для руководителя проекта очень важно авторитет так или иначе получить от участников команды.

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

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

Но в жизни, коллеги, я вам скажу честно, мы сталкиваемся с абсолютно обратным фактом. То есть я вам сейчас обрисовал идеальную картину, с точки зрения подрядчика или вообще внедрения SAP: правильные кадры, которые знают, чего они хотят, чтобы я мог понять их желания и воплотить их в системе своими силами. И чтобы эти кадры все время смотрели, что я делаю, и поправляли меня — помните, я вам говорил про каскадные постоянные уточнения? Чтобы они смотрели на результат и говорили «чуть вправо, влево» — и мы наконец попадаем, вот эта мозаика складывается. Зачастую, к сожалению, все люди, которые нужны на проекте, заняты в повседневной работе. И вместо них присылают замов, суб-замов и так далее — специалистов, которые не обладают достаточным опытом, полномочиями и потом бегут к начальникам, пытаются через них все утвердить и спросить, как это делается, либо берут инициативу на себя без достаточных знаний, либо просто недоступны для работы на проекте. Это огромная проблема, и с ней позволяет справиться проджект-менеджер, руководитель проекта со стороны заказчика. Все необходимые для проекта люди добываются через него, приказами зачастую.

Когда я работал в Zeppelin, я делал график занятости людей на подготовке к тестированию, на самом тестировании, по дням, просто в Excel, потом его копировал в Word, делал такой красивый приказ с шапкой ко компании, и на эти дни все люди подписью генерального директора освобождались от основных обязанностей и переводились полностью в распоряжение проекта. Только так удавалось сделать все вовремя и качественно, потому что иначе просто никак. Люди не раздваиваются, их невозможно вытащить из производства. Поэтому вот здесь очень важно этому уделить внимание.

На каждой фазе каждый рабочий поток, естественно, какие‑то результаты приносит. Смотрите, поток «управление проектами» — здесь стандарты проекта готовятся, график проекта и оргструктура проекта прорабатывается. Вот она, оргструктура. Есть спонсор проекта, есть руководитель, есть управляющий комитет. Ну и функциональные области — это самая простая straightforward-структура, которая позволяет управлять проектом.

Это все показывается на kick-off meeting: когда люди собираются, им всегда показывается их место в этом проекте, как они встроены в общую структуру, роли и обязанности участников, права и полномочия для этой работы. Устав, в котором описан проект — вкратце цели, задачи, бюджет, верхнеуровневый план, этапы, основные участники, планируемые результаты по этапам, и кто этим проектом руководит. Иногда этот документ называют «паспорт проекта» — он достаточно краткий и подписывается спонсором, чтобы этот проект формально в организации утвердить.

На этапе по управлению оргизменениями мы должны определить людей, которые будут затронуты, будут работать в проектном офисе, у них появятся другие должности. Стратегия дальнейших оргизменений, которая будет сопровождать внедрение системы, должна тоже создаваться на этом этапе, потом она уточняется. Здесь же проектная команда должна начать обучаться в учебном центре SAP, на серьезных курсах, позволяющих достаточно глубоко изучить функционал системы. Эти курсы должны планироваться заранее, потому что они всегда проводятся либо с отрывом от производства на территории SAP СНГ, либо преподаватели выезжают к заказчику. Но для этого надо руководителю проекта со стороны заказчика подготовить аудитории, подготовить компьютерное оборудование, сделать доступ к удаленным демонстрационным системам SAP, чтобы можно было показать, как все работает на демонстрационных системах, преднастроенных прототипах и так далее. Тренеры, которые выезжают, должны быть организованы. Подготовка обучения — сложный, но необходимый процесс, иначе команда просто не сможет работать.

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

Ну и, соответственно, здесь делается оценка имеющегося оборудования, особенно если наша новая база данных SAP HANA — для нее нужно специальное оборудование. На обычное «железо» SAP HANA не поставишь, потому что она требует большого объема оперативной памяти. В дело включаются сертифицированные SAP производители такого оборудования. Его надо заказывать, и сроки поставки могут быть около полгода — важно провести планирование работы с поставщиками оборудования.

Если вы будете такой проект делать, обязательно включайте в один из пунктов тендера поставку тестового сервера — до поставки основного оборудования. Если поставщик оборудования такую услугу не оказывает, не рассматривайте его. IBM это делает, Hewlett-Packard это делает, но некоторые не делают — и с ними связываться не надо, потому что вы будете ждать оборудование и не сможете начать прототипировать, пока оно к вам не приедет. А потом еще его устанавливать, решать проблемы с кластерами, если вы будете кластеризовать, чтобы у вас была безотказность, и так далее. На это может уйти куча времени. Поставщики вам могут дать простой сервер под HANA во временное пользование. Бесплатно причем. Вот вы у них купили, они вам бесплатно привезли сервер, на котором вполне достаточно места, чтобы развернуть прототип и начать уже работать. Это обязательно надо делать — я это подсказал на «ОМК», где мы как раз сейчас внедряли SAP HANA, и они были страшно счастливы, внесли в план, именно такого подрядчика выбрали, и у нас получилось внедрить проект вовремя. Если бы мы это не сделали, то проект выбился бы из графика, потому что оборудование привезли значительно позже, и еще установка и кластеризация, которую делали специалисты IBM, заняла два месяца — это сложные настройки, так бывает. Поэтому вот этот момент очень важен — вовремя начать готовить оборудование.

Ну и, соответственно, надо понять, как все это тестировать на этой фазе. Здесь такой общий подход к работам на проекте делается. Вот как выглядят наши бизнес-процессы на этом этапе. У нас есть, например, бюджетирование. И вот у этого процесса бюджетирования (это первый уровень) есть маленькие подпроцессики. Я даже сам не вижу при таком масштабе. Например, казначейство — и идут подпроцессы: верификация договоров, введение заявок на оплату, формирование графика платежей. И вот формирование графика платежей, например, потом разбивается еще на процессы третьего уровня, эти процессы третьего — на операции и так далее. К каждой из этих операций еще прикрепляется, во‑первых, исполнитель, кто это делает, плюс еще транзакция назначается в SAP, то есть вот за эти итерации через несколько фаз мы должны прийти именно к этому детальному виду, который будет несколько позже.

Вот тут у нас видно, как мы сначала должны утвердить верхнеуровневую структуру системы — то, что в ней будет воплощено. Здесь мы пока не пишем, как это делается, какие там дополнительные расширения. То есть какой‑то из этих кубиков может в SAP и не существовать, это та самая Z-разработка, которая будет сделана с помощью дополнительного кода. Объем проекта — это и бюджетирование, и планирование управления производством, и планирование производства, и управление продажами, и управление закупками, и управленческий учет и так далее, вот эти все модули, они посвящены, каждый из них, определенному какому‑то функционалу.

Помимо процессного, у этого объема еще есть другие разрезы, другие измерения. Организационные объемы: например, когда несколько предприятий в холдинге, и на всех внедряется SAP. Может на каком‑то предприятии быть сделано пилотное решение, а потом тиражировано на остальные. Либо сделано централизованное решение с учетом всех требований, и все сразу дистанционно подключаются к единой системе ERP, начинают работать в ней единовременно. То есть это оргобъем нашего проекта. Есть географический — предприятия расположены в разных регионах России, а зачастую и за рубежом: например, у металлургов часто есть заводы в Америке (почему‑то все время заводы в Америке открывают). Есть системный — это когда не только ERP внедряется, но и дополнительные модули — то, что не входит в ERP. Это, например, APO, CRM, BI и так далее. И объем по данным.

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

Если изменение необратимо, существует такой поток управления проектами, как раз он из PMI-методологии, называется Change Management, управление изменениями. Мы этими изменениями можем грамотно управлять: собирать, документировать, оценивать. И потом управляющий комитет может выносить свое решение, посмотрев на обоснованную необходимость этого изменения и на его оценку, с определенными поправками по бюджету и по времени, и принять решение: «Да, мы это изменение делаем, мы даем вам деньги и продлеваем сроки проекта», — тогда все нормально, все это формализованно происходит. Либо отвергается изменение, и оно уходит либо на развитие, как потенциальное изменение в дальнейшем, либо полностью хоронится и никогда к нему не возвращаются уже больше, как к ненужному.

Фаза концептуального проекта — это следующая фаза, в которой начинаются уточнения того, что известно с предыдущих фаз. Есть набор процессов, которые надо детально с бизнесом проговорить и написать проектные решения: как все настройки стандарта будут в системе воплощены. То есть уже расписать конкретно, как это будет выглядеть в системе SAP. Поэтому мы здесь делаем уже описание «to be» процессов — дополнительные функциональные технические требования и дизайн-решения. И архитектура появляется на этом этапе, как взаимодействие между системами. Происходят интеграционные решения: каким образом система будет взаимодействовать, между собой, внутри самого SAP, и с системами, которые остаются снаружи.

Например, на железной дороге есть система, которая управляет перевозками, от нее никуда не денешься — SAP к ней должен прицепиться и как‑то взаимодействовать. Интеграция эта обязательно должна быть создана на этом этапе. И каждый субпроцесс раскрывается в виде вот такого flowchart. Это что‑то связанное с заказами на поставку, процесс. И здесь видно, что вход идет отсюда, и здесь происходит какое‑то действие, которое выполняется: а) мы рисуем, кто это делает, какая транзакция в SAP за это ответственна.

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

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

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

План коммуникаций — обязательно у нас есть матрица коммуникаций и средства, носители этих коммуникаций: мы можем публиковать на веб-сайте, выпускать газету, рассылать какие‑то е-mail. С определенной периодичностью мы рассылаем статус-отчеты в PowerPoint или в Word и так далее: кому, с какой частотой, в каком виде, что должно приходить — это прописано в плане коммуникаций. Он представляет собой матрицу, если много участников, потому что всех спамить тоже не нужно — каждому по необходимости приходит определенная информация.

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

И, соответственно, у нас стратегия и план обучения конечных пользователей — это очень важный аспект, потому что, как я вам говорил, «час Ч» наступает, люди в понедельник приходят на работу — и им надо работать в новой системе, они уже должны быть все обучены. Вот для этого должны быть проведены грандиозные мероприятия. Очень часто ключевые пользователи, которые обучены уже в учебном центре SAP, могут (и должны) планировать вместе с проектной командой, с руководителями проектов на обеих сторонах обучающие семинары для всех конечных пользователей с отрывом от производства. Зачастую это тоже занимает неделю, так как людей надо хорошо обучить. Когда большое массированное обучение, SAP может помогать — организовывать эти семинары. И даже наши тренеры, как я понимаю, тоже могут принимать участие, поэтому это очень важно планировать.

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

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

Как и кем это будет администрироваться? И какие процедуры будут использоваться? Это уже должно быть написано на фазе концептуального проекта. Стратегия поддержки обязательно должна быть понятна, и концепция полномочий, чтобы пользователей новых в систему вводить. И план и стратегия тестирования должны быть готовы.

Этап реализации — это уже основные мероприятия, кроме подготовки данных и обучения пользователей. То есть остается на заключительную подготовку только мигрировать основные данные и обучить пользователей. Обычно фаза заключительной подготовки небольшая — месяц, две недели. И мы готовим операционные и транзакционные данные опять же на заключительной подготовке: это так называемый cutover (сейчас в 8‑м АSAP даже появился отдельный поток, Cutover Management), тот самый момент, когда новая система переходит в продуктив, и происходит это обычно с пятницы по понедельник. Обычно старая система в пятницу отключается, закачиваются данные — остатки операционных данных, транзакционных данных закачиваются в новую систему, и новая система включается, проверяется, как она работает, чтобы люди в понедельник, придя на работу, продолжили с этими же остатками работать в новой уже системе, в SAP.

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

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

И план мониторинга — у нас есть такие сервисы в SAP, которые мониторят критичные бизнес-процессы. Например, «EarlyWatch» каждое утро выдает отчет по состоянию бизнес-процессов. Естественно, уже должны практически быть установлены системы разработки и тестирования. То есть у нас в SAP есть обычно трехсистемный ландшафт: система разработки, на которой все разрабатывается, система тестирования, система продуктивная. Между этими системами настройки гоняются специальными транспортами так называемыми. И вот эти системы устанавливаются обычно в таком постепенном порядке: сначала делается система разработки, на которой начинается сразу прототипирование, она как песочница. Бывает, что песочницу четвертую отдельно ставят, на которой люди ставят разнообразные эксперименты, совершенно безумные — кто что хочет, тот там и делает, испытывают разные идеи и так далее, обкатывают, но это уже отдельная история. Обычно применяют трехсистемный стандартный ландшафт, и на фазе реализации, в принципе, уже готовят систему разработки и тестирования, она должна быть обязательно.

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

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

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

Заключительная подготовка. Должно быть самое главное — мы должны убедиться, что к продуктивному старту люди обучены, данные все правильно очищены, перенесены, архивированы, мы можем с ними работать в новой системе, служба поддержки готова к началу продуктивной работы. То есть люди, которые начнут работать с системой и столкнутся с какими‑то проблемами, будут знать, куда бежать. И все коммуникации сделаны, и приказ о начале работы в новой системе выпущен. Все знают, что в воскресенье вечером рубильник старой системы отключается, в понедельник все приходят, открывают компьютеры, а там уже написано SAP, и все начинают работать в нем.

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

Факторы успехов мы с вами, в принципе, обсудили. Всем понятно — мощная команда, поддержка руководства, хорошее управление проектами, правильное, обязательно проговорить «на берегу» между всеми участниками проекта, в каком виде будут результаты представлены, и как мы их будем принимать. Обязательно результаты должны быть структурированы таким образом, чтоб их люди почаще видели, то есть нельзя эти фазы проекта делать при планировании там год, потому что все начинают просто уставать. Когда люди не видят результатов, и их никто не поощряет, не говорит: «Ребята, молодцы, как вы хорошо сделали». Всегда люди должны каким‑то образом мотивироваться, тогда и работать приятней и легче.

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

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

И поддержка продуктивной эксплуатации. Здесь, естественно, самое главное — чтобы она была на должном уровне оказана. Jчень важный момент — собирать статистику об этой поддержке. Есть в SAP новый модуль KNOA, который позволяет эту статистику собирать, показывает, сколько было обращений, по какому функционалу, кто обращался — все статистические данные довольно здорово в нем аккумулируются. С помощью этого модуля можно, во‑первых, вычислять, какое дополнительное обучение должны пройти пользователи, какие области поддержки, каких дополнительных людей надо усилить, какие системы поддержки можно еще внедрить. Система, которая позволяет собирать статистику именно по поддержке, помогает управлять фазой поддержки продуктивной эксплуатации и дальнейшей эксплуатацией. KNOA — это дополнительный модуль, который надо отдельно приобретать.

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

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

Организация работ и воля спонсора определяет все. То есть, если спонсор — генеральный директор предприятия — выходит и говорит: «Мы внедряем стандарт, и 10 % у нас должно быть там Z, все, кто не готов — расстрел», — тогда народ начинает под это дело подписываться и работать в этом направлении. Если спонсор продекларировал, что мы внедряем SAP, а потом самоустранился — так бывает, наверное, в 90 % случаев: крайне сложно человеку постоянно сидеть на этом проекте, как наседка. Они считают, что есть нанятые специалисты, за большие зарплаты, пусть они это делают. Но зачастую просто нужна административная, политическая воля, чтобы все это заработало.

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

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

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