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


Сложности могут быть разными, и возникают они на различных этапах проекта. Я бы хотел поделиться нашим опытом решения проблем в процессе опытной эксплуатации, когда уже все бизнес-процессы в новой системе описаны, роли настроены, модификации сделаны, инструкции выданы и надо просто начинать работать. По каждой проблеме я опишу её причины и приведу 1 или 2 кейса – примеры решения подобных проблем из нашего опыта.




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


Все это мы на своих проектах делаем.


Проблема №1. Не выполняются в полном объеме планы работ


По опыту чаще всего даже эти предварительно согласованные и выполнимые планы остаются нереализованными. Основная озвучиваемая исполнителями причина – недостаток времени. Хотя полный список причин чуть больше:


  • Принцип: «Главное – производить продукцию, а все остальное подождёт».
  • Психологический момент: исполнителям намного проще делать привычную рутину, чем что-то новое.
  • Неприятие идеологии системы исполнителями: «Ваша система не заработает. У нас есть Алевтина Светозаровна – умнейшая женщина, 60 лет на заводе, все в голове держит, никакая система не учтет всего, что она помнит».
  • Объективные причины:
    • низкий уровень компьютерной грамотности сотрудников заказчика.
    • как правило, при автоматизации растет трудоемкость ввода данных – учет становится более детальным, требуется вводить в систему больше информации, а это требует больше времени.

Я сознательно исключил из списка такие пункты, как саботаж и реальная нехватка рабочих рук – такое встречается не так уж часто, как можно подумать.


Что делать в таких случаях?


Комплекс мероприятий для решения проблемы №1:


  • Повышение приоритета системы. Исполнителям надо постоянно озвучивать, насколько внедрение ERP-системы важно для предприятия. Причем не просто постоянно «капать на мозги» по этому поводу (что тоже, кстати, нужно в обязательном порядке делать), но и объяснять логически, почему это необходимо: что Алевтине Светозаровне уже 85 лет, она хочет на давно заслуженную пенсию, что без ERP-системы наладить нормальный учет и планирование не получится, а это в итоге приведет к банкротству и увольнениям и т.д. Аргументов может быть много, но основной ожидаемый результат этих действий – внедрение системы должно получить, как минимум, тот же приоритет, что и текущая работа.
  • Изменение корпоративной культуры. Есть 2 функции менеджмента — это поддержание и совершенствование. Первая нужна для обеспечения выполнения текущих технологических, управленческих и организационных стандартов. А совершенствование — это шаги, направленные на улучшение существующих стандартов работы. Согласно кайдзен, худшие компании — это те, что сосредоточены только на первой функции. Их ждет крах в результате конкуренции либо изменений условий на рынке. В приложении к промышленным предприятиям это означает, что уже с уровня начальников цехов менеджмент должен больше внимания уделять совершенствованию, а не «текучке». То есть надо доносить до руководства предприятия необходимость перехода от такой картинки:


к вот такой:



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

«Ну что, Иваныч, работаете в новой системе?» — «Работаем потихоньку» — «Ну ладно, молодцы. Вы уж там постарайтесь, генерал с меня спрашивает»,


это должно быть так:


«Иван Иванович, вчера комиссия проверила ваш цех, только у 5 партий деталей из 300 партий, которые находятся у вас в цехе, рядом лежала сопроводительная документация, распечатанная из ERP-системы. Это всего 1,7% вместо 95%, которые вы должны обеспечить. На следующей неделе будет повторная проверка, если результаты будут такие же, квартальной премии вам не видать».


  • Не теоретизировать, а идти разбираться на конкретные рабочие места. Нельзя внедрить ERP-систему, сидя в кабинете. Если сотрудник говорит, что он не успевает работать в системе, надо идти к нему на рабочее место и смотреть, как он работает. Возможно, он просто не ту инструкцию использует или у него слишком маленький монитор.
  • Обучать, обучать и еще раз обучать. Вы должны быть уверены, что все исполнители обучены работе с компьютером и работе с системой, что у каждого есть инструкция и соответствующие права.
  • Продолжение работы по оптимизации АРМов исполнителей. Чем больше люди работают с системой, тем более ценную обратную связь они дают. По мере получения этой осмысленной обратной связи можно дооптимизировать рабочие места, чтобы сократить время на ввод информации. Но делать это стоит только после того, как люди активно поработали с системой хотя бы месяц.

