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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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