Дело сделано, никому не расходиться
Ольга Щепунова, руководитель проекта Oracle компании «Твое», уверена, что в ретейле, как и в других отраслях, на этапе ввода ИТ-решений в эксплуатацию неизбежны конфликты между бизнесом и проектной командой. Высказанные по завершении проекта претензии из разряда «я совсем не то имел в виду» и «забыл сказать, здесь нужны колонки в формате Excel» могут с уверенностью считаться системными.
Проект закончен: что дальше? Иными словами, как происходит переход проекта в процесс?
Мне знакомы как процессный подход, так и проекты подход. Поскольку я была и директором по ИТ, и руководителем проектов внедрения ERP_систем. Одним из таких проектов я руковожу сейчас в розничной сети «Твое». Предыдущий, похожий проект, был реализован в компании «Детский мир». И чем больше любой проект, тем дольше он продолжается после своего «завершения». То есть после внедрения системы и сдачи ее в эксплуатацию начинается развитие созданного решения. Продолжение проекта, его вторая жизнь после внедрения, может быть реализована внешним подрядчиком или внутренним подразделением компании-заказчика, а иногда и обоими сразу
Мой опыт связан с розницей, где проекты нередко делаются с привлечением внешнего подрядчика. В этом случае не редкость, когда по завершении работ по внедрению к заказчику переходит часть проектной команды, которая в дальнейшем занимается поддержкой. Особенно это касается бизнес-аналитиков. Но и программисты, так же как и консультанты по продукту, часто остаются на проекте. Когда проект делается внешней компанией и она же его поддерживает, важную роль приобретает центр компетенции в компании-заказчике. С этим проще всего, если в проектной группе заранее создается подразделение, сотрудники которого знают и продукт, и бизнес-процессы, и они, пусть и не в полном составе, остаются у заказчика в качестве «группы поддержки».
В другой ситуации, когда поддержка осуществляется линейными сотрудниками самого заказчика, возникает порой «разрыв в знаниях». Дело в том, что у заказчика зачастую нет серьезной компетенции по продукту. И со временем появятся вопросы: как данным ИТ-решением поддерживать наши новые бизнес-процессы? как изменять под них систему? как использовать функции, имеющиеся в программе, но ранее не задействованные? Здесь в игру должен включиться бизнес-аналитик, который должен сказать: «На данную систему мы наши процессы положим вот так». После чего подключается разработка и внедрение. То есть решение продолжает развиваться.
Так или иначе люди, обладающие знаниями о продукте и о бизнес-процессах, составляют основу центра компетенции. Создание таких центров — важный момент. Жаль, но далеко не все руководители предприятий это понимают. Центры компетенции, как и комитеты по изменениям ИТ-решений, следящие за развитием ИТ-проектов, должны быть в любой крупной компании, вне зависимости от того, было ли там серьезное внедрение или нет.
А если доработка ведется полностью своими силами?
При доработке ИТ-системы силами собственных программистов не последнюю роль играет передача знаний из разработки в сопровождение. И здесь все зависит от того, как ИТ-директор относится к этой деятельности, как он выстраивает группы внутри ИТ-подразделения. Есть схема, по которой техподдержка сама что-то дорабатывает и тут же сопровождает. В других компаниях есть четкое разделение на группу разработки и группу сопровождения. И процесс передачи четко регламентирован. В любом случае важно не забывать про процесс документирования. Для этого нередко используется отдельный программист. Надо помнить, что техподдержка должна участвовать в проекте еще до сдачи его в эксплуатацию — на этапе пользовательского тестирования, чтобы понимать, с чем придется работать, что поддерживать. Да, на момент сдачи у группы поддержки будет документация, но ее не всегда бывает достаточно.
Стоит ли заводить отдельную команду под проект?
В моей практике бывали случаи, когда под ИТ-проект выделялись отдельные люди. Они набирались в компанию с тем расчетом, чтобы в дальнейшем оказаться в центре компетенции. В одном из подобных проектов, который я в целом считаю удачным, был, тем не менее, заложен избыточное количество людей. Команду сформировали с довольно большим запасом. С другой стороны, заранее рассчитать нагрузку на проектную команду достаточно сложно.
Но чаще, во всяком случае в ретейле, где я в основном работаю, выделенной команды даже при внедрении большой ИТ-системы не предусмотрено. Есть руководитель проекта, под его началом находится проект-менеджер, который выполняет техническую роль. Это позволяет экономить средства. Но приходится мириться с тем, что сроки реализации всего проекта целиком и его отдельных этапов постоянно смещаются. Дело в том, что люди, задействованные во внедрении, выполняют и другие обязанности, кроме того, они могут участвовать в иных проектах, параллельно реализуемых в компании. Смещение сроков — один из основных рисков больших проектов, когда речь идет о замене крупной ИТ-системы.
Если внедренная система не нравится, кто виноват — программист или техподдержка?
Конфликт, обычно разгорается не между программистами-внедренцами и поддержкой, а между бизнес-пользователями и проектной командой. Именно бизнес при начале эксплуатации начнет говорить: «Я имел в виду другое» либо «Ой, а я забыл, что здесь хотел пять колонок в файле Excel». Конфликт между бизнес-пользователями и проектной командой — это неизбежно. Это системный конфликт, он всегда будет. Нужно заранее подготовить к этому руководство и разработать методику минимизации такого рода издержек.
Как понять, что лучше: внедрять и поддерживать своими силами или доверить все внешней компании?
Первое, с чем надо определиться, — стоит ли писать систему с нуля. Но сегодня такой подход — редкость. Обычно берется стандартное решение и адаптируется под нужды компании. Вопрос о том, брать ли для такой задачи сторонних разработчиков или своих решается просто — на что денег хватит. При этом к внешним подрядчикам прислушиваются, к своим — не всегда. Ибо, как известно, нет пророка в своем отечестве.
Я считаю, что оптимально, когда в проекте участвует один или несколько внутренних аналитиков, а также внешняя компания-исполнитель, которая настраивает программный продукт под нужды заказчика. В дальнейшем она либо сдает систему заказчику, либо сама остается ее поддерживать. В редких случаях для поддержки внедренной системы нанимается третья сторона. Это случается, к примеру, если подрядчик на этапе сдачи в эксплуатацию разругался с заказчиком. Такое случается.
Надо иметь в виду, что если поддержкой готов заняться сам внедренец, то от него нужно требовать не менее строгой документации, чем в любом другом случае. Тогда снижаются риски остаться привязанным к поставщику.
Стоит ли стремится ИТ-руководителю сплотить вокруг себя всех, в том числе топ-менеджеров, и рулить процессом?
Зависит от проекта — среди них бывают «чисто айтишные» проекты. Связанные с заменой серверов, к примеру. В них от «топов» нужно только согласие на финансирование. Если же это крупный бизнес-проект, сопровождающийся изменениями в ИТ-архитектуре, то у него всегда есть бизнес-заказчик. Не стоит пытаться им «рулить». Даже в случае, когда ИТ-директор первым заметил, что ИТ-система начинает не соответствовать потребностям бизнеса. Тогда его задача — привлечь на свою сторону представителей бизнес-подразделений. И влияние авторитета ИТ-директора в этом случае важно, но я полагаю, что он вряд ли должен пытаться «подмять» под себя весь проект.
Опубликовано 29.04.2013
