БИЗНЕС-СЕТЬ KINETICS CRM CALL-ЦЕНТРЫ ERP ECM ITSM PM АБС АБН SEC SAAS
ЧТО ТАКОЕ ERP? НОВОСТИ ПРАКТИКА АНАЛИТИКА УСЛУГИ ERP-СИСТЕМЫ ПОСТАВЩИКИ ФОРУМ  
СТАТЬИ /более 450/
РЕЙТИНГИ
МНЕНИЯ ЭКСПЕРТОВ
ИНТЕРВЬЮ
ОБЗОРЫ
ERP МЕТОДОЛОГИЯ

СПЕЦИАЛЬНЫЙ ПРОЕКТ ERP-ONLINE.RU Представляем Компанию AVA ERP. Читайте случаи "из жизни", мнения экспертов, комментарии специалистов.
Заходите, читайте, комментируйте >>>

   
ЧТО ТАКОЕ ERP?
ERP — это информационная система для идентификации и планирования всех ресурсов предприятия, которые необходимы для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов >>>
 
СТАТЬИ

Нужно ли внедрять ERP-систему? Как сделать это с минимальными рисками



Переход на комплексное IT-решение похож на бег по коридору, заваленному граблями. Евгений Вергазов обращает внимание на главные риски внедрений ERP-систем.

 

Внедрение систем класса ERP – один из самых частых IT-проектов для среднего и крупного бизнеса в сегменте производства, торговле и на предприятиях сферы услуг. Рано или поздно менеджмент предприятия оказывается в ситуации, когда содержание «зоопарка» из слабо интегрированных между собой инструментов для управления и учета тормозит развитие бизнеса. Как правило, в таких случаях в качестве панацеи от всех бед преподносится комплексная автоматизация.

Давайте разберемся, насколько это соответствует действительности. Для начала стоит понять, какие причины инициируют процесс внедрения ERP-системы на предприятии. В большинстве случаев их можно разделить на технологические, политические и экономические. Здесь царит путаница, потому что технологические причины тесно связаны с экономическими, политические тоже обычно выдают за экономические. Получается, что в любом споре об ERP собеседники вооружаются, по сути, одинаковыми аргументами, только трактует их каждый по-своему. Однако, на самом деле, есть и различия в мотивах.

Технологичная засада

Яркий пример технологических предпосылок для внедрения ERP-системы – часто встречающаяся «тупиковая ветвь развития». Здесь возможны два основных варианта: эволюционный и революционный. Несмотря на кажущееся противопоставление, речь на самом деле идет практически об одном и том же.

При эволюционном регрессе идет постепенное накопление и наслаивание различных IT-решений, которые честнее всего называть заглушками. Они, возможно, действительно решают какие-то текущие задачи, но, с учетом игнорирования интеграции с уже существующим IT-ландшафтом, проблем создают не меньше. Пока IT-директор и/или команда талантливых энтузиастов успевают поддерживать жизнь в этом «Франкенштейне», с точки зрения высшего руководства компании дела идут неплохо. Но как только начинаются сбои внезапно (всегда внезапно), выясняется, что это не частный досадный случай, который можно локализовать малой кровью, а полноценный системный коллапс, сопряженный со ступором всей инфраструктуры. В худшем случае еще с потерей данных, и другими неприятными последствиями. Летят обидные письма и слова, головы с плеч, показатели и бонусы, все летит в эту черную IT-дыру – пока, наконец, кто-то тихо и торжественно не произносит: «Пора внедрять ERP».

Революционный путь к этой сакраментальной фразе начинается обычно с того, что менеджмент соблазняется умелым маркетингом и пламенными презентациями внушающего доверие безвестного подрядчика с предложением в стиле «А если нет разницы, зачем платить больше?». И вот уже приобретена, внедрена, с помпой запущена в эксплуатацию некая комплексная информационная система – тут бы всем и радоваться – но неожиданно (всегда неожиданно) разработчик уходит с рынка и с горизонта. Оказавшись без поддержки вендора, IT-служба начинает лихорадочно метаться, изобретать «костыли», все разваливается, и в один прекрасный день… Пора внедрять ERP. Настоящую ERP.

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

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

Политическая спекуляция

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

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

Экономическая легенда

