0. Все то оно конечно правильно, но я бы первым пунктом поставил отсутствие консультантов у интегратора, выполнявших первое внедрение, к моменту продажи второго. Консалтинг это прежде всего люди, а они имеют свойство перемещаться, поэтому если компания А внедрила успешно продукт в компании В, то это не значит, что она седлает это так же успешно у вас, по причине того , что консультанты внедрявшие это решение уже давно сменили место своей работы, поэтому я бы рекомендовал прежде всего узнать кто внедрял решение в компании В и будут ли эти же специалисты делать внедрение у вас. Поверьте чаще всего это уже будут другие люди и 99% что и другие знания.
 
1. Платим дважды, да к сожалению это наверное 95% внедрений, а потому что так проще и идем по накатанной схеме, чем разбираться как же оно на самом деле работает. Кстати, тут так же большая проблема интегратора, так как консультанта стараются загрузить на 120% и соответственно времени на изучение функциональности, исследования системы, у человека просто нет времени, поэтому и заталкивают консультанты, то что уже где-то было проверено и фиг с ним что криво или пусть абапер допилит, потому что - ВРЕМЕНИ НЕТ!
 
2. Ну тут ответ один, требуйте документацию, причем если вы ее получили и ничего не поняли, требуйте чтобы ее привели в понятный вид, чтобы было описано, что сделано, как сделано и зачем было сделано. Пригласите специалиста со стороны, если не имеете своих, чтобы он оценил написанное и сказал ясно было ему это или нет. Денег это потребует не много, а пользы дальше вам же будет вагон.
 
3. А вот это вот про баги не надо и про отделы тестирования больших компаний тоже.. как говорится, кто не видел абаповский код стандарта, тот пусть постоит и покурит в стороне, а потому что нервных просим не смотреть :-).
 
4. Ну это опять же проблемы из пункта 0  и 1, времени на приведение разработки к вменяемому виду нет, разрабатывали действительно под одного клиента и т.д. Мне в свое время как-то предложили поучаствовать в реализации одного пакетного отраслевого решения, после внедрения на одном из проектов. Отказался, объяснив, что отраслевое решение, могу начать делать, после внедрения этой функциональности ну как минимум после 3-4 клиента, тогда у меня будет опыт и представление, а один клиент это никакое не отраслевое, а частные докрутки.

В общем-то все правильно.. но для наших реалий нужно добавить еще одни тип проекта: "Проект типа ОТКАТ" при этом получается что у нас есть и "Высокая степень контакта с клиентом" и "Индивидуальный подход", а вот результат внедрения нет, хотя по комбинации очень похоже на проект типа  "МОЗГИ".

Ну что я могу сказать... одна сторона, если все это реально посчитать, то 99 из 100 клиентов будут не ваши, а потому что цифра их шокирует и они побегут к конкуренту, который покажет 20% от вашей суммы. Нет, конечно потом он возможно с них снимет еще 100% от вашей или даже больше, просто как мне сказал один знакомый: "Понимаешь, не надо клиента шокировать полной суммой, скажи часть, а потом он влезет, заплатит эту часть, потом ему будет жалко потраченных денег и в 99 к одному, он заплатит все остальное и именно тебе :-)". Вторая сторона, это, ну возьмем пункт 11 - Обучение,. Стандартный курс по функциональности первого уровня обычно это 5 дней, но последние лет так уже пять, в лучшем случае курс ужимают до трех дней, а часто, часто вообще пишут один. И что пользователи за этот один день поймут? А зато в пять раз дешевле можно показать сумму по пункту обучение. Ну и по другим пунктам похоже часто действуют так же и на выходе получают нечто... за что систему нормально внедрить все равно не получится...

То есть пункты с 1-го по 15-й включать в бюджет при любых ситуациях не стоит?

Александр?
 
Задача элементарная для математиков (и физиков), если правильна поставлена.
Ключевые пользователи ставят вам такие задачи?

Как-то который день глядя на этот заголовок: "Что важнее при внедрении ERP: проектное лидерство или менеджмент?", так и хочется написать.. что главное, чтобы костюмчик сидел, т.е. система заработала, а кто и как был при этом сверху, т.е. главные это уже вопрос десятый, при разборе ситуации, если костюмчик, читай система, таки не стартовала. И что самое интересное, что будут случаи, когда было плохое лидерство в одном случае, а в другом этот самый менеджмент. Ну ка говорится люди и проекты все разные :-)

