Интегрированные информационные системы. Практикум

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

На российском рынке наиболее популярны СУБД Progress (Progress software), Oracle RDBMS v7 (Oracle), Microsoft SQL Server v6.5 (Microsoft), DB2 (IBM), Sybase System 11 (Sybase);

использование существующих ресурсов. От эффективности ис-

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

наличие системы защиты информации. Безопасность данных яв-

ляется одним из главных требований к ИСУП. Должна быть предусмотрена как устойчивость работы при неправильных действиях персонала, так и специализированные системы защиты от преднамеренного взлома ИСУП с корыстными или иными целями. На сегодняшний день безопасность ИСУП так важна, что мы рассмотрим этот вопрос подробнее. Система защиты и безопасности информации в ИСУП предполагает наличие:

•  средств физического ограничения доступа к компьютерам ИСУП (идентификационные карточки, съемные блокирующие устройства и т.п.);

•  полномочий, привилегий и прав доступа к ИСУП на уровне отдельного пользователя (сотрудника или клиента предприятия);

•  средств централизованного обнаружения несанкционированных попыток проникнуть к ресурсам ИСУП, дающих возможность своевременно принять соответствующие меры;

•  защиты данных при их передаче по каналам связи (особенно актуально при использовании открытых каналов связи, например сети Internet). Здесь возможно использование «цифровой электронной подписи» и других криптографических методов;

31

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

•  средств восстановления при сбоях. В ИСУП должны быть предусмотрены средства для прогноза, фиксации и локализации различных нештатных ситуаций и отказов оборудования (таких как повреждения и перегрузки каналов связи; перегрузки устройств внешней памяти; нарушение целостности БД; попытки несанкционированного доступа в систему и т.д.);

•  возможности адаптации. Система должна быть адаптируемой к изменениям финансового законодательства или структуры предприятия и другим событиям. Более того, система должна иметь возможность адаптации именно силами работников предприятия. Выбор более популярной СУБД также учитывает фактор того, что программист такой СУБД как Progress «стоил» в два или три раза дороже, чем программист MS SQL;

•  возможности работы в режиме реального времени. В настоящее время системы типа OLTP (Online Transaction Processing) становят-

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

Вопросы для самоконтроля

1.Какие критерии необходимо использовать при оптимизации интегрированной системы?

2.Опишите основные отличия технологии «клиент-сервер» и технологией «файл-сервер».

3.Охарактеризуйте направления развития технологий «клиентсервер» в настоящее время.

4.Перечислите основные требования к СУБД.

5.Перечислите наиболее популярные СУБД на российском рынке на сегодняшний день.

32

6.Какие факторы влияют на стоимость интегрированной системы?

7.Перечислите основные компоненты системы защиты и безопасности информации в ИСУП.

8.Какую роль играют системы типа OLTPпри создании ИСУП?

Тест 4

Из предложенных вам ответов на данный вопрос выберите правильный.

3.1. Как обеспечивается интеллектуальный доступ к информации? а) С помощью организации логической обработки информации в

системах баз знаний.

б) С помощью специального программного обеспечения.

в) Благодаря наличию развитой системы отображения информации.

г) Благодаря применению совершенных технических средств.

3.2.Почему при создании ИСУП важно обеспечить максимальное использование существующих ресурсов?

а) Чтобы не допустить простоя имеющегося оборудования. б) Для минимизации финансовых затрат на создание ИСУП.

в) Чтобы ввести в заблуждение конкурентов относительно действительных финансовых возможностей компании, внедряющей ИСУП.

г) С целью повышения эффективности использования имеющегося оборудования.

3.3.Для чего нужна система защиты информации?

а) Для отпугивания злоумышленников, пытающихся воспользоваться конфиденциальной информацией.

б) Чтобы устранить возможность несанкционированного доступа к хранящейся в БД информации.

в) Чтобы информационные файлы не стерли злоумышленники. г) Чтобы избежать финансовых потерь при несанкционированных

доступах к хранящейся в базах данных информации.

3.4. Что является самой главной задачей компьютерного департамента предприятия?

а) Разработка ИСУП.

б) Подбор высококвалифицированных специалистов в области ИСУП.

в) Оценка эффективности ИСУП.

33

г) Самой главной задачей компьютерного департамента предприятия является выбор наилучшего решения из предлагаемых на рынке вариантов ИСУП или выбор стратегии разработки или модернизации существующей ИСУП.

3.5. Что понимается под возможностью масштабирования продукта?

а) Возможность наращивания объема оперативной памяти.

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

в) Возможность использования в компьютерных системах аппаратных средств от разных производителей.

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

34

5. ОБЗОР ИНТЕГРИРОВАННЫХ СИСТЕМ НА РОССИЙСКОМ РЫНКЕ

5.1. Исследование российских интегрированных систем

После первоначального отбора среди десятка российских систем корпоративная система «Галактика» (корпорация «Галактика»), корпоративная система «Парус» (корпорация «Парус») и система NS2000 (компания Никос-Софт) были отобраны для более глубокого ознакомления.

На протяжении года прошло ознакомление с материалами данных компаний, было сделано множество посещений как в офисы компаний, так и в компании, где система была внедрена (по мере предоставления такой возможности компаниями-производителями программ).

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

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

35

5.2. История развития корпорации и системы «Галактика»

Первоначально система «Галактика» создавалась коллективом разработчиков Института теоретической кибернетики г. Минска (в настоящее время ТОП СОФТ г. Минск). В 1984−1985 годах данным коллективом была разработана библиотека, расширяющая возможности BTRIEVE (NOVELL) по манипуляции с данными (BTRIEVE − это фактически не СУБД, а библиотека примитивов для работы с индексно-последовательными файлами в режиме клиент-сервер под NOVELL). Данная разработка была громко названа СУБД «Атлант». Одновременно был разработан язык, подобный 4GL, который позволял более или менее быстро разрабатывать прикладные программы (формы, меню, отчеты) для работы с данным СУБД. Это ПО и было положено в качестве базового системного ПО будущей системы и используется до сих пор.

В1986 г. были написаны первые заказные модули (Сбыт, Склад)

ипод этот проект была создана фирма «Новый атлант» в г. Москве. Основными задачами этой фирмы были поиск новых заказов и разработка прикладных программ. Данное разделение направлений деятельности сохраняется в корпорации до сих пор.

Фирма «Новый атлант» и дочерние фирмы (представительства в регионах и сервисные организации) занимаются разработкой самой системы и сбытом, а ТОП СОФТ – разработкой системного ПО. Единого плана разработки системы «Галактика» не было. Система разрабатывалась помодульно, под заказ. Как сказал президент корпорации Д. Черных: «При разработке мы отталкиваемся от потребностей заказчика» (на самом деле сиюминутных потребностей). В результате к 1993 г. набралось достаточно много модулей, и фирма «Новый атлант» заявила о существование интегрированной системы «Галактика». Естественно, что некоторые модули сначала разрабатывались, потом, при изменении экономической ситуации «забывались», а затем «всплывали» снова. Так было с модулями, связанными с планированием и управлением производством. В 1980-х годах это были зачаточные реализации модулей планирования и калькуляции плановой себестоимости, реализованные под заказ машиностроительных заводов (скорее одного завода). Когда машиностроительные заводы стали недееспособны, об этих модулях забыли. В 1996−1998 годах начались разговоры об ERP-MRP системах и об этих модулях вспомнили. Од-

36

нако никто их не собирался и не собирается развивать и дорабатывать до реально необходимой функциональности. С тех пор базовая функциональность системы практически не изменилась. Развитие шло по линии совершенствования каналов сбыта, сервиса и совершенствования структуры самой корпорации, а также переводу системы на новые платформы (Windows, новые СУБД). Во всех этих направлениях были достигнуты определенные успехи.

5.3. Функциональные особенности архитектуры системы «Галактика»

Как было сказано выше, система развивалась без единого плана, под заказ и результатом такого проектирования и разработки стало следующее:

––системасостоитизнабораслабосвязанныхмеждусобоймодулей;

––модули реализуют, в первую очередь, функции учета конкретных внешних документов (приходных ордеров, счетов-фактур, складских документов и т.д.);

––не существует управляющих или автоматически генерируемых документов.

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

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

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

