Вы неправы: на СВС были привлечены на субподряд несколько консультантов Мекомпа, до этого более-менее успешно внедривших на МСКР (Миттел Стил Кривый Рих - Кривой Рог по нашему). Не пивная и тому подобная, однако. Но, к сожалению, их опыт и решения на СВС не совсем подошли. Причём некоторые не подошли сразу, а некоторые - не сразу, а уже на фазе реализации, что ещё печальнее. Потом появились "перебежчики" с НЛМК (Липецк). Тогда стало понятнее, что в Липецке многие функциональные решения были довольно сильно упрощены с целью упрощения внедрения, но с некоторым ущербом функциональным потребностям отрасли.
Фактически можно констатировать, что "пирог оказался не по зубам" - даже один только ЧерМК слишком сложен, а там ещё кроме него трубы, метизы, инвест...

Тоже правильное сравнение.
Большая проблема была в том, что на ЧерМК до-саповский "зоопарк софта" был очень продвинутым. Не в смысле интеграции внутри себя, однако, но в смысле удобства пользователей. Оттачивался он 6 лет, и поэтому удовлетворял самые мелкие и извращённые хотелки.
Что для внедрения сапа - безусловно тоже минус.

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

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

Я уже не говорю что решения принимаются по принципу "каждый суслик - агроном".

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

а требования из примера - они вполне осуществимы, если бы так и в консалтинге.

Больше к внешнему консалтингу относится, кто на скоуп подписывался и предложение делал. Раннее вполне себе успешно и неспешно ССР запустили.

1. Слабо проработанная миграция данных со стороны процессных команд. Мигрировать нужно по максимуму всего, чтобы не было потом стыдно смотреть в глаза разочарованных пользователей, только так можно по максимуму сохранить прелести существующих систем. На эту тему я писал ещё летом 2010 года.
2. Разработка и поддержка системы в Череповце - это заведомо сужение числа и качества специалистов без реальной производственной необходимости.
3. В конце августа под давлением Заказчика было принято решение специалистов поддержки 2-го уровня закрепить жёстко за модулями. Это сломало наш процесс подготовки кросс-модульных специалистов поддержки (это была вполне решаемая задача). Системной их подготовки силами 3-го уровня не получилось. В начале ноября оказалось, что нужны кросс-модульные специалисты.

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

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

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

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

Конечно. Но продавали проект и на скоуп подписывались совсем не те люди, которые потом это должны были реализовывать.
У продажников всегда всё хорошо: проект продали, бонусы получили, гуляй рванина!


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

А можно этот момент по-подробнее?

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

смотрю у вас неплохо получается.

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

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

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

А так лозунг "клиент всегда прав" конечно коммерчески правильный. Ну хочет чипсы с водкой, пусть получает

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

Наиболее точный диагноз данного проекта. Бурно аплодирую.