исследования одной компании, которая сравнила затраты по сотрудничеству, используя программное обеспечение от SAP и Microsoft (SharePoint). Как оказалось, стоимость использования программного обеспечения от SAP была значительно ниже, чем SharePoint.
 
а это что за компания такая? можно ссылочку на исследование?

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

Новый подход к настройке функционала SAP изложен в цикле наших статей "Целесообразное внедрение ERP" (подраздел Российская SAP-экспертиза).

А дальше то что?
Автор не описывает применив какой "новый подход к настройке функционала SAP" мы получим "конкурентные преимущества".
Думаю я тоже мог бы перечисли массу других концепций управления типа LP, 6 sigma, JIT и т.д., которые можно было бы учесть при внедрении SAP. Мы же с Вами понимаем, что дьявол в мелочах и многих бы как раз интересовал более или менее подробный пример такого применения "нового подхода", который так загадочно и заманчиво описал автор.
В любом случае спасибо за данное автором направление мысли, думаю многим будет полезно.

Мягкость? Ну в такой концепции как "пособность системы удовлетворять еще не сформировавшиеся потребности пользователей" вряд ли можно как это формализовать? Например SAP, хорошо если пользователи используют его на 10-20% от возможностей, тогда можно ли считать его "мягким"? Или нужно заранее определить направления развития и если основное направление развития изменение оргструктуры, то не "мягкий", а вот если расширение оргструктуры, тогда уже  "мягкий" :-)

Остается проблема коммуникаций. К сожалению, в ERM 5.3 не реализован поток операция для взаимодействия участников процессов разработки роли (не считая согласования).

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

Весь подход - это сплошная архитектурная ошибка, не понимание и не знание технологий SAP BW. Зато автор владеет JAVA технологиями - что и продемонстрировал. Напоминает древний анекдот про торжество советской медицины в деле удаление гланд.

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

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

Из практики на скольких проектах топ-менеджмент озвучивал следующую фразу, типа система не гибкая, причем в их понимании гибкость, это когда чуть ли не каждый месяц меняется оргструктура компании, а система должна за этим всем успевать и ответы, что ну нельзя менять коды БЕ/Заводов/Пароходов раз в месяц и т.д., их подчиненность между собой натыкаются на один ответ: "Ваша система не гибкая". Причем объяснение, что это даже не система, а принципы построения и функционирования реляционных баз данных, не проходит. В общем я так понимаю, многие продолжают путать гибкость с флюгером.

Полезная нота 1375425, а то с этими экселями вечные проблемы с отображением. А что по факту загрузки курса, ну оно к сожалению по данному методу все в диалоге грузит, а это значит есть человек, рабочий день у которого или начинается или заканчивается данным процессом, а курсы они могут и в 22:00 и позже, стать известными. В свое время мы просто через интернет из системы дергали курсы размещенные на официальном сайте национального банка Украины, часа в 2 ночи и автоматом заполняли таблицу курсов, затем ответственному сотруднику отправлялась сис, что все ОК или наоборот проблемы загрузки, так что ты мил человек типа выйди по раньше на работу, чтобы разрулить ситуацию. Времени оно конечно заняло написать эту программу больше, чем эту статью прочитать, но как по мне это более автоматизированно вышло.

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

В теории написано все правильно, на практике мы сталкиваемся с иной реальностью.
1. Отсутствие устоявшейся, регламентированной и измеримой модели процессов компании сводит на нет сравнение процессов as-is и to-be. Следует также понимать, что в условиях нашей экономики бизнес-процессы компании динамично изменяются (этим мы сильно отличается от Запада). За 1 год могут измениться не только бизнес-процессы, их владельцы, оргструктура (не говоря уже о KPI и системе отчетности), но и само направление развития бизнеса.
2. Если ранее в компании не была внедрена ERP система, то никто из владельце бизнес-процессов и представить себе не может на что он подписывается. Новые бизнес-процессы, как правило существуют в голове у консультантов уже проходивших не одно внедрение и знающих систему. Доказывать, что-либо бизнесу в этой ситуации не просто.
3. Сразу ограничиваем круг внедрений ERP - коммерческими проектами (Госсектор и Нефтянку вычеркиваем) - это так называемые ограничения проекта.
 
Можно было бы еще написать массу замечаний, но не вижу смысла. В целом, согласен с посылом авторов - сейчас на рынке ERP экономический эффект как правило не измеряется. Это факт.