Пример. Я вижу успешно внедренный отдельно стоящий HR для расчета зарплаты на несколько тыс. человек.
Я также знаю, что десятки таких внедрений есть и у CBOSS и даже, о ужас, у 1С.
Поскольку внедрение - отдельно стоящее, сравнение корректное.
Внимание, вопрос - какими инженерными или бизнесовыми аргументами оправдано вливание в эту автоматизацию нескольких млн $ и продолжение вливания десятков тыс. $ в месяц на продолжение ее работы? Без мегасуперконсультанта она просто не работает.
Я делаю вывод, что аргументы не бизнесовые и не инженерные.

Мой пример не про пару тыс юзеров, а про несколько тыс зарплатных учеток. Юзеров десяток, может 2, если считать начальство.
С хорошей вероятностью это будет работать на штатной ЗиК на хорошем железе, дешевле на 2 десятичных порядка, чем у SAP.

Proforg...
Только потом придется думать, как допилить эту самую 1Ску, чтоб увязать ее с FI/CO/MM/SD и прочими неприличными аббревиатурами.
Cтоит смотреть чуть дальше собственного носа. Хотя - это уже задача начальства.

Судя по тому, что я вижу, интеграция даже одинаково устроенных внутри HR (HCM) и ERP не обеспечивается из коробки. Под чутким руководством мегаопытных внедренцев SAP руководство поддалось навешиванию лапши на уши и мы имеем физически отдельные инстансы (Ведь Так У Нас в HCM Будет Порядок!). Их интеграция - опять отдельный проект, и он опять дороже любой альтернативы. И делается методами, далекими от интересных крупным заказчикам - а именно, спагетти - передача "точка-точка" отдельных табличек через ALE.

ProforgА6дуллаh3Судя по тому, что я вижу, интеграция даже одинаково устроенных внутри HR (HCM) и ERP не обеспечивается из коробки.
SAP нельзя установить только нажав setup.exe и введя серийник ;)


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

ProforgЭто дело формирования системного ландшафта. В некоторых случаях имеет свои преимущества. Вы можете однозначно утверждать, что раздельный ландшафт хуже?

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

ProforgУ вас есть апробированная альтернатива связке ALE+IDOCs с меньшим TCO? Вдобавок, к крупный заказчикам вы относите проект на пару тыщ человек и 20 пользователей? :D

У нас есть. А еще вы наверное, в курсе, что SAP принципиально не поддерживает из коробки индустриальные стандарты интеграции, чтобы опять же рубить бабло? Чтобы запустить jdbc, нужно найти такого базисника и такого консультанта, который с этим справится. WS у них из коробки тоже свои-необычные, просто так не поработаешь. ODBC - нее! OLE - нее! Зато есть Свой ALE!
Вдобавок, вы намеренно оставили под хи-хи в стороне вторую систему, с которой собственно, интегрируется HCM? Там не 20 пользователей, как вы верно догадались.

Ладно, поздравьте нас с третьим прожитым в режиме внедрения "самой лучшей системы" годом и началом четвертого года успешного слива мегабаблоса в бездонную дыру под названием SAP.

Кто карму попортить не боится - вперед :)

В России километр газопровода в разы дороже, чем в Европе. В России самая популярная ERP - SAP.
Продолжите ряд :)

Proforg
авторSAP принципиально не поддерживает из коробки индустриальные стандарты интеграции
Прямая связка с базами (Oracle, MS SQL, DB2), ale, RFC, Webservices, .net connector, java connector - это только что сразу на ум приходит.

авторЧтобы запустить jdbc, нужно найти такого базисника и такого консультанта, который с этим справится.
Jdbc к саповской базе напрямую? За такое любой приличный базисник сразу оторвет верхние конечности и вставит их туда, где им самое место.


ALE, RFC - ваши проприетарные стандарты, интересные только вам.
.NET (который, кстати - от SAP или от MS?), JCo - очень мало распространены, плохо документированы, вопросы со стабильностью и поддержкой.
Опять хихи в позиции ухода от вопроса? Во второй цитате я имел в виду работа "изнутри SAP" с внешними источниками. Именно для этой работы внутри SAP наваян собственный стек работы с БД (DBConnect), в обход всех индустриальных стандартов и соответственно, только для ограниченного набора СУБД. Недавно появилась поддержка JDBC для этой же цели - так вот, включить ее и найти способных это поднять спецов - нереально. "Приличный базисник" этим не владеет, никогда не включал, ничего не хочет об этом ничего слышать (!)

Из инженера можно сделать сапера.
Из сапера инженера - уже нет.

Короче, если нужна бухгалтерия, производство, CRM, HR - тут SAP на высоте. Но не дай вам бог послушать их сейлов и выбрать SAP как платформу для массивной разработки, интеграции, MDM или BI для гетерогенных сред. Ни в одной из этих областей SAP не блещет ничем, кроме гигантских костов и своих проприетарных стандартов производительности и взаимодействия с чем-либо кроме себя самой.