ахозяйственные операции − сами по себе.

37

Какой-либо единой базовой технологии обработки документов

(типа FLEXBUILDER, WORKFLOW или ACCOUNT ENGINE) не су-

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

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

5.4. Технологические особенности архитектуры системы «Галактика»

Система сначала была реализована в архитектуре клиент-сервер и остается такой же в настоящее время.

Реализация прикладного ПО на языке высокого уровня теоретически позволяло разработчикам обеспечить работу системы с любым СУБД путем простой подмены базовой библиотеки. Однако сложность заключается в том, каким набором функциональности базовой библиотеки BTRIEVE пользовались разработчики. Таким образом, если система работы с новым СУБД похожа на BTRIEVE, то переход не представляет проблем. Если же это не так, то требуется весьма трудоемкая доработка базовой библиотеки, которая иногда завершается изменением функциональности и необходимостью переписывания исходных программ системы. Нет установок систем на SQL Server или Oracle. В заключении необходимо отметить, что техническая реализация на базе BTRIEVE не позволяет системе манипулировать большими объемами данных и соответственно претендовать на корпоративное решение.

5.5. Описание основных функциональных возможностей системы «Галактика»

Функции системы «Галактика» необходимо оценивать не на основании рекламных материалов с функциональными структурами, а из содержания прайс-листа со списком подсистем («контуров»), списком модулей в этих подсистемах и их названий.

В прайс-листах, а также презентациях и рекламных материалах, систему представляют как интегрированную управляю-

38

щую систему, состоящую из так называемых четырех контуров управления.

Контур административного управления

Управление документооборотом. Данный модуль не является на-

стоящей почтовой системой. Это модуль, который позволяет пересылать сообщения от одного пользователя системы «Галактики» другому в рамках одной инсталляции (сервера). Дополнительно, если данный модуль используется, то возможно присоединить текстовый документ (из этой почты) к документам, вводимым в систему.

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

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

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

Модуль позволяет вести историю изменения цен на рынке, а также спроса и предложения на товары и услуги (все эти данные вводятся естественно руками). Естественно (в стиле всей системы) история изменения собственных цен на продаваемые товары и услуги из модуля СБЫТ не подгружается.

Ведется ручной учет спроса-предложения на товары и услуги на рынке. Что такое этот спрос реально, какими документами и функциями в системе этот спрос формируется и как используется для управления, разработчики системы «Галактика» по-видимому не знают.

Финансовое планирование. Имеет функции инвестиционной и финансовой стратегии предприятия. Этот же модуль соответствует ква-

39

дратику «Стратегическое планирование» в рекламных материалах. Реально это просто таблица с наименованиями статей затрат, направлений деятельности и т.д.

Управление проектами, календарно-сетевое планирование. Мо-

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

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

Таким образом, просмотрев данную подсистему, остается открытым вопрос: «При чем тут управление?». Данные модули ни с чем (в системе) не связаны и ничем не управляют.

Контур бухгалтерского учета

В состав этой подсистемы входят стандартные российские бухгалтерские модули: Главная книга, Дебиторы-Кредиторы (на самом деле это Банк), Касса, Бухгалтерский учет материальных ценностей (учет МБП, учет ТМЦ), Валютные операции и мультивалютная отчетность, Заработная плата, Бухгалтерская отчетность. Система проектировалась в советские времена и реализует журнально-ордерную систему бухгалтерского учета. При этом за основу брались не задачи автоматизации, а так называемые требования пользователей. То есть система построена так, чтобы ни в коем случае не был сокращен ни один человек из бухгалтерии. Таким образом, журнально-ордерная система учета была разработана для ручного учета первичных документов. При этом каждый документ обрабатывался как минимум двумя разными бухгалтерами (например, один вел журнал-ордер по дебету 10-го счета, другой − ведомость по кредиту 60-го счета для одних и тех же документов − приход на склад). Затем заместитель главного бухгалтера заполнял главную книгу − верхнюю половину на основании журналов-ордеров, а нижнюю − на основании ведомостей. При этом тут же выявлялись ошибки, так как эта матрица должна была быть симметрична. Это и было основной целью журнально-ордер-

40