1. Забавно, что вариант "заказать разработку программы в софтовой фирме" в таких ветках обычно даже не обсуждается :) А, возможно, зря.
2. На самом деле, за самостоятельную разработку есть смысл браться только в том случае, если в коллективе есть пара разработчиков, прошедших через несколько проваленных проектов и сделавших из этого определённые выводы. И надо чётко представлять, сколько конкретно времени на какую часть проекта уйдёт. И что с ним будет дальше.
3. С другой стороны, по собственному опыту, в SAP'е много чего нужного не хватает. Как и в любой тиражной системе. Ну да, можно дописать то, чего не хватает. Но это получится переписывание с нуля всего модуля, в конечном итоге. У SAP'а движок довольно неудобный для программирования, т.к. не объектный ни разу (ну да, да, есть там какие-то объекты, даже 2 вида :) и представляет собой нагромождение каких-то почти не связанных решений разной степени удачности.
4. Конечно, если уже есть SAP, выбрасывать жалко... ;)

1. Забавно, что вариант "заказать разработку программы в софтовой фирме" в таких ветках обычно даже не обсуждается :) А, возможно, зря.
2. На самом деле, за самостоятельную разработку есть смысл браться только в том случае, если в коллективе есть пара разработчиков, прошедших через несколько проваленных проектов и сделавших из этого определённые выводы. И надо чётко представлять, сколько конкретно времени на какую часть проекта уйдёт. И что с ним будет дальше.
3. С другой стороны, по собственному опыту, в SAP'е много чего нужного не хватает. Как и в любой тиражной системе. Ну да, можно дописать то, чего не хватает. Но это получится переписывание с нуля всего модуля, в конечном итоге. У SAP'а движок довольно неудобный для программирования, т.к. не объектный ни разу (ну да, да, есть там какие-то объекты, даже 2 вида :) и представляет собой нагромождение каких-то почти не связанных решений разной степени удачности.
4. Конечно, если уже есть SAP, выбрасывать жалко... ;)

1. "Движок у SAP" - ABAP + Workflow + SapScript + Редактор экранов + SmartForms + ... Достаточно? В общем, всё то, что не реализует конкретную бизнес-логику.
2. Ну... Ну да, ООП. Вполне. Но при этом почти всё, что есть в системе, написано без применения оного ООП. А жалкие попытки поООПить на абапе (как в модуле MM, например) выглядят странно. Их почти невозможно отлаживать из стандартного отладчика экранов. С ними почти никак не работает пакетный ввод из-за ActiveX control'ов. При этом язык странным образом поддерживает 2 типа объектов: бизнес-объекты и абап-объекты. Для которых даже редакторы разные. Вот вам и "найдите 2 отличия".
3. Ну... Ну да. Не умею. И не хочу больше уметь. Мне хватило полугода работы под руководством нехилых профессионалов-абаперов, чтобы проникнуться к системе отвращением (ну да, возможно, отчасти не очень заслуженным - всё-таки, система могучая, чего и говорить).

Небольшое продолжение. Немного коррелирует с п.2
"Об убогости и незаменимости пакетного ввода". Убогость: ну какое мне дело до того, что там пользователю на экране показывают, если я программирую бизнес-логику? Ан нет, фактически, приходится, вместо того, чтобы вызывать стандартную функцию с заданными параметрами, программным образом вводить на экран всё то же самое, что вводит пользователь. А если потом интерфейс изменится? А если автор интерфейса решит контролами побаловаться? В общем, муть. Незаменимость: а чем его заменишь? Нету другой возможности вызывать из своих программ стандартные саповские функции. BAPI? Я вас умоляю. Он делает совсем не то. САПовские программы сами не используют BAPI_...-функции. Потому что они глючны. Я сам видел очевидные ляпы.

Это всё уже не говоря о том общем положении, что, если бизнес-логика хоть немного выходит за рамки того, что есть в тиражной системе, проще всё переписать, чем подгонять под стандарт. Ну ладно, не проще. Но ЗАЧЕМ мне стандартные саповские резервирования, заявки на закупку и заказы на поставку из MM, если РЕАЛЬНЫЙ бизнес процесс никак не укладывается в эту схему. И все эти стандартные саповские первичные документы только мешаются. И никак от них не изолируешь конечного пользователя, если всё не переписать.

