Здравствуйте, уважаемые форумчане!

Хотел услышать Ваше мнение вот по какой ситуации:

Компания в данный момент имеет много различных конфигураций системы 1С у разных юрлиц. Каждое юрлицо ведет учет в своей собственной базе. В итоге получается много систем и много баз данных не интегрированных между собой.

Внимание вопрос:

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

Иными словами,вопрос заключается в том, по какому пути (и какие у этого пути за и против)стоит идти при организации ИТ-архитектуры:
1.    Много конфигураций и много баз
2.    Единая конфигурация и много баз под каждое юрлицо, но с возможностью интеграции баз друг с другом
3.    Единая конфигурация и единая база данных для всех юрлиц.

Надеюсь услышать ваши соображения.

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

(0) если почитать, то вот:
Завершен крупнейший проект по внедрению «1С: Предприятия» - КАМАЗ

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

Скажу за торговую команию. Нужен баланс. Когда каждое юр. лицо в своей базе и их около 50, с учетом того что конфа одинаковая но на каждое юр. лицо приходится как правило 1 торговая + 1 бухия (я не говорю про множество сопутствующих мелких баз) то возникают проблеммы следующего харатера:
- при активной разработке проблема с обновлением - временной ресурс. Не напоминайте мне про автоматизацию этого процесса - при динамическом внесении правок в рабочие базы автообновление не работает.
- неимоверное количество обменов. Примерно пропорционально количеству баз.
- нашли критичную ошибку? обновите ка 50 баз динамически.

С объединеним баз в одну другие сложности. Если пользователи разбиты по юрикам/базам 200-300 то нагрузка одного "юрика" не нарушает работу других. Падение одного филиала это просто всего лишь одного филиала. Когда одна база на 1000-2000 пользователей то даже с учетом кластеризации любая неосторожная строчка кода введет в ступор работу всей компании.

Вот както так, по моим наблюдениям.

если компания готова вести учет по рекомендациям аудиторов - то одна база...

если компания декларирует свою "уникальность" то регламентированные (бух, зуп) базы (максимально типовые) отдельно от переписанной в пух и прах УТ (УПП и т.д.)

.

(0) > Какие существуют преимущества и недостатки

По каждому из предложенных вариантов все преимущества и недостатки давным давно известны и уже многократно обсуждались.

> по какому пути ... стоит идти?

По тому, которое укажет руководство (владельцы/топменеджмент). Без знания их потребностей (насущных и предполагаемых в будущем) все разговоры на эту тему - чистой воды флуд. Чтобы можно было хоть сколько-нибудь серьезно обсуждать вопрос, надо знать, как минимум:
- структуру компании (под словосочетанием "много юрлиц" может скрываться что угодно, начиная от фактически одной фирмы, которая имеет кучу помоечных юрлиц, и заканчивая структурами типа Газпрома или РЖД)
- сферу(ы) деятельности (производство, торговля, услуги или всего по-немножку)
- размеры компании;
- объемы ИТ-инфраструктуры (количество пользователей, количество отдельных баз, приблизительный документооборот);
- территориальная распределенность (здание/город/регион/страна/мир);
- автоматизируемые разделы учета (только БУ, только УУ, БУ+НУ+УУ, расчет з/п, что-либо еще)
- и т.д.

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

1. Самый простой и наименее требовательный к квалификации как ИТ специалистов, так и к квалификации  конечных пользователей. Для консолидации достаточно утвержденного справочника затрат и выделения аффилированных лиц в справочнике контрагенты. А дальше Excel наш друг.
2. Теоретически облегчает жизнь ИТ отделу в процессе обновления, но на практике требует от них высокой квалификации в части управления совместной работой. Помимо ИТ специалистов, требуется грамотный отдел методологии и крайне желателен отдел тестирования - в противном случае вместо облегчения жизни программистов будет требоваться больше трудозатрат. Да единая конфигурация для всех может быть только УПП/ЕРП - а это еще и высокие требования к квалификации пользователей в том числе.
3. В принципе большинство недостатков 2 го варианта здесь отсекаются - но могут качественно вырасти требования к аппаратному обеспечению - ибо 10 баз по 10 гигабайт и по 50 пользователей - и 1 база на 100 гигабайт и 500 пользователей - это две большие разницы.
Кроме того - по идее третий вариант требует большего количества лицензий так как все пользователи одновременно работают в одной базе. Ну и если пару-тройку компаний из базы захотят продать - то могут возникнуть разного рода сложности с передачей данных по одной из компаний из общей базы.

В общем 3-й вариант кончено обладает многими достоинствами - но цена этого решения ощутимо выше.
2 вариант как любой универсальный вариант - ни то ни се. Трудозатрат много - а выхлоп далеко не гарантирован.

Недостаточно данных для ответа.
Как писали выше - нужен анализ деятельности этих фирм.

Сначала нужно делать обследование, а потом будет и решение. Этот вопрос "пальцем в носу" не решается. Кто заказчик проекта и что желает получить. Согласен с (58).