Ещё немного поспорю с 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, так и в рамках специализированной системы, вопрос в соотношении цены, времени, и качества :) На мой взгляд, внедрение готовой системы (по крайней мере, бездумное внедрение) - это выигрыш во времени за счёт качества. По сравнению с этим, разработка специализированной системы выполняется медленнее, но при профессиональном подходе даёт лучшее соотношение цена/качество. При внедрении готовой системы всегда приходится чем-то жертвовать для того, чтобы втиснуться в стандарт, а если вдруг потребуется выйти за рамки стандарта - надо будет перелопачивать неоправданно большое количество кода. При разработке специализированной системы, результат бывает более предсказуем, пропорционально зависит от приложенных усилий и оказывается ближе к желаемому. При этом нельзя забывать, что за готовую систему надо заплатить довольно большие деньги сразу, а следующий за этим процесс внедрения может оказаться сравнимым по стоимости с процессом разработки специализированной системы.
Вот. По-моему, так :)