авторФункционал SAP - нормальный функционал, пригодный для реализации в большинстве компаний
Ну да - где-то пригоден. А где-то нет. Надо разбираться на месте. Надо сначала решить, как всё будет выглядеть, если поставить сап, а потом уже приступать к непосредственно к внедрению. И если вдруг окажется, что что-то из требуемой функциональности сапёрами не было реализовано, то тут и вступит в силу пункт о том, что авторABAP - это достаточно убогий язык.
авторПроекты по внедрению ERP-системы, ориентированные на программирование, обречны на провал
? О чём я и говорил. Сначала надо выяснить, много ли надо будет программировать, чтобы подогнать сап под предприятие. Потому что если много - то внедрение обречено на провал.
авторпочему же Вы воспринимаете систему как коробочный продукт, с которым можно разобраться за пару месяцев?
? Никогда не говорил, что в коробочном продукте можно разобраться за пару месяцев. Не говорил слов "коробочная система".
З.Ы. авторbapi - функции не пользуются стандартным функционалом, просто потому, что они сами - оболочка над стандартным функционалом Возможно. Я не особо разбираюсь в этих вещах. Но знаю, что иногда они работают не так, как стандартный функционал.
З.З.Ы. авторВидно, что внедрение sap нанесло Вам сильное морально увечье Спокойнее, спокойнее, товарищ :)

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

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

mazzy Так_забежал_простоЯ считаю, что сложность - это минус ERP-системы.
Сложность - обратная сторона функциональности.
..., а особенно избыточной функциональности.

Избыточная функциональность (неважно, у тиражного или не тиражного продукта - при оценке уже работающей вещи какая разница, тиражный продукт, заказной или самописный) - это когда система поддерживает функциональность, невостребованную на данном предприятии. Один из признаков избыточной функциональности - когда система применяет при "разговоре" с конечным пользователем слишком высокий для данной задачи уровень абстракций. Например, конкретно с R/3, есть некий шанс "увязнуть" в терминах "МВЗ", "ПФМ", "контроллинговая единица", "контировка". "Заявка на закупку" и "резервирование" имеют большой шанс оказаться невостребованными, если система внутреннего заказа предприятия "не влезает" в стандартную саповскую схему. Мало того, что в этом случае придётся писать свой внутренний заказ, так ещё и надо будет скрывать от пользователя (а хорошо бы также и от админов ...) всё "лишнее". А такое "сокрытие" не всегда возможно. Соответственно, может оказаться, что внедрение R/3 окажется более дорогостоящим, чем изготовление системы на заказ хорошей софтверной конторой, и при этом R/3 будет существенно менее дружелюбной к пользователю.
Дополнительная информация к размышлению: приличный консультант R/3 "стоит" раза в 2-3 дороже просто приличного программиста :)

Ещё немного поспорю с AnS1. Вот Вы говорите, что
AnS1Внедрение требует значительных знаний экономической теории, знаний в области финансов, контроллинга, огранизации поставок. ERP-системы - это действительно сложно.
Но, по моему убеждению, небольшая группа людей, владеющих такими серьёзными знаниями, умеющих программировать и уже имеющая какие-то свои наработки, способна создать в разумные сроки систему управления данным конкретным предприятием. Речь не идёт о том, чтобы переписать R/3, 40 ГБ текстов на абапе - это выше всяких человеческих возможностей, но создать специализированную систему, заточенную под данное предприятие - вполне реально. Верьте мне :) Я сейчас работаю под руководством как раз таких людей. И здесь ведётся значительно меньше разговоров о том, что "ERP надо насаждать сверху", потому что система, заточенная под конкретное предприятие, значительно дружелюбнее к пользователю, здесь значительно меньше надо чего-то "насаждать".

