1. Статья отражает мнение автора, сложившееся на основе весьма поверхностного знакомства с обсуждаемым предметом. К сожалению, метод "от частного к общему" иногда приводит к парадоксальным результатам, таким как пронизанные личными обидами опусы бывших руководителей проектов, с неподдельным удивлением обнаруживающих в процессе внедрения, что "ERP-система показывает только те данные, что были в неё введены" (таких как http://www.business-process.ru/kis/erp/hold_advisers_erp.html), либо приведённая статья.
В данном случае, идёт путаница в терминологии, либо полноценная подмена понятий. Объект критики в статье - не отраслевые решения (без которых внедрить систему в той или иной области бизнеса затруднительно - например SAP IS-A в автомобильной промышленности), а z-решения, т.е. дописывание системы под требования конкретного заказчика. А вот с критикой z-решений, изложенной в статье, трудно не согласиться. Основных же причин появления z-решений всего 3:
1) Недостаточная квалификация специалистов по внедряемой системе - от этого, увы, не застрахован ни один заказчик и ни один интегратор; спасти здесь может только система контроля результатов (проектных решений, документации по разработкам и настройкам) на проекте, которая позволит выявлять недостаточно квалифицированные ресурсы и замещать их по мере необходимости.
2) Нежелание или неспособность предприятия пересматривать и изменять порядок своей работы. Зачастую стихийно сложившиеся "изобретённые колёса", либо существующий бардак в части оргструктуры и бизнес-процессов успешно преподносятся топ-менеджменту предприятия как "конкурентные преимущества" и само предприятие требует переписывания целых блоков системы под "требования бизнеса". Перед этим зачастую бессильны даже самые квалифицированные консультанты - ведь они только могут аргументировать, перечислить "за" и "против" каждого из вариантов, тогда как непосредственно принятие решения всегда остаётся за менеджментом заказчика, зачастую руководствующимся не объективными а субъективными соображениями (сохраним наши "конкурентные преимущества").
3) Витиеватые требования законодательства. Тут, как говорится, без комментариев.
 

2. Не могу не согласиться с Олегом Точенюком, что 99% внедрений выполняется в условиях жёстких, а иногда и жесточайших ограничений по времени и ресурсам. А как известно "дёшево", "хорошо" и "быстро" не бывает. Так что не надо удивляться очевидным вещам.
 
3. К сожалению, на 100% российских проектов наблюдаю жуткую ситуацию: после продуктивного старта документация, подготовленная на этапе внедрения и переданная команде поддержки, перестаёт актуализироваться и через 3-6 месяцев перестаёт быть источником информации о системе. Причины: повсеместная экономия на количестве и качестве ресурсов в службах поддержки. Так что совсем не всегда "неизвестно как работающая система" - это вина "бестолковых" и "ленивых" консультантов.

Мда... ставить телегу впереди паровоза - это веселое занятие...

Вот именно этим тут постоянно и занимаются. Переписывают и переподписывают вот эти самые документы. Ну процесс у них такой.

Ну, если реальные заказчики ЕРП (акционеры и руководители компании) готовы рисковать бюджетами таких проектов, они не будут мотивировать персонал для активного участия в проектных работах... Но лучше, как говорится, один день потерять, потом за 5 минут долететь... - некоторая мотивация участников обернется экономией в разных областях и процессах.
Что же касается "интуитивно понятного интерфейса" apple - посадите за Mac человека который ни разу не видел MacOS. Увидите, что интуитивность интерфейса вдруг куда-то испарится... Чтобы что-то узнать, нужно в любом случае потратить время и усилия и с пользователями нужно грамотно работать; если говорить заезженными фразами "управлять их ожиданиями". Для этого в крупных проектах у заказчиков создаются команды бизнес-экспертов, полностью вовлекаемых в проект.

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

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

А почему ты так считаешь? был какой-то случай из практики?
указанная тобой схема больше напоминает схему "вывода денег из оборота".
 
В случае сделки купли-продажи увеличиваются риски неполучения конечного продукта (заказчик может отказаться покупать, а подрядчик продавать), а также увеличиваются транзакционные издержки (при продаже нужно налоги платить).
Кроме того, возможны случаи, когда подрядчику передают компоненты, общая стоимость которых настолько велика, что подрядчик не может себе позволить их купить.
 
Т.о., и та, и другая схема имеет право на существование и, в общем случае, нельзя сказать, что 1ое лучше 2го или наоборот. В России, Германии ли, или еще где-нибудь (хотя у меня не такой большой опыт, чтобы говорить за все государства :-) ).
 
И еще: подрядчику могут передавать не только сырье, но и технологичные компоненты.

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

Пользователи не хотят участвовать в проектировании системы, не хотят знать учет и формировать TЗ.
Пользователи хотят запустить файл setup.exe и иметь интуитивно понятный интерфейс как у apple.

А тем временем книжка вышла и в бумажном формате...
 
sapexpert.co.uk/the-essential-sap-career-guide-is-now-available-in-paperback

Олег, давайте будем честны.
ERP и есть первичный регистратор документов. Баланс, ОПУ, остатки должны формироваться в том числе и в BW. Почему, думаю объяснять не требуется, но для примера возьмем хотя бы один аспект - производительность и анализ детализации, цена вопроса простоя  ERP из-за тяжелых ABAP отчетов несоизмерима с штатной работой BW, где все механизмы оптимизированы для формирование отчета и выполнения OLAP анализа.
К вопросу о том как получить правильные остатки ;) могу прочитать целую лекцию о том как и когда, в какой последовательности что нужно внедрять чтобы "остатки" были правильными ;)

Ну если тут есть реализаторы такого копирования ERP, то хотелось бы у них узнать каким образом они после такого копирования в новом продуктиве получали правильные входящие остатки, как по логистике так и по финансам?!? Потому что такая реализация подразумевает что ERP это первичный регистратор документов, больше ничего... баланс, остатки по складам и закупка все в BW, что ли?

Алексей, здравствуйте.
А где в этой архитектуре место для архивированных данных?
Для всех уровней срок жизни не превышает нескольких лет.
Если существуют требования  по архивированию данных на сроки измеряемые десятками лет с целью обеспечения к ним редкого доступа по запросу. То в таком контексте, архивирование вообще не является задачей для BW, а должно достигаться на уровне исходых систем?
Тогда данные планирования после переноса в такой архив, также надо рассматривать в качестве исходной системы? И в случае развития текущей модели данных, доступ к архивным может быть настроен за счет настройки ETL и переноса по запросу?

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

Чем то напоминает google :)