Проект как элемент культуры

Методология управления проектами — часть корпоративной культуры. Единственным критерием ее формирования является результативность.

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

Проект итерационного типа

История группы компаний «Восток-Сервис» насчитывает более 17 лет. «Восток-Сервис» — один из ключевых игроков на российском и восточноевропейском рынках средств охраны труда (спецодежды, спецобуви, средств индивидуальной защиты, инструмента, сопутствующих товаров). У «Восток-Сервиса» имеется собственная производственная база — шесть швейных и две обувные фабрики. Также есть 118 филиалов и 260 фирменных магазинов в 170 городах России, стран СНГ, Балтии, Азии.

Четыре года назад было принято решение о переходе группы компаний на промышленную программную систему — отраслевое решение SAP для производителей одежды и обуви SAP AFS. «Для меня как логиста было абсолютно все равно, кто является разработчиком внедряемого решения, — отмечает Александр Жданов, директор по логистике ГК “Восток-Сервис”. — Логистика в компании развивается очень быстро, и не всегда ясно, какие решения в этой области будут для нас предпочтительными через несколько лет, поэтому информационная система должна быть достаточно гибкой, чтобы ее можно было эффективно перестроить». Важно также, чтобы система содержала обобщение лучшего опыта.

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

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

«В концепции мы изложили наши требования, но затем выяснилось, что их реализация будет очень дорогостоящей. Анализ показал, что можно модифицировать требования». Таким образом, проектной команде удалось найти компромисс между требованиями бизнеса и возможностями системы, вернее стоимостью их реализации в системе. Лидия Семичастная, директор по ИТ ГК «Восток-Сервис», отмечает: «Если модификация будет слишком дорогой, то ИТ-подразделение может выступить инициатором модификации требований и по-другому выстроить процесс на складе, так как в системе есть возможности реализовать ИТ-поддержку несколько иначе».

По словам Андрея Гаршина, начальника отдела разработки системной архитектуры, руководителя проекта по внедрению ERP-системы, первоначальные требования сводились к наличию ячеечного хранения и подбора заказов по листам-заданиям (pick-листам). Логисты организовали посещение нескольких складов для сотрудников ИТ-подразделения и показали, что они имеют в виду. «Мы выдвигаем очень широкие, общие требования: адресное хранение, снижение роли человеческого фактора, увеличение степени автоматизации складской работы», — рассказывает Жданов. Далее проектная группа анализирует эти требования, и если выясняется, что их трудно реализовать в изначально задуманном виде, то сотрудники Жданова вносят в них изменения.

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

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

В результате было принято решение внедрять SAP AFS своими силами. Сотрудники Семичастной имеют большой опыт разработки ПО и глубокие знания предметной области. За время работы с WMS они приобрели опыт работы с решениями SAP. Если возникают проблемы, заказываются «точечные» консультации. Что самое главное, руководство компании доверяет Семичастной и ее коллегам. «Генеральный директор сказал: я верю, что вы сможете», — замечает она.

Проекты, основанные на знаниях

Банк UniCredit представлен в России с 1989 года, до конца 2007 года он работал здесь под названием «Международный Московский Банк» (ММБ). У банка свыше 100 подразделений в России, около 3700 сотрудников и свыше 700 тыс. клиентов — физических лиц.

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

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

Нередко проекты, связанные с внедрением информационных систем, умирают на стадии написания технического задания. С одной стороны, заказчик оказывается не в состоянии составить необходимый документ из-за отсутствия соответствующих компетенций, а исполнитель не способен (или не считает нужным) донести до заказчика свои идеи. Кто и как должен выполнять эту работу? Отвечая на этот вопрос, Медокс в первую очередь обращает внимание на отечественные стандарты. В частности, в Приложении 1 к ГОСТ 34.602-89 прямо указано, что «Проект ТЗ на АС (автоматизированную систему) разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.)».

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

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

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

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

Главное в ходе написания ТЗ — добиться взаимопонимания между заказчиком и исполнителем. В частности, необходимо договориться о терминологии. Для обеспечения взаимопонимания можно даже пригласить третью компанию в качестве «переводчика». Правда, если уровень зрелости проектного менеджмента невысок, заказчика иногда бывает трудно убедить в необходимости потратиться на такого переводчика. Кроме того, в некоторых случаях консультант-интегратор может быть не заинтересован в полном понимании заказчиком сути проекта — например, чтобы создать условия для привлечения дополнительных ресурсов со стороны интегратора. Это объясняет преимущество ситуации, когда основные технические компетенции находятся на стороне заказчика.

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

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

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