10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

20.12.23

Управление проектом - Кейсы проектов

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

 

Меня зовут Евгений Грибков, я – руководитель внедренческого центра «Раздолье».

Наша компания специализируется на внедрениях 1С:ERP и 1С:Управление холдингом – в основном на промышленных предприятиях.

Ежегодно наши проекты становятся победителями конкурса «1С:Проект года». По данным Справочника внедрённых решений фирмы «1С» у нас самое большое количество успешных внедрений 1С:ERP на крупных промышленных предприятиях.

 

 

Мы работаем с разными отраслями – машиностроение, пищевая отрасль, фармакологическая, добывающая промышленность и т.д.

Естественно, в ходе этих проектов мы набиваем много шишек, систематизируем их и по итогам выработали список типовых рисков.

О десяти таких рисках я и собираюсь рассказать в докладе. Надеюсь, это поможет вам избежать хотя бы одного из них – это будет уже ценно.

 

Риск №1. Нет бизнес-цели

 

 

Первый риск – это риск проектов, у которых нет бизнес-цели.

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

Если не проработан вопрос бизнес-целей для самого предприятия, на котором внедряется, например, ERP-система, такие проекты в подавляющей части в нашем опыте заканчиваются очень плохо:

  • в лучшем случае рождается система, которая постепенно деградирует до бухучета;

  • в худшем случае такой проект вообще не завершается успешно.

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

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

Здесь тоже нужно понимать, что если это абсолютно технологический переход, который не дает никакого профита для бизнеса, это будет либо не очень успешный проект (чаще всего). Либо этот проект будет очень дорогой, потому что, скорее всего, в новой системе придется повторить все то, что было в старой;

Если пользователи не понимают, что они приобретают при внедрении новой системы – они будут как минимум требовать повторения функциональности, интерфейсов и т.д. старой системы.

 

Риск №2. Заказчик не готов выделять время своих специалистов

 

 

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

Естественно, так не бывает. В любом проекте внедрения ERP-системы цели исполнителя и заказчика слегка отличаются.

  • цель исполнителя – выполнить проект, уложиться в бюджет, в сроки и в те границы, на которые договорились;

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

Так вот: за вторую часть исполнитель отвечать не может. Если время ключевых пользователей не будет выделено, скорее всего, вы получите систему в том виде, в котором ее представляет себе исполнитель. И вообще не факт, что вы добьетесь основной цели для бизнеса – не получите какого-то содержательного эффекта.

Как с этим риском можно управляться?

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

  • И руководителю проектов со стороны заказчика в обязательном порядке нужно это время запланировать. И не надо надеяться, что ключевые пользователи смогут сделать это между делом. Они обычно на то и ключевые, что сильно заняты, и между делом они просто проигнорируют проектные задачи.

 

Риск №3. Переход с сильно доработанного старого решения

 

 

Следующий риск, о котором хочу рассказать – это переход с сильно доработанного старого решения.

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

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

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

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

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

 

Риск №4. На этапе моделирования – излишние требования пользователей

 

 

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

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

Поэтому либо берите опытного исполнителя, который будет с этим бороться, либо боритесь с этим сами.

 

Риск №5. Изменение процессов в ходе проектирования системы

 

 

Пятый риск – изменение процессов в ходе проектирования системы.

Эта ситуация обычно выглядит так: запускается новый завод. Он строится, и в этот момент начинается проектирование будущей ERP-системы.

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

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

Если бюджет не ограничен, можно сделать два проекта.

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

 

Риск №6. Команда проекта не имеет компетенций в области внедрения

 

 

Следующий риск, о котором я хочу рассказать – это когда команда проекта не имеет компетенций в области внедрения. Например, они хорошо знают ERP, но никогда ранее в вашей отрасли не работали.

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

 

Риск №7. Нехватка времени на подготовку данных

 

 

