Требования к системе:
- Распределенная структура по филиалам в России (география от Калининграда до Камчатки) с возможностью оперативного получения данных в центр;
- Количество транзакций в день: до 100 000 документов по 15 строк в табличной части;
- Количество активных номенклатурных позиций: ~5000
- Количество пользователей: ~1500
- Функционал должен включать управление торговлей и складом, управление закупками, расчет затрат и себестоимости, ценообразование, управление транспортом, управление финансами, МСФО, Бюджетирование, консолидированную отчетность.

В настоящее время в области РСБУ и HR уже используются и работают такие решения как 1С:БП 3.0. и 1С:ЗУП 2.5

Способна ли платформа 1С «перереварить» такой объем данных? У кого есть опыт внедрения, поделитесь, какой на ваш взгляд должна быть архитектура системы?

(327) Ежедневный отчет делается и в настоящее время, цель повысить оперативность. Заказы в головном интересная идея, но тогда придется подтягивать в центр всю специфику региональных клиентов, формы заказов, прайсов и т.д.

(329) Эээ... ты вот сейчас серьезно про то, что плевать на альбом печатных и отчетных форм, сделаем потом все что просят?

(323) Абсолютно серьёзно. Цель компании продавать оперативно товар, чтобы был в наличии и запасы не превышали спроса. Вряд ли отчеты по кадрам помогут, так же как и по затратам на канцелярию и т.д. Важно видеть динамику продаж и оперативно принимать решения, а отчеты  дело 5-е

(327) У нас в НСКе так работает птицефабрика, она собирает продажи по точкам, и сама привозит товар, что не продали забирает. В конце недели оплата торговле за объём продажи. Всегда свежие продукты и все довольны.

(333) Ну то есть все-равно, печатных форм 10 или 300?
И нужен ли пакет финотчетности или плевать?
И пакет регламентированной отчетности подходит типовой или что-то не нравится?

(335) У нас разные цели автоматизации, я за пользу заказчику, а вы за пользу исполнителям его. Может вообще отчетов не быть, будут вовремя приказы на отгрузку и дозаказ, и если они будут верныыми, то это уже 90% успеха от автоматизации.

(336) Совершенно верно, в первую очередь инвесторов интересует оперативное получение данных по продажам, дефектуре, заказам, оплатам, расчет потребностей, затрат. Бухотчетность на втором плане.

(336) Не надо рисоваться на моем фоне и красоваться в позе альтруиста на фоне рвача:))
Я не про цели автоматизации, в про то, что довольно странно оставить неосвещенным огромный пласт работ и требований, который с огромной вероятностью повлияет на архитектуру решения.

PR высказался, ждем Мебиуса...

(339) Заканчивай уже выпендриваться :))
Мебиус не занимается не медийными конторами.

(337)
"В первую очередь инвесторов интересует оперативное получение данных по продажам, дефектуре, заказам, оплатам, расчет потребностей, затрат"


Для достижения этой цели необходимо единое информационное пространство.

В пользу ERP так же говорит наличие отлаженного и готового функционала учета затрат, МСФО, бюджетирования и т.д.  
Отлаженного не только с точки зрения работоспособности кода, но и в части методологии и интеграции.

Это серьезно снижает риски проекта, так как разработка "с нуля" на подобных проектах - авантюра чистой воды.

Если рассматривать 1С - то ERP.

В качестве интегратора, выбирайте любого кто предоставит вменяемую проектную команду. Так как работать будут люди, а не бренд.

В качестве куратора можно привлечь саму 1С.

(341) а 1500 пользователей потянет в одной базе?

(340) Мебиус, в отличие от тебя, имеет внедренные решения, и отзывы клиентов у себя на сайте. Его мнению хоть как-то можно доверять, у тебя из достижений какой-то биллинг на БСП, и то только с твоих слов...

(340) кроме того у Мебиуса бэха, а у тебя даже хаты нет, максимум на красную кожанку собрал...умнобедный?

(342)
Несколько лет назад УПП вживую тянуло 200 активных пользователей на без доработок и на вполне земных серверах.

Сейчас судя по последним данным с семинаров 1С Эксперт, 1500 вполне реально.
  
Если исключить РЛС то потянет.

УТ 11 точно потянет http://v8.1c.ru/expert/cts/cts-202-008.htm

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

(347) в 1C ERP и в РСБУ и в МСФО  отложенные движения по планам счетов, жить без них можно хоть весь квартал

(348) а потом тормознуть всю отгрузку, когда бухи захотят перезакрыть этот квартал?

к тому же бюджетирование, МСФО, консолидация и прочие высокоабстрактные вещи - это не оперативная работа купи-продайцв, час простоя которой в масштабе всей страны обойдется очень дорого...

