Корпоративные информационные системы

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

Не секрет, что правильная и четкая организация информационных бизнес-решений является слагающим фактором успеха любой компании. Особенно важным этот фактор является для предприятий среднего и малого бизнеса, которым необходима система, которая способна предоставить весь объем бизнес-логики для решения задач компании. В то же время, такие системы для компаний со средним и малым масштабом сетей часто попадают под критерий “цена — качество”, то есть должны обладать максимальной производительностью и надежностью при доступной цене.

Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture) (рис. 3.1).

 

Рисунок 3.1 — Двухуровневая клиент-серверная архитектура

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей — автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых — это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.

Как видим, минусов у такой архитектуры достаточно, а решение тривиально — нужно отделить бизнес-логику от клиентской части и СУБД, выделив ее в отдельный слой. Так и поступили разработчики и следующим шагом развития клиент-серверной архитектуры стало внедрение среднего уровня, реализующего задачи бизнес-логики и управления механизмами доступа к БД (рис. 3.2).

 

Рисунок 3.2 — Трехуровневая клиент-серверная архитектура (Three-tier architecture)

Плюсы данной архитектуры очевидны. Благодаря концентрации бизнес-логики на сервере приложений, стало возможно подключать различные БД. Теперь, сервер базы данных освобожден от задач распараллеливания работы между различными пользователями, что существенно снижает его аппаратные требования. Также снизились требования к клиентским машинам за счет выполнения ресурсоемких операций сервером приложений и решающих теперь только задачи визуализации данных. Именно поэтому такую схему построения информационных систем часто называют архитектурой “тонкого” клиента.

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

Существует еще один важный момент использования систем, построенных на такой архитектуре. Самый верхний уровень (АРМы), в целом обладающий огромной вычислительной мощностью, на самом деле простаивает, занимаясь лишь выводом информации на экран пользователя. Так почему бы не использовать этот потенциал в работе всей системы? Рассмотрим следующую архитектуру(Рис. 3.3) которая позволяет решить эту задачу.

Рисунок 3.3 — Распределенная архитектура системы

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

Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизиться. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.

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

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

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

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

 

Примеры КИС

 

Система «Парус»

 

Корпоративная информационная система ПАРУС построена как комплексная система автоматизации управления. Состав приложений (модулей) КИС ПАРУС и их функциональное объединение в подсистемы обусловлено объективным наличием четырех основных бизнес- направлений деятельности предприятия:

— Управление финансами;

— Маркетинг и логистика;

— Управление производством;

— Управление персоналом.

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

Логистика имеет несколько функциональных областей или, другими словами, имеется несколько видов логистики: закупочная, запасов и сбытовая. Соответственно, в логистической цепи, то есть пути, по которому проходят товарный и информационный потоки от поставщика до потребителя, выделяются следующие главные звенья: закупка товаров, их хранение и реализация.

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

— суммы по графику — формируются на основании графиков поступления/отпуска товаров и платежей по лицевому счету. Эти суммы отражают заранее оговоренные и согласованные с контрагентом объемы и периоды поступления/отпуска товаров и осуществления платежей;

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

— фактические суммы — на основании фактических товарных документов (накладных на отпуск товаров, фактических приходных ордеров и т.п.) и фактических платежей.

Исходные данные лицевого счета формируются вручную или на основании этапа договора.

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

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

—         Базовая модель с фиксированным размером заказа;

—         Базовая модель с фиксированным интервалом времени между заказами;

—         Модифицированная модель с установленной периодичностью пополнения заказов до определенного уровня;

—         Модифицированная модель с условным названием «минимум-максимум».

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

девятнадцать − двенадцать =