Следующий риск, о котором скажу – это нехватка времени на подготовку данных. Этот риск в основном свойственен проектам, которые выполняются не очень опытными командами.

Проблема связана с тем, что иногда период подготовки данных для загрузки системы – это несколько месяцев. И когда исполнитель говорит, что система готова к запуску, в нее нужно грузить данные, а у вас еще ничего нет – вы получаете отсрочку в проекте. А это всегда печально.

Управление этим риском довольно простое – об этом просто надо не забывать и прорабатывать этот вопрос с самого начала проекта.

 

Риск №8. Саботаж пользователей при запуске

 

 

Следующий риск – саботаж пользователей при запуске проекта.

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

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

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

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

 

Риск №9. Люди не успевают вносить данные в 2 программы

 

 

Девятый риск – люди не успевают вносить данные в две системы.

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

В этом случае пользователи, естественно, не успевают вносить данные в обе системы.

Этот риск можно решить через:

  • вопрос мотивации – возможна дополнительная мотивация;

  • набор людей-операторов на момент параллельного ведения учета;

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

 

Риск №10. Ошибки при сравнении данных со старой программой

 

 

Следующий риск, о котором расскажу – это ошибки при сравнении данных со старой программой.

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

Наш опыт показывает, что получить такие же данные, как в старой системе, практически никогда не удается. Это связано:

  • с ошибками ввода данных;

  • с тем, что старая система работает неправильно – так происходит в огромном числе случаев, почти всегда;

  • к тому же в разных системах может быть разная логика ведения учета.

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

 

Вопросы и ответы

 

Если вернуться к первому риску, который звучит как «бизнес не является заказчиком» – как же быть в тех проектах, где действительно ИТ подталкивает бизнес? Например, если проект – переход с УПП на ERP. Понятно, что это риск, но что, ничего не делать?

Здесь есть три варианта.

  • Первый вариант (более правильный): все-таки совмещать переход с УПП на ERP с внедрением какой-то функциональности, которая принесет пользу бизнесу. И тогда бизнесу станет понятно, зачем им тратить на это время – в этом будет хоть какой-то смысл.

  • Либо нужна сильная политическая воля, чтобы ломать все претензии пользователей.

  • Либо большой бюджет на то, чтобы все кастомизировать и делать ERP похожей на УПП.

Все это усугубляется тем, что некоторые механизмы УПП и ERP организованы таким образом, что пользователям больше нравятся УПП-шные варианты. И очень сложно перевести их на ERP – нужно объяснять, почему они теряют некоторые удобства, которые у них были. Т.е. мы дополнительно сталкиваемся с риском противодействия.

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

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

Я с вами абсолютно согласен. Риски – это обязательный раздел для статус-совещаний, которые должны проводиться на большом нудном заводе раз в неделю пусть без первых заместителей, но хотя бы с руководством проекта.

На тех проектах, где участвует собственник, это можно делать реже, и основная задача здесь конечно же анализировать, что сработало. Чаще всего мы же указываем риски заказчика. Например, если нет сервера к старту проекта – все, проект остановился.

Указывать свои риски или нет – это зависит от уровня доверия между вами и заказчиком. Вопрос откровенности между исполнителем и заказчиком очень разный. Это примерно как вопрос: «Можно применять Agile на фикспрайсовых проектах или нельзя?» Если доверие есть, то можно. Если его нет, это будет очень странная игра с закрытым бюджетом в открытые границы.

Что для вас значит «провал проекта»? Увеличение сроков, увеличение бюджета – это провал?

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

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

Мы к этому относимся так: если заказчик систему использует, для нас это успешный проект. Да, он, естественно, может быть с разными показателями: убыток, не убыток, не та прибыль, но если система используется, мы считаем внутри компании, что проект успешный.

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

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

Если вы не видите часть рисков, значит их пока нет в вашей области управления. Количество рисков нарастает по ходу проекта и по ходу получения опыта на других проектах и т.д.

