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

Как-то который день глядя на этот заголовок: "Что важнее при внедрении 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 экономический эффект как правило не измеряется. Это факт.

Как-то пункт 2.3.1.:
 
======== цитата ========
В настоящее время ERP система настраивается на предоставление «отчетных» данных (составление многочисленных отчетов о затратах, о «локальной» эффективности деятельности подразделений). Эти данные не дают возможности принимать управленческие решения, направленные на достижение главной цели - увеличение прибыльности бизнеса.
 
Однако возможна такая настройка системы, которая позволит предоставить менедже-рам информацию, необходимую для принятия управленческих решений, обеспечивающих достижение главной цели Компании.
======== конец ========
 
И 2.3.3 по факту одно и тоже два раза два раза... выходит написано, с изменениями пары слов. Оно конечно повторение мать учения, но тут мне кажется это лишнее.
 
======== цитата ========
В настоящее время ERP система настраивается на предоставление «отчетных» данных (составление многочисленных отчетов о затратах, о «локальной» эффективности деятельности подразделений). Эти данные не дают возможности принимать управленческие решения, направленные на решение главной задачи.
 
Однако возможна такая настройка системы, которая позволит предоставить менеджерам информацию, необходимую для принятия управленческих решений, обеспечивающих достижение цели – увеличение эффективности бизнеса.
======== конец ========

Интересные замечания, но вопрос: Зачем Вы выбрали данную функциональность?
Вам необходима простота подтверждения? - Вы ее получили.
Вам тяжело вести технологические ил производственные заказы? - Вы существенно упростили процесс ведения документов (они практически удаляются без следа).
Что же вы хотели получить?
 
PS. орфографию лучше поправить, например слово аксельратор.

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

ИМХО: Лучше использовать элементы функциональности серийного производства, такие как Варианты изготовления, Таблица данных планирования, Коллектор затрат в сочетании с Технологическими заказами, чем просто использовать функциональность серийного производства.
 
PS. Очень жаль, что шаблоны иногда пишут безграмотные консультанты, а потом выдают это за "шедевры решений SAP". Не повезло с центральной командой :)