Вообще исходя из опыта работы в одной транспортной компании, филиалы которой есть по всей России, напрашивается такая архитектура (конфигурации имеют второстепенное значение, ибо могут быть самописки):
1. База оперучета (использовалась распределенка, но судя по опыту Enter можно все транзакции проводить в одной базе).
2. Базы регл. учета (по одной на каждое ЮЛ), в которые данные сливаются из базы оперучета.
3. Базы консолидации, МСФО, бюджетирования и т.п. вещей, которые определяются фантазиями фин. директора.

+(351) Вести все виды учета в одной базе для такого огромного холдинга с разными требованиями по оперативности информации - это самоубийство для холдинга...

Я бы мог архитектурурешения для тс набросать.

(353) Она уже должна быть понятна к 353 посту :). Одна база - одно инф.пространство т.е. без распределенки. И на выходе ставится ERP и все вводят данные по расходам и доходам по своим разделителям.

+(354) из затрат - перенос остатков и ... аппаратное обеспечение . А с вендора 1С гарантии что функционал коробки   будет приемлемо дышать.

1сные акулы рвут друг-друга за 30 мультов

(356) Они говорят что кризиса нет, а с другой стороны говорят : выбери Меня!

почитал... те, кто самостоятельно зарабатывают на жизнь, пытаются адекватно оценить требования и сформулировать предложения..
те, кто "кормятся" - ржунемогуделают.
и, немало Маньяков((...
зы.. автору бы последовательности пожелал.. то он выбрал платформу, то он будет выбирать...

(356) ух... отправил сообщение, потом почитал пост... да, так и есть... как проститутки...

(359) Оу!

(356) Ну а почему бы и не порвать, на 1,5к пользаков 30 мультов выглядят оптимистично

(361) слишком оптимистично. Сюда надо как минимум двухсоттысячников, да не одного, а пяток минимум. Т.е. получается что если они год проработают то только они 12 миллионов получат, считали что ПО надо купить на 8, что то с серверами это еще 10. получается что франч будет работать исключительно за портфолио внедрятеля.

(362) а потом, уже за свой счет, исправлять косяки :)

(363) Если франч крупный, то он либо будет пытаться увеличить бюджет, что бы реализовать все в полном объеме, либо уменьшит объем работ, либо изменит архитектуру решения, что бы хватило денег. Никто не будет работать себе в убыток.

(359) устроили тут из топа панель, понимаешь ли... ))

(364)
> Никто не будет работать себе в убыток
твои слова, да на hh бы в банер

(386) ну почему же. Если прибыль по другим проектам покрывает затраты, то могут.

(364) работать будут пока результата не достигнут, ну или неустойку не заплатят ;)

(368) Дааааааа. Неустойка это здорово. В общем тогда ждем на мисте темы:
1. Ура квартира в Москве! - в случае удачи.
2. Черт, я продал почку ((((( ! - тут вопросов нет, и так все понятно.

И только тот, кому нечего сказать, громче всех кричит...

предлагаю такой вариант (для критики)

ЕРП без изменений, в режиме автоматического обновления, в ней ведется регламентируемый учет (бух, зп, производство), все бизнес процессы в ней упрощены или откючены, детализация аналитик - укрупнена.

ЕРП заточенная под под оперативный учет и финансовую отчетность (управленка), в ней колбасим все под себя, обновляем редко, в ней всякие согласования бюджетов, заявок, и другая полная детализация...

между ними обмен...

плюсы
1. однотипные данные
2. устойчивость оперативной базы от регламентированной базы и наоборот
3. уменьшаем взаимные блокировки, разделяем работу персонала на условный фронт и бек...
3. отделение

(371) Предварительно склоняюсь примерно к такому варианту, только вместо оперативной ЕРП дописанная УТ.
Получается:
Бек-офис - ЕРП  
Фронт-офис - УТ

Остается вопрос в чем вести бухучет и HR в филиалах.
Как вариант, оставить БП + ЗУП и сделать обмены с ЕРП.

даже если у филиалах отдельные КПП все равно учет лучше вести в центральной и единой базе

(176) франч заинтересован в прибыли. А главная статья затрат это з/п. У кого она больше у студента или спеца?
Если меня спрашивают куда обратиться, то говорю в такую-то фирму где работают такие-то люди

(373) В единой не хорошо с точки зрения проверок и разделения доступов. И придется задействовать рлс, а это заведомо тормоза.

(375)в единой все хорошо с точки зрения НСИ

(376) Для НСИ ЕРП будет мастер-базой.

(375) там все нормально, учет по выделенным подразделениям рулит, ничего дорабатывать не нужно вообще...

и будет единый контроль для аудиторов и т.д.

(377) сейчас я бы мастербазу делал на внешнем хранилище.

(378) Не уверен, что все нормально там. ОС, например, скорее всего не делятся по подразделениям.

(378) Монстрообразная система имеет свои плюсы из за единой базы.
Но дальше начинаются одни минусы:
- сложнее обслуживать;
- ниже отказоустойчивость;
- теряется возможность автономной работы в отсутствие связи;

(381) ггг, а в случае раздельной - отсутствует возможность работать вообще :)))

(382) Аргументы есть в пользу "отсутствует возможность работать вообще". Или это очередной троллинг и ясновидение?

(383) в одной базе - решаем проблемы со связью.
много - обмен,нси и те же проблемы со связью.

(383) для отказоустойчивости делай РИБ с 15 минутной репликацией, но база все равно единая :)

как только ты сделаешь отдельные конфиги в филиалах - ты потеряешь контроль...

(381)
"- сложнее обслуживать;
- ниже отказоустойчивость;
- теряется возможность автономной работы в отсутствие связи;"

По сути - это все технические проблемы, которые должен решать ИТ отдел и которые принципиально решаемы.  


А решение основное задачи инвестора
- Оперативность в получение данных
Мне кажется более важным требованием.

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

Вопрос приоритетов.
Что важнее
Требование инвестора или стоимость решения технических проблем в случае единой базы.

(386) ага, при таком народонаселении наверняка на связь расходы оло-ло-ло.

опсос свою вышку поставит, если надо :)

