Достоинства и недостатки системы "Галактика"

Материал подготовлен неизвестным аналитиком
Oracle для внутрифирменного пользования

История развития корпорации и системы

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

В 1986 году были написаны первые заказные модули (СБЫТ, СКЛАД) и подэтот проект была создана фирма НОВЫЙ АТЛАНТ в г. Москве. Основными задачамиэтой фирмы были поиск новых заказов и разработка прикладных программ. Данноеразделение направлений деятельности сохраняется в корпорации до сих пор.

НОВЫЙ АТЛАНТ и дочерние фирмы (представительства в регионах и сервисныеорганизации) занимаются разработкой самой системы и сбытом, а ТОП СОФТ- разработкой системного программного обеспечения. Единого плана разработкисистемы ГАЛАКТИКА естественно не было. Система разрабатывалась по модульнопод заказ. Как сказал президент корпорации Д. Черных: “При разработке мыотталкиваемся от потребностей заказчика” (на самом деле сиюминутных потребностей).В результате, к 1993 году набралось достаточно много модулей, и фирма НОВЫЙАТЛАНТ заявила о существование ИНТЕГРИРОВАННОЙ системы ГАЛАКТИКА. Естественно,что некоторые модули сначала разрабатывались, потом, при изменении экономическойситуации - “забывались”, а затем “всплывали” снова. Так было с модулями,связанными с планированием и управлением производством. В восьмидесятыхгодах - это были зачаточные реализации модулей планирования и калькуляцииплановой себестоимости, реализованные под заказ машиностроительных заводов(скорее одного завода). Когда машиностроительные заводы стали недееспособны,об этих модулях забыли. В 96 -98 годах начались разговоры об ERP-MRP системахи об этих модулях вспомнили. Однако никто их не собирался и не собираетсяразвивать и дорабатывать до реально необходимой функциональности. С техпор базовая функциональность системы практически не изменилась (у меняесть рекламные материалы 1994 года, в которых написано тоже самое, чтои в 1998). Развитие шло по линии совершенствования каналов сбыта, сервисаи совершенствования структуры самой корпорации, а так же переводу системына новые платформы (Windows, новые СУБД). Во всех этих направлениях былидостигнуты определенные успехи.

Функциональные особенности архитектуры системы

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

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

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

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

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

Система исходно была реализована в архитектуре клиент-сервер в понимании этоготермина системой BTRIEVE и остается такой по сей день. 90 процентов (я думаю,что 99,9%) установок системы сделаны на этой архитектуре (т.е. NOVELL).

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

Что касается ORACLE, то при запросе одного нашего клиента продемонстрироватьсистему на ORACLE, представители НОВОГО АТЛАНТА не смогли этого сделать(Морской порт СПБ, лето 1998 года), более того цена на систему на ORACLEоказалась в 7 раз выше, чем на BTRIEVE. В рекламных материалах о версииГАЛАКТИКИ на ORACLE в основном рассказывается о том, что получит клиентот перехода на ORACLE и ничего о работающей системе.

Система не поддерживает ни трехуровневую архитектуру, ни WEB архитектуру.Вся логика приложения находится на клиенте (правда это не страшно, таккак бизнес логика в системе отсутствует).

В заключении, необходимо отметить, что техническая реализация на базеBTRIEVE не позволяет системе манипулировать большими объемами данных и,соответственно, претендовать на Корпоративное решение.

Описание основных функциональных возможностей системы ГАЛАКТИКА

Функции системы ГАЛАКТИКА необходимо оценивать не на основании рекламныхматериалов с функциональными структурами (очень красивыми!!!), а из содержанияпрайс-листа со списком подсистем (“контуров”), списком модулей в этих подсистемахи их названий.

В прайс листах, а также презентациях и рекламных материалах, системупредставляют, как интегрированную управляющую систему, состоящую из такназываемых четырех “КОНТУРОВ УПРАВЛЕНИЯ”. Далее приводятся все эти контурыи модули и проводится сравнение их функциональности с функциональностьюORACLE APPLICATION.

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