История создания системы и технологические особенности еереализации
Материал подготовлен неизвестным аналитиком 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.
Контур административного управления:
Управление документооборотом
Данный модуль не является настоящей почтовой системой. Это модуль, которыйпозволяет пересылать сообщения от одного пользователя ГАЛАКТИКИ другому. Естественнов рамках одной инсталляции (сервера). Дополнительно, если данный модуль используется,возможно присоединить текстовый документ (из этой почты) к документам, вводимымв систему.
Обычный кадровый учет. Ведется карточка. Печатаются стандартные документы типаприема на работу, увольнения и т.д. Рассчитываются стажи, правда, только конкретные(общий, непрерывный, в данной отрасли). Этих данных хватает, чтобы сформировать пакет документов для пенсии.
Карточка работника расширяемая (как любая другая форма системы - функциональностьпохожаяна DESCRIPTIVE FLEXFIELD). Однако поиска по этим полям я не видел.Нет и фотографии работника.
Табельный учет (и больничные) ведется и печатается!!!!!! Модулем зарплатане используется. Яркий пример песенки о наборе системы из кубиков. Естественно,что кубики легко собираются, если они никак не связаны между собой.
Определения структуры корпорации, распределения функций между организациямикорпорации (например, определение организации осуществляющей централизованноеснабжение запасными частями) естественно нет, так как система не поддерживаеттаких функций.
Очевидно, что Управления карьерой, Управления обучением не существует.
Ведется база данных клиентов и определяются их весовые коэффициенты. Зачемэто делается непонятно. К клиентам не привязываются материальные ценности, которыеони покупают или поставляют. Нельзя в соответствии с коэффициентами автоматическивыбрать поставщика (данная база вообще не связана со Сбытом и Снабжением).
Модуль позволяет вести историю изменения цен на рынке, а также спросаи предложения на товары и услуги (все эти данные вводятся естественно руками).Естественно (в стиле всей системы) история изменения собственных цен напродаваемые товары и услуги из модуля Сбыт не подгружается.
Ведется ручной учет спроса-предложения на товары и услуги на рынке. Что такоеэтот спрос реально, какими документами и функциями в системе этот спрос формируетсяи как используется для управления разработчики ГАЛАКТИКИ по-видимому не знают.(например - 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 алгоритм,т.е. расчет того, сколько нужно ЗАКУПИТЬ материалов (с учетом наличия,ожидаемого спроса и поступления) для выполнения плана.
План имеет только два уровня: план производства и производственная программа.Производственная программа может быть сформирована на основании плана производства.Вроде бы очень похоже на то,что есть в APPLICATION, однако:
А главное, нельзя сформировать план с учетом реального состояния сбыта; можнотолько включить в план абстрактный производственный заказ, который вводитсяв этом же модуле. Дополнительно данный модуль позволяет рассчитать нормативнуюсебестоимость по плану в разрезе предприятия и цехов.
Данный модуль позволяет ввести фактические затраты ресурсов за месяц по определеннымстатьям затрат и загрузить из контура оперативного управления данные по фактическииспользованным материалам и фактическому выходу готовой продукции. Далее данныймодуль по таким образом введенным (с потолка) данным рассчитывает фактическуюсебестоимость. При этом косвенные затраты, естественно, рассчитываются котловымметодом. Возможно сравнение нормативной и фактической себестоимости.
Все это очень хорошо и позволяет бухгалтерии в кратчайшие сроки рассчитатьсебестоимость по тем данным, которые введены. Весь вопрос в том, а можно липозволять вводить данные о затратах таким образом и насколько адекватна получившаясясебестоимость.
Данный модуль для Российских систем просто фантастичен. Это действительно BOMс неограниченной иерархией. Однако способы задания норм и, главное, методы списанияматериальных ценностей отсутствуют. Понятие ROUTING в системе отсутствует. Вместонего используются нормы по затратам ресурсов, где ресурсы фактически эквивалентныстатьям затрат в калькуляции себестоимости. Естественно, понятий операций, ихпорядка выполнения, ресурсов под них, момента списания ресурсов не существует.
Для Российских систем данный контур явление уникальное. Его существованиеи позволяет ГАЛАКТИКЕ говорить о том, что это производственная система. Однакообратите внимание, что основной упор делается не на автоматизации функций планированияи учета производственной деятельности и, тем более, не на регламентации проведенияосновных производственных операций (например, контроль момента и количествасписания материалов и ресурсов), а на автоматизации расчета “котловой” себестоимостиВСЕГО ПРОИЗВОДСТВА ЗА МЕСЯЦ для нужд бухгалтерии.
В системе вообще отсутствует понятие производственное задание или сменныйплан-график и, соответственно невозможно рассчитать себестоимость по этимобъектам. А ЭТО НЕОБХОДИМО В СОВРЕМЕННЫХ УСЛОВИЯХ. Результатом являетсяполное отсутствие производственного контроля. Однако, для наших Заказчиков,это потрясающее продвижение вперед. Тем более что фактическая себестоимостьрассчитывается по средним ценам.
Недостатком модуля является то, что фактические затраты вводятся руками и ихневозможно проконтролировать, хотя реально все эти данные в системе есть - например,оплаты за электричество и т.д. Так же нет никаких способов провести в соответствиеданные о реальном наличие в производстве и введенных фактических затратах (MassAllocation). Таким образом, внедрение системы не повлияет на контроль использованияматериалов и ресурсов в производстве.
Маркетинговая политика корпорации ГАЛАКТИКА
Корпорация проводит очень грамотную маркетинговая политику. Основой ее являетсяследующее:
Необходимо отметить, что в целом данные материалы не врут, и то что предлагаетреально ГАЛАКТИКА, воспринимается руководством именно как управление предприятием(Т.е. РУССКОЕ ERP). Корпорация имеет очень эффективные каналы сбыта. Применяетсякомбинированный метод. Компания имеет 6ть представительств в регионах, которыеобеспечивают прямые продажи. В тех регионах, где представительства отсутствуют,работают более 150 дилеров. При этом корпорация обеспечивает, насколько я знаю,очень хорошую их поддержку.
Достоинства системы
Система имеет очень широкий набор функций, по-видимому самый большой средиРоссийских систем и покрывает широкий спектр запросов Заказчиков. Это единственнаясистема, которая имеет функции планирования и производства.
В бухгалтерской части система построена в полном соответствии с представлениямибухгалтеров об автоматизированной системе. Имеет полный набор стандартнойи специальной бухгалтерской отчетности.
Во всех своих модулях система очень хорошо обеспечивает нужды печатиоперативных документов (накладных, счетов-фактур, счетов, сопроводительныхдокументов и т.д.). Это обеспечивает достаточную эффективность ее использования.
Система имеет достаточно много параметров настройки на особенности конкретногоЗаказчика.
Система имеет очень простые, эффективные и универсальные средства расширенияформ ввода и определения новых справочников. Генераторы финансовой и табличнойотчетности очень эффективны и просты.
Система уже отлажена (в своем ядре) и по-видимому достаточно устойчивоработает.
Имеет четкую стратегию и тактику продвижения системы на рынке, а также развитиясистемы.
Недостатки системы
Несмотря на заявленную на первой странице своего описания правильную ЦЕЛЬРАБОТЫ ПРЕДПРИЯТИЯ и ЗАДАЧУ ВНЕДРЕНИЯ СИСТЕМЫ на нем, реально ГАЛАКТИКА не обеспечиваетвыполнение этой цели. Система не является управляющей. Она не реализуеталгоритмов формирования оптимальных запросов на производство и/или снабжениев зависимости от состояния спроса, планов, прогнозов или их комбинации. Внедрениеее не приносит конкретной прибыли.
Система не имеет механизма определения и контроля процедур выполненияконкретных операций или группы операций (например, определение процедурыСНАБЖЕНИЕ: способ формирования заявки - заявка - выбор поставщика - формированиезаказа - отслеживание его выполнения - процедура получения на склад), чтоне позволяет руководителю быть уверенным, что его управляющие решения исполняются.
Система не имеет функций, необходимых для обеспечения деятельности крупныхкорпораций (Централизованное снабжение, распределение функций между организациями,передача полномочий от одной организации к другой, взаиморасчеты внутрикорпорации и т.д.)
Система, практически, не является интегрированной. Большинство модулейпрактически не связано между собой, а их связь с финансами очень условна,т.к. документы в финансовом модуле вводятся вручную на основании первичныхдокументов, что приводит к расхождению в материальном и финансовом учете.
Система практически не имеет аналитики в Главной Книге (счет, субсчет,код аналитического учета, который неизвестно как используется). Даннаясистема учета не позволяет на основании финансовых данных построить болееили менее глубокий Финансовый анализ.
Система не контролирует бюджет при вводе оперативных документов и вообщене имеет механизмов прогнозирования движения денежных средств, что недопустимопри управлении предприятием.
На мой взгляд, основным назначением системы является максимально быстроеформирование всех необходимых проводок для закрытия месяца и формированияотчетности в налоговую инспекцию.
Т.е. все модули системы, включая и производственные, обеспечивают нефункции БИЗНЕСА (получение максимальной прибыли с минимальными затратами),а функции автоматического формирования проводок в главную книгу. Бухгалтериясчастлива. Все предприятие вводит за нее проводки.
Претензии Галактики на ERP-систему просто блеф и маркетинговый трюк, однако,при поголовной АБСОЛЮТНОЙ неграмотности нашего менеджмента он проходит. Мало-мальскиграмотный руководитель тут же увидит подмену понятий.
Способы маркетинговой борьбы с данным конкурентом
Рекомендуется обратить внимание руководителя предприятия на описание системыГАЛАКТИКА (стр.5) и задуматься, каким образом, по каким данным, каким критериями по каким алгоритмам проводится анализ, планирование, как учитывается реализацияплана и как осуществляется его контроль (рис1 Схема управления предприятием).Необходимо объяснить, что анализировать при оперативном управлении на самомделе нечего. Есть просто конкретный алгоритм расчета необходимых к ПОКУПКЕ (нек производству) ресурсов и дат этих покупок в соответствии с имеющимся и будущимспросом, который и реализован в Oracle Application.
Необходимо объяснить руководству, что основные потери предприятие несетпри не обоснованных закупках, и отследить вручную этот процесс (на крупныхпредприятиях) невозможно. ГАЛАКТИКА и не пытается исправить это положение.Oracle Application предлагает эффективные способы решения этих проблем.
Руководству предприятия необходимо продемонстрировать обеспечение контролябюджета при вводе оперативных документов.
Если руководитель уверовал в то, что система очень модульная и собираетсяиз кубиков, необходимо показать, что это действительно так, потому чтомодули просто не имеют связей между собой.
Если все это не убеждает, то выбором системы занимается Главный бухгалтерили финансист, который либо не знает вопросов управления предприятия вцелом, либо его эти вопросы не интересуют.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Ссылки по теме: Interface Ltd корпорация "Галактика"
Автомобили
Бизнес