Кейс 1. Не теоретизировать, а идти на рабочие места


Проблема: Один из наших заказчиков. На этапе запуска системы были сложности с кладовщицей, которая жаловалась, что у нее нет времени на регистрацию движения товарно-материальных ценностей в системе. Был дополнительно оптимизирован АРМ кладовщика, мы сделали так, чтобы надо было вводить самый минимум информации. Ничего не помогало.


Как была решена проблема: главный бухгалтер предприятия пришел к кладовщику на склад и с секундомером замерил, сколько времени она тратит на работу. Оказалось, что 80% времени уходит на заполнение бумажных карточек для ТМЦ. У главбуха хватало полномочий, чтобы оптимизировать процесс, с кладовщицы перестали требовать бумажные карточки, и проблема нехватки времени исчезла.


Проблема №2. Желание сделать всё и сразу


Этот пункт в чем-то перекликается с проблемой №1. Если был сформирован выполнимый план, его согласовали и утвердили, то дальше путь один – надо его выполнять. Но часто вместо этого люди вносят в него правки, добавляя новые работы, а потом не справляются с тем, что получилось. Вот несколько примеров из нашего опыта:


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

Причины этой проблемы:


  • Любовь к вызовам. Нашим людям неинтересно заниматься тем, что кажется простым, хочется вызова и испытаний.
  • Недооценка сложности задачи/переоценка собственных сил. Не всегда руководители представляют, какой объем работ могут выполнить сотрудники их подразделений. Иногда людей подводит привычка обещать на совещаниях больше, чем они могут сделать, в надежде, что на следующем совещании забудут спросить про результаты.
  • Неправильно расставленные приоритеты. Например, надо заниматься устранением ошибок в нормативно-справочных данных, без которых запуститься в принципе невозможно, а заказчик упорно не желает разбираться с этой реальной проблемой и засыпает нас вопросами по отчетности для экономических служб – отчетности, нужной намного позже и только при условии корректности «нормативки».
  • Страх перед руководством. Такое бывает, когда над руководителем проекта со стороны заказчика стоит генеральный директор или собственник, который не только не участвует, но и особо не вникает в процесс внедрения. При этом он возникает на определенных контрольных точках и дает свое весомое напутствие: «Не надо детский сад тут устраивать! Как это – запускаться только по одному цеху? Почему вам нужно 2 месяца на опытную эксплуатацию? Даю вам 3 недели на запуск в полном объеме, надо в этот срок уложиться или вы знаете, что я с вами сделаю». И если руководителю проекта не хватит смелости ответить: «Чудес не бывает, 9 женщин за месяц не рожают 1 ребенка», —то потом он транслирует эти «ценные указания» и «осуществимые сроки» на исполнителей. Все понимают, что план невыполним, но идут создавать видимость работы, чтобы не было формального повода к ним придраться – при этом на показуху тратится драгоценное время, которое можно было использовать для дела.

Что можно сделать с этим?


Комплекс мероприятий для решения проблемы №2:


  • Идти от простого к сложному: согласовали осуществимый план работ, выполнили, перешли к плану посерьезнее. С каждым шагом будет понятно, какой объем работ реально выполнить с текущими ресурсами, это позволит планировать точнее. К тому же только так можно оценить реальные масштабы проблемы, что позволит принимать осмысленные управленческие решения, а не прятать голову в песок.
  • Умение упрощать. Очень важно уметь при необходимости на время отказаться от каких-то требований, чтобы выполнить задачу в целом: часто сделать на троечку лучше, чем не сделать совсем.

К тому же, речь не идет о том, чтобы сделать на троечку и успокоиться. Обычно все происходит так: сделали на троечку, потихоньку через некоторое время вышли на четверочку, а потом года через 3-4, когда система стала уже родной, либо выходят на твердую пятерку, либо понимают, что четверка – уже оптимальный по соотношению затрачиваемых усилий и получаемому результату вариант.


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

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


Кейс 2. Умение упрощать


