Comments 32
Пожалуй обращает внимание отсутствие в списке главной причины — зачем предприятию ЕРП кроме самого ЕРП.
Этому пункту, по моему мнению, в списке делать нечего. Поскольку решение о том, что СУПР этой конкретной фирме нужна, уже принято (как правило, на уровне руководства).
В том или ином виде, СУПР присутствует в каждой фирме — даже если это набор таблиц или записная книжка. Вопрос, как управлять предприятием, есть везде. Какая за этим стоит система (SAP или мой личный ежедневник) — личное дело каждого.
В том или ином виде, СУПР присутствует в каждой фирме — даже если это набор таблиц или записная книжка. Вопрос, как управлять предприятием, есть везде. Какая за этим стоит система (SAP или мой личный ежедневник) — личное дело каждого.
Практически все причины удачи или неудачи внедрений систем типа ERP/MRP и подобных обычно связаны с одной, но огромной группой событий. Это события реального мира (не детерминированная среда) и программного обеспечения (детерминированная среда).
Все чудеса возникают обычно на стыке моделей. Там где неопределенность нужно преобразовывать в определенность и наоборот. Причем еще везде работает «человеческий фактор», а значит надо 90% внимания (и времени) тратить на психологические аспекты внедрения. Специалисты внедрения часто забывают, что людям не свойственно рациональное и разумное поведение. Причем это справедливо и для самих специалистов, даже очень высокого уровня. В том числе для тех, кто профессионально занимается психологией.
То есть даже психологи не принимают во внимание психологические аспекты внедрения.
Очень хорошо эти проблемы (кстати и методы решения тоже) описаны у Даниэла Канемана в книге «Думай медленно… решай быстро».
Люди в большинстве своем стараются не мыслить, а делать выводы (и работать) интуитивно. В простых и привычных системах это прокатывает.
Но как только появляется что-то новое, то все, ошибок интуиции становится слишком много.
Сотни исследований, на многих тысячах людей показывают, что все очень плохо в аспекте мышления. А без мышления (системы 2 по Канеману) — никакие новые методы работы (те же бизнес-процессы в ERP) внедрить не получится. Причем чем больше фирма или проект — тем хуже ситуация с мышлением каждого участника. Особенно все фигово в государственных и крупных корпоративных структурах.
Плюс к когнитивным искажениям в таком проекте накладывается специфика восприятия «потерь и пользы» у разных людей. Оказывается, важно не только какие «плюшки» получат от внедрения ERP участники, но и что они теряют. Причем важен не только размер потерь и приобретений, но и их последовательность.
Человек крайне негативно относится к потере, даже малой. И средне позитивно оценивает плюсы и приобретения, даже очень важные.
Но если плюсов будет много (мелких) и постоянно во времени — то минусы не волнуют, даже очень серьезные. А наоборот — не работает.
Плюс реальным людям свойственно произвольно менять свое отношение к фичам системы.
И даже действовать даже себе во вред, а не на пользу. А уж «польза фирме» — вообще малопонятная абстракция.
Все эти чудеса психологии известны очень давно (от 30 до 50 лет). Но специалисты не спешат их учитывать и применять при создании сложных искусственных систем с участием человека и объектов реального мира.
У Канемана описаны методы работы с чудесами восприятия людей, как на практике применять эти знания в разных отраслях. Мой личный опыт показывает, что если пользоваться методами психологии — то проекты по внедрению софта идут намного лучше.
И еще прикол: наказание человека за результат работы ниже среднего не приносит пользы. Но и вознаграждение за лучший результат тоже практически не влияет на его работу! Это справедливо для больших групп людей занятых практической работой по сложным моделям (ERP, учет, инженерная работа, проекты в корпорации).
В общем, крайне рекомендую почитать книгу Канемана, тогда многие проекты в IT станет проще делать.
Все чудеса возникают обычно на стыке моделей. Там где неопределенность нужно преобразовывать в определенность и наоборот. Причем еще везде работает «человеческий фактор», а значит надо 90% внимания (и времени) тратить на психологические аспекты внедрения. Специалисты внедрения часто забывают, что людям не свойственно рациональное и разумное поведение. Причем это справедливо и для самих специалистов, даже очень высокого уровня. В том числе для тех, кто профессионально занимается психологией.
То есть даже психологи не принимают во внимание психологические аспекты внедрения.
Очень хорошо эти проблемы (кстати и методы решения тоже) описаны у Даниэла Канемана в книге «Думай медленно… решай быстро».
Люди в большинстве своем стараются не мыслить, а делать выводы (и работать) интуитивно. В простых и привычных системах это прокатывает.
Но как только появляется что-то новое, то все, ошибок интуиции становится слишком много.
Сотни исследований, на многих тысячах людей показывают, что все очень плохо в аспекте мышления. А без мышления (системы 2 по Канеману) — никакие новые методы работы (те же бизнес-процессы в ERP) внедрить не получится. Причем чем больше фирма или проект — тем хуже ситуация с мышлением каждого участника. Особенно все фигово в государственных и крупных корпоративных структурах.
Плюс к когнитивным искажениям в таком проекте накладывается специфика восприятия «потерь и пользы» у разных людей. Оказывается, важно не только какие «плюшки» получат от внедрения ERP участники, но и что они теряют. Причем важен не только размер потерь и приобретений, но и их последовательность.
Человек крайне негативно относится к потере, даже малой. И средне позитивно оценивает плюсы и приобретения, даже очень важные.
Но если плюсов будет много (мелких) и постоянно во времени — то минусы не волнуют, даже очень серьезные. А наоборот — не работает.
Плюс реальным людям свойственно произвольно менять свое отношение к фичам системы.
И даже действовать даже себе во вред, а не на пользу. А уж «польза фирме» — вообще малопонятная абстракция.
Все эти чудеса психологии известны очень давно (от 30 до 50 лет). Но специалисты не спешат их учитывать и применять при создании сложных искусственных систем с участием человека и объектов реального мира.
У Канемана описаны методы работы с чудесами восприятия людей, как на практике применять эти знания в разных отраслях. Мой личный опыт показывает, что если пользоваться методами психологии — то проекты по внедрению софта идут намного лучше.
И еще прикол: наказание человека за результат работы ниже среднего не приносит пользы. Но и вознаграждение за лучший результат тоже практически не влияет на его работу! Это справедливо для больших групп людей занятых практической работой по сложным моделям (ERP, учет, инженерная работа, проекты в корпорации).
В общем, крайне рекомендую почитать книгу Канемана, тогда многие проекты в IT станет проще делать.
Увы, такова реальность ХХ века. Пока мы не придумали искуственный интеллект, который даст нам возможность отключить свой собственный и дергадировать до уровня куска хлеба, придётся думать своей головой и справляться со всё более сложными системами автоматизации (дискуссию о том, кому это и зачем это надо, лучше вынести в отдельный топик %)
А автоматизация просто может делать набор вещей, которые ей объяслини заранее (это к вопросу о детерминированной среде). В контексте СУПР есть два варианта: (1) могу только то, чему научили (если шаг влево или право — всё плохо) или (2) юзер может (если знает, что он делает!) выполнить и другие операции в ручном режиме. 95% СУПР относятся к первой группе. Группа 2 хотя бы позволяет регламентированным способом разрулить разные косяки, возникающие в процессе работы.
Кроме того, не надо забывать, что СУПР «просто» жонглирует цифрами. Гораздо веселее рассуждать о детерминизме на примере автоматизации производства. Если сотрудник переводит систему в ручной режим, вносит свою долю анти-детерминизма (например, переставляет палеты в автоматическом складе) и потом опять включает автоматический режим — те же проблемы!
А автоматизация просто может делать набор вещей, которые ей объяслини заранее (это к вопросу о детерминированной среде). В контексте СУПР есть два варианта: (1) могу только то, чему научили (если шаг влево или право — всё плохо) или (2) юзер может (если знает, что он делает!) выполнить и другие операции в ручном режиме. 95% СУПР относятся к первой группе. Группа 2 хотя бы позволяет регламентированным способом разрулить разные косяки, возникающие в процессе работы.
Кроме того, не надо забывать, что СУПР «просто» жонглирует цифрами. Гораздо веселее рассуждать о детерминизме на примере автоматизации производства. Если сотрудник переводит систему в ручной режим, вносит свою долю анти-детерминизма (например, переставляет палеты в автоматическом складе) и потом опять включает автоматический режим — те же проблемы!
Я как-то рулил внедрением САП в одной большой организации. Крайне нервное занятие.
Основная проблема — сопротивление на местах. Потому что внедрение ERP неминуемо ведет к формализации и попытке осмысления существующих бизнес процессов. А там — полный завал. Десятилетиями люди делают ненужную, зачастую, мешающую процессу работу. Целые группы занимаются никому не нужной бюрократией, которую легко заменить на автоматизацию. При этом получают зарплаты, имеют власть в компании через контроль над этими процессами.
Понятно, они не хотят потерять что имеют.
У нас ушло 2 ПМа из-за нервных срывов. Но в итоге мы его внедрили :-).
Мой опыт говорит о том, что критически необходимо получить карт бланш от самого высокого руководства на изучение/исправление/оптимизацию существующих бизнес процессов. Это пре-рек для начала внедрения новой ERP. Идея о том, что все останется как раньше, только у вас появится САП не работает. Можно потратить сколько угодно денег на кастомизацию САП, но если сами процессы кривые, все это не взлетит сколько не бейся.
Основная проблема — сопротивление на местах. Потому что внедрение ERP неминуемо ведет к формализации и попытке осмысления существующих бизнес процессов. А там — полный завал. Десятилетиями люди делают ненужную, зачастую, мешающую процессу работу. Целые группы занимаются никому не нужной бюрократией, которую легко заменить на автоматизацию. При этом получают зарплаты, имеют власть в компании через контроль над этими процессами.
Понятно, они не хотят потерять что имеют.
У нас ушло 2 ПМа из-за нервных срывов. Но в итоге мы его внедрили :-).
Мой опыт говорит о том, что критически необходимо получить карт бланш от самого высокого руководства на изучение/исправление/оптимизацию существующих бизнес процессов. Это пре-рек для начала внедрения новой ERP. Идея о том, что все останется как раньше, только у вас появится САП не работает. Можно потратить сколько угодно денег на кастомизацию САП, но если сами процессы кривые, все это не взлетит сколько не бейся.
В указанных фейлах его тоже внедрили. Только ненадолго.
Наше внедрение уже несколько лет успешно работает.
Единственное, ряд модулей SAP тогда было решено заменить на сторонние/кастомные решения по причине дороговизны. В результате, все равно пришлось потом заменять на «родные» от SAP. Менеджеры хотели сэкономить — получили даже большие затраты. Я сразу понял политику SAP в области интеграции со сторонними приложениями и рекомендовал заплатить. Но менеджменту было виднее…
Единственное, ряд модулей SAP тогда было решено заменить на сторонние/кастомные решения по причине дороговизны. В результате, все равно пришлось потом заменять на «родные» от SAP. Менеджеры хотели сэкономить — получили даже большие затраты. Я сразу понял политику SAP в области интеграции со сторонними приложениями и рекомендовал заплатить. Но менеджменту было виднее…
А что дальше случилось с фейлами? От всего отказались и вернулись к «бумажкам»? И это после огромных затрат на лицензии, разработку и т.п.? Не дешевле было довести проект до конца?
Тут у каждого своя судьба…
Как правило, если запуск по принципу «большого взрыва» — то сценария отката просто не существует. Если фирма небольшая, можно еще кое-как спастись. Если побольше — сцепи зубы и греби (так было на нашей фирме 12 лет назад. Через пару месяцев ночных смен, SQL и прочего безумия кое-как стабилизировали. Через 6 лет работала как игрушка!)
А так, по слухам:
Liqui Moly раньше работал на СУПР собственного сочинения, написанной еще на Cobol. Такие экзоты в Германии еще встречаются — «работает — не трогай». Плюсы и минусы обсуждать здесь не буду. Предполагаю, что АХ заработала таки через какое-то время.
LIDL поставил жирный крест на SAP и списал 500 миллионов евро. Интрига в том, что у LIDL и так SAP, просто «старый и с костылями». Хотели радикально переделать.
Об остальных проектах не слышал.
Как правило, если запуск по принципу «большого взрыва» — то сценария отката просто не существует. Если фирма небольшая, можно еще кое-как спастись. Если побольше — сцепи зубы и греби (так было на нашей фирме 12 лет назад. Через пару месяцев ночных смен, SQL и прочего безумия кое-как стабилизировали. Через 6 лет работала как игрушка!)
А так, по слухам:
Liqui Moly раньше работал на СУПР собственного сочинения, написанной еще на Cobol. Такие экзоты в Германии еще встречаются — «работает — не трогай». Плюсы и минусы обсуждать здесь не буду. Предполагаю, что АХ заработала таки через какое-то время.
LIDL поставил жирный крест на SAP и списал 500 миллионов евро. Интрига в том, что у LIDL и так SAP, просто «старый и с костылями». Хотели радикально переделать.
Об остальных проектах не слышал.
Если верить исследованию Reuters от 2017 года, то в штатах 220 миллиардов строк на Коболе обслуживают 43% банковских систем, 80% персональных транзакций и 95% снятий в банкоматах. Все достаточно плохо, чтобы тут начали вытаскивать релевантных делу шаманов с пенсии и взывать к духу контр-адмирала Грейс Хоппер. Если шарите в теме — приезжайте, судя по этой ситуации, на мраморную говядину (см. соседний топик) вам хватит.
Главная ошибка внедрений то, что заказчик хочет все легко и быстро и не хочет признавать обратного, а исполнитель спешит его в этом заверить, чтобы завоевать проект, и часто, сам недооценивает сложность таких проектов, хотя бы потому, что не имеет детального представления о бизнесе заказчика. Обе стороны, как правило, договариваются о том, о чем не имеют представления. Поэтому и большие взрывы, нервные срывы и так далее, со всеми остановками
Мастер-данные (Stammdaten) — термин Мастер-данные как-то не очень для понимания сути, Stammdaten — это исходные данные или основные, или базовые данные. В контексте внедрения проекта скорее всего это исходные данные.
Как я понимаю это дело, то провал главным образом происходит по причине, что на старые бизнес-процессы пытаются нахлобучить автоматизированную систему с совершенно другими бизнес-процессами. А оно не стыкуется. Видимо надо начинать с реинжиниринга существующих бизнес-процессов, возможно менять структуру компании. А уже потом это все автоматизировать и затачивать автоматизацию под обновленные бизнес-процессы компании. Тогда одно с другим состыкуется.
Как я понимаю это дело, то провал главным образом происходит по причине, что на старые бизнес-процессы пытаются нахлобучить автоматизированную систему с совершенно другими бизнес-процессами. А оно не стыкуется. Видимо надо начинать с реинжиниринга существующих бизнес-процессов, возможно менять структуру компании. А уже потом это все автоматизировать и затачивать автоматизацию под обновленные бизнес-процессы компании. Тогда одно с другим состыкуется.
Я с этим термином мучаюсь уже давно :) Гугл говорит «основные данные», мне это как-то режет слух. Сейчас вот еще порылся в интернете, нашел «основные записи»…
У меня есть старый мультиязычный бумажный словарь по программированию — английский, немецкий, русский, французский — в нем master data = Stammdaten = основные данные. Аналогично электронный Abbyy Lingvo выдает англо-русский: master data = основные данные, и немецко-русский Stammdaten = основные данные.
Старые бизнес процессы часто описываются фразой "всё работает или потихоньку, или как-то так".
Я так понял, речь идет об НСИ
Мастер-данные вполне устоявшийся термин. Но правильнее перевести как основные данные. Термин НСИ, более привычный постсоветскому пространству, более узкий.
Но проблема тут в самой статье. Упущено очень важное — управлять нужно ВСЕМИ данными, а не только master data. Что, транзакционные данные — не проблема? Или нарушение реляционной целостности?
Следовательно, по смыслу правильнее было бы «Подготовка данных»
Но даже если данные подготовлены и вылизаны, есть не менее важная причина провала проекта — миграция данных. Это отдельный business critical процесс, на который завязана непрерывность бизнеса. Про это в статье не сказано вообще ничего.
Но проблема тут в самой статье. Упущено очень важное — управлять нужно ВСЕМИ данными, а не только master data. Что, транзакционные данные — не проблема? Или нарушение реляционной целостности?
Следовательно, по смыслу правильнее было бы «Подготовка данных»
Но даже если данные подготовлены и вылизаны, есть не менее важная причина провала проекта — миграция данных. Это отдельный business critical процесс, на который завязана непрерывность бизнеса. Про это в статье не сказано вообще ничего.
НСИ расшифровывается как?
Нормативно-справочная информация
по части терминологии, да и вообще, всего, что связано с данными, есть хорошая книжка:
www.olbuss.ru/catalog/dama-dmbok-svod-znaniy-po-upravleniyu-dannymi-vtoroe-izdanie
www.olbuss.ru/catalog/dama-dmbok-svod-znaniy-po-upravleniyu-dannymi-vtoroe-izdanie
Из практики: к внедрению ERP подталкивают косвенные причины, не связанные с самим производством, — это рост роли управленческого учета.
— Нужен детальный контроль над производством — внедряем мониторинговые сервисы по ключевым показателям.
— Нужно планирование продаж, производства, закупок и т.п. — подключаем к вышеупомянутым мониторинговым сервисам сервис планирования.
— Нужна автоматизация производственного учета — добавляем к связке {мониторинговые сервисы и сервис планирования} систему постановки задач в бизнес-процессах (каждая цепочка процессов детализирована и подготовлена к частичной замене человеческого присутствия).
PS: внедряя erp, готовьтесь начать свой бизнес с нуля ;-)
— Нужен детальный контроль над производством — внедряем мониторинговые сервисы по ключевым показателям.
— Нужно планирование продаж, производства, закупок и т.п. — подключаем к вышеупомянутым мониторинговым сервисам сервис планирования.
— Нужна автоматизация производственного учета — добавляем к связке {мониторинговые сервисы и сервис планирования} систему постановки задач в бизнес-процессах (каждая цепочка процессов детализирована и подготовлена к частичной замене человеческого присутствия).
PS: внедряя erp, готовьтесь начать свой бизнес с нуля ;-)
innovaIT, да, руководству нет дела до процессов внедрения erp в плане настроек, «заточки» под звено. Их интересует быстрый эффект — «это же бизнес, здесь нет места экспериментам».
Из практики: есть задача перейти на систему планирования более высокого уровня. Прикол, а вместе с тем и печаль, в том, что в маркетинге систем планирования не заложены этапы внедрения. Руководство «ведётся» на готовых презентациях, обещаниях. Итог — приходится «пилить и еще раз пилить» новую систему под текущие устои, так как останавливать бизнес нельзя! Так «велосипеды» в новых этих системах и рождаются, приводя всю «движуху инноваций» к деградации и хаосу, в следствии чего одни не успевают освоить систему и возвращаются к работе в эксель, другие к бумажным записям в журнале.
Может тут причина не в erp системах, а в человеческом факторе — над этим, конечно, можно спорить долго… С вами согласен насчет этого.
Из практики: есть задача перейти на систему планирования более высокого уровня. Прикол, а вместе с тем и печаль, в том, что в маркетинге систем планирования не заложены этапы внедрения. Руководство «ведётся» на готовых презентациях, обещаниях. Итог — приходится «пилить и еще раз пилить» новую систему под текущие устои, так как останавливать бизнес нельзя! Так «велосипеды» в новых этих системах и рождаются, приводя всю «движуху инноваций» к деградации и хаосу, в следствии чего одни не успевают освоить систему и возвращаются к работе в эксель, другие к бумажным записям в журнале.
Может тут причина не в erp системах, а в человеческом факторе — над этим, конечно, можно спорить долго… С вами согласен насчет этого.
И снова про ERP-системы – динозавров из IT Jurassic Park.
«Никогда такого не было и вот опять».
Снова про провальные ERP-проекты. Иллюстрация того, что история ничему не учит и наступать на грабли, на которые до тебя уже устали наступать другие, это любимое занятие заказчиков ERP-проектов. Опять крупнейшие немецкие заказчики и опять немецкая же ERP от SAP, ну и от Microsoft, конечно, куда ж без нее. Видимо, эта проблема еще долго будет существовать – столько же, сколько и ERP-системы – динозавры из IT Jurassic Park (©).
Сразу резюме. Статья бесполезная и даже вредная. Опять как минимум часть вины за провалы перекладывается на заказчиков. Которые виноваты лишь в том, что 1) заплатили миллионы за проект и 2) доверились подрядчикам, не имея собственных экспертов по таким проектам.
Тут все очевидно. Перекладывать вину на потерпевшего, добропорядочного покупателя, честно заплатившего деньги, как минимум неэтично и несправедливо. Заказчик нанимает подрядчика на внедрение готовой (!) ИТ-системы, на которую он приобретает лицензии, именно потому, что не имеет собственной экспертизы по настройке таких систем. Да, это совместный проект заказчика и подрядчика, настройка ERP-системы является непростым делом и для этой цели привлекают стороннего подрядчика. Который должен полностью отвечать за конечный результат — это и есть его работа. Проект совместный, а ответственность на подрядчике. Вот главный принцип. Заказчик платит деньги и участвует в проекте по мере своих возможностей. Не более того.
Все 10 рекомендаций, перечисленных в статье, весьма невнятные, размывают ответственность за проект и никак не помогут спасти такие проекты. Простые и понятные советы как надо делать ERP-проекты, чтобы не допустить провала, я давно еще изложил в своих старых статьях.
В частности, тут.
«Итак, Элвис все-таки умер или Добро пожаловать в клуб миллиардеров-неудачников! Только для вас специальная цена входного билета 500 миллионов евро...»
«Target epic fail в Канаде: как профукать $7 миллиардов из-за проекта ERP и как предотвращать такие провалы / Target's epic fail in Canada...»
www.facebook.com/V.Senkevich/posts/713062439033767
Если коротко, главный принцип таких проектов, о котором уже выше сказал — ответственность подрядчика за проект в целом, а не только за его промежуточные этапы. А главный рецепт успеха — «Не платите за бумагу!». ERP-проект это не создание системы с нуля, а настройка готового ПО, на которое приобретаются лицензии. Любой документ (ТЗ и пр.) должен сдаваться только вместе с работающим прототипом ПО. В XX веке бумажные подходы еще имели право на существование, в XXI веке средств прототипирования достаточно, чтобы продемонстрировать будущий функционал. Не говоря уже о том, что, в случае настройки готовой системы (а проект ERP именно такой) прототип надо делать на ней самой. Неспособность команды внедрения это сделать уже выглядит подозрительно — то ли команда слабовата, то ли сама система не является достаточно гибкой, чтобы удовлетворить запросы заказчика (и чем раньше этот факт выяснится, тем лучше для заказчика). В таких случаях принцип оплаты за конечный результат является единственной гарантией если и не спасти проект, то хотя бы минимизировать убытки.
«Никогда такого не было и вот опять».
Снова про провальные ERP-проекты. Иллюстрация того, что история ничему не учит и наступать на грабли, на которые до тебя уже устали наступать другие, это любимое занятие заказчиков ERP-проектов. Опять крупнейшие немецкие заказчики и опять немецкая же ERP от SAP, ну и от Microsoft, конечно, куда ж без нее. Видимо, эта проблема еще долго будет существовать – столько же, сколько и ERP-системы – динозавры из IT Jurassic Park (©).
Сразу резюме. Статья бесполезная и даже вредная. Опять как минимум часть вины за провалы перекладывается на заказчиков. Которые виноваты лишь в том, что 1) заплатили миллионы за проект и 2) доверились подрядчикам, не имея собственных экспертов по таким проектам.
Тут все очевидно. Перекладывать вину на потерпевшего, добропорядочного покупателя, честно заплатившего деньги, как минимум неэтично и несправедливо. Заказчик нанимает подрядчика на внедрение готовой (!) ИТ-системы, на которую он приобретает лицензии, именно потому, что не имеет собственной экспертизы по настройке таких систем. Да, это совместный проект заказчика и подрядчика, настройка ERP-системы является непростым делом и для этой цели привлекают стороннего подрядчика. Который должен полностью отвечать за конечный результат — это и есть его работа. Проект совместный, а ответственность на подрядчике. Вот главный принцип. Заказчик платит деньги и участвует в проекте по мере своих возможностей. Не более того.
Все 10 рекомендаций, перечисленных в статье, весьма невнятные, размывают ответственность за проект и никак не помогут спасти такие проекты. Простые и понятные советы как надо делать ERP-проекты, чтобы не допустить провала, я давно еще изложил в своих старых статьях.
В частности, тут.
«Итак, Элвис все-таки умер или Добро пожаловать в клуб миллиардеров-неудачников! Только для вас специальная цена входного билета 500 миллионов евро...»
«Target epic fail в Канаде: как профукать $7 миллиардов из-за проекта ERP и как предотвращать такие провалы / Target's epic fail in Canada...»
www.facebook.com/V.Senkevich/posts/713062439033767
Если коротко, главный принцип таких проектов, о котором уже выше сказал — ответственность подрядчика за проект в целом, а не только за его промежуточные этапы. А главный рецепт успеха — «Не платите за бумагу!». ERP-проект это не создание системы с нуля, а настройка готового ПО, на которое приобретаются лицензии. Любой документ (ТЗ и пр.) должен сдаваться только вместе с работающим прототипом ПО. В XX веке бумажные подходы еще имели право на существование, в XXI веке средств прототипирования достаточно, чтобы продемонстрировать будущий функционал. Не говоря уже о том, что, в случае настройки готовой системы (а проект ERP именно такой) прототип надо делать на ней самой. Неспособность команды внедрения это сделать уже выглядит подозрительно — то ли команда слабовата, то ли сама система не является достаточно гибкой, чтобы удовлетворить запросы заказчика (и чем раньше этот факт выяснится, тем лучше для заказчика). В таких случаях принцип оплаты за конечный результат является единственной гарантией если и не спасти проект, то хотя бы минимизировать убытки.
Сколько людей — столько мнений, убеждаюсь в очередной раз. «Итак, Элвис все-таки умер...» прочитал. Приятно слышать, что не перевелись еще на Руси люди, которые в разы умнее всяких «милиардеров-неудачников». Россия всегда была богата талантами.
На мой взгляд, утверждать, что LIDL «доверился подрядчикам, не имея собственных экспертов по таким проектам», как минимум, неумно.
Легко вести поклёп на всякие там «ERP-системы – динозавры из IT Jurassic Park». Какие альтернативы Вы можете предложить концернам типа LIDL или BMW?
На мой взгляд, утверждать, что LIDL «доверился подрядчикам, не имея собственных экспертов по таким проектам», как минимум, неумно.
Легко вести поклёп на всякие там «ERP-системы – динозавры из IT Jurassic Park». Какие альтернативы Вы можете предложить концернам типа LIDL или BMW?
>>Россия всегда была богата талантами
Да, это справедливо и с долей сарказма и вовсе без него, но в данном случае дело совсем не в этом. А в многолетнем практическом опыте проектов внедрения корпоративного софта
LIDL именно что «доверился подрядчикам», имея при этом собственных экспертов по старой версии SAP R/3. Подписывали тонны бумаги на оплачиваемые часы работы множества консультантов на миллионы евро, фактически не проверяя результатов (которых и не было). Чтобы убедиться, достаточно почитать про историю этого проекта. Потом уже стоит делать выводы, умно это или нет.
>>Какие альтернативы Вы можете предложить концернам типа LIDL или BMW?
Видимо, я плохо объясняю. Я не предлагаю альтернативы существующим ERP-системам. Хотя это интересный вопрос для обсуждения. Я предлагаю альтернативу традиционной затратной и рискованной технологии внедрения. Позволяющую контролировать результативность проекта на всех этапах внедрения системы. И позволяющую кардинально снизить риски провала проекта. По статистике (щадящей), менее 50% внедрений ERP являются успешными. По беспристрастной статистике, еще меньше. Подробности в статьях кому интересно. Уфф… надеюсь, прояснил.
Короткий анекдот в завершение. Я его в SAP рассказывал, он им близок. Кто знает, поймет. Две знакомых женщины в автобусе повстречались. «О, привет, ты где сейчас?»
«В ресторане Ханой работаю». «Кем-кем?!!»
Это я к тому, что в LIDL не получилось Ханой работать…
А LIDL неплохой магазин. Малость, правда, на склад похож, как многие дискаунтеры. Я в нем хороший недорогой шоколад покупаю (их марки) и алкоголь, там часто скидки. Когда рядом бываю…
Да, это справедливо и с долей сарказма и вовсе без него, но в данном случае дело совсем не в этом. А в многолетнем практическом опыте проектов внедрения корпоративного софта
LIDL именно что «доверился подрядчикам», имея при этом собственных экспертов по старой версии SAP R/3. Подписывали тонны бумаги на оплачиваемые часы работы множества консультантов на миллионы евро, фактически не проверяя результатов (которых и не было). Чтобы убедиться, достаточно почитать про историю этого проекта. Потом уже стоит делать выводы, умно это или нет.
>>Какие альтернативы Вы можете предложить концернам типа LIDL или BMW?
Видимо, я плохо объясняю. Я не предлагаю альтернативы существующим ERP-системам. Хотя это интересный вопрос для обсуждения. Я предлагаю альтернативу традиционной затратной и рискованной технологии внедрения. Позволяющую контролировать результативность проекта на всех этапах внедрения системы. И позволяющую кардинально снизить риски провала проекта. По статистике (щадящей), менее 50% внедрений ERP являются успешными. По беспристрастной статистике, еще меньше. Подробности в статьях кому интересно. Уфф… надеюсь, прояснил.
Короткий анекдот в завершение. Я его в SAP рассказывал, он им близок. Кто знает, поймет. Две знакомых женщины в автобусе повстречались. «О, привет, ты где сейчас?»
«В ресторане Ханой работаю». «Кем-кем?!!»
Это я к тому, что в LIDL не получилось Ханой работать…
А LIDL неплохой магазин. Малость, правда, на склад похож, как многие дискаунтеры. Я в нем хороший недорогой шоколад покупаю (их марки) и алкоголь, там часто скидки. Когда рядом бываю…
Подскажите, пожалуйста, где найти историю этого проекта. Я сейчас полчаса в интернете провёл — в основном цитируют официальную информацию и распостраняют вымыслы. Один из вариантов: LIDL хотел «прогнуть» SAP ERP под себя. Это никогда хорошо не кончается. (Источники: www.heise.de/newsticker/meldung/So-starb-Elwis-Hintergruende-zu-Lidls-SAP-Rueckzug-4113285.html и www.crn.de/software-services/7-jahre-1000-mitarbeiter-500-millionen-euro.117785.html)
У знакомого SAP-шника есть выражение на этот случай: «Империя наносит ответный удар».
У знакомого SAP-шника есть выражение на этот случай: «Империя наносит ответный удар».
Важен ещё следующий момент. Существует три принципиальных варианта натягивания ИС управления предприятием (максимально уйду от термина ERP, пусть будет «информационная система») на некоторое предприятие (ну как всегда — два крайних и промежуточный) с точки зрения бизнес-процессов. И «получилось/не получилось» во многом зависит от этого…
В первом случае внедряемая ИС является хранилищем best practices, то есть эталоном бизнес-процессов. Весь накопленный отраслевой опыт — там. Как правило, это устоявшиеся, стандартные отрасли (ну не знаю, нефтегаз там или традиционное с/х) либо жестко регламентированные направления деятельности (бухгалтерия, скажем). Таким образом, при внедрении бизнес-процессы предприятия изменяются под внедряемую ИС, поскольку (теоретически) в ней зафиксировано, «как правильно делать».
Во втором случае — бизнес-процессы предприятия сильно специфические, либо предприятие единственное в своём роде. То есть бизнес-процессы тоже устоявшиеся, но нигде больше, кроме этого предприятия, таких нет. То есть предприятие является образцом того, «как надо делать». Соответственно, «зашитые» в ИС бизнес-процессы меняются под предприятие.
Ну и третий вариант (точнее, многообразие вариантов) — это когда бизнес-процессы динамичны (в силу молодости отрасли, перехода предприятия с этапа на этап своего жизненного цикла, и т.п.), и при этом не существует «правильного» варианта их реализации. Тогда и допиливаем напильником ИС (как зашито), и перестраиваем функционирование процессов (как на самом деле происходит), т.е. приводим к некоторому общему знаменателю.
И вот в зависимости от того, какой вариант реализуется, очень по-разному должно быть организовано внедрение, разными будут и требования к процессу такого внедрения, и требуемый уровень поддержки, ресурсы, чувствительность к внешним изменениям и параллельным проектам, и т.п.
В первом случае внедряемая ИС является хранилищем best practices, то есть эталоном бизнес-процессов. Весь накопленный отраслевой опыт — там. Как правило, это устоявшиеся, стандартные отрасли (ну не знаю, нефтегаз там или традиционное с/х) либо жестко регламентированные направления деятельности (бухгалтерия, скажем). Таким образом, при внедрении бизнес-процессы предприятия изменяются под внедряемую ИС, поскольку (теоретически) в ней зафиксировано, «как правильно делать».
Во втором случае — бизнес-процессы предприятия сильно специфические, либо предприятие единственное в своём роде. То есть бизнес-процессы тоже устоявшиеся, но нигде больше, кроме этого предприятия, таких нет. То есть предприятие является образцом того, «как надо делать». Соответственно, «зашитые» в ИС бизнес-процессы меняются под предприятие.
Ну и третий вариант (точнее, многообразие вариантов) — это когда бизнес-процессы динамичны (в силу молодости отрасли, перехода предприятия с этапа на этап своего жизненного цикла, и т.п.), и при этом не существует «правильного» варианта их реализации. Тогда и допиливаем напильником ИС (как зашито), и перестраиваем функционирование процессов (как на самом деле происходит), т.е. приводим к некоторому общему знаменателю.
И вот в зависимости от того, какой вариант реализуется, очень по-разному должно быть организовано внедрение, разными будут и требования к процессу такого внедрения, и требуемый уровень поддержки, ресурсы, чувствительность к внешним изменениям и параллельным проектам, и т.п.
Главная причина всех таких провалов – устаревшая технология внедрения, позволяющая интеграторам безнаказанно закрывать бумажные этапы проекта без предъявления реальных результатов хотя бы на работающем прототипе. Все такие провалы выглядят одинаково – на бумажные этапы списывается основное время и деньги, потом выясняется, что в софте ничего из успешно сданного и оплаченного не работает. У меня были статьи на эту тему. В 21 веке бумажных этапов вообще не должно быть, вся документация (имеющая вспомогательное значение и совершенно не нужная заказчику, ну, кроме инструкций пользователя, а нужная лишь поставщику) должна сдаваться только вместе с работающим прототипом.
Sign up to leave a comment.
Провал ERP проекта (Liqui Moly, Отто и им подобным посвящается)