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

Ниже приведены только те моменты и трудности, с которыми я столкнулся, и то, как они повлияли на проект.

Пресейл

На пресейл надо тратить ресурсы! Обследование должно быть детальным, чтобы потом не получить неадекватную оценку и отрицательную прибыль.

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

На этапе предпродажной оценки проекта стоит предусмотреть перечень возможных дополнительных работ (объем, стоимость, время). Например, изменение каких-либо показателей влечет перестройку всей модели, что может занять значительное время, потребовать привлечение существенных ресурсов и стоить приличных денег.

Интеграция

Оценка интеграции так же относится к предпродажной оценке предстоящего проекта, но я выделил этот пункт намеренно.

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

В нашем проекте несовместимость систем обнаружилась только на стадии начала работ по интеграции облачного SAP с 1С, что вызвало негодование Заказчика и дополнительные трудозатраты на проработку и настройку альтернативы.

Составление договора

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

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

Подробно описать в Договоре процесс обучения (количество часов, темы, количество и тип пользователей - бизнес и/или технический пользователь) и перечень прилагаемых инструкций (количество, названия и т.д.)

В нашем договоре было указано, что мы предоставим инструкции и проведем обучение. Но Архитектор запланировал один (примерный) перечень инструкций и объем обучения, а Заказчик потребовал сильно больше.

Обязательно прописать в Договоре, что изменения, которые требуют корректировки архитектуры более на чем на 10%, выполняются только за дополнительную плату.

Этот важный пункт, как правило, фигурирует в шаблонах договор, но лучше удостовериться, что он действительно есть.

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

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

Избегать формулировок, которые можно трактовать по-разному

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

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

Этот пункт, скорее всего, есть во всех шаблонных договорах. Однако, мало кто обращает на него внимание, затягивая сроки. Зафиксировав просрочки в переписке с Заказчиком или в протоколах оперативного совета можно выиграть немного времени для сдвига сроков в случае, если возникнет необходимость.

Всегда документировать всю дополнительную (сверх прописанного в договоре объема) работу, которую пришлось делать для исполнения проекта.

Хранить всю переписку с Заказчиком до завершения проекта.

Фаза обследования и написания ПР (проектных решений)

Заложить достаточно времени на обследование процессов Заказчика с целью написания качественного ПР. Контроль соблюдения Заказчиком сроков рассмотрения и согласования ПР (обязательно протоколировать просрочки со стороны Заказчика с указанием рисков сдвига сроков реализации проекта в целом и этапа в частности).

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

Тестирование

Зафиксировать в договоре порядок проведения тестирования (количество тестов, участие Заказчика в тестировании и т.д.).

Контроль ответственность Заказчика за обеспечение доступности требуемых для тестирования сотрудников в отведенные на тестирование сроки (обязательно протоколировать просрочки и\или отсутствие сотрудников со стороны Заказчика).

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

Спасибо, что дочитали. Я понимаю, что опытным РП мои тезисы покажутся очевидными, но начинающим специалиста они могут быть полезны. Мне бы это помогло в свое время :-)

Разбор ошибок одного проекта, или «как подстелить соломку» начинающему руководителю проектов