Если наоборот, вы видите очевидный риск, но бизнес-заказчик с ним не согласен, я бы аккуратно шел в такой проект, потому что заказчик, видимо, не очень понимает, зачем ему система.

Но заказчик действительно в 95% проектов не понимает, зачем ему система.

Ну а тогда зачем?

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Кейсы проектов Бесплатно (free)

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

09.09.2024    467    0    user1231217    1    

4

Кейсы проектов Работа с заинтересованными сторонами Бесплатно (free)

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

12.07.2024    1011    0    1c-izh    1    

5

Кейсы проектов Бесплатно (free)

В двадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, как проходил запуск Lamoda Sport в части автоматизации, какие специалисты работали над этой задачей и что помогло запуститься в короткие сроки.

28.05.2024    588    0    Radio_Analyst    0    

4

Кейсы проектов Бесплатно (free)

Когда проект ограничен по времени, и уже через два месяца заказчик физически не сможет работать в старой системе, нет времени обкладываться бумажками – нужно быстро подготовить новую систему к переходу. Расскажем о том, как гибкие технологии SCRUM и ТБР помогли за два месяца адаптировать 1С:ERP под существующие бизнес-процессы компании.

07.02.2024    2971    0    izybaevda    18    

16

Кейсы проектов Бесплатно (free)

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

12.09.2023    1596    0    chat007    0    

5

Кейсы автоматизации Кейсы проектов Кейсы продуктов Программист Руководитель проекта Бесплатно (free)

В управлении проектами нет однозначных рецептов, особенно при взаимодействии с заказчиком из другой страны и другой культуры в проектах перехода из принципиально другой исторической системы. Расскажем об истории крупнейшего международного проекта перехода с SAP на 1С:ERP.

01.09.2023    2155    0    olegminkov    2    

10

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15437    0    ASchekachev    37    

55

Кейсы проектов Бесплатно (free)

В восемнадцатом выпуске подкаста Радио “Аналитик“ обсудили, что делать, если ценность продукта не очевидна для пользователя, какие трудности могут возникнуть при изменении позиционирования продукта и как с ними справиться.

15.05.2023    664    0    Radio_Analyst    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. DENSKR 16 21.12.23 15:30 Сейчас в теме
Хорошая статья, спасибо!
2. roman72 388 21.12.23 22:48 Сейчас в теме
Спасибо, что не побоялись публично изложить своё видение рисков на проектах по внедрению систем ERP-класса.
Такие материалы всегда интересны, чтобы "сверить часы" - своё видение с таким же специалистом в родственной сфере.

Но что неожиданно, из материала следует, что компания, работающая с подобными проектами лет 20 и прошедшая, наверное, десятки или сотни таких проектов, по-прежнему называет рисками то, что является нормой жизни на таких проектах.
И эти "нормы" должны решаться технологией.

Заметно, что далеко не по всем рискам вы назвали способы их решения.
А те что назвали относятся к организационным, а не к технологическим решениям.

Как это понимать?
Не выработали свою технологию гарантированного решения нормальных, в смысле обычных, рисков проектов до сих пор?
3. 1СERP 3043 22.12.23 10:36 Сейчас в теме
(2)
Роман, то, что риски срабатывают часто и стали нормой не значит, что о них не нужно рассказывать коллегам.

То, что разные риски имеют разные способы минимизации их последствий (организационные, технические) - соглашусь.
Если Вы хотите обсудить какие-то конкретные моменты в статье более подробно - буду рад.
5. roman72 388 22.12.23 12:50 Сейчас в теме
(3) Я же не про то что не стоит рассказывать про риски. Я здесь наоборот хвалю статью.
Обсудить я хотел бы конкретный из конркетнейших моментов - почему статья с хорошим изложением рисков есть, а методов снижения этих рисков на уровне технологии в ней не называется.
Нет таких методов?
9. 1СERP 3043 22.12.23 15:39 Сейчас в теме
(5)
Роман, если хотите обсудить какой-то конкретный риск - давайте обсудим. Сразу о 10 вариантах сложно говорить
12. roman72 388 25.12.23 14:27 Сейчас в теме
(9) Хорошо, обсудим "риск" № 4 - "на этапе моделирования пользователи генерят очень много требований, которые выходят за границы проекта. Опытный исполнитель, естественно, с самого начала проекта будет этим управлять и будет пытаться не допустить расширения требований."