Проблема: Один из наших заказчиков. Запуск ERP-системы тормозился из-за того, что заказчик считал, что для нормальной работы системы требуется формирование в полном объеме пооперационных маршрутов. Технологи заявили, что для создания необходимых операционных маршрутов им потребуется 5 лет работы.


Как была решена проблема: заказчик признал, что с таким подходом он никогда не запустится. После этого за основу автоматизации взяли данные из расцеховок и реализовали учет межцеховых передвижений деталей и сборочных единиц. Этого хватило для полноценного планирования и учета. Теперь постепенно идет переход от расцеховок к пооперационным маршрутам при уже работающей ERP-системе.


Кейс 3. Концентрироваться на важном


Проблема: Тоже один из наших заказчиков. Большой объем нормативно-справочной информации, который переносится из старой самописной системы, заказчик понимает, что там множество ошибок. Основная масса вопросов касалась корректности маршрутов. По-хорошему, надо все проверить и откорректировать, но это огромный объем информации, а технологи и конструкторы и так уже загружены. К тому же возник вопрос: а как проверить, что все откорректировано правильно, если в системе никто не работает?


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


  • сконцентрировать свое внимание только на производимой сейчас продукции;
  • сделать работы по исправлению маршрутов в системе приоритетными.



Проблема №3. У исполнителей нет понимания того, что от их работы зависит деятельность остальных подразделений


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


Но часто исполнители не понимают, как результаты их работы будут влиять на остальных. Примеры:


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

Здесь могут быть возражения из серии: «А почему конструктор или технолог должны думать о том, что есть на рынке? Для этого же есть снабжение». Я считаю, что это было бы справедливо, если бы руководство изначально конструкторам и технологам сказало: «Вы творцы, поэтому творите, не ограничивайте себя в выборе красок для своих прекрасных картин», — а отделу снабжения внушило: «Все, что попросят эти ребята, должно быть привезено в срок. Не жалейте денег, везите хоть с Северного полюса, но творчество не должно останавливаться». К сожалению, даже озвучив первую часть, про вторую забывают – снабжение всегда должно закупаться максимально дешево и не превышая бюджет.


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

Причины этой проблемы:


  • Исполнители не знают весь процесс целиком, не осознают взаимосвязей между отделами.
  • Исполнители понимают, как устроен процесс, но настолько загружены, что не могут себе позволить такой роскоши, как думать об остальных.
  • Процесс требует усовершенствования: например, сотрудник может оказаться «лишним звеном» в цепочке – информацию берет у одного подразделения, вводит в систему, а потом её использует другое подразделение. Сложно ожидать, что человек в таких условиях будет как-то проверять информацию и заботиться о её корректности.

При отсутствии автоматизации либо локальной автоматизации в рамках одного отдела, проблем с взаимодействием подразделений вроде как не возникает, они незаметны. А ERP – это интегрированный продукт, который не позволит игнорировать нестыковки и несовершенства процесса.


Комплекс мероприятий для решения проблемы №3:


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

Здесь принципиально не добавлен пункт об уменьшении нагрузки на исполнителей, чтобы у них было время думать о том, как их работа влияет на остальные отделы. Пока сотрудник верит, что большой объем работ – оправдание для некачественной работы и саботирования деятельности своих коллег, он будет загружен исправлением своих же косяков.


Кейс 4. Английский завод


Завод английский, поэтому разделов «Проблема» и «Как была решена проблема» в этом кейсе нет, он попал в эту статью скорее в качестве примера.


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


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


Проблема №4. «Почему вы нам про это не сказали?»


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


Но этого недостаточно. На многих проектах при запуске в опытную эксплуатацию возникали вопросы:


  • «Почему вы нам про это не рассказали раньше?»
  • «Почему этот режим работы не описан в инструкции?»

Причины этой проблемы:


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

Комплекс мероприятий для решения проблемы №4:


  • Принятие. Надо просто принять эту особенность и разбираться с проблемами по мере их возникновения.

Кейс 5. «Я поняла вашу хитрость»


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


«Я поняла вашу хитрость. Вы выдавали нам информацию дозированно, чтобы мы не испугались. Если бы мы с самого начала представляли весь объем работ, то отказались бы от проекта. А так – не поднимая головы, постоянно решая возникающие проблемы, проскочили и получили работающую систему».


Проблема №5. «Два пишем, три в уме»


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


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


  • Согласно технологии, деталь обрабатывается в цехе номер 1, но все знают, что указанный станок давно переместили в цех номер 21 и везут партию туда. Менять технологию времени нет, да и зачем, если все и так всё знают?

«А теперь придумайте, как это отразить в ERP-системе, чтобы и новый маршрут не создавать, и правки в текущий не вносить, и чтобы все правильно учлось! Не можете? Значит ваша система не понимает наши особенности и не подходит нам!»


  • Детали, которые идут в готовые изделия, красятся уже в составе изделия после сборки, а если деталь идет в качестве запчасти на продажу, то она окрашивается отдельно. «А почему в ваших документах нигде не указан расход краски и соответствующие операции?» — «Не знаю. Все же и так в курсе, что запчасти на продажу красятся».

Причины этого:


  • Лень исполнителей.
  • Отсутствие трудовой дисциплины.

Комплекс мероприятий для решения проблемы №5:


  • Бороться с этим. Беспощадно. Люто. Везде. Всегда.

Кейсов на эту проблему у нас нет, потому что мы с этим боремся. Беспощадно. Люто. Везде. Всегда.


Проблема №6. «Мы очень-очень особенные и уникальные»


При проработке функциональных дизайнов делается глубокий анализ и унификация бизнес-процессов. Как правило, на этом этапе сотрудники заказчика помнят об установке руководства: «Надо внедрить максимально стандартный функционал, меньше доработок – дешевле внедрение».


А потом начинается опытная эксплуатация и отдельные сотрудники заказчика начинают «медленно варить лягушку»:


  • «У нас даже в старой самописной системе был этот функционал, неужели такая дорогая ERP не может мелочи? Доработайте!»
  • «Это же явная ошибка, не может планирование так работать. Да, вы нам показывали, как это будет работать, да, мы согласовали дизайн. Наверное, мы были не в себе. Давайте переделаем планирование так, чтобы оно работало вот как этот экселевский файл, проверенный годами и Алевтиной Светозаровной, умнейшей женщиной, 60 лет на заводе».

Причины этой проблемы:


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

Комплекс мероприятий для решения проблемы №6:


  • Унификация навсегда. Сохранить установку на максимальную унификацию работы различных подразделений на всё время проекта, а не только на начальных стадиях.
  • Минимум модификаций системы. Рассматривать доработки как крайнюю меру, к которой можно прибегать в самом конце.
  • Не брать в качестве KPI утилизацию программистов. Если у заказчика есть свой штат разработчиков, очень важно удержаться от соблазна загрузить программистов на 100%, чтобы они не простаивали.
  • Суровый архитектор, желательно бородатый. Если у клиента есть штат программистов, то в идеале следует нанять отдельного высококвалифицированного специалиста, который бы выполнял функцию архитектора системы. Этот сотрудник должен проверять все доработки на соответствие идеологии системы, давать свои рекомендации и не пускать в работу то, что не укладывается в архитектуру существующего решения.

Кейс 6. «Программистский беспредел»


К нам пришел клиент со своей проблемой: им внедрили систему несколько лет назад, после этого свой отдел разработки (3-4 программиста) работал день и ночь, чтобы закрыть все «хотелки» пользователей. За это время они «убили» систему – в ней было невозможно работать, потому что все тормозило. Клиенту пришлось заново внедрять систему и внедрение столкнулось с серьезной трудностью – избалованными пользователями, привыкшими, что все их пожелания выполняются. И здесь проблема даже не в программистах (они-то ни в чем не виноваты, что им говорили, то и делали), а в отсутствии того самого архитектора.


Перечисленные советы могут вам показаться простыми и очевидными, но от этого они не перестают быть действенными и эффективными. Да и следуют им немногие. Это как со здоровьем – все знают, что для того, чтобы оставаться здоровым до старости, надо следовать простым рекомендациям: контролировать своё питание, заниматься спортом, следить за языком и мыслями, не изменять супруге/супругу, избегать темных переулков и отморозков. Но счастливых и здоровых людей не так уж много.


На этом все. Внедряйте ERP, решайте возникающие проблемы, будьте добрее. И боритесь с ленью и отсутствием производственной дисциплины. Беспощадно. Люто. Везде. Всегда…

Комментарии (12)


  1. Nikita001
    12.03.2019 15:16

    им внедрили систему несколько лет назад, после этого свой отдел разработки (3-4 программиста) работал день и ночь, чтобы закрыть все «хотелки» пользователей. За это время они «убили» систему – в ней было невозможно работать, потому что все тормозило. Клиенту пришлось заново внедрять систему


    Узнаю брата Колю — 1С франчайзинг.
    Но вот вердикт «убили систему — все тормозило — пришлось заново внедрять» отдает дилетантством.


    1. Koyashkai Автор
      12.03.2019 15:36

      Но вот вердикт «убили систему — все тормозило — пришлось заново внедрять» отдает дилетантством.

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


      1. Nikita001
        12.03.2019 15:56

        есть и организационные, и политические моменты.

        Перевнедрение — это адское количество организационных моментов, в угоду одному политическому моменту.
        важен не факт перевнедрения (такая радикальная мера — скорее исключение)

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

        В заметке сказано, что они _решали_ проблемы бизнеса слишком рьяно, допустим, без приоритезации и без оценки затрат на поддержку.
        Но очевидно, что анализ проблемы, которую они создали, вообще не проводился даже по apdex. «Убили систему — все тормозит» — это не серьезно, не бывает так чтоб тормозило прям все.
        Это оценка продажника при первом контакте, но не эксперта по внедрению ERP.


        1. Koyashkai Автор
          12.03.2019 16:45

          Анализ проблемы проводился, просто заметка была не об этом) В рамках примера я посчитал достаточной формулировку «все тормозит»)

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

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


    1. Sjam
      12.03.2019 21:59

      увы, такое не редкость при удовлетворении всех хотелок


  1. eagleivg
    12.03.2019 16:13

    Все эти истории про внедрение ERP каждый раз напоминают мне бородатый анекдот:

    Изобретен аппарат автоматического бритья:
    — Бросаешь рубль, суешь голову в прорезь
    и он тебя автоматически бреет.
    — Но ведь у всех разные лица!?!?
    — В первый раз да…

    Серьезно, у подавляющего большинства внедренцев установка — ваши бизнес процессы слишком сложны для нашей системы? Надо упростить их! Формализовать! (далее следуют голословные утверждения о пользе бизнесу) Вот только проблема в том, что сложность процессов зачастую возникает не на пустом месте…


    1. Koyashkai Автор
      12.03.2019 17:10

      Как я уже писал, современные ERP-системы имеют избыточный функционал, — чаще возникает вопрос, каким из нескольких способов лучше реализовать то, что хочет заказчик. И большинство сложных процессов можно реализовать в системе путем настроек.

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


  1. Grigorenkovic
    12.03.2019 18:01

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


  1. Safronov
    12.03.2019 22:47

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


    1. Koyashkai Автор
      13.03.2019 07:57

      В этом мы не отличаемся — уверен, при внедрении любой ERP-системы проводят этап концептуального планирования сильно раньше начала опытной эксплуатации. Как я и писал к началу опытной все модификации реализованы, все прекрасно понимают, где изменена система, а где бизнес-процессы будут работать по-другому, есть написанные дизайны или СТП, инструкции, правила кодирования и т.д.:

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

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


  1. os9
    13.03.2019 09:47

    Неприятие идеологии системы исполнителями: «Ваша система не заработает. У нас есть Алевтина Светозаровна – умнейшая женщина, 60 лет на заводе, все в голове держит, никакая система не учтет всего, что она помнит».

    Как показывает практика, с умнейшими действительно полезно найти общий язык.
    А у вас красной нитью — «мы пришли причинить вам счастье»
    Беспощадно. Люто. Везде. Всегда…


    1. Koyashkai Автор
      13.03.2019 09:55

      Так к Алевтине Светозаровне претензий нет)) Претензии к тем, кто её использует в качестве символа. С умнейшими действительно стоит договариваться — без них никак.
      А «беспощадно, люто, везде и всегда» — это только против лени и отсутствия дисциплины.