(387) А если канал во Владивостоке через спутник с временем отклика 0,5 секунды? ;)

(388) протянут оптику до ближайшего провайдера с хорошим каналом :)

до ростелекома, например.

То (0) Ладно, раз уж так интересно. Отвечу по существу.
Все возможно. Для помощи в реализации этих целей возможно использовать следующие продукты.
DB Cluster
http://www.softpoint.ru/data-cluster-basi-dannih-sql-server
DATA EXCHANGE
http://bimsis.ru/solutions/programmnyy-kompleks-sod/
DB REPLICATION
http://repltech.ru/reshenia/replikatsiya-informatsionnykh-baz/
PERFEXPERT
http://www.softpoint.ru/perfexpert-administrirovanie-serverov
RESOURCE MANAGER
http://www.softpoint.ru/resource-manager
и
http://www.softpointplus.ru/bazi-dannih-sql/851.html

(391) сумму ИТОГО забыл написать :)

(371) Дима, ты в облака уже реально ушел.

>>плюсы
1. однотипные данные
--все---

2. устойчивость оперативной базы от регламентированной базы и наоборот <-- Если людям функционала УТ МНОГО, зачем нужна ERP, если в ней все отключено? Чтобы сдавать регл.отчетность? Какой в этом смысл и почему это нельзя делать в классике КОРПе? Ты сам пробовал, то что пишешь? Вот-это-все в виде оффлайновых проводок, оффлайновых допроведений и т.д.?

3. уменьшаем взаимные блокировки, разделяем работу персонала на условный фронт и бек... <-- это вообще пять баллов. Сначала запустить полтоrашку пользователей в единую базу, а потом бороться с блокировками. Это просто праздник какой-то.


3. отделение <--WTF?

По теме распределенок: как я уже писал, участвовал в проекте по внедрению УКХ на овер 50 дочерних узлов с одним "консолидирующим" единым. Весь затык был в оптимизации обмена, а именно в таблице регистрации изменений. И ничего, вопрос решился. А все вопросы, касаемо НСИ и прав - описались регламентами и правами. Все обмены были настроены онлайн. Допустимой считалось оперативное получение данных 12-ти часовой давности (если что-то где-то отвалилось и обмен не произошел). В бошке работало всего около 30 пользователей - бухгалтера, финансисты центрального аппарата. После решения проблем с обменом - вообще никаких проблем с параллельностью работы не наблюдалось, т.к. им не откуда было просто взяться. Все это крутилось на хорошем сервере.

(386) Приоритет конечно требование инвестора. При указанной архитектуре оперативность повысится за счет использования единой платформы.
(389) В этом плане у нас Камчатка выпадает. Там действительно 0,5 сек через спутник.
(391) Вполне можем у себя внедрить эти продукты при выборе 1С.
(393) Сейчас архитектура обменов в используемых продуктах 1С нами так и организована. Из узлов передается в центр. Вопрос регистрации изменений решен частично с использованием доп. обработок, частично организационными мероприятиями.
Кстати, типовой план обмена "По организациям" без допиливания нормально не работает.

(394) и насколько оперативно при существующей схеме обмена можно в центре получить всю необходимую кому-то информацию?

(395) По-разному.
Часть софта у нас работает через терминал - т.е. данные могут быть получены практически с любой периодичностью.
В базах, которые работают без терминалов обмены делаются 3 раза в день. Оперативнее пока не требуют.

