Нужно ли внедрять 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-совокупностей:

  • В случае если наглядно и разумеется угадывается один из обрисованных выше случаев системных неприятностей, замешанных на фальшивых предпосылках для комплексной автоматизации – ничего не окажет помощь. Все пропало, бегите!
  • Быть может, имеется здоровая база для внедрения, высшее управление клиента нацелено на пользу для компании, а не для себя лично, выделены ресурсы, имеется вменяемый подрядчик, ТЗ – другими словами в наличии полный набор нужного, как оно и должно быть? Превосходно! Но в случае если обращение о рядовом простом «хорошем» проекте, придется поднапрячься.
  • Предельно четкие и прозрачные замыслы, внедрение – приоритетный проект у клиента и серьёзный для подрядчика, проектные команды мотивированы и «сыграны», имеется регламенты, матрица рисков и вся вторая нужная отчетность – более того, она систематично актуализируется и используется. Вам крупно повезло. Дело идет на лад.
  • Управление внедрением сфокусировано на ответе бизнес-задач клиента, педантично придерживается согласованного ТЗ, замысел-бюджета и графика, наряду с этим систематично проводя заседания для управления и обсуждения отклонений трансформациями в равном паритетном диалоге? И это не связано с тем, что вы рехнулись от стресса на гибнущем проекте, все взаправду? Тогда пора заказывать шампанское.

Последний вариант открыто фантастический, чисто для масштаба. В действительности так не бывает. Помимо этого, вероятен микс из различных случаев.

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

Выяснение имело возможность затянуться на 6 месяцев, что очень очень плохо оказывало влияние на всех участников проекта.

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

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

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

Чаще всего подобные риски проявляются в «экономических» проектах, в то время, когда хочется «всего и сходу».

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

Данный риск характерен как для «экономических», так и для «технологических» проектов (для «политических» он менее ответствен потому, что на них редко проводится детальный анализ результатов).

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

Главное слово тут «незаинтересованной», в противном случае вы получите легко дополнительного лоббиста, услуги которого еще нужно будет оплатить.

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

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

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

Редактор рубрики «IT для бизнеса» – Сергей Соловьев

Обзор возможностей AVA ERP


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer