Важная составляющая серьезного подхода к началу проекта – это наличие у клиента четкой организации своих бизнес-процессов, корректная постановка целей и задач внедрения, четкое понимание всеми пользователями конечных результатов автоматизации. В противном случае по ходу внедрения можно ожидать включенияв перечень дополнительных задач, не предусмотренных бюджетом проекта, саботажа «из принципа» со стороны тех, кому автоматизация должна принести облегчение в работе, но им не хочется овладевать новыми навыками, и так далее.
Например, на допроектной стадии специалисты Исполнителя поверхностно оценили проект по срокам выполнения, по стоимости, рискам. В ходе внедрения может выясниться, что задача на самом деле более объемная, чем была определена ранее, и количество заложенных часов недостаточно. Клиент неохотно идет на внесение изменений в бюджете проекта, который уже согласован и утвержден на всех уровня, так какэто дополнительные затраты, а всем компаниям хочется сэкономить. Кроме того, из-за недооцененного объема задач могут происходить сдвиги проекта по срокам выполнения. То есть изначально поверхностно оцененный проект порождает проблемы в будущем. Следовательно, подходить к этому вопросу надо тщательно.
Встречаются случаи, когда Заказчик высказывает свои пожелания по доработкам конфигураций уже в процессе внедрения,хотя все документы подписаны, согласованы, аванс выплачен. Пример из практики работы на проекте по внедрению «1С:ERPУправление предприятием»: по договору первый этап предполагал моделирование нескольких подсистем. Специалисты «Кодерлайн» сделали моделирование и карту функционального покрытия. Предстояли длительные выходные и праздничные дни, в течение которых мы хотели перенести остатки, доделать необходимые работы. Но оказалось, что сервера выключены, а Заказчик нас не предупредил, то есть дни прошли впустую. Когда же начали вносить информацию, необходимую для запуска, то Заказчик сказал, что хочет видеть по-другому блок продаж и потребовался месяц на его переделку. В результате оперативный контур не был запущен вовремя.
Со стороны Исполнителя могут быть проблемы, связанные с составом проектной команды. Например, замена сотрудника во время внедрения по личностным качествам, неумению коммуницировать, недостаточным компетенциям, знаниям или по семейным обстоятельствам. Конечно,после первого предупреждения надо датьсотруднику шансисправить положение, если видны явные огрехи в работе. Но если изменений нет, то надо сразу искать замену, так как на введение, адаптацию нового сотрудника потребуется время, а у Исполнителя четко прописанные сроки выполнения проекта,и лучше не усугублять ситуацию.Был пример, когда архитектор выстраивал систему на проекте у клиента, но потом по семейным обстоятельствам оставил команду и вверенный блок не доделал. Руководителю проекта пришлось вникать в методологию, во все нюансы, что заняло определенное время. К тому же сотрудники Заказчика тормозили с проверкой остатков, и в итоге проект шел с задержкой на 5 месяцев от установленной изначально даты.
То есть можно сказать, что большая часть проблем связана с управлением людьми как в проектной команде Исполнителя, так и у Заказчика. Причем на последних повлиять могут только они сами.
Во многом залог успеха проекта зависит от руководителя проекта (РП) со стороны Заказчика, его личности и должности в структуре компании. Для Исполнителя – он первый помощник, связующее звено и основной коммуникатором между проектной командой Исполнителя и сотрудниками своей компании, конечных пользователей, участие которых также важно. К сожалению, при выбореРП часто применяется формальный подход, так как нет понимания степени его загрузки и нагрузки, ответственности за выполнение проекта. Многим специалистам 1С знакома ситуация, когда руководителем проекта назначаютруководителей функциональных подразделений, например, главных бухгалтеров или главных финансистов, которые достаточно загружены по своей основной деятельности, и у них физически не хватает времени на участие в проекте. При этом их не хотят даже частично освободить от основных обязанностей, текущей нагрузки, или взять дополнительного сотрудника в помощь.
На этапе запуска новой программы в эксплуатацию важна сознательность и мотивация конечных пользователей, за которыми закреплен определенный участок работы, так как требуется их большая занятость в процессе. Но иногда сам Заказчик не понимает, насколько они (пользователи) будут вовлечены, когда потребуется проверить остатки, корректно завести документы, грамотно заполнить аналитику для новой системы, поскольку из-за разниц конфигураций «переложить» документы один к одному не получается. Бывают случаи, когда надо протестировать тот или иной участок работы, а ответственный сотрудник ушел, потому что закончилось рабочее время и у него нет стимула оставаться сверх нормы.
Возникает масса трудностей, идет негатив, а порой и саботаж со стороны сотрудников компании-заказчика.
Получается замкнутый круг: Исполнитель не можем воздействовать на конечного пользователя, так как их взаимоотношения никак не регулируются, а ответственное лицо со стороны Заказчика все время занят своей основной работой, ему некогда. В результате при завершении отдельных этапов и проекта в целом внедренцыбьются в закрытые двери, так как никто не хочет принимать работы и подписывать акты выполненных работ, не хочет брать на себя ответственность. Из-за этого затягиваются сроки, накаляется обстановка на проекте.
Большую часть проблем, которые возникают в ходе проекта, можно решить на этапе его обсуждения, согласования, принятия в работу.Во-первых, для исключения неприятных ситуаций, непонимания между командами или хотя бы сведения их к минимуму при внедрении информационной системы должна быть поддержка со стороны высшего руководства компании-заказчика. На крупных проектах, как показывает практика, руководителем проекта должен быть человек, занимающий вторую ступеньку в структуре компании, который имеет соответствующие полномочия для принятия решений и может давать указания подчиненным, а не уговаривать их остаться и поработать на пользу проекта.
Во-вторых, в начале проекта Заказчику необходимо проговариватьс пользователями вероятность сверхурочной работы с соответствующими оплатами, поощрениями, доступными в компании. Также важна разъяснительная работа, так как на начальном этапе сотрудники компании не знают преимуществ автоматизации, и не понимают, насколько облегчится их работа с помощью, условно говоря, волшебной кнопки, по которой оперативно можно будет получать все отчеты.
Из нашего опыта могу сказать, что многие текущие вопросы решаются на еженедельных совещаниях по статусу проекта с участием представителей Заказчика и участников проектной команды Исполнителя – РП, архитектора, методолога, где рассматривается выполнение плана-графика, устанавливаются сроки, назначаются ответственные лица. По итогам составляется протокол с перечислением задач для решения и сроков их выполнения, отмечается, какаядокументация не была предоставлена, какие участки не протестированы. Протокол отправляется на согласование всем ответственным лицам. Если для сохранения сроков реализации проекта не удастся достичь компромисса на этом этапе, то нужно выноситьобсуждение вопросов на более высокий уровень, вплоть до первых руководителей.
В целом, относительно идеального проекта не помню ни в своей практики, ни у коллег. Но иногда даже маленькие шажки в виде закрепленного одного часа работы конечных пользователей с проектной командой Исполнителя – это уже удача и реальный прогресс в выполнении поставленной задачи.
Алла Зайцева,
руководитель отдела внедрения компании ООО «Кодерлайн»