Казалось бы – безупречный фундамент для создания действительно полезного и практичного IT-фундамента. Цели внедрения касаются повышения эффективности бизнеса. Чаще всего это означает повышение оперативности и точности, создание единого информационного пространства, бла-бла-бла… Более детальные подробности в любом описании любого решения и проекта на рынке ERP.

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

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

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

Матрица рисков глазами Нео

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

Грамотный менеджмент со стороны заказчика и поставщика IT-системы способен применять матрицу рисков по назначению, в качестве одного из многих инструментов. А как минимизировать риски тем, кто «в первый раз»?

Предлагаю не очень научную, зато практичную классификацию при оценке ситуаций на проектах по внедрению ERP-систем:

  • Если наглядно и очевидно угадывается один из описанных выше случаев системных проблем, замешанных на ложных предпосылках для комплексной автоматизации – ничего не поможет. Все пропало, бегите!

  • Возможно, есть здоровая основа для внедрения, высшее руководство заказчика нацелено на пользу для компании, а не для себя лично, выделены ресурсы, есть вменяемый подрядчик, ТЗ – то есть в наличии полный комплект необходимого, как оно и должно быть? Отлично! Но если речь о рядовом обычном «хорошем» проекте, придется поднапрячься.

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

  • Руководство внедрением сфокусировано на решении бизнес-задач заказчика, педантично придерживается согласованного ТЗ, план-графика и бюджета, при этом регулярно проводя совещания для обсуждения отклонений и управления изменениями в равном паритетном диалоге? И это не связано с тем, что вы рехнулись от стресса на гибнущем проекте, все взаправду? Тогда пора заказывать шампанское.

Последний вариант откровенно фантастический, чисто для масштаба. В реальности так не бывает. Кроме того, возможен микс из разных случаев. Например, все идет относительно хорошо – а потом вдруг (всегда вдруг) меняется топ-менеджер со стороны заказчика. Такой риск сложно предсказать, трудно не заметить и невозможно забыть. Мы не раз сталкивались с ситуацией, когда первое, что делал новый руководитель – останавливал работы до выяснения целей, статусов, назначения и ожидаемой эффективности проекта. Выяснение могло затянуться на полгода, что крайне негативно влияло на всех участников проекта.

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

Другим ключевым фактором проекта является постоянный контроль фокусировки на целях проекта и нахождения в установленных организационных и функциональных границах проекта. Очень часто в процессе внедрения ERP возникают новые задачи области и пожелания, которые предлагается реализовать «по пути» (зачастую это выглядит как полет из Москвы в Санкт-Петербург через Владивосток). Расширение границ проекта без изменения ресурсного обеспечения чревато провалом не только новых, но и исходных целей. Наиболее часто подобные риски проявляются в «экономических» проектах, когда хочется «всего и сразу».

Значит ли это, что всегда нужно придерживаться базовой концепции, не отступая от нее ни на шаг? Отнюдь. С этим связан еще один важный фактор успеха проекта – системное управление изменениями. Если мы расширяем границы проекта, это должен быть управляемый процесс с адекватным пересчетом ресурсной составляющей и согласованием результатов пересчета с уполномоченными заинтересованными лицами (резюме «срок проекта отодвигается еще на год» вполне может быть достаточно для пересмотра приоритетов). В противном случае риск потери управляемости становится крайне высоким. Этот риск характерен как для «экономических», так и для «технологических» проектов (для «политических» он менее важен в силу того, что на них редко проводится детальный анализ результатов).

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

Итак, в предельном упрощении рекомендации по внедрению ERP-системы:

1) Если есть возможность отказаться от автоматизации управления в пользу повышения его качества другими способами (административными, мотивационными, маркетинговыми и т.д.) – отложите модернизацию IT на потом, разберитесь сначала с накопившимися проблемами на более глубоком уровне. Это многократно окупится, и больше всего на последующем внедрении ERP-системы.

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

e-xecutive.ru


<<< Обсудить на форуме  |  Все статьи >>>





 
О проекте Конфиденциальность Размещение рекламы Карта сайта Напишите нам! RUS / ENG
Copyright © 2005 - 2017 ERP-ONLINE.RU и Бизнес-сеть "Kinetics". All rights reserved
ECMONLINE.RU