Архитектура АСУ предприятия

[RZX]

Добрый день!

Хотел посоветоваться по следующему вопросу:

Есть крупное предприятие: производство, оптовая торговля, розница, вторсырье + еще много чего мелкого
Около 40 рабочих мест + удаленные рабочие места подключены к сети.
Есть сетевая (DBF) версия 1С:Бухгалтерия 7.7, настройка "МиСофт", где в данный момент ведется работа, написаны обработки, в общем много чего уже успешно было сделано (правда, там работает 5 бухгалтеров и удаленно ведется торговля с 1-го удаленного рабочего места).

Сервер Intel Xeon 2.0GHz 4G RAM.

Какой вариант дальнейшей автоматизации здесь будет предпочтительнее:

1. Использовать имеющуюся 1С 7.7 в режиме терминального доступа:
   Все вести в 1С 7.7: бухучет, заработная плата, торговля, документооборот (учет документов, приказов, вх/исх. корреспондениции и т.п.)
2. Использовать 1С 7.7 SQL:
   Все вести в 1С 7.7 SQL. Купить SQL-версию 1С 7.7, сам MS SQL Server и дорабатывать и продолжать вести текущую конфигурацию
3. Использовать 1С 8.x:
   Купить 1С v 8, попытаться перенести все данные, наработки и работать в ней в т.ч. документооборот, удаленные рабочие места
4. Использовать имеющуюся 1С 7.7 в режиме терминального доступа и СУБД MySQL со спец. софтом на рабочих местах:
   Бухучет, заработную плату, производство вести в имеющейся 1С. Документооборот, торговлю (выписку накладных и некоторые прочие задачи) возложить на программы C++ на рабочих местах (только необходимые функции) и СУБД MySQL на сервере, организвав только необходимое взаимодействие между MySQL и 1C.

 

[vitfil]

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

 

[RZX]

Сейчас я смотрю на пункты 1 и 4. - по крайней мере доп. затраты нулевые (кроме усилий разработчиков, конечно).

В дальнейшем ожидается увеличение числа пользователей, работающих в 1С.

Меня интересует снижение времени отклика системы в данном случае. Потому что, если будет тормозить, то тормозить будет везде, в т.ч. на отгрузке и удаленных рабочих местах.

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

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

Короче, хез... Пока склоняюсь больше к 4-му варианту.

 

[vitfil]

"Затраты нулевые, кроме усилия разработчиков"

Ваши разработчики за тарелку супа работают или за деньги? Или же стоимость труда разработчиков настолько мала по сравнению с оборотами предприятия, что ее можно не учитывать?

 

[RZX]

Работа разработчиков понадобится в любом из вышеназванных пунктов как ни крути. Причем трудозатраты будут очень похожими.
Отличие в том, что в пуктах 2 и 3 кроме усилий разработчиков необходимо докупать еще продукты (причем весьма недешевые), а в остальных случаях этого не потребуется.

 

[Дайнеко]

Мое мнение таково:
Вариант 1. Если вы остаетесь на платформе 7. Тогда считаю приемлемым только работу в терминале.
По поводу SQL говорю не голословно - мы пытались перенести базу крупного предприятия в SQL.
Результат оказался плачевным: скорость резко упала + необходимость знать и администрировать
SQL-сервер. А гибрид терминала и SQL совсем нелеп.
Вариант 2. Решитесь перейти на 8-ку. Здесь опыта нет, есть надежды на саму платформу. Но прежде чем решится на такой крупный шаг надо найти хоть одно счастливое предприятие, работающее на бухгалтерии 8-ке (внедренной малой кровью).
Рекомендация. Можно думать над разделением работы в двух базах. Отдел продаж в оперативной и бухгалтерия в своей. Только вот задача эскпорта - импорта не примитивная задача.

 

[vitfil]

По поводу SQL говорю не голословно - мы пытались перенести базу крупного предприятия в SQL.
Результат оказался плачевным: скорость резко упала + необходимость знать и администрировать
SQL-сервер.
Может, вы просто не умеете ее готовить? (с)

 

[Hryv]

В этом вопросе немаловажно сколько в итоге будет рабочих мест
Если хотябы больше 10, то первый вариант я бы отбросил сразу
Далее детально сравнил бы варианты 2 и 3 по
<!--QuoteBegin-"vitfil"+-->
<span class="vbquote">("vitfil")</span><!--QuoteEBegin-->двум критериям: наименьшие финансовые затраты (стоит учитывать баланс между внедрением и последующим владением) и наибольшее удовлетворение по функционалу на стадии внедрения.[/quote]

Про вариант 4 затрудняюсь что-то сказать

Доступ через удаленный рабочий стол для удаленных рабочих мест стоит использовать (хотябы опробовать) при любом раскладе