Уф-ф, наконец-то дорвался до форума.
AnS1Может быть, наш спор о пригодности \ непригодности использования тиражных ERP систем перевести в практическое русло? С учетом того, что у Вас имеется определенный опыт внедрения R/3, это было бы даже интересно. Например, Вы могли бы предложить схему процесса, которую, как Вы считаете, невозможно \ сложно реализовать в R/3. А я бы посмотрел, что можно с этим случаем сделать.
Сложно. Не хотелось бы прилюдно здесь описывать все бизнес-процессы конкретных компаний, а выдумать что-то у меня опыта пока не хватает. В общем, наверное, так. В R/3 плохо вписывается сложная разветвлённая схема составных частей компании, которые взаимодействуют по заданным законам и существенно неравноправны. Например, отношения центральный офис-региональный офис-городской офис-магазины-сервис-центры-склады. В R/3 вместо всего этого есть схема Контроллинговая единица-БЕ-Завод. Т.е. иерархическая структура ограничивается 3-мя уровнями. При этом у понятия "БЕ" есть вполне определённый физический смысл - по-англицки это company code, т.е. официально зарегистрированное юр. лицо. А если все элементы в сложной иерархии представляют собой отдельные БЕ и иерархические отношения между ними "неуставные", например, основанные на взаимной зависимости? Тогда вся R3шная система вырождается в 2-хступенчатую иерархию, понятие "завод" теряет смысл. А такой 2-хступенчатой иерархии недостаточно для отражения всех взаимодействий внутри компании. Кстати, многие документы логистики будет продолжать требовать ввести пару "БЕ-завод", хотя эти 2 понятия сольются.
Кроме того, в R/3 достаточно слабая система управления движением товара внутри компании. На мой взгляд.
AnS1Раз уж речь зашла об избыточности функционала, то, хотелось бы заметить, что система построена по модульному принципу. Если Вам не нужны документы резервирования, то не используйте их.
Ну да. Можно не использовать. Но при этом придётся писать что-то своё, а потом вклинивать его в стандартный функционал. А это не особо простая задача.
Про модульную структуру - избыточный функционал неизбежно присутствует в каждом модуле. А бывает, что в каком-то модуле чего-то не хватает. А если не хватает - придётся дописывать. А потом вклинивать в стандартный функционал. Если получится. А не получится - переписывать полмодуля.
AnS1если вдруг у вас возникла необходимость использования этих объектов ВНЕ контроллинга или вне схем передачи данных в контроллиг, которые, замечу, можно эффективно скрыть от пользователя, т.ч., осуществляя проводку ему абсолютно не нужно указывать вручную МВП \ МВЗ, то это явно проблемы с проектированием
Несколько дурацких вопросов: а контроллинг - он есть? Т.е. это что-то реальное? Всегда ли МВП отличается от МВЗ и всегда ли есть смысл вводить эти понятия? Например, есть сеть ресторанов. При этом один ресторан является и источником прибыли, и источником затрат, и собственно орг. единицей внутри предприятия (заводом?) Выгодно ли тут городить огород из МВЗ, МВП, заводов и т.д.? В общем, по-моему, человек, поработав с R/3, почитав умных книжек, начинает верить в то, что все эти придуманные объекты существуют на самом деле.

В общем, почитав то, что здесь написано, я внезапно осознал, что принимал участие в автоматизации разумно организованных компаний, где все "местнические интересы" руководство волшебным образом поставило на службу компании в целом.
Соответственно, в этом случае "насильственная автоматизация" с изменением взаимоотношений внутри компании была нежелательна - компания и так обгоняла своих конкурентов по многим параметрам. Поэтому стояла именно задача упрощения и упорядочения работы пользователей, ускорения доступа к требуемой информации. Естественно, что-то надо было внедрять насильно, но немного. А разработка системы конкретно под предприятие позволяет сохранить то хорошее, что уже есть в отношениях внутри компании.
Далее, возникает вопрос - действительно ли с помощью "насильственной автоматизации" можно упорядочить хаос? Может быть, упорядочение хаоса на предприятии - отдельный процесс, лишь частично связанный с автоматизацией? А информационная система предприятия всего лишь закрепляет установившийся порядок вещей, упрощая работу пользователям(и руководителям) и не давая им сойти с один раз выбранного пути?

Тоже работаю на работе, так что связь замедленная :)
AnS1В R/3 структура предприятия описывается не сама по себе, а в зависимости от требований к автоматизируемым функциям.
"В зависимости от требований" - это, я так понимаю, значит, что внутри каждого модуля своя структура? Такое описание часто бывает избыточным (хотя, конечно, это не особо страшно)
AnS1Если Вы прописываете структуру для сбыта, то оперируете понятием "Рынок сбыта", который есть объединение таких единиц как
- сбытовая организация
- канал сбыта
- сектор сбыта
+ для 2 уровня для организационного оформления отделов продаж
- отдел сбыта
- группа сбыта
А если у нас иерархическая структура каналов сбыта? Со сложными механизмами управления движением товара между каналами? Сбытовая организация - не привязана ли она к БЕ или ещё чему нибудь такому? Это было бы довольно неприятно. Это только вопросы, касающиеся структуры. Структуру в системе с нормальным движком описать - дело пары дней. В R/3 надо дольше думать, каким R/3-шным термином обозвать реальный объект. А ещё есть алгоритмы, стоящие за структурой. С ними тоже могут быть какие-то проблемы (с конкретными примерами у меня туго - не настолько хорошо знаю R/3 :)
AnS1Если складское ходяйство, то это
завод
-склад
--пункт отгрузки
--пункт приемки
--- складское место
и еще что-то
ОК. А теперь предположим, у нас есть система с объектным движком. И учётной машиной. Описываем в ней сущности "склад", "пункт отгрузки" и т.д. Составляем соответствующий план счетов учёта движения товара (это так и так надо будет сделать). Пока всё просто. Реализуем ввод соответствующих накладных, порождающих соответствующие проводки. Эта часть громоздкая, но тоже реализуемая. И получаем то, что есть в сапе. Вроде. Так? Только с некоторыми преимуществами. Например, можно будет сделать так, чтобы товар на складе был привязан к каналу сбыта - будет сразу видно, зачем он там лежит, куда он должен потом поехать.
AnS1Все эти структуры связаны друг с другом. Надо понимать, что связь эта не произвольна, и определяется смысловой нагрузкой, которую разработчики заложили в систему
Естественно - голая структура никому не нужна. Структуру можно описать за пару дней. Но заложили ли разработчики в эту структуру алгоритмы, которые устраивают абсолютно всех? Сомневаюсь...
AnS1В 99 случаев из 100 сбытовую деятельность можно описать без потери функционала теми терминами, что предлагает система.
Здесь возникает принципиальная проблема. А если вдруг , в результате развития предприятия, сбытовая деятельность перестанет описываться саповской схемой? Вдруг в схеме появится принципиально новый объект? Или процесс? Если система написана специально под предприятие - она так же легко и допишется, при условии что у неё нормальный движок. Если система готовая - как поступать в этом случае? Я уже не говорю о том, что эти 99% явно завышены.
Ещё из проблем готовой системы: в стандартные саповские таблицы ничего добавить нельзя. Фактически. А если нужно будет учитывать какое-нибудь новое свойство объекта? В специализированной системе проблем нет. В R/3 есть. Приходится писать такие вещи куда придётся. Типичная проблема: "ну и куда бы нам это вписать?"

