Серьезный бизнес представить без ERP невозможно. Современные ERP-системы (термин Enterprise Resource Planning переводится с английского как «планирование ресурсов предприятия») автоматизируют управление практически всеми видами ресурсов, в том числе трудовыми, технологическими, маркетинговыми. Что особенно важно: такая автоматизация не делается заранее, про запас. Все нужно делать «по живому», в рамках действующей коммерческой организации – что создает немало проблем и вопросов, на которые мы постараемся сейчас ответить.
Взгляд со стороны заказчиков представляет Александр Козаржевский, руководитель проектов с опытом внедрения серийных IT-решений на производстве и в ритейле. Позицию разработчиков озвучивает Инна Петрова, руководитель группы по внедрению ERP-системы в компании Legrand. Их пожелания редакция Executive.ru свела в таблицу, расположенную ниже.
Executive.ru: Что прежде всего нужно выяснить заказчику у поставщика ERP-системы, и встречно, разработчику у заказчика?
Инна Петрова: «Почему?». Почему вы решили, что вам нужна ERP-система? Почему именно эта, если указывается конкретная? Почему обратились к нам?
Александр Козаржевский: Две основные причины для автоматизации управления: конкуренция и проблемы бизнеса. Как правило, техническими причинами становятся нехватка информации о состоянии бизнес-процессов и недостаточная оперативность ее обработки. Все это создает предпосылки к поиску и внедрению новых IT-инструментов.
По поводу конкретного решения и поставщика – сначала составляется список предложений на рынке, оцениваются различные варианты. На первом шаге, с порога, нет никаких заказов, это просто сбор информации. В частности, интересует экспертиза и опыт внедрений (масштаба нашей компании), а также практика внедрения. Поэтому мои вопросы:
- Что именно внедряли?
- Где, какой масштаб компаний-заказчиков и пользователей ваших IT-решений?
- Когда? Если давно, могли уйти те, кто добился этого успеха.
Важно также понимание специфики нашего бизнеса и процесса внедрения:
- Какой у вас подход?
- Что определено в качестве рамок проекта?
- Как контролируется ход внедрения ERP-системы?
И.П.: В принципе, логика построения всех ERP-систем идентична. Поэтому могу ответить на свежем примере – автоматизации управления транснациональной корпорацией Legrand. Был проведен даже не один проект, а несколько, для разных SBU (strategic business unit, стратегических бизнес-единиц – Executive.ru), плюс общая интеграция.
Мы практикуем Agile-подход, поскольку он позволяет начать работу пользователей с системой гораздо раньше, чем традиционный «каскад». Кроме того, так на ранних стадиях можно выявить проблемные моменты и уделить внимание их исправлению не в «пожарном», а в рабочем порядке. Рамки проекта изначально определяются в ходе переговоров с заказчиком. Как правило, это срок на внедрение системы до ее полного запуска, плюс время на доработку. Реальные сроки очень индивидуальны и зависят от масштабов компании и специфики ее бизнеса. Ну и, соответственно, от объема вовлеченных ресурсов – как с нашей стороны, так и со стороны заказчика. Последнюю стадию доработок мы стараемся минимизировать – еще один аргумент в пользу Agile.
Ход внедрения контролируется руководителем проекта и регулярно освещается в ходе совещаний представителями заказчика, в том числе с топ-менеджментом.
Executive.ru: Назовите, пожалуйста, ключевые характеристики ERP-систем.
А.К.: Функциональные возможности и их особенности. Например, как реализовано планирование, закупки, производство и т.п. Разумеется, сроки и стоимость внедрения, а также стоимость платформы, расходы на сопровождение. И наличие соответствующих специалистов на рынке. Другими словами, интересна практическая целесообразность выбора конкретного IT-решения, и слагаемые полной стоимости владения.
И.П.: Согласна с тем, что в первую очередь нужно оценивать функциональные возможности системы. Желательно, чтобы они в полной мере соответствовали не только текущим потребностям бизнеса, но и его перспективам. Иначе потом придется докупать, достраивать, донастраивать. Это как раз то, чего надо стараться всеми силами избегать.
Здесь начинается второй важный критерий – перспективы развития, поддержки и интеграции. Следует обратить внимание на сервис провайдера системы, его надежность, гибкость и оперативность реагирования. Далее – технические характеристики, которые влияют на возможность расширения функционала системы и увеличение числа пользователей.
Последним назову стоимость владения. Конечно, следует ориентироваться на разумное соотношение цены и качества, в том числе поддержки. И не забывать о том, что «скупой платит дважды».
Executive.ru: Какие главные риски внедрения ERP? Какой самый главный риск, на ваш взгляд?
И.П.: Главный риск – это непродуманность решения заказчика. Речь не об IT-решении, а в прямом смысле слова, «решение» как управленческий вердикт. Иногда бывает, что все критерии взвешены (казалось бы), выбор сделан, проект стартовал. С энтузиазмом закипает работа с обеих сторон, а потом вдруг у заказчика меняются приоритеты – как по финансам, так и по времени. И работа «виснет». Случай, замечу, нечасто встречающийся, но, как говорится, имеет место быть. Безусловно, тут есть и определенная вина разработчика – в том, что на предварительных переговорах не были «вскрыты» истинные потребности клиента. Тем не менее, все остальные риски в той или иной степени сопряжены с этим ключевым обстоятельством – четким и однозначным намерением довести внедрение до успешного завершения.
А.К.: По-моему, основной риск – неправильно определенные цели. Причем не цели проекта внедрения ERP, а цели бизнеса. Именно поэтому «вдруг» пропадает энтузиазм. На определенной глубине детализации заказчик может понять, что не получит желаемый эффект в бизнесе – и тогда он выйдет из проекта, или начнет его тормозить.
Поэтому еще и еще раз – критичны правильно сформулированные экономические ожидания от внедрения. Они определяют рамки проекта, помогают контролировать ход проекта. На каждом шаге исполнитель обязан соотносить свои действия с целями бизнеса заказчика.
Executive.ru: Очевидно, приступая к внедрению ERP, и заказчик, и поставщик системы нацелены на успех. И если заранее известны риски, то… наивно ожидать, что этого окажется достаточно для предотвращения проблем?
И.П.: Естественно. Не зря ведь управление рисками выделяют в отдельный раздел управления проектами. Рискуя показаться банальной, отмечу, что при планировании проекта важно определить до 10 наиболее вероятных рисков. Не более! Все предугадать невозможно. Каждый заказчик индивидуален. При этом, для разработчика важно умение быстро реагировать на вновь открывающиеся обстоятельства. И, соответственно, оперативно предлагать новые решения.
А.К.: Добавлю, что для предотвращения проблем важно обеспечить: однозначное распределение ответственности за конкретные работы; правильное, однозначное разграничение работ, с исчисляемым результатом по каждой задаче; список работ должен быть изначально полон.
Три этих условия не защитят полностью. Наивно ожидать, что проблем вообще не будет. Но в этом случае будет хороший шанс их исправить в рамках сроков и бюджета.
Executive.ru: Раз мы заговорили о неприятных вариантах – по каким признакам можно определить, что внедрение ERP не просто «буксует», а окончательно провалилось? И как предотвращать такие ситуации?
А.К.: Проект ограничивают сроками, суммами и объемами работ – либо функциональными требованиями, что, в конечном счете, тот же самый объем работ. Если какие-то из этих требований жестко зафиксированы, то невозможность соблюсти зафиксированные параметры – провал. Например, сроки: если доработки не сделали к запуску магазина, то все – срыв открытия.
Как предотвратить? Планирование и сопоставление план/факта на регулярной основе. Если сроки очередного этапа срываются, надо устранить причину срыва и перестроить технологические решения оставшихся этапов, чтобы успеть в более сжатые сроки. Возможно, придется пожертвовать чем-то из менее важного функционала, найти какие-то другие способы. Главное, не допустить накопления проблем. Они должны решаться по возможности немедленно – в рамках текущего этапа. В крайнем случае, за следующий этап. Иначе может наступить момент, когда либо продолжение работ уже невозможно, либо смысл потерян – не успеваем, не помещаемся в бюджет, ключевой функционал не будет реализован.
И.П.: Насчет предотвращения – я уже упомянула, что важно «вскрыть» потребности заказчика еще на стадии предварительных переговоров. Действительно ли он нуждается в ERP? Почему? Что он реально хочет от системы? Готов ли он вкладываться не только деньгами, но и людскими ресурсами в ее внедрение? Если на эти вопросы получены четкие ответы, то риск провала и даже «пробуксовки» проекта стремится к нулю. Провал очевиден тогда, когда заказчик самоустраняется от взаимодействия с разработчиком, выдвигая иные приоритеты для использования своих финансовых и временных ресурсов. Все остальное, на мой взгляд, решаемо.
Executive.ru: Каких гарантий заказчики должны требовать у разработчиков? Адекватных, разумеется. Тот же вопрос вам, Инна – какие гарантии поставщики ERP-систем готовы давать?
А.К.: Гарантий качества. Готов согласиться с Инной в том, что если не уложились в сроки или бюджет из-за неучтенных ранее требований – это плохо, но тут вина не только исполнителя. А вот качество, на мой взгляд, исполнитель не только может обеспечить, но и обязан. Причем, никакие «отмазки» по этому пункту не помогут. Поэтому при выборе поставщика IT-продукта и проверяют репутацию, наряду с экспертизой предметной области.
И.П.: Отвечу кратко: время, цена, качество. И все это фиксируется документально. Количественные показатели определяются «на берегу», и коль скоро они устраивают обе стороны, разработчик действительно отвечает за их соблюдение своей репутацией. Да, конечно, возможны отклонения, но их масштабы тоже оговариваются предварительно.
Executive.ru: Что разработчики хотят и вправе требовать у заказчиков, помимо оплаты? Есть некий «райдер», без выполнения которого приличная IT-компания не возьмется за проект?
И.П.: Вовлеченности в проект. Буду настойчива по донесению этой мысли, потому что иначе качественное решение становится абсолютно недостижимым. Со стороны заказчика всегда должна быть полная готовность к сотрудничеству: пояснениям, консультациям, интервью. Без выполнения этих условий затевать проект не имеет ни малейшего смысла.
А.К.: Помимо оплаты? Предоплату. Если серьезно, согласен – готовность компании к внедрению необходима. Важна зрелость процессов компании, определенная вовлеченность топ-менеджмента, понимание ими выгоды, наличие экспертных знаний сотрудников, делающих возможным применить как новую методологию, так и новые IT-инструменты.
Executive.ru: Представьте, что ваш партнер по внедрению ERP идеален. Самый лучший поставщик! И вот вы вместе организуете образцово-показательное внедрение. Как оно выглядит?
А.К.: Есть экономическое обоснование, измеряемые цели проекта, функциональные требования и use-cases (формальное описание взаимодействий между пользователями с разными ролями и полномочиями в IT-системе, примечание редакции). Возможности ERP без доработок покрывают 99% функциональных требований.
Топ-менеджеры начинают утро с контроля задач ключевых пользователей, а поставщик решения – с демонстрации того, как можно решить ранее заданные вопросы ключевых пользователей, причем без доработок. Затем обе стороны актуализируют список оставшихся проблем, и немедленно приступают к их решению.
И так каждый день, а не только перед подписанием актов и выставлением счетов.
И.П.: Говорят, мысль материальна. Почему бы и не помечтать? Тогда резюмирую то, о чем уже упоминала: заказчик, полностью определившийся в своих потребностях, умеющий четко описать специфику и проблемы своего бизнеса, готовый активно участвовать в разработке и внедрении проекта, ну и, конечно, платежеспособный.
Образцово-показательным внедрение будет тогда, когда разработчик на основе информации, полученной от заказчика (я тут имею в виду весь заинтересованный коллектив) презентует решение, которому все аплодируют, предвкушая скорое внедрение.
Далее, все с энтузиазмом участвуют в интеграционных тестах, «разбирают полеты», разработчик доводит дело «до ума» и наступает торжественный момент «разрезания ленточки». Заказчик получает свою идеальную систему, а разработчик – денежное вознаграждение и моральное удовлетворение. Обе стороны гордятся результатом, охотно обмениваются отзывами, помогают друг другу использовать факт внедрения в рекламе, и продолжают столь успешное сотрудничество, становясь надежными долгосрочными партнерами.
Какие вопросы стороны непременно должны задать друг другу
|
Что должен выяснить поставщик ERP-системы у заказчика |
Что должен выяснить заказчик |
|
1. Почему вы решили, что вам нужна ERP-система? Действительно ли вы нуждаетесь в ERP? 2. Почему вы считаете, что вам нужна именно эта система (если указывается конкретная)? 3. Почему обратились к нам? 4. Что реально вы хотите получить от системы? 5. Готовы ли вы вкладываться не только деньгами, но и людскими ресурсами в ее внедрение? 6. Каковы реальные цели (не цели проекта внедрения ERP, а цели бизнеса)? 7. Каковы экономические ожидания от внедрения ERP? |
1. Что именно вы внедряли? 2. Где, какой масштаб компаний-заказчиков и пользователей ваших IT-решений? 3. Когда? Если давно, могли уйти те, кто добился этого успеха. 4. Какой у вас подход? Что определено в качестве рамок проекта? 5. Как контролируется ход внедрения ERP-системы? 6. Каковы функциональные возможности системы? 7. Каковы перспективы ее развития, поддержки и интеграции? 8. Каковы технические характеристики, которые влияют на возможность расширения функционала системы и увеличение числа пользователей? 9. Какова стоимость владения системой? |
|
Ключевые параметры: время, цена, качество. Они фиксируются документально. |
|
Когда компания выбирает и внедряет свою первую ERP систему - это одна ситуация, когда пытается выбрать третью по счёту - другая. В первом случае больше'е влияние оказывает имеет несовершенство или асимметричность информации. В т.ч. клиент предполагает, что вместе с системой он получит ещё и бест-практикс. Но когда директор метургического комбината понимает, что теряет конкурентные преимущества за которые боролся многие годы, а предложенная бест-практикс - это опыт для молочной фермы - а об этом его никто не предупредил, он и начинает тормозить проект.
Ваши рассуждения о том, что ERP покрывает 99% функциональных требований - это точно не отвечает реалиям.
:)