Просмотр исходного текста страницы Горячая замена

<blockquote>
''[[:Категория:Михаил Заборов (Статьи)|Михаил Заборов]], наш заместитель генерального директора по стратегическим проектам, рассказал журналу [http://www.allcio.ru/itmanager/113/ IT Manager] о смене управленческого ПО в&nbsp;компании. Почему компании решаются на замену ключевой ИТ-системы? Что лучше&nbsp;— дать ей «долго умирать» или сменить «резким движением»? Как выбрать новую систему и не повторить ошибки прошлого? Об этом&nbsp;— в статье [http://www.allcio.ru/business/it/46099.html «Горячая замена»] на сайте и в бумажной версии журнала. Мы публикуем полный текст беседы с Михаилом.''
</blockquote>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



[[Категория:IT Manager (Публикации)]]
[[Категория:Михаил Заборов (Статьи)]]
[[Категория:2013 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}