организовать выявление нарушений трудовой дисциплины.
Модуль "Аттестация и проверка профессиональных знаний" на базе системы управления обучением позволяет автоматизировать процесс проверки знаний. Модуль предназначен для проведения аттестации при приеме на работу, периодической аттестации, ежегодной проверки знаний и проверки знаний по запросу руководителя.
Модуль "ХК Арена "Металлург" - позволяет автоматизировать систему по продаже билетов на хоккейные матчи для работников ОАО "ММК" и обществ Группы компаний ОАО "ММК" с последующим удержанием из заработной платы, а также систематизировать отчетность по проведенным удержаниям.
Управление запасами
Модуль КИС "Управление запасами" автоматизирует процесс учета движения сырья, полуфабрикатов, отходов и готовой продукции по цеховым складам: поступление, расход в производство, списание со склада и оприходование на склад, перемещение внутри склада, передача на склад цеха дальнейшего передела, отгрузка готовой продукции.
Управление разработкой продукции
Модуль КИС "Управление разработкой продукции" обеспечивает поддержку единых справочников сырья, продукции и полуфабрикатов и рецептур для их производства, а также управление рецептами и технологическими маршрутами производства на основе установленных правил.
Управление производством и контроль операций
Модуль КИС "Управление производством и контроль операций" предназначен для оперативного учет производства цехов в натуральных единицах (тоннах): нормативное и фактическое количество израсходованных сырья и полуфабрикатов, произведенных продуктов, полуфабрикатов и отходов, время начала операций и их продолжительность.
Планирование выпуска продукции и потребности в материалах
Модуль КИС "Планирование выпуска продукции и потребности в материалах" является программным решением по формированию запланированных производственных заказов и плана производства в цехах энергокомплекса.
Управление качеством
Модуль КИС "Управление качеством" является инструментом для формирования спецификаций поставщика и спецификаций заказчика, контроль их соответствия базовым спецификациям, описывающим качественные характеристики материалов и необходимые проверки на соответствие заданному качеству, обеспечивает формирование заявок на отбор проб и анализ результатов испытаний.
Управление затратами
Модуль КИС "Управление затратами" является комплексным программным решением учета связанных с производством затрат в натуральном и стоимостном выражениях: прямые затраты (сырье, полуфабрикаты) и накладные затраты (вспомогательные материалы, топливо, электроэнергия, ремонты, зарплата и т.д.) - и обеспечивает калькулирование плановой и фактическое себестоимости продукции.
Дебиторы
Модуль "Дебиторы" позволяет автоматизировать учет взаиморасчетов с Заказчиками. Модуль предназначен для ведения оперативного и бухгалтерского учета всех видов документов при взаиморасчетах между ОАО "ММК" и Заказчиками, а также позволяет формировать отчетность о дебиторской задолженности.
Кредиторы
Модуль "Кредиторы" позволяет автоматизировать учет взаиморасчетов с Поставщиками. Модуль предназначен для ведения оперативного и бухгалтерского учета всех видов документов при взаиморасчетах между ОАО "ММК" и Поставщиками, а также позволяет формировать отчетность о кредиторской задолженности.
Движение денежных средств
Модуль "Движение денежных средств" позволяет автоматизировать процессы управления финансовыми потоками ОАО "ММК", а также формировать отчетность о движение финансов предприятия.
Главная книга
Осуществляет сбор бухгалтерских записей со всех модулей OEBS. Позволяет формировать сводные отчетные формы для целей бухгалтерского учета.
Налоговый учет
Модуль "Налоговый учет" позволяет автоматизировать процесс расчета налога на прибыль, а также формирует налоговые регистры установленного образца.
Учет ЖД тарифа
Модуль "Учет ЖД тарифа" позволяет автоматизировать процесс выверки взаиморасчетов за предъявленный ОАО "РЖД" и выставленный в адрес других контрагентов ЖД тариф.
Казначейство
Модуль "Казначейство" позволяет автоматизировать процесс управления денежными средствами в рамках Группы компаний ММК. Позволяет отслеживать движение и остатки денежных средств на счетах предприятий входящих в Группу ММК.
Договоры. Претензии и иски.
Модуль КИС "Договоры" предназначен для реализации основных бизнес-процессов ведения договоров, контроля их исполнения и претензионно-исковой работы по ним.
Управление взаимоотношениями с клиентами (CRM).
Модуль "Управление преддоговорной работой (CRM)" предназначен для управления отношениями с потенциальными и существующими клиентами. В модуль включены средства сопровождения продавца, направленные на конечных потребителей и их эффективного вовлечения в процессы продаж.
Управление заказами
Модуль "Управление заказами" автоматизирует и упорядочивает процессы формирования, изменения и исполнения заказов на продажу.
Расширенное ценообразование. Формирование счетов-фактур.
Модуль "Расширенное ценообразование" предназначен для формирования цен. Модуль позволяет эффективными методами назначить цену, исходя из сложных правил и комплексных стратегий, определяемых условиями рынка. Для расчета цены и скидок модуль "Расширенное ценообразование" позволяет определять прейскуранты (прайс-листы), формулы расчета цен и ценовые модификаторы.
Автоматизация процесса выставления счетов-фактур позволяет автоматически генерировать счета и создавать соответствующие им проводки в бухгалтерском учете.
Отгрузка
Модуль "Отгрузка" является комплексным программным решением для оперативного учета отгруженной и неотфактурованной товарной продукции ОАО "ММК". Модуль предназначен для анализа производства товарной продукции.
2. Архитектура Субд Oracle
2.1 Распределенные БД в Oracle и Oracle в распределенных БД
СУБД Oracle позволяет поддерживать связь не только между клиентами и сервером, но и между серверами. Построение распределенных БД открывает возможности для решения целого комплекса задач: собрать в единое целое данные, хранящиеся в разных местах, увеличить серверную мощность системы, добавив в нее новые серверы (воспользоваться так называемой горизонтальной масштабируемостью), сосредоточить данные в непосредственной близости от их потребителей, сохраняя при этом целостность системы, и многие другие.
Концепция построения распределенных БД в Oracle основана на децентрализованной их организации. Серверы взаимодействуют друг с другом с помощью уже знакомого нам протокола SQL*Net. Ссылки друг на друга - так называемые каналы связи БД (database links) - серверы хранят в качестве объектов БД. В свою очередь полное имя объекта может включать в себя канал связи (т.е. вместо самого объекта в локальной базе данных может храниться как бы ссылка на него): это, безусловно, требует обеспечения уникальности имен серверов ("сервисов" в терминологии Oracle) в сети, что достигается с помощью иерархической организации доменов, подобной существующей в Internet.
Поскольку вместо "настоящих" имен объектов можно использовать их синонимы (также в свою очередь являющиеся объектами БД), то приложение клиента может попросту не знать, является ли данный объект локальным для сервера, с которым установлена связь, или нет. Конечно, механизм каналов связи и синонимов - лишь внешняя сторона той системы, которая позволяет сделать структуру распределенной БД Oracle абсолютно прозрачной для приложений независимо от размещения данных и режима взаимодействия серверов. А таких вариантов организации Oracle предлагает множество - как говорится, на любой вкус, хотя точнее было бы сказать, для любой ситуации.
2.2 Синхронная связь без тиражирования данных
Рассмотрим сначала самый простой, с логической точки зрения, вариант, при котором любой объект распределенной БД хранится только в одном экземпляре (не тиражируется). Это неизбежно означает, что если какая-либо транзакция (или запрос) пользовательского приложения включает в себя обращения к удаленным (расположенным не на том сервере, с которым установлена связь) объектам, эта транзакция (запрос) не может быть завершена, пока все задействованные серверы не обменяются необходимой информацией (т.е. они взаимодействуют в синхронном режиме).
Наиболее сложные проблемы при этом возникают при выполнении транзакций, одновременно изменяющих данные, хранящиеся на нескольких серверах (такие транзакции называются распределенными в отличие от удаленных, которые хотя и изменяют удаленные данные, но только на одном сервере). Суть проблемы в том, что при любых обстоятельствах нужно обеспечить, чтобы транзакция либо завершилась, либо "откатилась" на всех затронутых ею серверах (в противном случае возникнет рассогласование данных в распределенной БД). Вот почему при работе распределенной БД требуется использовать двухфазную фиксацию транзакций.
Схема алгоритма двухфазной фиксации упрощенно сводится к тому, что на первой фазе (подготовке к фиксации) сервер-инициатор транзакции рассылает соответствующий запрос другим серверам (находящимся для него "в непосредственной видимости") и ждет ответа. Каждый из этих серверов может в случае необходимости повторить то же действие рекурсивно. Если все затронутые транзакцией серверы информируют о готовности к ее завершению в своих ответах, инициируется вторая фаза - собственно завершение транзакции.
Описанная схема действительно сильно упрощена, поскольку основные сложности при двухфазной фиксации транзакций начинаются тогда, когда встает вопрос об обеспечении корректного и предсказуемого поведения системы в случае выхода из строя отдельных серверов или временных разрывов линий связи. Самое простое - переложить решение данной проблемы на прикладного программиста (что фактически и делается в ряде СУБД), но, даже если это требуется в ограниченном наборе ситуаций, говорить о прозрачности структуры распределенной БД для приложений в таком случае уже нельзя. Реализация двухфазного завершения в Oracle такова, что все проблемы разрешаются автоматически, хотя возможность вмешательства администратора предусмотрена.
Как нетрудно догадаться, организация распределенной БД в данном варианте требует наличия надежных, постоянно доступных и достаточно быстрых линий связи между серверами.
2.3 Тиражирование данных
Предположим, что банк помимо центрального офиса имеет ряд филиалов, связанных с ним выделенными линиями связи, не обладающими, однако, достаточной пропускной способностью для подключения рабочих мест в филиалах к центральной БД в режиме клиентов. Напрашивается решение с использованием распределенной БД, организованной так, чтобы данные, чаще всего требующиеся в филиале, физически располагались на его локальном сервере. При этом возникает вопрос: как обеспечить возможность доступа из филиалов к центральной БД и из центрального офиса к данным в филиалах?
Если организовать распределенное хранение данных, как в предыдущем варианте, любой такой запрос (или транзакция) может выполняться с большой задержкой. В качестве выхода можно предложить хранить объекты данных в распределенной БД не в единственном экземпляре, а тиражировать их на всех серверах, где к ним может потребоваться быстрый доступ. Естественно при этом возникает необходимость каким-либо образом обеспечить синхронизацию различных копий одних и тех же данных, иначе распределенная БД потеряет свою целостность и превратится в хаос.
2.4 Промышленные системы
Методика обеспечения целостности распределенной БД - лишь один из аспектов, определяющих упомянутое различие. Если попробовать сформулировать основной его критерий в общем виде, то, пожалуй, можно предложить следующую формулировку: в промышленной системе всегда можно дать однозначный ответ на вопрос "А что будет, если.?". Другими словами, промышленная система должна обеспечивать своими внутренними средствами предсказуемость своего состояния независимо от внешних условий. Безусловно, любое общее определение страдает неполнотой (в самом деле, формально наиболее предсказуемым является состояние системы, которая вообще никогда не работает), однако, по мнению автора, оно все-таки дает идею, необходимую для понимания сути утверждения о том, что Oracle предоставляет технологию для создания именно промышленных систем.
В качестве поясняющего примера вернемся к проблеме синхронизации тиражируемых данных. Рассмотрим вопрос об организации связи между серверами в распределенной БД. Очень соблазнительной является идея: если уж мы не требуем, чтобы целостность данных обеспечивалась в любой момент времени, нельзя ли организовать указанную связь на основе электронной почты? На первый взгляд, ничего опасного в этом нет, но вспомним, что электронная почта не гарантирует, что "письма" будут получены адресатом в той же последовательности, в которой они были посланы и даже что все они вообще будут получены. Даже если с помощью специального контроля на приеме последствия данной неоднозначности сводятся к минимуму, все равно оказывается невозможным предсказать, скажем, момент времени, когда информация об изменении одной из копий объекта дойдет до других его копий, и в каком состоянии к этому моменту эта изменившаяся копия будет находиться. Означает ли это, что электронной почтой в распределенной БД пользоваться вообще нельзя? И да, и нет. Все зависит от требований к системе. Если "свежесть" тиражированных данных требуется, допустим, в пределах суток, а последствия непредсказуемости системы и потери ее целостности не слишком разрушительны, то почему бы и нет? Но если все-таки требуется действительно промышленная система, то необходимо очень тщательно оценить все возможные последствия применения выбранного механизма взаимодействия и ввести в использование того же тиражирования такие ограничения, которые обеспечили бы требуемый уровень целостности системы.
2.5 Варианты тиражирования данных в Oracle
Самым простым (и исторически реализованным первым) вариантом тиражирования в Oracle является механизм так называемых неизменяемых снимков (read-only snapshots). Он подразумевает создание удаленной копии таблицы (или ее подмножества), которая доступна только на чтение и обновляется по заданному сценарию и расписанию. Точнее, снимок определяется так же, как представление - view, т.е. он может быть основан и на нескольких таблицах.
Следующим по своей логической сложности вариантом является организация изменяемых снимков, предоставляющая возможность модификации удаленных копий. Однако, как и в предыдущем случае, отношения серверов при этом асимметричны (один из них является владельцем "оригинала" данных, хотя и подверженного удаленным изменениям).
Последним "атомарным" вариантом тиражирования в Oracle (ибо возможны также любые комбинации) является тиражирование с множественными хозяевами (multi-master site replication). При данном варианте полностью тиражируются целые наборы объектов БД (в них помимо таблиц могут входить индексы, представления, триггеры, пакеты хранимых процедур, синонимы, генераторы последовательностей). При этом тиражируются все определения и атрибуты объектов, так что в результате все хозяева их копий становятся равноправными. Любые изменения тиражированных данных непосредственно передаются ("распространяются") всем хозяевам (в отличие от варианта изменяемых снимков, где несколько снимков одного объекта могут обменяться изменениями только через посредство хозяина этого объекта). Такое решение, в частности, приводит к тому, что в системе не будет ни одного сервера, единичный выход из строя которого означал бы невозможность продолжения работы с набором тиражированных объектов.
Механизм распространения изменений в Oracle встроен в ядро системы и не требует использования никаких дополнительных программных продуктов. Любое изменение тиражированного объекта приводит в действие специальный триггер, который формирует вызов удаленной процедуры, необходимый для воспроизведения изменения во всех оставшихся копиях объекта. Далее в случае использования синхронного тиражирования сформированный вызов немедленно начинает выполняться, в случае же асинхронного тиражирования он помещается в специальную очередь отложенных вызовов, ожидая наступления момента своей передачи.
Теперь, когда общий механизм тиражирования ясен, попробуем разобраться в некоторых аспектах его применения.
Как уже упоминалось, возможны два режима тиражирования: синхронный, когда все изменения данных распространяются немедленно, и асинхронный, когда по отношению к этим изменениям применяется алгоритм "запомнить и передать" (store and forward), а момент передачи выбирается по заданному правилу (или явно инициируется, например, после восстановления связи).
Синхронный вариант оправдан, по-видимому, в примере с банком и его филиалами, приведенном в самом начале раздела (в случае асинхронного тиражирования появляется опасность, что нечистый на руку клиент банка может, к примеру, несколько раз закрыть свой счет, быстро перемещаясь из филиала в филиал, - впрочем, как показано ниже, данная проблема может быть разрешена и иначе). По сравнению с вариантом использования синхронной связи без тиражирования, преимущества состоят в том, что, во-первых, запросы выполняются на локальном сервере и не требуют передачи данных между серверами, во-вторых, транзакции, хотя и требуют распространения изменений, все же выполняются для клиентов быстрее, поскольку это распространение происходит асинхронно по отношению к транзакциям (клиент не ждет окончания обмена данными между серверами).
Другой важный пример использования синхронного тиражирования - поддержка "зеркальной" БД на резервном сервере, причем оба сервера (основной и резервный) в этом случае могут работать параллельно.
Что касается асинхронного тиражирования, то оно применимо тогда, когда нет возможности поддерживать постоянную связь между серверами, а временным рассогласованием данных можно поступиться (опять-таки в предположении, что состояние БД во времени предсказуемо). Если на Западе в качестве примера чаще всего приводят торгового агента, разъезжающего со своим ноутбуком и имеющего возможность лишь время от времени подключаться к сети, то в российских условиях, увы, аналогичная ситуация весьма типична. В тех регионах нашей могучей страны, где до сих пор самое надежное средство связи - это трактор, реализация даже предсказуемо работающего тиражирования данных представляется нелегкой задачей.
Впрочем, задача эта непроста и в случае, когда со связью все в порядке. Серьезной проблемой при проектировании системы является обеспечение ее корректного функционирования в условиях возможных конфликтов по обновлению различных копий одних и тех же данных на разных серверах. Здесь мы сталкиваемся с ситуацией, когда универсального решения попросту не существует, поэтому все, что может предоставить СУБД, - это средства для реализации различных вариантов решений и рекомендации по их использованию.
Прежде всего, необходимо выбрать общую архитектуру системы, точнее, тот ее аспект, который относится к дисциплине доступа к данным. Можно, конечно, никакой дисциплины не устанавливать, но в этом случае задача проектировщика становится наиболее сложной, да и стопроцентная гарантия корректности работы не всегда достигается. Впрочем, давайте по порядку.
Самый простой вариант архитектуры, заведомо гарантирующий отсутствие конфликтов, предполагает, что для любого тиражированного элемента данных среди всех равноправных хранителей его копий выбирается один, так сказать, самый равноправный. Ему одному разрешается этот элемент данных изменять, всем остальным дозволяется только наблюдать за этим. Вариантов реализации такой схемы может быть множество: от самого простого - звездообразного (филиалам банка разрешается видеть данные центрального отделения, но не изменять их) до гораздо более изощренных со сложной сетью неизменяемых снимков.
Более развитый вариант архитектуры, также дающий гарантию отсутствия конфликтов, разрешает динамическую передачу права модификации (в англоязычных материалах обычно употребляется термин, буквально переводимый как "документооборот") от сервера к серверу. Каждый элемент данных снабжается специальным атрибутом "разрешена запись", и вводится процедура передачи этого атрибута. Варианты реализации опять-таки могут быть различными. Характерным примером может служить информационная система торговой фирмы, где для каждого заказа эстафета последовательно передается от отдела продаж к управлению складом и далее к отделу доставки. Аналогичная схема в принципе решает упомянутую выше проблему "многократного закрытия счета" в банке.
Любые другие организации архитектуры тиражирования допускают возникновение конфликтов, следовательно, не остается ничего другого, как пытаться их разрешать. От СУБД здесь в первую очередь требуется обеспечить автоматическое обнаружение конфликтов и возможность извещения о них (наверное, излишне упоминать, что Oracle делает это), ибо момент возникновения конфликта зависит от механизма распространения изменений. Но просто извещать о проблеме и ждать ее "ручного" разрешения (по всей видимости, крайним, как всегда, окажется администратор БД) - вероятно, не лучший выход. По возможности нужно стремиться разрешать конфликты автоматически.предлагает для этой цели набор процедур разрешения конфликтов, которые можно ассоциировать с группами столбцов таблицы. Руководствоваться при этом лучше всего здравым смыслом: скажем, если речь идет об описательных данных клиента, в качестве разрешающей функции разумно выбрать последнюю по времени модификацию, изменения количества товара на складе имеет смысл просуммировать и т.д.
Помимо внушительного набора стандартных функций разрешения конфликтов можно использовать и свои собственные. Однако не все так просто. Далеко не все функции способны обеспечить стопроцентную конвергенцию (непременную установку в одно и то же значение) данных, особенно в случае, когда в конфликте участвует более двух серверов. Если применяется нестандартная функция, для определения ее свойств может потребоваться весьма тонкий анализ (для стандартных он уже проведен). Как бы то ни было, в системе необходимо предусматривать либо выбор только тех функций, которые обеспечивают конвергенцию данных при принятой дисциплине доступа к ним, либо использовать извещение администратора, когда функция не способна справиться с ситуацией самостоятельно.
В качестве резюме отметим еще раз, что тиражирование дает чрезвычайно широкие возможности, но относиться к нему необходимо с большой осторожностью и тщательно анализировать все аспекты возможного поведения системы при ее проектировании.
2.6 Поддержка резервной копии БД
предлагает еще один механизм, напоминающий тиражирование. Это предназначенная для повышения устойчивости системы к сбоям поддержка резервной копии БД (standby database). Смешивать данный механизм с тиражированием, пожалуй, не стоит, ибо резервная БД недоступна для пользователей одновременно с основной. Зато отсутствует дополнительная нагрузка на ядро основного сервера, связанная с распространением изменений. Дело в том, что для поддержания соответствия резервной и основной баз данных используются журнальные файлы изменений, вообще говоря, предназначенные для восстановления БД после сбоев. Собственно, резервная БД как раз и функционирует в режиме перманентного восстановления, считывая журнальные файлы основной БД, переданные тем или иным способом на резервный сервер.
Выбор варианта решения задачи во многом зависит от составляющих гетерогенную систему СУБД.
Если это реляционные СУБД (MS SQL Server, Informix, Sybase, DB2, CA Ingres), можно использовать так называемые прозрачные шлюзы для объединения их с Oracle. Для пользователя такого шлюза полностью имитируется функциональная среда сервера Oracle при доступе к данным, хранящимся в "чужих" СУБД.
Для реализации шлюза используется промежуточный сервер Oracle (чаще всего он функционирует на том же компьютере, что и "чужой" сервер), за счет которого и достигается эффект "ораклизации" данных. Например, если пользователь вызывает хранимую процедуру на PL/SQL, то она фактически выполняется севером-шлюзом (СУБД других производителей с PL/SQL не работают), а "чужому" серверу передаются только SQL-предложения, содержащиеся или сформированные в процедуре.
Сложнее обстоит дело, если необходимо получить доступ к данным, хранящимся в нереляционных СУБД (ADABAS, VSAM и пр.). В таком случае, как правило, невозможно формально однозначно отобразить эти данные в реляционные структуры Oracle, поэтому подход прозрачных шлюзов не применим. Тем не менее Oracle предлагает решение для таких ситуаций в виде процедурных шлюзов. В них вместо стандартного SQL для взаимодействия с "чужими" данными предоставляется библиотека процедур, с помощью которых разработчик реализует необходимое отображение данных.
Другой вариант решения проблемы в случае обращения к экзотическим системам хранения данных - использование мониторов транзакций.
Надо отметить, что при работе со шлюзами данные других СУБД органически включаются в среду распределенных БД Oracle: реализуется полнофункциональная поддержка синхронной связи между серверами без тиражирования и даже некоторые варианты тиражирования данных.
2.7 Администрирование распределенных систем на примере Oracle
Немного поговорим о тех средствах, которые Oracle предлагает в помощь администратору распределенной информационной системы.
В принципе, такая система может иметь (и обычно имеет) более одного администратора. Однако подобная организация имеет много недостатков. Не говоря уж о необходимости найти нужное количество высококвалифицированных специалистов, их деятельность нужно тесно координировать, например, для обеспечения единой политики защиты данных. Понятны неудобства пользователя, который должен помнить множество паролей для доступа к различным серверам. Если же пароли везде одинаковы, то увеличивается вероятность потери их секретности.
Полезность централизации хотя бы части административных функций очевидна. На рынке программных продуктов существует достаточно много средств, направленных на решение именно этой задачи. К примеру, есть системы, реализующие централизованную идентификацию пользователей. Для некоторых из них (Kerberos, Sesame) Oracle предоставляет интерфейсы, что позволяет ввести их функциональность в распределенную БД на базе Oracle.
Что касается средств централизованного управления, то их на рынке тоже достаточно много, и значительная часть из них в той или иной степени способны работать с СУБД Oracle. Однако в данной области находиться в полной зависимости от технологии третьих фирм чересчур рискованно для крупных поставщиков передовых программных технологий, таких как Oracle: слишком большое значение приобретает данный аспект системы, чтобы игнорировать его в собственных разработках.
В значительной степени задачу централизованного администрирования распределенной БД позволяет решить Oracle Enterprise Manager, поставляемый сейчас в комплекте с сервером БД. Этот программный продукт позволяет с помощью графического интерфейса управлять сколь угодно сложной конфигурацией распределенной БД, включая возможность определения удаленных заданий, выполняемых по заданному расписанию, извещения о различных событиях в системе и т.п.
Кроме этого, в состав программного продукта включен ряд утилит, выполняющих детальный мониторинг серверов БД, оптимизацию их параметров. В их состав входит также Oracle Expert - экспертная система, позволяющая провести оптимизирующую настройку любого сервера.
Важно еще и то, что Oracle Enterprise Manager предоставляет открытый интерфейс, позволяющий дополнять управляющую консоль администратора новыми средствами как третьим фирмам, так и самим пользователям. Можно рассчитывать поэтому на то, что в самое ближайшее время большая часть существующих на рынке средств централизованного администрирования систем на основе Oracle объединится в интегрированную управляющую среду.
3. Oracle на практике в отделе снабжения
3.1 Обязанности отдела снабжения
Процесс снабжения, а точнее осуществление закупок материально-технических ценностей, является стартовой ступенью для работы на предприятии, а от эффективности их функционирования зависят показатели всей производственно-хозяйственной деятельности. Абсолютно все предприятия нуждаются в снабжении, разница лишь в объемах и направленности, где-то раз в квартал закупаются лишь канцтовары и кофе, а где то в этот процесс вовлечены сотни людей и тратятся миллионы рублей.
Основной задачей отдела снабжения предприятия является своевременное и оптимальное обеспечение производства необходимыми материальными ресурсами соответствующей комплектности и качества. Решая эту задачу, работники отдела снабжения должны изучать и учитывать спрос и предложение на все потребляемые предприятием материальные ресурсы, уровень и изменение цен на них и на услуги посреднических организаций, выбирать наиболее экономичную форму товародвижения, оптимизировать запасы, снижать транспортно-заготовительные и складские расходы. В общем виде сущность организации снабжения заключается в ритмичном и своевременном обеспечении производственного процесса необходимыми предметами производственно-технического назначения и товарами, так как от этого зависит весь процесс производства, а следовательно, и конечный результат - выпуск в поставленные сроки определенного вида продукции или услуг. Несоблюдение сроков поставки или несвоевременное обнаружение недостающей продукции на любом этапе, становится причиной нарушения сроков изготовления промежуточной или конечной готовой продукции в последующих звеньях цепи. При этом несоблюдение требований к заказываемым и поставляемым материальным ресурсам по качеству, цене приводит к увеличению себестоимости выпускаемой продукции. В свою очередь, своевременная поставка производству материальных ресурсов необходимого качества, комплектности и ассортимента позволяет сократить затраты труда на изготовление продукции и потери времени в связи с простоем оборудования или трудовой силы при отсутствии материальных ресурсов.
3.2 Информационное обеспечение комплексных задач
Информация столь же необходима управленческому аппарату, как объекту управления - сырье и ресурсы. Она формируется в результате обработки специфического сырья, известного под названием данные. Последние отражают конкретные финансово-хозяйственные факты, состояние или процессы и имеют собственный материальный носитель (бухгалтерские и финансовые документы, сигналы, поступающие от датчиков, дисплеи, магнитные носители и т.д.). Разработку проведем на базе системы управления базами данных (СУБД) ORACLE
Данная СУБД была выбрана по следующим причинам:
·простота средств реализации,
·легкость освоения инструментарием разработчика,
·наглядность визуализации информации.
Базы данных созданные с помощью системы управления базами данных ORACLE полностью реализует реляционную модель построения данных. База данных ORACLE представляет собой набор групп объектов, таких как таблицы, запросы, формы, отчеты.
Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:
·один-к-одному;
·один-ко-многим;
·многие-к-одному;
·многие-ко-многим.
Структура организации таблиц позволяет создание первичных и внешних ключей. Имеется возможность изменения типа внутренних объединений для связанных таблиц.
База данных отдела снабжения должна хранить данные, исходящие из взаимоотношений отдела с другими подразделениями предприятия:
инфологическая или информационная модель (схема данных) и ее описание предполагает моделирование входных, промежуточных и результатных информационных массивов предметной области и их характеристика.
Необходимо детально освятить как на основе входных документов и нормативно справочной информации происходит обработка с использованием массивов оперативной информации и формирования выходных данных.
Рассмотрим схему информационных потоков данных.
Входная информация
КодНаименованиеОтравитель-получательПериодичность1Приходная накладнаяГоловной офис-Подразделение1 раз в неделю2Прайс-листГоловной офис-Подразделение1 раз в неделю3Расходная накладнаяПодразделение-ПокупательПри продаже4СчетПодразделение-ПокупательПри покупке по безнал. расчету5Счет-фактураПодразделение-ПокупательПри продаже6Квитанция ПКОПодразделение-ПокупательПри покупке за нал. расчет7Расходная накладнаяПодразделение-СкладПри продаже
Выходная информация
КодНаименованиеОтравитель-получательПериодичность8Доверенность получ. товараПокупатель-подразделение-головной офисПри покупке по безнал. расчету9Платежное поручениеПокупатель-подразделение-подразделениеОплата за товар10Расходная накладнаяСклад-ПодразделениеПри продаже11ОтчетностьПодразделение-головной офис2 раза в неделю
3.3 Описание структуры базы данных
В результате анализа предметной области выявляются документы - источники данных для создания базы данных.
Особо отметим, что документы предметной области не только дают возможность выявить структуру данных, но и являются основой для разработки форм ввода / вывода, отчетов для печати документов.
Список тренажерных устройств:
Таб. Номер Наименование Вес (сопротивление)
Вся информация вводится через экранную форму. Описание входной информации содержит файлы и справочники. Перечень тренажерных устройств:
Наименование реквизитаИдентификаторЗначение реквизитаТабельный номерTABkeyНаименованиеNTextВес (сопротивление) VNumber
Перечень выполняемых упражнений:
Наименование реквизитаИдентификаторЗначение реквизитаКод упражненияTIPkeyНаименованиеNTextВес (сопротивление) VNumber
Выходная информация включает в себя отчет, запросы и файлы. В данном проекте главной выходной формой будет следующая таблица, реализованная программно, она является выходным файлом, на основе которого формируются запросы.
Инфологическая или информационная модель (схема данных) и ее описание предполагает моделирование входных, промежуточных и результатных информационных массивов предметной области и их характеристика. Необходимо детально освятить как на основе входных документов и нормативно справочной информации происходит обработка с использованием массивов оперативной информации и формирования выходных данных.
3.4 Схема информационных потоков данных
Содержание потоков данных расшифровывается в таблице входная информация и таблице выходная информация.
Таблица 1: Входная информация
КодНаименованиеОтравитель-получательПериодичность1Приходная накладнаяГоловной офис-Подразделение1 раз в неделю2Прайс-листГоловной офис-Подразделение1 раз в неделю3Расходная накладнаяПодразделение-ПокупательПри продаже4СчетПодразделение-ПокупательПри покупке по безнал. расчету5Счет-фактураПодразделение-ПокупательПри продаже6Квитанция ПКОПодразделение-ПокупательПри покупке за нал. расчет7Расходная накладнаяПодразделение-СкладПри продаже
Таблица 2: Выходная информация
КодНаименованиеОтравитель-получательПериодичность8Доверенность получ. товараПокупатель-подразделение-головной офисПри покупке по безнал. расчету9Платежное поручениеПокупатель-подразделение-подразделениеОплата за товар10Расходная накладнаяСклад-ПодразделениеПри продаже11ОтчетностьПодразделение-головной офис2 раза в неделю
Рассмотрим атрибуты каждого из этих пунктов.
Вся информация вводится через экранную форму.
Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).
После запуска программы для учета ОС и МЗ в отделе снабжения и закупок появляется главная форма, и пользователь получает доступ к главному меню программы (Рис.1). На главной форме в строке состояния показаны текущая дата и время, а также общее количество объектов ОС и МЗ, полученных в результате запроса.
3.5 Главная форма программы
На данной форме возможен просмотр всех объектов выбранного МОЛ и их реквизитов:
·инвентарный номер;
·наименование объекта;
·единицы измерения;
·количество объектов;
·сумма;
·номер счета поступления ОС или МЗ;
·дата поступления;
·поставщик;
·лицо, получившее в пользование данный объект ОС или МЗ;
·место нахождения объекта на данный момент;
·номер инвентарной карточки, присвоенный данному объекту.
Эти данные можно отредактировать, выбрав нужный объект и нажав кнопку.
·Поиск МОЛ
Возможен поиск интересующего МОЛ по первым буквам фамилии при этом вся информация об объектах, за которые он несет материальную ответственность, отражаются в таблице "Объекты ОС и МЗ".
·Поиск объекта
Кроме того, реализован поиск объекта / объектов ОС или МЗ по значениям инв. номера, наименованию объекта, а также по другим реквизитам.
·Списание объекта
После того, как объект выбран, его можно списать. Для этого необходимо ввести данные о списании (кол-во, сумма и дата списания) в таблицу "Списание выбранного объекта". При этом инвентарный номер списываемого объекта заносится в таблицу автоматически.
·Вкладка "Списанные объекты"
После того, как объект был списан, информация о его списании отражается в таблице на вкладке "Списанные объекты" при нажатии на кнопку "Перечень списанных ОС и МЗ". При этом формируется соответствующий документ о списанных объектах. Его можно сохранить в любую директорию с расширением. xls либо напечатать.
·Вкладка "Добавление и удаление"
После сохранения документа на вкладке "Добавление и удаление" можно удалить списанные объекты, если имеется уверенность в правильности списания объектов, для этого необходимо выбрать интересующий объект и нажать кнопку.
Добавление нового объекта производится нажатием на кнопку. Для удобства поиска интересующего объекта предусмотрен поиск МОЛ, отвечающего за данный объект по первым буквам фамилии.
Кроме того, информацию можно корректировать.
·Справочник "МОЛ"
В справочнике "МОЛ" хранится информация обо всех материально ответственных лицах. Этот справочник можно пополнять новыми данными о новых материально ответственных лицах, удалять записи о некоторых МОЛ, редактировать информацию об определенном МОЛ.
·Справочник "Счета объектов"
В справочнике "Счета объектов" хранится информация о тех объектах, для которых указан счет поступления, дата поступления, номер инвентарной карточки, получатель и место нахождения объекта.
При нажатии на кнопку печати формируется отчетный документ обо всех таких объектах. Этот отчет можно сохранить и распечатать.
·Справочник "Перечень объектов"
В справочнике "Перечень объектов" хранится информация обо всех объектах, находящихся на учете с указанием ответственных лиц.
При нажатии на кнопку печати формируется отчетный документ обо всех объектах. Формирование отчета может занять некоторое время, так как обрабатывается большой массив данных. На время формирования документа на кнопке печати появляется надпись. Этот отчет можно сохранить и распечатать.
·Списание выбранного объекта
Чтобы списать выбранный объект, в таблице "Списание выбранного объекта" заполняем поля: кол., сумма и ставим дату списания. Принимаем изменения.
·Просмотр списка списанных с учета объектов
После этого на вкладке "Списанные объекты" появляется запись о списанном нами объекте. При печати списка списанных с учета объектов формируется отчетный документ "Перечень списанных объектов на дату".
Кроме того, можно сформировать отчеты "Перечень всех объектов ОС и МЗ" и "Счета объектов", при этом в этих отчетах будет отражена информация о добавленном МОЛ и находящемся у него объекте ОС.
Заключение
Таким образом, путем контрольного примера удалось доказать работоспособность системы и ее соответствие поставленным задачам. Все функционирует правильно, без сбоев, изменения фиксируются в соответствующих таблицах, и по запросу пользователя формируются отчетные документы с учетом внесенных изменений.
Даже без дальнейшей детализации уже ясно, что за 15 лет Oracle на ММК превратился из "золушки" в основное средство КИС.
Использование автоматизированной информационной системы в реальных условиях позволит повысить эффективность работы и уменьшить издержки.
Переход к автоматизированному методу делопроизводству дает возможность:
·наладить комплексное управление документированной информацией в единой автоматизированной среде;
·получить целостную картину поступления и составления документов;
·проводить согласование документов в электронной форме;
·контролировать все операции, связанные с организацией документооборота;
·повысить эффективность и качество управления, так как минимальная трудоемкость при организации работы с документами позволяет работникам структурного подразделения рационально планировать свою деятельность.
Создание АИС способствует повышению эффективности производства экономического объекта и обеспечивает качество управления.
Включение электронных документов в делопроизводственный цикл позволяет перейти на качественно новый уровень эффективности работы с документами, поскольку технологии работы с ними (редактирование, перемещение, тиражирование и др.) принципиально более эффективны.
Что создает основу для интеграции всех документационных технологий в единый комплекс, включая средства сканирования документов и распознавания текстов, средства обработки и пересылки электронных документов, приема и передачи факсимильной информации, печати и тиражирования документов и т.д.
Использование данной автоматизированной системы электронного документооборота в реальных условиях приведет к улучшению ряда экономических показателей:
·улучшение значений показателей качества обработки информации (повышение степени достоверности обработки информации, степени ее защищенности, повышение степени автоматизации получения первичной информации);
·увеличение числа обслуживаемых клиентов.
К составляющим эффективность при использовании данной системы электронного документооборота можно отнести также следующее:
·во всех подразделениях и в организации в целом вводится унифицированная, формализованная и строго регламентированная технология делопроизводства;
·организация становится полностью управляемой;
·система автоматизации делопроизводства, по сути, является носителем строго формализованной и документированной технологической информации о правилах и порядке работы с документами;
·создаются условия для резкого ускорения прохождения документов по организации, особенно при организации электронного документооборота.
·минимизируется трудоемкость делопроизводственных операций. При этом, однако, надо иметь в виду, что необходимость ввода полной и точной информации о документе, скажем, при первичной регистрации может потребовать дополнительных усилий на некоторых рабочих мест, тогда как трудоемкость работы на других рабочих местах, использующих эту информацию, может сократиться, как показывает опыт, в несколько раз.
·качественный выигрыш достигается организации взаимоувязанного электронного документооборота между организациями.
Сегодня эффективность управленческой деятельности зависит в первую очередь от автоматизации всех управленческих процессов. Таким образом, успешная автоматизация управления предприятием будет зависеть от правильного выбора автоматизированной системы.
Список использованной литературы