5. Проблемы крупных предприятий. Транзакция. Промышленная субд. Репликация данных. Авторизация данных.

Если предприятие действительно крупное, то оно имеет распределенную структуру. То есть в его состав входят филиалы или подразделения, расположенные на других территориях или даже в других городах. В связи с такой территориальной распределенностью подразделений возникают следующие проблемы:

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

Повторный ввод данных. Чтобы обеспечить полноту используемых данных, приходится осуществлять повторный ввод данных в центральном офисе. Если удаленные склады или филиалы – это необходимо для обеспечения единых бухгалтерских данных, если удаленные юридические лица – для того, чтобы получить общую картину по корпорации.

Задержка в получении данных, их повторный ввод, путаница с порядком учета в результате приводят к потере оперативности управления. Для решения этих проблем, используются разные технические решения:

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

Единая база, удаленный доступ к данным. Подход, унаследованный еще от mainframe – структур предполагает наличие одной большой центральной базы данных, с которой работают все пользователи в реальном масштабе времени. На современных технологиях – это web-доступ. Однако подразумевается, что у каждого есть постоянная связь с центральной машиной. Увы, в современных российских условиях это не всегда проходит. В случае разрыва линии терминал на складе зависает и вся работа останавливается.

Репликация – Восстановление идентичности баз данных. При синхронной репликации все назначения должны быть доступны одновременно. При асинхронной – необязательно.

Встроенная репликация на уровне таблиц. Данный механизм в том или ином виде реализован практически во всех промышленных СУБД (Oracle, MS SQL, Progress, Ingres, Sybase,…). Означает он, как правило, автоматическое выравнивание на уровне таблиц баз данных. В простейшем случае – просто поддержание зеркальных слепков в одну сторону. Более сложные механизмы предполагают обмен данными на уровне записей таблиц. Ранее использовался механизм так называемой синхронной репликации, когда для гарантированного обмена данных необходимо было одновременное подключение всех задействованных серверов, что явно является нереальным для большой организации при существующих условиях связи. Позднее появились более гибкие возможности, реализующие асинхронную репликацию данных. При этом одновременное подключение всех серверов не требуется, однако любые изменения в настройках по-прежнему требуют весьма квалифицированных работ программистов фирмы – разработчика.

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

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

Этот механизм позволяет пользователям таких крупных торгово-производственных фирм, как ЭТМ (Санкт-Петербург) работать в следующем режиме: днем в течение получаса до 10-20 удаленных площадок оперативно доходят изменения цен и информация о поставках, а в ночное время обратно передается вся информация о результатах работы за день. Наутро в центральном офисе уже есть все данные о работе фирмы, вплоть до первичных документов. При этом, например, в Перми использовались три разных способа доставки данных, исходя из расценок на передачу: по городу – дозвон по модемам напрямую, по области – местная электронная почта, по стране – Relcom.

В качестве примера решения методических проблем можно привести предприятие Лукойл-Бурение, где внедрение системы проводилось одновременно с переводом на единый план счетов, что позволило создать единые типовые операции. Сотрудниками предприятия был также разработан единый классификатор номенклатуры, который используется на всех трех юридически и территориально независимых организациях, охваченных автоматизацией (1 предприятие в Самаре и 2 предприятия в Когалыме).

Похожий принцип использует система ведения НСИ ДИП (ИКТ), системы документооборота на базе Lotus Domino.

При расширении спектра продукции и услуг бизнес сталкивается с новыми проблемами, связанными с большим объемом информации. Например, следующие.

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

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

Вероятность сбоев. Еще одна беда многих администраторов больших систем – в том, что с повышением объема операций увеличивается и вероятность сбоев. Причиной могут быть как чисто технические, так и нерегламентированные действия пользователей, которые заранее нельзя ни предвидеть, ни предотвратить. Наиболее вырожденный случай можно было наблюдать в одном из банков, где в 2 одинаковых комнатах сидели по 10 человек. В одной – девушки – операционистки, которые выполняли обычную банковскую работу. А вот 10 юношей в другой комнате – следили за тем, чтобы не рушились индексы у общей базы. И как только это происходило, тут же запускали процедуры пересчета и восстановления индексов.

Часто предлагаются следующие решения.

Замена аппаратуры. В результате сервер имеет еще больше памяти, сеть работает еще быстрее, и действительно, характеристики не ухудшаются после вхождения 5-го пользователя. 10-й по счету сотрудник, правда, как не мог войти, так и не может.

Средства защиты. В организации «Сантехкомплект» после многократных проблем к каждому компьютеру пользователя был закуплено устройство бесперебойного питания (UPS). Однако случайных выходов из системы по вине пользователя это не предотвратило.

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

«Транзакция – это набор операций, обычно человеко-машинных, который либо

выполняется целиком, либо не выполняется вообще.»

Корпоративные информационные системы. Бизнес-требования

Если же говорить о сложности администрирования, то на предприятии, входящем в структуру Мегионнефтегаз, в течение нескольких лет систему поддерживал сотрудник, в чьи обязанности входило только знать как сервер включается утром и как выключается вечером. В период, когда из строя вышел блок UPS, многочисленные сбои в электропитании приводили лишь к необходимости пользователям подождать окончания перезагрузки сервера. Дальше можно было продолжать с того же самого документа, который вводился последним.