Дело сделано, никому не расходиться

Дело сделано, никому не расходиться
Ольга Попова | Макс Волк | 29.04.2013

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

Проект закончен: что дальше? Иными словами, как происходит переход проекта в процесс?

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

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

В другой ситуации, когда поддержка осуществляется линейными сотрудниками самого заказчика, возникает порой «разрыв в знаниях». Дело в том, что у заказчика зачастую нет серьезной компетенции по продукту. И со временем появятся вопросы: как данным ИТ-решением поддерживать наши новые бизнес-процессы? как изменять под них систему? как использовать функции, имеющиеся в программе, но ранее не задействованные? Здесь в игру должен включиться бизнес-аналитик, который должен сказать: «На данную систему мы наши процессы положим вот так». После чего подключается разработка и внедрение. То есть решение продолжает развиваться.

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

А если доработка ведется полностью своими силами?

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

Стоит ли заводить отдельную команду под проект?

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

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

Если внедренная система не нравится, кто виноват — программист или техподдержка?

Конфликт, обычно разгорается не между программистами-внедренцами и поддержкой, а между бизнес-пользователями и проектной командой. Именно бизнес при начале эксплуатации начнет говорить: «Я имел в виду другое» либо «Ой, а я забыл, что здесь хотел пять колонок в файле Excel». Конфликт между бизнес-пользователями и проектной командой — это неизбежно. Это системный конфликт, он всегда будет. Нужно заранее подготовить к этому руководство и разработать методику минимизации такого рода издержек.

Как понять, что лучше: внедрять и поддерживать своими силами или доверить все внешней компании?

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

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

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

Стоит ли стремится ИТ-руководителю сплотить вокруг себя всех, в том числе топ-менеджеров, и рулить процессом?

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

Теги: управление проектами, стандарты, практики, стратегии, кейсы, задачи, решения

Журнал IT-Manager    [ PDF ]    [ Подписка на журнал ]

Об авторе


Ольга Попова

Ольга Попова

С 2008г. главный редактор IT Manager. В журналистике с 1986 года, правда, с перерывом на "лихие 90-е". До информационных технологий организовала несколько успешных бизнес-проектов в "Деловом Петербурге". Убеждена, что грамотный менеджер может работать в любой сфере, вне зависимости от специальности, так как ИТ-управленец мало чем отличается от управлеца-логиста. Но считаю, что именно в ИТ сейчас происходит все самое интересное.

Об авторе


Макс Волк


ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Другие материалы рубрики

Сегодня каждое наше шоу снимаем с разрешением 4K, а еще думаем о том, чтобы проводить съемку в 3D.
Возможно, кому-то такое заявление покажется немодным, но облачные технологии часто усугубляют существующие проблемы бизнеса и не приносят ожидаемого сокращения расходов и развития инноваций.

Мероприятия


08.09.2016
Санкт-Петербургский клуб ИТ-директоров «SPb CIO Club» и компания Event House приглашает Вас принять участие во втором Форуме по промышленной автоматизации «Industrial IT-Forum»! Промышленная автоматизация на предприятии – важная область, которой уделяется повышенное внимание. Использование информационных технологий - один из немногих технологически и экономически выгодных способов повышения эффективности подготовки производства. На современных предприятиях автоматизируются по максимуму все возможные участки работ. Новый взгляд на проблемы и тенденции информационных технологий в области промышленной автоматизации будут рассмотрены на II Форуме по промышленной автоматизации «Industrial IT Forum»

14.09.2016
Компания IBM приглашает Вас принять участие в Инфраструктурном Форуме IBM. Опережайте пределы возможного. Дата и место проведения: 14 сентября 2016 г., г. Москва. Подробная информация о месте проведения мероприятия предоставляется при регистрации. Каждый год тема мероприятия диктуется актуальными задачами, стоящими перед бизнесом. В прошлом году мы говорили об инфраструктуре для цифрового бизнеса, в этом году мы призываем выйти за пределы цифрового бизнеса, опередить "статус кво" и расширить инфраструктурные границы до новой эры когнитивного бизнеса.