Господа кто может поделиться информацией - никак не можем для себя определить конечные возможности системы.
Просто если смотреть на существующие внедрения, то больше 15-20 пользователей в озвучиваемых проектах не встречал. (может они и есть но найти информации не смогли)
Продавцы системы естественно утверждают, что нам хватит возможностей системы, но ответить на вопрос при каких условиях нам бы ее не хватило не могут. Интересует - граничные число пользователей, размер базы, кол-во филиалов, кол-во документов в день, кол-во записей в справочниках, ну в общем любые граничные данные при которых стоит подумать об следующем продукте SAP (или не сап). Заранее спасибо за любую информацию.

1 Без указания число строк в документах граничные условия не могут быть определены.
2 Без указания критерия ...при которых стоит подумать об следующем продукте SAP тем паче, поясню - для одного заказчика время сохранение документа 30 сек критично,ибо документы часто водят и редко читают,для другого критично время построения отчет по складскому журналу в горизонтальном развороте.
3 мораль - опишите вкратце бизнес-процесс,т.е. строки документов и документы,склады, критичность время сохранения документов и выпуска отчетов,тогда есть шанс на экспертную оценку сообщества.
4 Идеальный вариант крэш-тест,когда система синтетическим тестом загоняется в 3 сигмы от Вашей реальной.

Для оценки соответствия системы конкретному заказчику существует специальный инструмент "Opportunity Qualification Tool". Найти его можно здесь.

Ну хорошо давайте попробуем
допустим есть несколько магазинов работающих с центральным складом, у некоторых также есть склад на территории магазина.
торговля в большей части розница, но есть и опт.
торговля идет достаточно крупногабаритным товаром - большей частью через продавцов консультантов(хотя есть секции самообслуживания). покупатель обращается к продавцу и продавец должен определить наличие товара в данный момент. допустим половину из того что нужно он нашел у себя, другую он должен on-line зарезервировать на складе, и возможно какую-то часть покупки он может зарезервировать on-line в другом магазине(если вдруг на складе этой позиции не оказалось). в нашем представлении база должна быть в каждом магазине, т.к. при обрыве связи магазин должен остаться работать со своим торговым запасом. Это все что касалось критичности работы.
Что еще ?
кол-во строк - ну допустим 10-20 хотя возможны варианты
кол-во документов - могу конечно ошибаться ну допустим 300-400(фрон-офис) в большом магазине за день (в маленьком может быть гораздо меньше)
бэк-офис - ну единственно могу опять же приблизительно назвать только предполагаемое кол-во пользователей - до 100

to DI:"Opportunity Qualification Tool" если можно в двух словах что это?
а то что-то пока не понятно что получится на выходе?

1 Итого: 300 продаж/день*10 товарных позиций * 5 магазинов + 100 закупок/день * 50 товарных позиций * 1 штаб-квартиру = взлетит.
Критичным будет канал связи магазин/штаб-квартира и дисковая подсистема сиквела.
2 Не подорвитесь с резервированием,в SBO оно сделано через партии и требует тщательной проработки ТЗ.
3 Розница + штрих-коды - аналогично п.2

Сейчас еще раз проверил можно немного уточнить
порядка 400 продаж/день
магазинов больше 10
остальное очень похоже
Взлетит наверное.
Но опять же непонятно насколько далеко улетим.
Вот при данных "Итого: 300 продаж/день*10 тов......."
когда наступит предел и на чем ?
Будем ли мы иметь запас на 4-5 лет ? Консультанты говорят вот какая хорошая система - у одного клиента база 5 Гигов и все летает. А у нас сейчас на 1С - 40Гб. Сможет SBO работать с такой базой ? Тут уже будут вопросы к времени формирования отчета........
По п.2. можно чуть более подробно.
Тут еще нашел что в SBO склад одноуровневый т.е. адресное хранение не реализуемо. Это действительно так ?

1 Размер баз 1С и SBO сравнивать не стоит,поскольку принципы хранения данных кардинально отличаются.
SBO классическая OLTP система с толстым клиентом , широкими таблицами и поддержкой целостности на стороне клиента,собственно масштабируемость продукта этим полностью определена.
2 из п.1 следует , что при неудачном стечение where скорость некоторых отчеты будет падать с ростом объема базы,назовите критичные для Вас отчеты и минимальное время реакции - получите экспертизу.
3 по поводу резервирования, складов и протчая - к консультантам,это нау-хау каждого партнера,делиться на форуме(да и за рюмкой чая )не будут.
4 Пишите детальное ТЗ и добивайтесь демонстрации,помните SBO и 1С разные не продукты,а идеологии.
Всякий термин должен быть расшифрован и лишен двоякой трактовки.

Ясно будем следовать п.4
SBO - самая лучшая система - безо всяких ограничений и с неописуемыми возможностями.
Спасибо за ответы.

следует читать как:
ограничения SBO проистекают из ограничений сиквела
возможности SBO ограничены бюджетом Заказчика и сроками исполнения проекта

Это полюбому не СБО.

Ну и задачки

Причем здесь ограничения Сиквела...
Вообщем у продукта (СБО) есть своя ниша - малый бизнес. Вот для него и только для него он и подходит.
Хотя сам себе противоречу, - как малый бизнес смогет без бухгалтерии ? Ведь бухгалтерию должны вести все предприятия от мало до великого.


Вообщем он оч. спесифичный, оч. спесифичный ...

1С - 40 Гигов ? Ну и как, ворочается?
Это за год ?

to Stepa22
>1С - 40 Гигов ? Ну и как, ворочается?
>Это за год ?
нет за четыре года.
ворочается. там правда уже в большинстве своем чистые sql-запросы везде используются. 1с только в основном формы рисует.

to Shuhard
>ограничения SBO проистекают из ограничений сиквела
ну ну ну хоть одно ограничение назови пожалуйста.
а то вот Stepa22 говорит, что при таком кол-ве пользователей это одназначно не SBO.

>возможности SBO ограничены бюджетом Заказчика и сроками >исполнения проекта
да вроде бы пока здесь все нормально

1 берите нижеописанный сиквел(раз бюджета хватает) 1,231,433 tpc хватит для Вашей задачи
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=105112801
2 чем больше экспертов,тем репрезентативнее выборка