Почему это вы называете "риском"?
Разве это не стандартная технологическая ситуация на проекте?

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

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

А вот ввязывание в проект, в котором гарантированно будет расширение за границы (а это всегда будет в 99% проектов), но с расчётом, что все такие расширения утрясутся за счёт исходного завышения стоимости и сроков проекта - это и есть риск.

Т.е. проблема не в пользователях с их требованиями, а в политике франча (интегратора) - что называть риском.
14. 1СERP 3043 26.12.23 08:53 Сейчас в теме
(12)
Приведу 2 примера, за которыми стоит много реальных ситуаций.
1. Обсуждается проект. Идет согласование границ, торг. Договор заключен. Пусть даже только на Функциональное моделирование. При сборе требований границы неожиданно расширяются. Появляется пара процессов, которые не поименованы в договоре. В результате бюджет на доработки растет от предполагаемых (цифры условно) 30млн до, скажем, 60. Директор заказчика считает, что его обманули. Попытка рассказать, что границы изначально обсуждали другие и предложить вернуться к ним (если нет бюджета на автоматизацию новых процессов) не приводит к успеху. Сотрудничество останавливается.

2. Конкурс по 223ФЗ. Пользователи заказчика при Функциональном моделировании формируют требования, которые мы даже не предполагали при оценке. Ну, скажем, что форм бюджетов (различных отчетов, которые заказчик называет "бюджетами") 700 штук. Мы такое количество не планировали. Изменить существенно договор по 223ФЗ нельзя. Попадаем на проект с убытками.

Вот, собственно, примерно такие ситуации я считаю рисками неконтролируемого расширения границ проекта.
16. roman72 388 26.12.23 22:17 Сейчас в теме
(14) Это два отличных примера типовых ситуаций на проекте.
Но опять же это не риск выхода требований за пределы проекта.
У проекта два предела (две границы) - срок и деньги.
То что требования выйдут за пределы проекта - это не риск, это событие, которое обязательно произойдёт.
И это известно заранее.
Исключения редки, это случаи когда в проект заложены очень большие запасы по срокам и деньгам, они лишь подтверждают правило.

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

Во втором примере, строго говоря, частный случай первого примера, когда исполнитель заранее заключает договор, где обязуется все выходы за границы решать за свой счёт по времени и деньгам.
То что вы не знали про "700 форм" и что договор "государственный, неизменный" это не означает риск роста требований, ведь никто не мешал вам в договор включить ограничения на количество создаваемых объектов, типа
"не более 500 форм, не более 100 объектов метаданных, не более 50 функций и механизмов".

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

Впрочем, все крупные франчи и интеграторы этим грешат.

