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

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

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

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

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

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

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

работает - не трожь
разные базы - меньше гемора

Компания ведет бухию на аутсорсе что ли?

без требований, текущей ситауции и целей - ни о чем

(0) сделай голосовалку... вариант №3 , все остальное в топку.

недостаточно данных

мой выбор

Нельзя лишать людей, включая программистов, их работы

Без вариантов

(6) в 1С-облаке :)

"крупной фирме" нужно быть честной и прозрачной

Спасибо откликнувшимся!

Комания централизует бухгалтерскую функцию (что то наподобие внутреннего аутсорсинга).

Хотелось бы услышать некоторую аргументацию мнений, если возможно. Может кто то подскажет ссылки на статьи, обсуждения по этой теме?

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

(10) Крутая компания с множеством юрлиц вполне может заказать себе профессиональный консалтинг, а не побираться по форумам

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

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

Не иначе как кто-то реферат или курсач пишет.

(15) что поделать сроки то горят...

(12) Знаем мы этих профессионалов. Аудиторы из большой тройки спрашивают как оборотка по счету строится.
(14) Поддержка руководства это одно, а вот когда дочки начнут разбегаться... :) Руководство за голову конечно схватится, но будет поздно. Ну да это все от отношений внутри холдинга зависит. В общем - Удачи!

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

(18) 1) Речь о бухгалтериии и документообороте
     2) Холдинг реальный. У каждой компании свой коллектив, и у каждой была своя бухгалтерия, теперь же именно бухгалтерию делаем общую для всех.

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

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

Если нет проблем с производительностью и речь идет о единообразном учете в ГК - то 3. Если есть изыски сугубо индивидуальные для ряда компаний - то вполне возможен вариант 1. Вариант 2 тоже жизнеспособен при высокой нагрузке.

Мало информации )

(19) Тогда вариант 3 вам скорее всего не нужен, т.к.
достоинства единой базы - возможность вести единые справочники НСИ и сквозной документооборот для поддержки сквозных бизнес-процессов. А вам оно похоже банально не зачем.
Недостатки единой базы - возникают проблемы при включении в холдинг новых компаний и исключении старых. При возникновении многих классов технических проблем - они сразу у всех. Больше проблем с производительностью. Если холдинг - территориально распределенный (а Вы говорите что компании не сидят в одном здании), значит возникают высокие требования к каналам связи.

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

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

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

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

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

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

(25) Вам нужно срочно отказаться от динамического обновления

(26) это невозможно при активных доработках. Ошибки находят каждый день и 1-2 из них не позволяют продолжить работу. Хорошо хоть динамическое обновление есть, на 8.0 вообще трындец был.

(27) Вы косячники. Прекратите портить базы

(28) нам за это платят :)

и вообще "от косячника слышу"

(19) рассмотреть + и - варианта 1 база но распределенка (РИБ)

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

затем для каждой компании/филиала свой узел, со своими правилами миграции (т.е. к примеру документа продажи другой своей фирме уходит в центр и оттуда автоматом приходит документа поступления товара куда нужно)

допиливать и обновлять проще, но начальная работа по кодингу и настройке сложнее

(31)+ сорри это совмещение вариантов

(31)+ и

(0) Если корпоративная структура развитая, и финансовая дисциплина высокая, то лучше вести учёт в одной базе данных.
Аргументы:
1. Единообразная структура справочников экономит время операторов из-за однократного ввода объектов в справочники.
2. Проще отслеживать расчёты intercompany.
3. Легче исправлять единообразные ошибки.
4. Проще разрабатывать учётные политики.
5. Обновлять одну конфигурацию быстрее, чем несколько.
6. Проше организовать централизованный надзор и контроль.

Присоединюсь к мнению что финансовая дисциплина и единообразие в заполнение НСИ первично
Я вот вижу много неудобств если связать, например строительную контору и торговую

(24) С пользователями какраз проблем нет особых, это легко автоматизируется...

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

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

(35) +1
>Я вот вижу много неудобств если связать, например строительную контору и торговую

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

(7) Соглашусь с ответом, но не соглашусь с аргументацией

Мы тоже столкнулись с решением данного вопроса.
+ Уникальные спраочники - нет дублей. Единая структура НСИ, единые управленческие справочники. Есть возможность строить консолидированную отчетность по группе предприятий. Меньше мусора в базе данных, обновления и доработки проще.
- Разделение прав по организация между пользователями, больше требование к безопасности, больше объемы базы/архива.

Но безусловно - если холдинг - то единая база.

3. Единая конфигурация и единая база данных
При любом ином варианте:
- Рост компании ограничен из-за
- Управление ИТ-инфраструктурой непрозрачно

(0)Сколько будет стоить простой всего табора из за косяка в одной кибитке ??

Главное условие - минимум простоев. Это значить независимая работа баз.
============================================================
Вы думаете как облегчить работу себе. Подумайте о хозяине бизнеса.

50 баз, 50! Обменов по риб, куча серверов... Куча геморроя. А все для чего? Чтобы минимизировать косяки криворуких кодеров. Может заменить на пряморуких и тщательнее тестировать?...

(43) я позавидую конторе которая имеет отдельный штат для тестирования.

сначала перевести всех на

по потом на

совмещать эти два процесса не желательно.
Убо ошибки будут не просто суммироваться, а умножаться

http://v8.1c.ru/consolid/или  http://v8.1c.ru/cpm/ +

УРБД и вперед.

.

первое что на ум приходит:
1) 1С система требующая обслуживания в монопольном режиме
2) погуглите "рухнула база 1С"
3) больше баз - меньше потенциальных проблем с производительностью

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

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

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

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

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

(0) есть потребность в интеграции - интергируй. Нет потребности от бизнес-пользователей видеть сводные отчеты по всем организациям - не лезь туда руками.

И это... будешь интегрировать, если, то но не суй всех в одну базу - горя хапнешь.

2 и 3 - точно не жизнеспособные варианты.
Остается - как есть и другое. Выбор шикарен у тебя, автор

(53) (54) Спасибо, поржал

(55) давно это у вас?

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

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

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

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