(394) Все продукты работают независимо от 1С с другими платформами. Другое дело что имеют с ней интеграцию.
Насчет камчатки, вполне можно реализовать онлайн обмен(секунды). При огромных объемах обмена максимальная скорость обеспечивается за счет - параллелизма(там уж насколько оборудования хватит и каналов связи), минимальных издержек на применение изменений(например балк инсерты),минимального воздействия на источник изменений. Впрочем это лучше посмотреть вживую.

+(397) Забыл сказать. 1С или нет это не важно.Единственное ограничение-пока что все работает только на MSSQL.

(398) Тоже склоняюсь к выбору MS SQL с ним и опыт работы есть и он гораздо дешевле Oracle.

(397) Это да, дело времени, будет возможность потренироваться с внедрением ваших продуктов сначала на ближних филиалах, затем распространить на дальние.

(0)
обращайтесь к вендору - то бишь в 1С.... Там вам предоставят парнёров с соответствующими компетенциями

проект серьезный по всем показателям - поддержкой 1С (ЦКТП или просто аудит какой) я бы не пренебрегал

1С проконтролирует, нагрузочное тестирование организует, консультации, саппорт по всяким низкоуровневым серверным настройкам и тому подобное

(от себя скажу - мы интеграторы с уклоном в "тяжелые" интеграции, можем помочь со всякими шинами, типа IBM WebSphere и т.п.. Возможно, имеет смысл выстраивать интеграционную платформу, движок интеграции на чем-то более суровом и надежном, чем 1С... Message Broker к примеру)

Смешно читать всевозможные предложения для фронт-офисной части на 1500 пользователей и 100000 документов в день на базе ERP.
Вопрос даже не в том, есть в этом мире волшебство, вопрос а нафига?

+(402) "есть ли"

(401) Примерно то же самое я сообщил автору в (106). А он продолжает слушать мнения. Много пустого.

А производство у вас есть, или чистая дистрибуция?
Если 2-е, то идея с бэк и фронтом не лишена оснований.

(404) C 1C взаимодействие, так же выше писал.
А мнения никогда не помешают.
(405) Чистая дистрибуция.

+ (406) "С 1С начали взаимодействие по этому вопросу"

(406) К чему попытка заочно установить диагноз? Пусть отдастся- ему докажут как выглядит его счастье.
(407) Удачи

(408) Это не диагноз, а скорее творческий поиск )

Работал по задачам франча для транспортной конторы, в которой было чота около 1000 пользователей. Но это был не проект, а постоянная многолетняя разработка, ибо на фронте и для упр. учета были самописки. Архитектуру приводил уже в этой ветке. Подход как к проекту ошибочен.

Где бы найти такой же проектик, тока с производством

(411) а зачем? заводы-фабрики на 30-60 р.м. наше всё...

запиливаю такие заводики с 2008 года, соваться в большие материии никакого желания нет...

(412) Неинтересны такие, хочется сложные тех процессы десятка 2-3 переделов, чтобы всё было типа литья, аскроя и прочего

Про ЦКТП уже было?
http://v8.1c.ru/expert/cts/cts.htm

(415) Конечно, наличие статуса ЦТКП будет плюсом при выборе интегратора. Но на практике сертификация и реальный опыт прошлых внедрений разные вещи. Поэтому успешно завершенные аналогичные проекты для нас гораздо весомее наличия статуса ЦКТП.

ТС, главное не теряйся держи нас в  курсе

1500 юзеров в одной базе весело
главное разнообразную бухию отдельно (но это уже тут читал) - остальное есть в УТ (РИБ или единая база уже пусть бизнес решает)

(418) Это тяжело. Работать в одной базе 1500 человек одновременно, даже справочник прочитать будет сложно. А про ввод данных тем более.
А вот закачивать документы и потом проводить данные по регистрам  в фоне вполне реально.

(419) В оракле значит норм, а в 1С тяжело ;-)

(420) Просто я не вижу необходимости в оперативном учете. Заявки собрать и передать можно 1 раз в день. А затраты так вобще раз в неделю. Привязался к курсу У.Е. +5% и торгуй.

Вбухать 50 млн, ради ежеминутного отражения заказов и продаж. (-Не верю!)

а у кого-то регистрируется 6 договоров в секунду ;-)

(420)  а разве нет необходимости ,например, уже на этапе ввода заявки завести того же контр агента один раз ? Т.e одна таблица контр агентов и одна ссылка в дальнейших сущностях.

А не путешествовать в распределение с трансформации ей в 10 Ивановых или хуже - Иванова в петрова

Или кассовые разрывы есть, или большая сумма в обороте висит.

Зачем главному дистрибьютору знать про ивановых в Кижме, Комсомольске на Амуре и владимире? Ему важно знать сколько купили и сколько своровали.

(427) можно и екаешь по почте гонять с таким подходом и в агрегатах со цветом

Т.e  excel

Скорее всего пока так и есть. Правда финрезультат получают через 10 дней спустя. А хотят ежедневно.