|
Персональные инструменты |
|||
|
Горячая заменаМатериал из CustisWiki
IT Manager: В каких случаях и по каким причинам, исходя из вашего опыта, компании обычно принимают решение о смене ключевой информационной системы, например, ERP? Михаил Заборов: Ситуаций, которые могут заставить компанию принять трудное решение о замене ключевой ИТ-системы, может быть несколько. Одна из самых распространенных — когда информационный ресурс теряет «хозяина»: например, компанию покидает ключевой специалист, который глубоко разбирался в устройстве системы и занимался ее развитием, или с рынка уходит поставщик ИТ-решения, что фактически означает остановку его поддержки и развития. Огромные проблемы для бизнеса может создавать и нелояльность поставщика решения: к примеру, вендор не заинтересован во внесении в систему необходимых для бизнеса изменений или делает это слишком медленно, чем тормозит развитие компании-заказчика, не позволяет ей завоевывать новые рынки и успешно конкурировать с другими фирмами. Еще одна распространенная ситуация — когда с ростом компании и развитием бизнеса функционал выбранной вначале системы перестает удовлетворять его требованиям, и устранить эти «разрывы» в рамках существующей системы становится просто невозможно из-за изменения самой концепции бизнеса. Ну и, наконец, естественная и неизбежная причина замены ИТ-системы — это устаревание технологий, на которых она построена, что в конечном счете упирается в невозможность использования современного Hardware (а старое ни купить, ни поддерживать уже тоже невозможно). Когда смена системы действительно неизбежна? Именно к неизбежной замене системы приводит только безнадежное устаревание технологий. Во всех остальных случаях «агонию» можно поддерживать достаточно долго. Только стоить это будет очень дорого и поможет в лучшем случае обеспечить «выживание» информационного ресурса, ни о каком целенаправленном развитии речи здесь быть не может. По каким критериям вы рекомендуете выбирать новую систему? Главное — четко осознавать, что приобретаемая ИТ-система должна подходить именно вам. Ни бренд компании-поставщика, ни его отраслевой опыт не должны играть здесь такой роли, как то, насколько предлагаемое ИТ-решение способно поддержать бизнес-процессы конкретно вашей компании. При выборе стоит обращать внимание не только на то, чтобы в системе было «все, что нужно», но и на то, чтобы в ней не было ничего лишнего. Ведь дополнительный функционал удорожает поддержку и существенно усложняет развитие ИТ-системы. Следующий чрезвычайно важный фактор — это компетентность и мощность команды внедрения. И система, и сама команда должны быть гибкими и способными адекватно реагировать на изменения, а в систему должен быть заложен ресурс развития под нужды клиента, иначе можно столкнуться с ситуацией, когда переделка 5% функционала обойдется в 30% от стоимости всей системы. Как правильно подобрать команду проекта при смене платформы критически важной информационной системы, чтобы, с одной стороны, обеспечить необходимую преемственность, а с другой — избежать старых ошибок и в результате получить именно то, что необходимо — каковы ваши рекомендации? Прежде всего, представители поставщика ИТ-решения, занятые в проекте внедрения, должны глубоко разбираться в фундаментальных принципах функционирования системы и иметь возможность влиять на них. Специалисты компании-подрядчика должны быть искренне заинтересованы в успехе проекта и действовать не исходя из возможностей существующей системы, а ориентируясь на потребности заказчика (к примеру, предлагать не те технологии, с которыми компания-разработчик привыкла работать, а те, которые позволят наилучшим образом решить проблему клиента). Крайне желательно, чтобы в таком проекте участвовали специалисты по существующим системам — это не обязательно должны быть представители предыдущего вендора, в их роли могут выступать специалисты заказчика. Ну и, наконец, важно понимать, что никакая сколь угодно хорошая команда не может гарантировать успех проекта, если нет активности и заинтересованности со стороны заказчика изменений. Какие трудности характерны для ИТ-проектов, связанных с заменой одной информационной системы на другую? Ключевая сложность таких проектов — это необходимость обеспечить непрерывное функционирование ИТ-системы заказчика целиком при замене ее части. Это требование может быть критическим для бизнеса, ведь перебои в работе системы зачастую означают остановку ключевых бизнес-процессов и приводят к огромным убыткам. Кроме того, подрядчик должен учитывать существующий контекст и уметь «бесшовно» встраивать свое решение в имеющийся ИТ-ландшафт. А для этого у команды внедрения должно быть умение и желание разбираться с этим ландшафтом и менять свое ПО в соответствии с ним. Далее, при внедрении новой системы изменения должны производиться «контролируемыми квантами», чтобы заказчик успевал их «переварить», а подрядчик — внести изменения в процесс внедрения и саму систему, если это необходимо. Какая схема взаимоотношений между заказчиком и поставщиком информационной системы является наиболее эффективной, на ваш взгляд? Главное, что необходимо для успеха проекта подобного масштаба, — это партнерские отношения между заказчиком и подрядчиком. Взаимное доверие и уважение, искренняя заинтересованность и работа на общие цели — только в этом случае стороны смогут слаженно и эффективно действовать в условиях сложности и неопределенности. Мы уже много лет работаем с нашими клиентами по неоклассическому контракту: по сути, это означает, что фиксируются только крупные задачи и параметры внедрения, а мелкие детали прорабатываются постепенно, в рабочем порядке. Такая схема позволяет сторонам сконцентрироваться на ключевых моментах и не «спотыкаться» о горы мелочей. Нельзя забывать и про то, что с внедрением новой системы все не заканчивается, а только начинается. Бизнес постоянно претерпевает изменения, которые нужно как-то «опрокидывать» в информационные ресурсы. А поскольку никто не знает ИТ-систему лучше ее создателя, хорошо бы, чтобы вендор принимал непосредственное участие в ее дальнейшем развитии.
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. |
||