| СТАТЬЯ |
12.10.00
|
Достоинства и недостатки системы "Галактика"
Материал подготовлен неизвестным аналитиком
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, то при запросе одного нашего клиента продемонстрировать систему на ORACLE, представители НОВОГО АТЛАНТА не смогли этого сделать (Морской порт СПБ, лето 1998 года), более того цена на систему на ORACLE оказалась в 7 раз выше, чем на BTRIEVE. В рекламных материалах о версии ГАЛАКТИКИ на ORACLE в основном рассказывается о том, что получит клиент от перехода на ORACLE и ничего о работающей системе.
Система не поддерживает ни трехуровневую архитектуру, ни WEB архитектуру. Вся логика приложения находится на клиенте (правда это не страшно, так как бизнес логика в системе отсутствует).
В заключении, необходимо отметить, что техническая реализация на базе BTRIEVE не позволяет системе манипулировать большими объемами данных и, соответственно, претендовать на Корпоративное решение.
Описание основных функциональных возможностей системы ГАЛАКТИКА
Функции системы ГАЛАКТИКА необходимо оценивать не на основании рекламных материалов с функциональными структурами (очень красивыми!!!), а из содержания прайс-листа со списком подсистем (“контуров”), списком модулей в этих подсистемах и их названий.
В прайс листах, а также презентациях и рекламных материалах, систему представляют, как интегрированную управляющую систему, состоящую из так называемых четырех “КОНТУРОВ УПРАВЛЕНИЯ”. Далее приводятся все эти контуры и модули и проводится сравнение их функциональности с функциональностью ORACLE APPLICATION.
Управление документооборотом
Данный модуль не является настоящей почтовой системой. Это модуль, который позволяет пересылать сообщения от одного пользователя ГАЛАКТИКИ другому. Естественно в рамках одной инсталляции (сервера). Дополнительно, если данный модуль используется, возможно присоединить текстовый документ (из этой почты) к документам, вводимым в систему.
Обычный кадровый учет. Ведется карточка. Печатаются стандартные документы типа приема на работу, увольнения и т.д. Рассчитываются стажи, правда, только конкретные (общий, непрерывный, в данной отрасли).
Карточка работника расширяемая (как любая другая форма системы - функциональность похожая
Табельный учет (и больничные) ведется и печатается!!!!!! Модулем зарплата не используется. Яркий пример песенки о наборе системы из кубиков. Естественно, что кубики легко собираются, если они никак не связаны между собой.
Определения структуры корпорации, распределения функций между организациями корпорации (например, определение организации осуществляющей централизованное снабжение запасными частями) естественно нет, так как система не поддерживает таких функций.
Очевидно, что Управления карьерой, Управления обучением не существует.
Ведется база данных клиентов и определяются их весовые коэффициенты. Зачем это делается непонятно. К клиентам не привязываются материальные ценности, которые они покупают или поставляют. Нельзя в соответствии с коэффициентами автоматически выбрать поставщика (данная база вообще не связана со Сбытом и Снабжением).
Модуль позволяет вести историю изменения цен на рынке, а также спроса и предложения на товары и услуги (все эти данные вводятся естественно руками). Естественно (в стиле всей системы) история изменения собственных цен на продаваемые товары и услуги из модуля Сбыт не подгружается.
Ведется ручной учет спроса-предложения на товары и услуги на рынке. Что такое этот спрос реально, какими документами и функциями в системе этот спрос формируется и как используется для управления разработчики ГАЛАКТИКИ по-видимому не знают. (например - ORACLE APPS: генерация статистических и сосредоточенных прогнозов на исторических данных; формирование плана реализации по прогнозу в сумме с реальными заказами; расчет не уменьшаемого запаса на складах на основании прогнозов и реального спроса для его удовлетворения; расчет потребности в материалах и генерация заявок на снабжение для выполнения получившегося плана с учетов ожидаемого спроса и поступления). Говорят, что есть функции учета рекламных компаний и расчета их эффективности. Я их не видел.
Имеет громко названные функции инвестиционной и финансовой стратегии предприятия. Этот же модуль соответствует квадратику “Стратегическое планирование” в рекламных материалах. Реально это просто таблица с наименованиями статей затрат, направлений деятельности и т.д. Фактически бизнес-план, причем я не видел можно ли задавать формулы. А потом можно ввести факт и получить отчет (Победа!!!). EXCEL безусловно имеет функциональность на несколько порядков больше. Естественно, данный план не преобразуется в бюджет (план по счетам).
Модуль позволяет составлять планы работ (задачи и сроки выполнения) на уровне предприятия, подразделений, сотрудников. Далее с этим планом не делается ничего, кроме печати. Непонятно название - календарно-сетевое планирование. По-видимому, разработчики забыли, что основная задача календарно-сетевого планирования (метод планирования ГАНТА) заключается в вычислении критического пути на основании выделенных ресурсов, а также моделировании ситуации, как он изменится при выделении дополнительных ресурсов.
ORACLE APPLICATION использует стандартные средства сетевого планирования: ARTEMIS, MANTIX, PRIMAVERA, MS PROJECT. Там план подготавливается и рассчитывается (при этом описания ресурсов подгружаются из системы) и формируется его бюджет. Затем он загружается в APPS (данный процесс может быть on-line) при этом бюджет грузится в главную книгу. В соответствии с этим планом могут далее формироваться и оптимизируются планы производства, снабжения и т.д., а главное, любой документ в системе и, сумма затрат по нему, может быть отнесена на соответствующий пункт сетевого плана с проверкой бюджета по этому пункту. Таким образом, система генерирует необходимые документы для выполнения сетевого плана и АВТОМАТИЧЕСКИ собирает фактические данные по исполнению этого плана, которые потом можно просматривать в Системах сетевого планирования.
Необходимо отметить, что учет (денежный) - сквозной, не зависящий от закрытия бухгалтерских периодов.
Вот это уже интересно. Я данный модуль не видел, но, по-видимому, это модуль написанный на ORACLE EXPRESS. Его функции отдаленно напоминают урезанный вариант Sales Analyzer. Трехмерная картина истории реализации по продуктам и месяцам впечатляющая, однако, удивляет состав продуктов (организация продает дизельное топливо, компьютеры, радиотелефоны и столы с тумбочками одновременно; впечатляющий размах операций).
Просмотрев данную подсистему, остается открытым вопрос: “При чем тут управление?”. Данные модули ни с чем (в системе) не связаны и ничем не управляют.
По-видимому, ставилась цель закрыть функции печати табличек в соответствующих отделах (маркетинга и т.д.), а главное маркетинговая цель наличия такой подсистемы. Я бы сказал, что EXCEL с этим справляется лучше.
Наиболее ценной, с практической точки зрения, является система Управления персоналом. В ORACLE APPLICATION все эти функции представлены гораздо шире, лучше структурированы и действительно имеют управляющий характер. Бизнес-план в Финансовом анализаторе преобразуется в Бюджет и загружается в главную книгу не для красоты, а для контроля исполнения.
Анализатор продаж, Финансовый анализатор и Sales & Marketing позволяют провести анализ тенденций по соответствующим направлениям и принять решения об изменении соответствующей бизнес процедуры, которая поддерживается системой. Например, изменить системы оплаты по договорам с определенной группой заказчиков и главное обеспечить чтобы эта процедура выполнялась.
Управление Проектами является действительно управлением проектами, с практически всеми функциями, необходимыми для данного типа производства.
Необходимо отметить, что данный “контур” является наиболее дорогим в системе (Unlimited license - 32990$). Я бы сказал, что руководство ГАЛАКТИКИ, хочет либо быстро покрыть затраты на разработку, либо не хочет продавать эти модули.
Базовые модули
В состав этой подсистемы входят стандартные Российские бухгалтерские модули: Главная книга, Дебиторы-Кредиторы (на самом деле это Банк), Касса, Бухгалтерский учет материальных ценностей (учет МБП, учет ТМЦ), Валютные операции и мультивалютная отчетность, Заработная плата, Бухгалтерская отчетность. Структурно система построена по принципу рабочих мест бухгалтеров по направлениям (поэтому в системе и присутствуют бухгалтерские модули типа учета ТМЦ). В данных модулях бухгалтер вводит операции относящиеся к его направлению (складские, МБП и т.д.), а затем суммарные результаты переносятся в Главную книгу. Основой формирования бухгалтерского учета в системе являются хозяйственные операции, т. е. именованные проводки, а не план счетов, хотя он и есть. Бухгалтер может ввести хозяйственную операцию вручную, или на основании документа пришедшего из модуля склад, сбыт, снабжение. При этом он сам решает какие документы обрабатывать и как. Результатом является очевидное расхождение между материальным и бухгалтерским учетом.
Вообще не понятно, как при такой системе учета, руководитель предприятия может верить хотя бы одной цифре, представленной бухгалтерией. Столь убогой структуры плана счетов, как в ГАЛАКТИКЕ, я не видел лет 15. Это даже не Российский план счетов, а Советский. Он имеет фиксированную структуру - счет, субсчет, код аналитического учета, который естественно не используется, так как бухгалтера и разработчики не знают как его использовать. Понятно, что такой план счетов предназначен только для формирования отчетности в НАЛОГОВУЮ ИНСПЕКЦИЮ. Ни для какого Финансового анализа он не пригоден. Самое интересное, что и с чисто Российскими особенностями учета, например с пассивно-активными счетами, имеются проблемы. В плане счетов нет определения способа разнесения сальдо на пассив и актив (очевидно, что его и не может быть, т.к. в структуре счета нет аналитики). Т.е. развернутое сальдо посмотреть нельзя. Баланс формируется по данным модуля Дебиторы-Кредиторы. Встает вопрос, а что делать с другими пассивно-активными счетами (ответа на этот вопрос я не получил). Учет рублевый и валютный ведется отдельно (очень интересно, как во многих Российских банковских системах).
Результатом этого должно быть (по аналогии) расхождение баланса.
Понятно, что мелкие прелести структуры Российских систем (двойная проводка при получении денег из Банка в кассу и т.д.) присутствуют в полный рост. Ни о каком бюджете, обязательствах и проверке свободного наличия на счете не может быть и речи. Так же не может быть и речи об ожидаемых сроках оплат/получения денег по уже введенным счетам-фактурам. Таким образом, в системе ПОЛНОСТЬ отсутствуют функции Планирования денежных средств. И реализация этих функций в будущем представляется проблематичной.
Так как все проводки делаются в виде хозяйственных операций, то, очевидно, что с корреспонденцией счетов, стандартными ведомостями и журналами-ордерами все в порядке.
К дополнительным модулям относится модуль Консолидированная финансовая и бухгалтерская отчетность. Этот модуль и является основанием для разговоров корпорации ГАЛАКТИКА о корпоративном решении. Работает он так: вы выгружаете данные (финансовые) из одной системы ГАЛАКТИКА, загружаете их в другую инсталлированную систему и получаете суммарный баланс (АПОФЕОЗ!!!). Как учитываются внутри корпоративные обязательства, акции и т.д. при этом не объяснялось.
Система проектировалась в Советские времена и тупо реализует журнально-ордерную систему бухгалтерского учета. При этом за основу брались не задачи автоматизации, а так называемые требования пользователей. Т.е. система построена так, чтобы ни в коем случае не был сокращен ни один человек из бухгалтерии. Поясняю. Журнально-ордерная система учета была разработана для РУЧНОГО учета первичных документов. При этом каждый документ обрабатывался как минимум двумя разными бухгалтерами (например, один вел журнал-ордер по дебету 10-го счета, другой ведомость по кредиту 60-го счета для одних и тех же документов - приход на склад). Затем заместитель главного бухгалтера заполнял главную книгу (ШАХМАТКУ). Верхнюю половину на основании журналов-ордеров, а нижнюю - на основании ведомостей. При этом тут же выявлялись ошибки, так как эта матрица должна была быть симметрична. Это и было основной целью журнально-ордерной системы учета. Безусловно, ГАЛАКТИКА не формирует двойных проводок, однако структура системы осталась. Но даже в Советские времена в учебниках говорилось, что существует журнально-ордерная система и автоматизированная система,
Главным недостатком системы, на мой взгляд, является то, что она фактически не интегрирована, т.е. бухгалтерский учет сам по себе, оперативный учет сам по себе. Однако структура и метод работы в системе ОЧЕНЬ нравится бухгалтерии и некоторым руководителям (так похоже, никого не сократят и ОЧЕНЬ “гибко”).
Основными достоинствами ORACLE APPLICATION по сравнению с ГАЛАКТИКОЙ являются:
В целом система ГАЛАКТИКА очень примитивна и не реализует никаких функций Финансового управления (т.е. планирования и контроля операций). Среди Российских систем есть системы на порядок лучше (ОМЕГА, БОСС, даже до определенной степени 1С).
Базовые модули
Под оперативным управлением предприятием разработчики системы ГАЛАКТИКА понимают просто ввод фактических документов в модулях СБЫТ, СКЛАД и СНАБЖЕНИЕ, включая расчеты с поставщиками и покупателями. Модуль сбыт достаточно хорошо структурирован, имеет стандартную схему обработки Заказ - Отгрузка. При отгрузке можно проверить состояние расчетов с данным контрагентом. Модуль имеет развитую систему задания прайс -листов с различными скидками и т.д., однако привязка их к клиенту или Продавцу не жесткая. Система резервирования на складе и распределение резервирования по различным складам в соответствии с приоритетами отсутствует.
Нет возможности задания процедуры необходимости утверждения заказа в зависимости от его параметров. Так как заказ можно удалить, а прайс -лист подменить, то имеет место ситуация, когда Продавец вводит и печатает счет по одному прайс -листу, затем его удаляет, вводит другой заказ на другую сумму, а разницу кладет в карман вместе с клиентом.
Связь с модулем склад осуществляется методом формирования (вручную) документа на основании отгрузки. При этом кладовщик может ввести другое количество. Счета-фактуры ведутся тут же. Фактически это документ на отгрузку.
Основным недостатком модуля, является то, что ПРОДАВЕЦ не может определить дату когда он может удовлетворить Заказчика, т.е. дату на которую он может принять заказ. Это связано с тем, что в системе вообще отсутствуют понятия ожидаемые приходы или ожидаемый спрос и связанное с этим понятие ожидаемое состояние склада.
В целом модуль зарекомендовал себя работоспособным, и им достаточно активно пользуются.
Склад является обычным учетным модулем (приход, расход, внутреннее перемещение). Никаких функций анализа складских запасов и тем более расчета не уменьшаемого количества и планирования пополнения НЕТ. Нет функций суммарного наличия по нескольким организациям с детализацией по конкретным организациям, что естественно, так как система не поддерживает корпорацию. Циклического подсчета по результатам анализа складских запасов также нет, что делает складской учет крайне неточным.
Модуль Снабжение просто примитивен. Можно ввести Заказ и поступление по нему. Нет никаких Заявок, проверок Бюджета и, соответственно, резервирования фондов под эти Заявки. Таких понятий, как ожидаемая дата поступления и ее использования в системе нет. Все заказы однотипные. Нет ни постоянных контрактов, ни плановых заказов. Поставщики не группируются по приоритетам (например, с которыми имеется постоянный контракт). Коды материальных ценностей поставщика и список возможных замен не поддерживаются.
Естественно, никаких бизнес-процедур обработки документов задать нельзя (например, для данной группы материальных ценностей должен быть выбран поставщик из списка утвержденных, если сумма заказа больше определенной, необходимо утвердить заказ у начальника отдела снабжения; приемка материальных ценностей по таким заказам проводится всегда с контролем качества и утверждением у начальника ОТК, при этом для других групп материальных ценностей и сумм контрактов задаются совершенно другие правила). Таких понятий в системе просто нет.
Тем более нет процедур сравнения счетов-фактур, поступлений и складских документов. Таким образом нет поддержки реальной процедуры обработки приемки материалов на крупных предприятиях, когда разные подразделения вводят необходимые документ, а затем бухгалтерия производит их сравнение и утверждение счета-фактуры.
В системе ГАЛАКТИКА вообще отсутствуют любые функции корпоративного снабжения/сбыта. Невозможно реализовать функции централизованного снабжения (заявки поступают из нескольких организаций, а одна занимается обеспечением снабжения по ним) и связанной с этой функцией “drop shipment”, т.е. прямая отгрузка заказчику от централизованной снабженческой организации. Не существуют специальных операций внутри корпоративных заказов и отгрузок, которые крайне необходимы для обеспечения внутри корпоративных расчетов.
К дополнительным модулям контура оперативного управления относятся: управление консигнационными товарами, давальческое сырье, учет материальных ценностей в производстве. Первые два модуля являются откликом на весьма специфические Российские запросы, хотя в ORACLE APPLICATION имеется возможность реализовать консигнационный склад (наличие учитывается, а проводки не делаются).
Третий модуль - очень интересен. Модуль представляет собой лимитно -заборную карту, которая открывается на определенный срок (месяц) в конкретном подразделении (цехе). В течении этого срока в ней фиксируются все выдачи материальных ценностей на производство, а затем (опять же вручную) вводятся данные о фактически использованных ресурсах. Получающаяся разница - это материалы в незавершенном производстве. Данный модуль является основой для калькуляции себестоимости “котловым методом”.
Просмотрев функциональность данного “контура” опять возникает резонный вопрос: ”А где же управление?”. Все управление заключается в том, что кто-то просматривает (глазами) какие-то отчеты или таблицы данных и принимает ВОЛЕВОЕ решение.
Система не поддерживает ГЛАВНУЮ ИДЕОЛОГИЮ БИЗНЕСА - максимальное удовлетворение заказчика с минимальными затратами. Т.е. система АВТОМАТИЧЕСКИ не решает следующих вопросов:
Вопросы неликвидов и дефицита на складе решаются классическим способом выдачи отчета о материальных ценностях не имеющих движения (наконец-то управляющий узнал, что у него есть неликвиды!!!!). В то время как система должна автоматически обеспечивать положение (как это делает ORACLE APPLICATION) при котором эти неликвиды и дефициты не возникают вообще. Модулю снабжение явно не хватает функциональности, а рекомендации по “гибкой” работе с заказчиком путем оперативной корректировке прайс - листов вызывают умиление. Безусловно, данная методика очень гибка, только нужна ли такая гибкость руководству предприятия?
Технико-экономическое планирование
Данный модуль позволяет сформировать (ввести вручную, на основании введенных в этом же модуле заказов, по результатам предыдущего года ) план производства по номенклатуре и объему по предприятию и цехам. Минимальный период планирования - месяц.
На основании этого плана и данных о структуре изделия (BOM) можно рассчитать плановую себестоимость также в разрезе предприятия и цехов. А главное, рассчитать, называемую красивым словом “свободную потребность” в материалах, т.е. просто, сколько нужно материалов для производства изделия по норме. ПОБЕДА!!! Это единственный действительно управляющий отчет в системе. Еще пять тысяч ведер (примерно пять лет) и ГАЛАКТИКА реализует MRP алгоритм, т.е. расчет того, сколько нужно ЗАКУПИТЬ материалов (с учетом наличия, ожидаемого спроса и поступления) для выполнения плана.
План имеет только два уровня: план производства и производственная программа. Производственная программа может быть сформирована на основании плана производства. Вроде бы очень похоже на то,
А главное, нельзя сформировать план с учетом реального состояния сбыта; можно только включить в план абстрактный производственный заказ, который вводится в этом же модуле. Дополнительно данный модуль позволяет рассчитать нормативную себестоимость по плану в разрезе предприятия и цехов.
Данный модуль позволяет ввести фактические затраты ресурсов за месяц по определенным статьям затрат и загрузить из контура оперативного управления данные по фактически использованным материалам и фактическому выходу готовой продукции. Далее данный модуль по таким образом введенным (с потолка) данным рассчитывает фактическую себестоимость. При этом косвенные затраты, естественно, рассчитываются котловым методом. Возможно сравнение нормативной и фактической себестоимости.
Все это очень хорошо и позволяет бухгалтерии в кратчайшие сроки рассчитать себестоимость по тем данным, которые введены. Весь вопрос в том, а можно ли позволять вводить данные о затратах таким образом и насколько адекватна получившаяся себестоимость.
Данный модуль для Российских систем просто фантастичен. Это действительно BOM с неограниченной иерархией. Однако способы задания норм и, главное, методы списания материальных ценностей отсутствуют. Понятие ROUTING в системе отсутствует. Вместо него используются нормы по затратам ресурсов, где ресурсы фактически эквивалентны статьям затрат в калькуляции себестоимости. Естественно, понятий операций, их порядка выполнения, ресурсов под них, момента списания ресурсов не существует.
Для Российских систем данный контур явление уникальное. Его существование и позволяет ГАЛАКТИКЕ говорить о том, что это производственная система. Однако обратите внимание, что основной упор делается не на автоматизации функций планирования и учета производственной деятельности и, тем более, не на регламентации проведения основных производственных операций (например, контроль момента и количества списания материалов и ресурсов), а на автоматизации расчета “котловой” себестоимости ВСЕГО ПРОИЗВОДСТВА ЗА МЕСЯЦ для нужд бухгалтерии.
В системе вообще отсутствует понятие производственное задание или сменный план-график и, соответственно невозможно рассчитать себестоимость по этим объектам. А ЭТО НЕОБХОДИМО В СОВРЕМЕННЫХ УСЛОВИЯХ. Результатом является полное отсутствие производственного контроля. Однако, для наших Заказчиков, это потрясающее продвижение вперед. Тем более что фактическая себестоимость рассчитывается по средним ценам.
Недостатком модуля является то, что фактические затраты вводятся руками и их невозможно проконтролировать, хотя реально все эти данные в системе есть - например, оплаты за электричество и т.д. Так же нет никаких способов провести в соответствие данные о реальном наличие в производстве и введенных фактических затратах (Mass Allocation). Таким образом, внедрение системы не повлияет на контроль использования материалов и ресурсов в производстве.
Корпорация проводит очень грамотную маркетинговая политику. Основой ее является следующее:
Необходимо отметить, что в целом данные материалы не врут, и то что предлагает реально ГАЛАКТИКА, воспринимается руководством именно как управление предприятием (Т.е. РУССКОЕ ERP). Корпорация имеет очень эффективные каналы сбыта. Применяется комбинированный метод. Компания имеет 6ть представительств в регионах, которые обеспечивают прямые продажи. В тех регионах, где представительства отсутствуют, работают более 150 дилеров. При этом корпорация обеспечивает, насколько я знаю, очень хорошую их поддержку.
Система имеет очень широкий набор функций, по-видимому самый большой среди Российских систем и покрывает широкий спектр запросов Заказчиков. Это единственная система, которая имеет функции планирования и производства.
В бухгалтерской части система построена в полном соответствии с представлениями бухгалтеров об автоматизированной системе. Имеет полный набор стандартной и специальной бухгалтерской отчетности.
Во всех своих модулях система очень хорошо обеспечивает нужды печати оперативных документов (накладных, счетов-фактур, счетов, сопроводительных документов и т.д.). Это обеспечивает достаточную эффективность ее использования.
Система имеет достаточно много параметров настройки на особенности конкретного Заказчика.
Система имеет очень простые, эффективные и универсальные средства расширения форм ввода и определения новых справочников. Генераторы финансовой и табличной отчетности очень эффективны и просты.
Система уже отлажена (в своем ядре) и по-видимому достаточно устойчиво работает.
Имеет четкую стратегию и тактику продвижения системы на рынке, а также развития системы.
Несмотря на заявленную на первой странице своего описания правильную ЦЕЛЬ РАБОТЫ ПРЕДПРИЯТИЯ и ЗАДАЧУ ВНЕДРЕНИЯ СИСТЕМЫ на нем, реально ГАЛАКТИКА не обеспечивает выполнение этой цели. Система не является управляющей. Она не реализует алгоритмов формирования оптимальных запросов на производство и/или снабжение в зависимости от состояния спроса, планов, прогнозов или их комбинации. Внедрение ее не приносит конкретной прибыли.
Система не имеет механизма определения и контроля процедур выполнения конкретных операций или группы операций (например, определение процедуры СНАБЖЕНИЕ: способ формирования заявки - заявка - выбор поставщика - формирование заказа - отслеживание его выполнения - процедура получения на склад), что не позволяет руководителю быть уверенным, что его управляющие решения исполняются.
Система не имеет функций, необходимых для обеспечения деятельности крупных корпораций (Централизованное снабжение, распределение функций между организациями, передача полномочий от одной организации к другой, взаиморасчеты внутри корпорации и т.д.)
Система, практически, не является интегрированной. Большинство модулей практически не связано между собой, а их связь с финансами очень условна, т.к. документы в финансовом модуле вводятся вручную на основании первичных документов, что приводит к расхождению в материальном и финансовом учете.
Система практически не имеет аналитики в Главной Книге (счет, субсчет, код аналитического учета, который неизвестно как используется). Данная система учета не позволяет на основании финансовых данных построить более или менее глубокий Финансовый анализ.
Система не контролирует бюджет при вводе оперативных документов и вообще не имеет механизмов прогнозирования движения денежных средств, что недопустимо при управлении предприятием.
На мой взгляд, основным назначением системы является максимально быстрое формирование всех необходимых проводок для закрытия месяца и формирования отчетности в налоговую инспекцию.
Т.е. все модули системы, включая и производственные, обеспечивают не функции БИЗНЕСА (получение максимальной прибыли с минимальными затратами), а функции автоматического формирования проводок в главную книгу. Бухгалтерия счастлива. Все предприятие вводит за нее проводки.
Претензии Галактики на ERP-систему просто блеф и маркетинговый трюк, однако, при поголовной АБСОЛЮТНОЙ неграмотности нашего менеджмента он проходит. Мало-мальски грамотный руководитель тут же увидит подмену понятий.
Рекомендуется обратить внимание руководителя предприятия на описание системы ГАЛАКТИКА (стр.5) и задуматься, каким образом, по каким данным, каким критериям и по каким алгоритмам проводится анализ, планирование, как учитывается реализация плана и как осуществляется его контроль (рис1 Схема управления предприятием). Необходимо объяснить, что анализировать при оперативном управлении на самом деле нечего. Есть просто конкретный алгоритм расчета необходимых к ПОКУПКЕ (не к производству) ресурсов и дат этих покупок в соответствии с имеющимся и будущим спросом, который и реализован в Oracle Application.
Необходимо объяснить руководству, что основные потери предприятие несет при не обоснованных закупках, и отследить вручную этот процесс (на крупных предприятиях) невозможно. ГАЛАКТИКА и не пытается исправить это положение. Oracle Application предлагает эффективные способы решения этих проблем.
Руководству предприятия необходимо продемонстрировать обеспечение контроля бюджета при вводе оперативных документов.
Если руководитель уверовал в то, что система очень модульная и собирается из кубиков, необходимо показать, что это действительно так, потому что модули просто не имеют связей между собой.
Если все это не убеждает, то выбором системы занимается Главный бухгалтер или финансист, который либо не знает вопросов управления предприятия в целом, либо его эти вопросы не интересуют.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Interface Ltd.http://www.interface.ru |
| Документ
опубликован:12.10.00 |