Ещё из нереализованного в R/3 - система контроля за возвратом документов от заказчика. Мой коллега писал её сам. Опять-таки там всякие сложности с интеграцией этого в R/3 - стандарт-то менять не принято.

AnS11 В действительности, дополнять стандартные таблицы МОЖНО. Даже бухгалтерские. Есть специальные механизмы расширения таблиц. Для большого количества прикладных областей это сопрягается с возможностью протянуть данные поля в приложения (так, можно расширить таблицы материалов, закупочных заказов, сбытовых заказов... с генерацией полей на экранах соотв. приложений)
Ладно, пожалуй, немного погорячился. Про специальные механизмы имеется в виду, что в некоторые таблицы включена расширяемая структура? Но это ведь не во всех таблицах. И не во все интерфейсы это потом вытаскивается. А как быть с алгоритмами для обработки новых полей? А если возникла потребность в каком-то особенном способе отображения новых полей?
AnS12 я уже отметил, что система для расширения имеет cross-applications функциональность. Т.е., Вы можете связать произвольные объекты в системе посредством системы классификации, классифицировать их будете в рамках стандартных user - exits - все автоматически, по стандарту :)
Слово cross-applications раньше не слышал :) User-exits есть в R/3 только там, где их поставили создатели той самой R/3. Их наличие не всегда может что-то изменить. Что делать с этой классификацией, если нет возможности поменять стандартный алгоритм?
AnS13 в самописной системе вместо вопроса "ну и куда бы нам это вписать?" возникает другой - "что и как нам писать?". Я думаю, что и в том, и другом случае положительный результат будет только если делом занимаются профессионалы достаточно высокого уровня - иллюзий, что вчерашние студенты настроят R3 \ напишут объектную систему под заказчика, быть не должно.
Если возникает вопрос "что писать?" - надо пинать заказчика. Это значит, что он не до конца понимает собственные бизнес-процессы. Другой вариант - запустить на предприятие бизнес-аналитиков, пусть сами решают, что писать, на свой страх и риск. В случае с готовыми системами этот вопрос также есть, но в изменённом виде: "что и как ставить?". При неблагоприятном исходе вопрос трансформируется в "а что это вы мне поставили?" Если заказчик задаёт такой вопрос, значит, внедрение провалено.
Если возникает вопрос "как писать?" - это уже некомпетентность программистов/внедренцев. Естественно, разработкой/внедрением должны заниматься профессионалы. В общем, конечно, любую проблему можно решить как в R/3, так и в рамках специализированной системы, вопрос в соотношении цены, времени, и качества :) На мой взгляд, внедрение готовой системы (по крайней мере, бездумное внедрение) - это выигрыш во времени за счёт качества. По сравнению с этим, разработка специализированной системы выполняется медленнее, но при профессиональном подходе даёт лучшее соотношение цена/качество. При внедрении готовой системы всегда приходится чем-то жертвовать для того, чтобы втиснуться в стандарт, а если вдруг потребуется выйти за рамки стандарта - надо будет перелопачивать неоправданно большое количество кода. При разработке специализированной системы, результат бывает более предсказуем, пропорционально зависит от приложенных усилий и оказывается ближе к желаемому. При этом нельзя забывать, что за готовую систему надо заплатить довольно большие деньги сразу, а следующий за этим процесс внедрения может оказаться сравнимым по стоимости с процессом разработки специализированной системы.
Вот. По-моему, так :)