|
|
| Строка 1: |
Строка 1: |
| − | [[:Категория:Максим Михалев (Статьи)|Максим Михалев]] | + | #перенаправление [[Что оживит российский рынок ERP?]] |
| − | : директор по маркетингу и продажам, CUSTIS
| + | |
| | | | |
| − | Опубликовано в обзоре [http://www.pcweek.ru/idea/article/detail.php?ID=135200 PC Week Review: ERP — системы, 15 ноября 2011]
| + | <noinclude>[[Категория:CustisWikiToLib]]</noinclude> |
| − | | + | |
| − | <blockquote> | + | |
| − | Научный редактор PC Week/RE [http://www.pcweek.ru/about/authors/detail.php?ID=13704 Сергей Свинарев] побеседовал с экспертами ряда ведущих ИТ-компаний о состоянии российского рынка ERP и проблемах, стоящих перед всеми его участниками. Результаты представлены в обзоре [http://www.pcweek.ru/idea/article/detail.php?ID=135200 Что оживит российский рынок ERP?]. В числе экспертов был и [[:Категория:Максим Михалев (Статьи)|Максим Михалев]], директор по маркетингу и продажам нашей компании.
| + | |
| − | | + | |
| − | Ниже мы приводим ответы Максима на вопросы Сергея Свинарева.
| + | |
| − | | + | |
| − | </blockquote> | + | |
| − | | + | |
| − | '''С. С.: Что, на ваш взгляд, является основной причиной неудачных внедрений ERP-систем: недостаточная функциональность тех или иных программных продуктов или ошибки консультантов-внедренцев? Могут ли стандартные методологии внедрения, предлагаемые вендорами, снизить риски ошибок консультантов?'''
| + | |
| − |
| + | |
| − | '''М. М.:''' На наш взгляд, причиной неудачных внедрений оказывается не только недостаточная, но и избыточная функциональность ERP-систем. Ну а ошибки консультантов только усугубляют ситуацию. Предположим, как это часто бывает, компания начинает внедрять готовое решение, которое по функционалу далеко не полностью соответствует ее потребностям. Часть процессов не укладываются в систему — как ее ни настраивай.
| + | |
| − | | + | |
| − | Стандартная методология внедрения предложит изменить такие бизнес-процессы компании под систему. Если компания идет на это — вопрос исчерпан: внедрение ERP-системы завершено успешно.
| + | |
| − | | + | |
| − | Если же компания сталкивается с недостаточной функциональностью ERP-системы и пытается сохранить свои особенные, ключевые бизнес-процессы, то ей нужно договориться с консультантами о доработках (кастомизации). Вот тут критически важно, чтобы консультанты были очень компетентными. Лучше всего, из числа архитекторов ERP-системы или тех, кто имеют возможность напрямую с ними коммуницировать. Тогда они в принципе могут предложить адекватное решение. А уж тут очень важно, чтобы кастомизируемая ERP-система не обладала избыточным функционалом. Иначе ее доработка обойдется дороже, чем создание нового решения.
| + | |
| − | Это известный парадокс: изменить универсальную большую ИТ-систему гораздо сложнее и дольше, чем вырастить из небольшого прототипа аналогичную ей по размерам специально для себя. Завязнуть в бесконечных доработках и исправлениях доработок — обычный сценарий для неудачного внедрения.
| + | |
| − | | + | |
| − | ИТ — жесткий материал, и изменениям он поддается с большим трудом. Зная это, вендоры стараются внедрять свои системы «как есть», уговаривая: «Только ничего не меняйте, работайте так, как того требует система». Заказчикам тоже пора избавляться от иллюзий, что внедренную ИТ-систему они в любой момент смогут «согнуть под себя». Трезвый взгляд на ИТ помогает выработать правильную стратегию автоматизации.
| + | |
| − | | + | |
| − | '''С. С.: Каковы ваши рекомендации будущим заказчикам по выбору компании, которой будет поручено развертывание системы? Какова должна быть степень участия в подобных проектах собственного ИТ-департамента заказчика?'''
| + | |
| − |
| + | |
| − | '''М. М.:''' Нужно точно сформулировать свои запросы к ИТ в крупном и на перспективу, и искать такого партнера, который способен довести проект до результата, а не «соскочит» после подписания акта о внедрении. Нужно смотреть портфолио и количество результативных (а не номинальных) внедрений, по возможности знакомиться с клиентами потенциального исполнителя.
| + | |
| − | Если речь о большой системе, то необходимо очень активное участие и глубокое погружение собственного ИТ-департамента заказчика. Но не только ИТ: реальный заказчик внедрения ERP-системы — это менеджмент бизнеса. Они должны определять вектор будущего развития участвовать в переговорах на ранних этапах принципиальных договоренностей. А собственный ИТ-департамент должен в течение всего проекта вникать в дела — смотреть промежуточные варианты, сверять детали и направление развития ИТ-системы. Благо современные Agile-технологии ведения проектов разработки это не просто позволяют, но фактически требуют такого взаимодействия между заказчиком и исполнителем.
| + | |
| − |
| + | |
| − | '''С. С.: Нужно ли на этапе внедрения планировать жизненный цикл корпоративной ERP-системы на длительную перспективу, учитывая при этом вероятность появления новых технологий (мобильность) или моделей развертывания (гибридные облачные архитектуры), возможность относительно безболезненной замены программного продукта, способность к масштабированию и т. д.?
| + | |
| − | '''
| + | |
| − | | + | |
| − | '''М. М.:''' Планировать жизненный цикл корпоративной ERP-системы нужно еще задолго до внедрения — на этапе ее выбора. Естественно, система выбирается исходя из планов компании. Если развитие бизнеса — освоение новых рынков, вывод новых продуктов — является приоритетным, то, помня о жесткости материала ИТ, нужно подбирать также способное к развитию ИТ-решение.
| + | |
| − | | + | |
| − | Что мы понимаем под способностью корпоративной ERP-системы к развитию? Это возможность изменять ее системную архитектуру без нарушения непрерывности бизнеса. Системная архитектура — это первоначальные договоренности о том, что должна делать система. Если вы покупаете готовое решение, то фактически, покупаете такие договоренности вендора со среднестатистической компанией. Поскольку именно так — обобщая и усредняя запросы клиентов — вендор отбирал функции для реализации в своей ERP-системе. Понятно, что такое решение может надежно работать на стабильном наборе операций, но не будет поддерживать изменения ваших уникальных бизнес-процессов.
| + | |
| − | | + | |
| − | Изменение программного продукта, поддерживающего ключевые процессы в крупной компании, не может быть безболезненным. Но оно может быть целенаправленным, обозримым и иметь гарантированный результат. Это достигается тем, что три заинтересованные стороны — компания-исполнитель, менеджмент и ИТ-служба заказчика — ответственно договариваются об архитектуре ERP-системы. Исполнитель подписывается на то, что в рамках архитектурных договоренностей он будет способен быстро и относительно недорого развивать систему. Если же требования бизнеса заказчика выйдут за оговоренные рамки, то в разумные сроки и бюджеты исполнитель будет в состоянии реализовать необходимый функционал. Это по плечу ИТ-компаниям, которые специализируются на проектах такого рода.
| + | |
| − | | + | |
| − | [http://www.pcweek.ru/idea/article/detail.php?ID=135200 Полный текст материала Сергея Свинарева «Что оживит российский рынок ERP?»]
| + | |
| − | | + | |
| − | | + | |
| − | [[Категория:Максим Михалев (Статьи)]]
| + | |
| − | [[Категория:PCWeek (Публикации)]]
| + | |
| − | [[Категория:2011 год (Статьи)]]
| + | |
| − | | + | |
| − | {{replicate-from-custiswiki-to-lib}}
| + | |
