Поделиться
Команда ИТ-проекта: как избежать проблем
Успешность внедрения информационных систем напрямую зависит от команды специалистов, работающих над проектом. Хотя каждое предприятие, безусловно, обладает своей спецификой, можно дать общие рекомендации, которые будут полезны для любого проекта.Фактор риска
Среди многочисленных рисков, сопровождающих выполнение крупных ИТ-проектов (таких, например, как внедрение ERP-систем), весомое место занимают разнообразные риски организационного характера. Так, серьезным фактором, требующим пристального внимания уже на первых этапах проекта, является правильный подбор команды. Данный вопрос актуален всегда, но особенную остроту он приобретает, когда отношения заказчика и исполнителя имеют высокую степень формальности.
Можно привести множество реальных ситуаций, демонстрирующих, например, важность такой роли в команде со стороны заказчика как куратор. В одном из подобных случаев проводилось внедрение нескольких модулей ERP-системы в транспортной компании. Процесс изначально шел по максимально «мягкому» сценарию, все отношения строились на личных контактах, на доверии между руководителями обеих сторон. Инициатором проекта была главный бухгалтер компании, однако право принимать решения она имела только в пределах своей службы. Иными словами, куратора как такового не было.
О наличии внутренней борьбы двух групп за влияние в компании, проводящей внедрение ERP, исполнители изначально не знали. Все проявилось тогда, когда внедрение информационной системы стало, по сути, разменной монетой в борьбе этих сил. Неизбежно возникавшие проблемы проекта использовались как аргумент в пользу противников внедрения. Поскольку затронут был ряд служб, не нашлось никого, кто имел бы достаточно власти и мог бы принять «волевое» решение по прекращению бесплодной дискуссии и переводу работы в конструктивное русло. Итог печален: проект прекращен, из пяти запланированных модулей внедрено два, что в целом можно рассматривать как провал.
В другом примере проект на авиационном производственном предприятии изначально стартовал под общим руководством коммерческого директора, имевшего значительную власть и, к тому же, интересовавшегося информационными технологиями. Внедрялся контур, включающий договоры, денежные потоки по ним и поставки отдела сбыта. Естественно, без проблем не обошлось и здесь. Если в финансовом управлении данные по платежам аккуратно вводились, то в отделе сбыта сотрудники находили тысячи причин, чтобы не работать в новой системе.
В результате, когда коммерческому директору показали свежий отчет по взаимоотношениям с контрагентами, он обнаружил, что платежи исправно идут, а поставок со стороны предприятия нет. После короткого выяснения ситуации начальница отдела сбыта была вызвана и предупреждена об увольнении. На следующий же день все поставки в системе появились. В итоге полный запланированный контур системы был внедрен и работает по сегодняшний день (почти 10 лет).
Наряду с куратором проекта, значение и ряда других ролей также может иметь принципиальный характер. Правильный подбор всех участников команды – важнейшая задача, требующая решения обычно на первых стадиях проекта или даже до его старта. Особо следует отметить, что ИТ-проект всегда выполняется двумя командами – заказчика и исполнителя, которые обязательно должны составлять единое целое.
Команда заказчика
Подбор команды проекта со стороны заказчика встречает обычно наибольшие трудности. Этот процесс затрудняет то обстоятельство, что выбор практически всегда идет только из существующих сотрудников заказчика, что совершенно естественно, но ограничивает круг возможных кандидатов. Другим неприятным моментом является распространенное нежелание заказчика выделять сотрудников под нужды проекта полностью. В результате ключевые фигуры занимаются совмещением работы в проекте с другими обязанностями, что часто приводит к печальным последствиям.
1. Куратор проекта. Эту важную роль к команде заказчика играет представитель администрации, пользующийся значительным влиянием и формальной властью. Он полномочен решать наиболее критические вопросы: развертывание очередных этапов внедрения, подписания дополнительных соглашений, определение объемов и сроков финансирования новых работ, привлечение других служб, издание приказов по предприятию заказчика, регламентирующих проведение определенных работ, связанных с проектом и т.д. Именно этот человек окончательно визирует акты приемки-сдачи этапов работ по проекту. Ориентировочно раз в месяц проводит рабочее совещание с руководителями проекта с обеих сторон, где осуществляет административный контроль за ходом проекта.
Иными словами, куратор осуществляет административное «прикрытие» проекта, обеспечивает ликвидацию многих организационных рисков. Достаточно часто он определяет сам факт появления проекта или выступает его инициатором. Сотрудник, выполняющий эту задачу, практически никогда не может быть заменен в процессе осуществления проекта. Замена или отсутствие данной роли с высокой вероятностью оборачивается тяжелыми проблемами для проекта.
2. Координатор проекта со стороны заказчика, иначе может называться «руководитель проекта». Координатор от заказчика представляет собой центр утверждения оперативных решений, в частности, по вопросам предметной области бизнеса заказчика. На эту роль требуется достаточно компетентный в предметной и компьютерной области сотрудник с высокой работоспособностью. Он должен получить значительные полномочия, включая первичное подписание актов приемки-сдачи этапов работ, оперативное привлечение других специалистов предприятия, решение текущих административных и организационных вопросов.
Координатор проекта должен быть назначен официальным приказом руководства предприятия с перечнем его полномочий. Это весьма желательно даже при высокой степени доверия заказчика и исполнителя на старте проекта. В подавляющем большинстве случаев координатор не должен выполнять в период выполнения проекта других обязанностей, что также отражается в официальном приказе. В связи с высокой загрузкой, по возможности должен быть проработан вопрос материального и иного стимулирования координатора.
Существенная трудность состоит в том, что достаточно часто заказчик вообще не может подыскать среди своих сотрудников подходящей фигуры на эту должность. Если такое лицо находится – это большая удача. В дальнейшем замена такого сотрудника крайне нежелательна и может быть очень болезненна для хода проекта, причем на любых этапах его осуществления. Еще одна проблема, которую необходимо пытаться устранять на самых ранних стадиях, – загрузка координатора от заказчика другой работой, «текучкой». При этом неминуемо значительное замедление процессов решения насущных вопросов, и, как следствие, затягивание общих сроков выполнения проекта.
3. Экспертный совет. Обязательное условие успеха обследования и корректного описания автоматизируемой предметной области – наличие экспертов заказчика по различным областям знаний. Чем выше их квалификация, тем меньше останется неясных моментов, вопросов, которые требуют обдумывания и решения координаторами с обеих сторон. Проекты разного масштаба предполагают различное оптимальное число задействованных экспертов. Тем не менее, все они должны обладать достаточной полнотой знаний в своих областях, а также иметь полномочия консультироваться с любыми другими специалистами предприятия на предмет получения недостающей информации.
В некоторых случаях эксперты иначе называются аналитиками со стороны заказчика. Основное отличие экспертов заказчика от описанных ниже аналитиков исполнителя – более глубокое знание специфики бизнес-процессов и текущей автоматизации своего предприятия. От аналитиков исполнителя требуется в первую очередь понимание универсальных подходов к автоматизации и знание внедряемой программной системы.
С экспертами должно быть налажено продуктивное взаимодействие сотрудников исполнителя, для чего тоже требуются определенные организационные решения. Эксперты так же, как и координатор, назначаются официальным приказом. В их рабочие обязанности включается регулярное участие в проекте, например, в течение первых 3-4 месяцев с момента начала работ эксперты проводят лекции и консультации по своей области не менее 6-8 часов в неделю, в последующие 6 месяцев их загрузка уменьшается до 1-3 часов в неделю. Мнение экспертов, заверенное руководителем проекта со стороны заказчика, должно считаться официальной позицией последнего, либо всю ответственность за формирование такой позиции может взять на себя координатор от заказчика.
В данном случае трудности подбора кандидатов могут возникать, если на предприятии заказчика отсутствуют эксперты по определенным вопросам. Впрочем, это довольно редкое явление: отсутствие одного эксперта почти всегда компенсируется наличием нескольких специалистов, вместе обладающих достаточным объемом знаний, поэтому данные риски невелики. Замена эксперта может иметь неприятный, но редко критический характер.
4. Технический ИТ-персонал. К этой категории относятся сотрудники ИТ-подразделений заказчика, выполняющие технические и вспомогательные работы в команде проекта или во взаимодействии с ней: программисты, тестировщики, преподаватели, операторы, системные администраторы.
Программисты заказчика играют существенную роль преимущественно в проектах внедрения «коробочных» продуктов, где на них ложится основная роль по доработке функциональности продукта до требований предприятия. Это особый род проектов, в которых роль команды исполнителя (поставщика программной системы) обычно невелика.
Тестировщики могут использоваться командой заказчика на этапах приемки и опытной эксплуатации системы. В некоторых случаях на период опытной, а иногда и промышленной эксплуатации может создаваться специальная группа техподдержки заказчика, в дополнение к описанной ниже аналогичной группе со стороны исполнителя. В этом случае в ее функции входит первичный разбор ошибок и замечаний по работе системы. Вместе с тем, наличие такой группы у заказчика не является обязательным для успеха проекта, с ее обязанностями может справляться и группа техподдержки исполнителя.
Группа обучения конечных пользователей (преподаватели) функционирует временно, чаще всего в начале этапа опытной эксплуатации. Ее наличие обычно связано с двухступенчатой организацией обучения: вначале сотрудники исполнителя обучают ИТ-сотрудников заказчика, затем последние обучают сотрудников бизнес-подразделений. Этот каскадный метод позволяет быстро обучить большое количество пользователей. В ряде случаев группа обучения существует у заказчика на постоянной основе. Это необходимо, когда автоматизация достигает уровня пользователей с высокой текучестью кадров – например кладовщики, кассиры и т.п.
Операторы осуществляют ввод данных, верификацию справочников и оперативных регистров. Часто в этой роли могут выступать сотрудники предметных подразделений заказчика.
Системные администраторы осуществляют техническую поддержку проекта, ведают вопросами безопасности и разделения доступа к данным.
Все приведенные роли, несмотря на их важность, не предполагают принятия ключевых решений по ходу проекта. Кроме того, обычно их выполнение возложено на довольно большое число сотрудников. Соответственно, риск отсутствия или замены конкретного сотрудника для проекта чаще всего невелик. Вместе с тем, следует избегать плохой организации этих служб в целом, иначе неприятные последствия могут быть гораздо серьезнее. Для этого, на старте проекта, должен быть официально утвержден регламент работы технического персонала в проекте.
Короткая ссылка