Вопрос собственно в том, почему никто не пытается решать подобные проблемы за счёт технологии исполнения проектов, а упрямым упорством бьют лоб о заранее известные последствия исполнения договоров с нечеткими границами и ответственностью только исполнителя.
Jenioshi; +1 Ответить
4. Andrekaa 22.12.23 11:45 Сейчас в теме
Слишком поверхностно.
А переход с УПП на ЕРП - тут уже не "И тогда бизнесу станет понятно, зачем им тратить на это время " , а необходимость суровая )
7. Сисой 88 22.12.23 13:41 Сейчас в теме
(4) а почему, собственно? УПП вполне может быть системой для УУ. Я сам интегрировал ее с БП 3 и все нормально работало.
8. Andrekaa 22.12.23 13:47 Сейчас в теме
(7)такая интеграция на "особенно на предприятиях советского типа (машиностроение и т.д.)" очень проблематичное решение
15. 1СERP 3043 26.12.23 08:58 Сейчас в теме
(8)
У нас несколько таких кейсов. Работает. Это точно меньшие сложности для заказчика, чем разовый огромный проект по замене сильно кастомизированной под запросы, скажем, производства, УПП.
При этом все заказчики с такой ситуацией понимают, что переводить оставшийся в УПП функционал на новые системы (ERP, скорее всего) придется. Но это уже несрочный проект. И его можно планировать спокойно.
17. roman72 388 26.12.23 22:46 Сейчас в теме
(8) С чего бы это вдруг проблематичное?
19. Andrekaa 27.12.23 10:53 Сейчас в теме
(17) По заказный метод учета, ГОЗ, сдельные наряды, полуфабрикатный метод учета и т.д на многих предприятиях
машиностроения.
Слишком сложный обмен в итоге нарисовывается.
20. roman72 388 27.12.23 11:52 Сейчас в теме
(19) В исходном тесте, на который вы ответили, а я ответил на ваш, шла речь лишь об интеграции БП и УПП.
Зачем в БП заказы, наряды и полуфабрикаты?

Нет ничего сверхсложного в интеграциях, если их делать правильно и без излишеств.
Jenioshi; +1 Ответить
11. 1СERP 3043 22.12.23 15:42 Сейчас в теме
(7)
У нас есть примеры, когда финансы переводятся на ERP, а оперативный контур остается в УПП
10. 1СERP 3043 22.12.23 15:41 Сейчас в теме
(4)
Если переход с УПП на ERP делается как технологический проект (без развития и улучшения уровня автоматизации) - это реально очень рискованный проект. Пользы никакой, заинтересованности владельцев процессов и пользователей никакой, а усилий от них требуется много.
6. Сисой 88 22.12.23 13:39 Сейчас в теме
>> переход с сильно доработанного старого решения

Когда меня приглашали такие заказчики, как частного консультанта, я им честно говорил, что у них хорошая ИС и перевнедрять ничего не нужно, разумнее немного доработать имеющееся. Но где та грань, за которой без внедрения не обойтись? Да и бизнес консультантов и интеграторов требует жертв.
Вот стоит такая сильно допиленная, обвешанная веб-сервисами и фоновыми заданиями УПП - и всем хорошо. А специалиста, умеющего (и желающего) работать с толстым клиентом - найти все тяжелее.
13. roman72 388 25.12.23 14:34 Сейчас в теме
(6) Вот эта грань - когда эфективность старой системы ниже чем эффективность новой +- стоимость внедрения новой.
И трудности с поиском специалистов на поддержание старой системы одна из гирек, которые в чашу весов кладутся в пользу новой системы.

И не бизнес консультантов и интеграторов требует жертв, а у них те же трудности с набором желающих поддерживать старую систему.
18. 1СERP 3043 27.12.23 08:36 Сейчас в теме
(16)
"То что требования выйдут за пределы проекта - это не риск, это событие, которое обязательно произойдёт.
И это известно заранее." - это конечно. вопрос масштаба выхода за пределы.

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

"это риск принятой технологии исполнения договоров в компании - вхождение в договора с нечётко определенными границами" - я не против вашего варианта квалификации риска.

Входить в проекты с не до конца определенными границами - это реальность. Вопрос в масштабах. Можно, конечно, при планировании пытаться устранить все неопределенности, но бюджет таких исследований может делать проект бессмысленным с экономической точки зрения.
21. roman72 388 27.12.23 11:54 Сейчас в теме
(18)
Можно, конечно, при планировании пытаться устранить все неопределенности, но бюджет таких исследований может делать проект бессмысленным с экономической точки зрения.


Для меня вот это самое ценное в ответе.
Предполагаю это ответ общий для/за всех франчей и интеграторов.
Оставьте свое сообщение