Персональные инструменты
 

Горячая замена

Материал из CustisWiki

Версия от 19:33, 24 июля 2013; AlexandraVelyaninova (обсуждение)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Михаил Заборов, наш заместитель генерального директора по стратегическим проектам, рассказал журналу IT Manager о смене управленческого ПО в компании. Почему компании решаются на замену ключевой ИТ-системы? Что лучше — дать ей «долго умирать» или сменить «резким движением»? Как выбрать новую систему и не повторить ошибки прошлого? Об этом — в статье «Горячая замена» на сайте и в бумажной версии журнала. Мы публикуем полный текст беседы с Михаилом.

IT Manager: В каких случаях и по каким причинам, исходя из вашего опыта, компании обычно принимают решение о смене ключевой информационной системы, например, ERP?

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

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

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

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

Когда смена системы действительно неизбежна?

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

По каким критериям вы рекомендуете выбирать новую систему?

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

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

Следующий чрезвычайно важный фактор — это компетентность и мощность команды внедрения. И система, и сама команда должны быть гибкими и способными адекватно реагировать на изменения, а в систему должен быть заложен ресурс развития под нужды клиента, иначе можно столкнуться с ситуацией, когда переделка 5% функционала обойдется в 30% от стоимости всей системы.

Как правильно подобрать команду проекта при смене платформы критически важной информационной системы, чтобы, с одной стороны, обеспечить необходимую преемственность, а с другой — избежать старых ошибок и в результате получить именно то, что необходимо — каковы ваши рекомендации?

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

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

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

Какие трудности характерны для ИТ-проектов, связанных с заменой одной информационной системы на другую?

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

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

Далее, при внедрении новой системы изменения должны производиться «контролируемыми квантами», чтобы заказчик успевал их «переварить», а подрядчик — внести изменения в процесс внедрения и саму систему, если это необходимо.

Какая схема взаимоотношений между заказчиком и поставщиком информационной системы является наиболее эффективной, на ваш взгляд?

Главное, что необходимо для успеха проекта подобного масштаба, — это партнерские отношения между заказчиком и подрядчиком. Взаимное доверие и уважение, искренняя заинтересованность и работа на общие цели — только в этом случае стороны смогут слаженно и эффективно действовать в условиях сложности и неопределенности. Мы уже много лет работаем с нашими клиентами по неоклассическому контракту: по сути, это означает, что фиксируются только крупные задачи и параметры внедрения, а мелкие детали прорабатываются постепенно, в рабочем порядке. Такая схема позволяет сторонам сконцентрироваться на ключевых моментах и не «спотыкаться» о горы мелочей.

Нельзя забывать и про то, что с внедрением новой системы все не заканчивается, а только начинается. Бизнес постоянно претерпевает изменения, которые нужно как-то «опрокидывать» в информационные ресурсы. А поскольку никто не знает ИТ-систему лучше ее создателя, хорошо бы, чтобы вендор принимал непосредственное участие в ее дальнейшем развитии.


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Горячая замена»