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

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

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

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

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

Абсолютно верно с точки зрения отчетности. Использование функциональности серийного производства целесообразно только в тех случаях, когда требования к отчетности не содержат явно выраженных требований к хранению плановых данных для последующего анализа планов и их выполнения (сравнение план/факт/отклонение) как по выработке, так и по потерям ингридиентов.
Это с точки зрения теории, де-факто же получается что это практически мало применимо для большинства российских предприятий, а также и производств иностранных компаний, базирующихся в России, т.к. исторически в России сравнение план-факт в различных разрезах - это базис аналитической отчетности производства.
В итоге получается, что использование данной функциональности при внедрении по умолчанию предполагает наличие разработок нестандартных отчетов (одна из причин - "бедность" функциональности серийного производства в плане отчетности). А также сразу же предполагает что получение отчетности в разрезе 1 производственного цикла практически невозможно (или требует неадекватных трудозатрат на ввод данной информации), т.к. объект вида "Производственный заказ" или "Технологический заказ" отсутствует.

Спасибо, поправил.

Немножко лишних ошибок.
И если "комонент" не так сильно режет глаз, то "мифическую простату" лучше исправить.......

Как-то вот читал, читал, и вроде тема интересная и комментариев что-то нет, а потом понял или точнее не понял, но предположу почему в ответ тишина, а потому что никто наверное так и не понял как же у вас получается совместить две эти задачи и главное их решить. Покажу на небольшом примере, итак задача исходя из предложенного:
 
1. Вы – руководитель ИТ-отдела на крупном предприятии и Ваше бизнес-руководство (инвесторы, владельцы, управляющие) посовещались и ставят вас перед известием: «будем внедрять SAP».
 
А вот теперь то что вы написали в пункте два, как это звучит со стороны, нужно решить следующая задачу: Будем покупать машину, нет не так... будем покупать МАШИНУ, с большой буквы! Дальше все тоже, вам как начальнику гаража надо:
 
Определить бюджет покупки МАШИНЫ, сроки на покупку, подготовить документы для покупки, выбрать что за машина будет, провести тендер, определить размеры гаража и вспомогательных помещений, определить требования к механикам и водителю машины, определить как будет использоваться машина, какая стоимость и периодичность ТО для этой машины и можно ли на этом деле с экономить?
 
А теперь заметьте я вам не говорю и не уточняю какую машину, для чего машину и т.д. но вы должны мне написать, опять же ваши слова: "какие из этих пунктов вызывали наибольшие трудности (для тех, кто уже полностью или частично, таки купил уже себе МАШИНУ)".
 
В общем если еще короче, то подите туда, не знаю куда, купите то не знаю что... и в цифрах...

Хорошо бы развить тему и сделать ролик в стиле Сержа Горелого.

Нужная статья, рекомендую обратить внимание на SAP ноту 152571.

Авизо об отправке - это входящая поставка
Накладные - исходящая поставка
Зависимые резервирования - это потребности РР/РМ заказов
Потребности отзыва - заказы/заявки на перемещение.

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

Если есть возможность, поясните пожалуйста, что такео Авизо об отправке (это входящая поставка?), Зависимые резервирования (это резервирования созданные из заказов РР и РМ ??), Потребности отзыва.
 
Хотелось бы так же чтобы вы рассмотрели взаимодействие связанных потребностей. Например Сбытового заказа и Исходящей поставке. Заказа на поставку и входящей поставки.

В этои посте к сожалению, много опечаток и ошибок :(
 
По поводу объема проверки хотел уточнить. Раньше вы писали что для сбытовых заказов и исходящих поставок жестко устанавливаются правила проверки (А и В соответственно). Значит ли это, что в таких документах объем проверки зависит только от материала (группы проверки) и нет возможности настроить разную логику проверки для разных видов заказов?

Начнем читать с анонса :)

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

Во всей русскоязычной документации давно принято Universe BusinessObjects именовать Юниверс, и не универс.

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

Адиль, можно попросить Вас обновить скриншоты?