78528

Построение системы управления поставками и маркетинга для крупного металлургического холдинга «КарМет»

Дипломная

Информатика, кибернетика и программирование

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

Русский

2015-02-08

19.86 MB

2 чел.

Оглавление.

[1]
Введение

[2]
Обследование объекта автоматизации

[2.1] Общие сведения об организации «КАРМЕТ».

[2.1.1] Профиль работ организации «КАРМЕТ»

[2.1.2] Организационная структура организации «КАРМЕТ»

[2.1.3] Структура отдела

[2.2] Управление процессом поставки

[2.3] Интеграция между отделами в процессе поставок

[2.4] Участники системы управления

[2.5] Обзор существующих систем планирования ресурсов предприятий

[2.6] Существующие проблемы

[2.7] Выводы

[3]
Техническое задание на подсистему управления поставками

[3.1] Общие сведения

[3.2] Исходные данные для выполнения работ

[3.3] Цели и назначение системы управления

[3.3.1] Цели подсистемы управления Сбытом

[3.3.2] Назначение подсистемы управления Сбытом

[3.4] Термины и определения

[3.5] Характеристика объекта автоматизации

[3.6] Требования к системе управления

[3.6.1] Требования к подсистеме Сбыта

[3.6.1.1] Общие требования

[3.6.1.2] Требования к надежности

[3.6.1.3] Требования к функциям, выполняемым подсистемой

[3.6.1.4] Требования к защите информации от несанкционированного доступа

[3.6.1.5] Требования к эргономике и технической эстетике

[3.6.1.6] Требования по стандартизации и унификации

[3.6.2] Требования к видам обеспечения

[3.6.2.1] Требования к программно-техническому обеспечению

[3.6.2.2] Требования к организационному обеспечению

[3.6.2.3] Требования к методическому обеспечению

[3.6.3] Требования к персоналу системы

[3.7] Объем автоматизации и архитектура системы управления

[3.7.1] Объем автоматизации системы управления

[3.7.2] Архитектура системы управления

[3.7.2.1] Описание архитектуры системы управления (не пойму в какую часть засунуть???)

[3.7.2.2] Требования к информационно-техническому оснащению

[3.7.2.3] Обмен данными между участниками системы управления.

[3.8] Состав этапов и работ разработки подсистемы

[3.9] Порядок приёмки и контроля системы управления

[3.10] Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

[3.11] Требования к документированию

[4]
Исследовательская часть

[4.1] Теоретические основы конфигурации производственных объектов

[4.1.1] Таксономия и мерономия

[4.1.2] Типы классификаций

[4.2] Выбор системы классификации

[4.2.1] Основные термины

[4.2.2] Назначение классификатора

[4.2.3] Методы классификации

[4.2.3.1] Иерархический метод классификации или древовидный

[4.2.3.2] Фасетный метод классификации или

[4.2.3.3] Методы кодирования в классификаторах

[4.2.4] Обзор существующих систем классификации

[4.2.4.1] Способы хранения данных

[4.2.4.2] Исследование конфигурации продукции в разных системах классификации и возможности интеграции SAP системы с системами классификации.

[4.2.4.3] Выбор системы классификации

[4.2.4.4] Структура Базовой системы классификации SAP на базе платформы SAP Netweaver

[4.2.5] Основные понятия

[4.2.6] Связи между признаками и их значениями

[4.2.7] Список процедур

[4.2.8] Возможности

[4.2.9] Основная продукция – классы, признаки.

[4.2.10] Средства разработки

[4.2.11] Разработка структуры базы знаний

[4.2.12] Описание отношений на примере рулонной стали

[4.2.13] Алгоритм сбора значений свойств выбранного объекта

[4.2.14] Алгоритм сбора состава выбранного объекта… .

[4.2.15] Алгоритм работы базы знаний

[4.2.16] Текст программы работы базы знаний

[5] Концептуальное проектирование

[5.1] Цели создания информационной системы управления поставками

[5.2] Цели создания системы классификации

[5.3] Основные принципы разработки информацонной системы системы

[5.4] Основные принципы заложенные в разрабатываемую систему

[5.5] Выбор Case средств при создании системы

[5.6] Функциональная структура TO-BE

[5.7] Состав подсистемы управления поставками

[5.8] Целевое задание на разработку

[5.9] Информационная модель подсистемы

[6] Техническое проектирование

[6.1] Блок-схема алгоритма работы подсистемы

[6.2] Описание алгоритма работы подсистемы управления заказами.

[7] Рабочее проектирование

[7.1] Руководство пользователя Для начала работы с подсистемой требуется войти в систему.

[7.2] Основные модули программы и их свойства

[7.3] Текст программы «Подсистема создания заказа клиента»

[8]
Сравнительный анализ подсистемы управления поставками.

[8.1] Сравнение систем управления поставками

[9] Оценка среднего объема базы знаний и времени поиска информации

[9.1] Расчет среднего объема базы знаний SAP

[9.2] Расчет времени поиска информации

[10]
Экономическая часть

[10.1] Организация и планирование процесса разработки программного продукта

[10.2] Определение стоимости разработки программной продукции

[11] Промышленная экология и безопасность

[11.1] Введение.

[11.2] Требования безопасности при работе с подсистемой управления поставкми

[11.2.0.1] Уровни ионизации воздуха помещений при работе на ВДТ и ПЭВМ

[11.2.0.2] Допустимые нормы вибрации на всех рабочих местах с ВДТ и ПЭВМ

[11.3] Расчет общего искусственного освещения на рабочем месте оператора

[12]
Заключение

[13]
Список литературы


Аннотация

В данной работе решалась задача построения системы управления поставками и маркетинга для крупного металлургического холдинга «КарМет».

Для этого было проведено обследование организации с целью построения системы управления, выделены основные функции, которые нуждаются в автоматизации. Принято решении о создании системы управления маркетингом на основе программного продукта SAP/R3 и разработке дополнительной подсистемы классификации конфигурируемых материалов.

В результате обследования была построена функциональная модель планирования и контроля основной деятельности организации «КарМет», в которой выделены функции, которые необходимо автоматизировать с помощью подсистемы управления маркетингом.

Было разработано техническое задание на подсистему маркетинга.

Была сформулирована постановка задач подсистемы классификации основных видов готовой продукции. Проведено исследование подходов организации систем поддержки НСИ. Выбрана система классификации, которая позволяют отражать сложные структурированные продукты, состоящих из нескольких уровней компонентов.

В результате работы разработана и реализована в единой информационной среде подсистема управления поставками на базе SAP/R3. Эта подсистема позволяет вести версии заказов клиента, управлять изменением единиц поставки, использовать систему классификации.

Проведен сравнительный анализ с базовыми функциями SAP/R3, который показал значительную эффективность созданной подсистемы. Оценка среднего объема базы знаний и времени поиска информации.

  1.  
    Введение

В настоящее время для решения различных задач планирования и контроля широко применяются ERP системы.

Традиционные информационные системы изначально были функциональной основой для множества организаций или функциональных сфер, но не могли объединять их в случае их географической распределенности. Одну и ту де информацию собирали многократно и во многих местах, и она была недоступна в реальном времени. В результате некоторая информация никогда не выходила за пределы отдельных подразделений корпораций. Определение процессов и работ было направлено на то, чтобы информация удовлетворяла локальным требованиям. Соответственно глобальные информационные отчеты об одних и тех же событиях часто были разными.

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

В результате ERP системы привели к улучшению возможности принятия решений, которые проявляются в широком ряде показателей, таких как сокращение запасов, сокращение штатов, ускорение закрытия финансовых процессов.

В данном дипломном проекте рассматривается построение системы управления маркетингом для предприятия  «КарМет». В качестве базового программного обеспечения использована ERP  система SAP/R3. В данной системе не разработана подсистема классификации, которые указаны выше. Поэтому была поставлена задача создать классификатор, позволяющий отразить сложные структурированные продукты состоящие из нескольких уровней компонентов.

В рамках дипломного проекта рассматривается создание системы управления заказами «КарМет», эта система должна обеспечить ведение вариантов заказов клиента с использованием классификатора. В целях создания системы управления необходимо провести обследование организации «Кармет».

  1.  
    Обследование объекта автоматизации
    1.  Общие сведения об организации «КАРМЕТ».

Холдинг имеет компании в 4 региональных центрах России.

Группа компаний “Кармет” имеет разветвленную сеть региональных представительств с технически оснащенными металлобазами в Санкт -Петербурге, Екатеринбурге, Челябинске и Омске.

Центральный офис Группы компаний располагается в г. Москве.

  1.  Профиль работ организации «КАРМЕТ»

Группа компаний “КарМет” – это динамично развивающийся холдинг, объединивший в себе 5 направлений деятельности:

  1.  поставка сортового и плоского металлопроката 
  2.  поставка трубной продукции широкого сортамента
  3.  поставка железнодорожных колес, комплектующих для подвижного состава, рельс и элементов верхнего строения пути;
  4.  поставка сельскохозяйственной продукции.

заводов и комбинатов России и стран СНГ.

Закупка металлопроката у производителя осуществляется по долгосрочным договорам, в которых отражены фиксированные объемы закупок. На основании этих договоренностей формируется производственная программа на год по всем позициям. Заказы клиента покрываются этим объемом.

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

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

На основании производственной программы определяются объемы предстоящего производства. Также возможна поставка проката сразу от поставщика к клиенту.

Для планирования и управления производством, учета затрат на резку   используется производственный заказ. Процесс производства инициируется сбытовым заказом на производимую позицию.

В случае, если планирование и управление производственным процессом, а также учет затрат на резку не требуется, возможна упрощенная процедура деления партии, позволяющая получить заданный размер металлопроката.

  1.  Организационная структура организации «КАРМЕТ»

Для исследуемого предприятия можно выделить следующие подразделения

На  приведено графическое представление организационной структуры организации «КарМет».

Рис. . Организационная структура металлургического холдинга «КарМет»

  1.  Структура отдела

Внутренняя структура отдела строится следующим образом:

На  приведена структура отдела Маркетинга «КАРМЕТ»

Рис. . Структура отдела по маркетингу «КАРМЕТ»

  1.  Управление процессом поставки

В результате обследования была сформирована функциональная модель управления поставками .

Рис. . Функциональная схема процессов управления поставками

Управление процессом разбивается на следующие основные этапы:

Исследование рынков сбыта. Этот этап подразумевает написание планов маркетинга, поиск новых направлений и сфер для развития бизнеса, поиск новых клиентов и поставщиков; Анализ ценовой политики конкурентов и конъюнктуры рынка; Анализ конкурентов, мониторинг рынка. Рекламно – маркетинговые мероприятия. Анализ Российского и зарубежного рынка металлопроката, ,проведение маркетинговых исследований анализ рынка и сбор информации, планирование, написание отчета, анализ продаж; Маркетинговые мероприятия ведутся Отделом сбыта с планированием затрат:

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

Все эти операции утверждаются зам. ген. директора по сбыту.

  1.  Заключение контракта и создание заказа клиента. Это один из основных этапов, функциональная модель планирования приведена на .

Рис. . Функциональная схема создания заказа клиента

Запросы регистрируются в Отделе сбыта и прорабатываются на возможность исполнения руководителями Отдела сбыта. С клиентом согласовываются сроки поставки, и после этого утверждается проект, а затем подписывается договор.

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

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

Исполнение подписанного договора контролируется начальником Отдела сбыта.

Отделом сбыта также могут вестись заказы клиентов, исполняемые в течение месяца. Их проработка и контроль аналогичны долгосрочным договорам.

  1.  Поставка продукции

Создается портфель заказов.

Портфель заказов формируется на основании следующих данных;

  •  сроки поставки по экспортным контрактам;
  •  писем с заказом на изготовление по долгосрочным договорам;
  •  месячных заказов клиентов;
  •  данных по переходящим и невыполненным месячным заказам.

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

Планирование суточной отгрузки

Основанием для планирования суточной отгрузки является наличие следующих документов:

  •  План отгрузки в натуральном выражении (месячный);
  •  Утвержденное от заказчика письмо на отгрузку (по договорам);
  •  Справка об остатках готовой продукции.

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

Отгрузка ОГП

После отгрузки оформляются следующие документы:

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

Оформление накладной на ОГП

В случае самовывоза экономистом отдела сбыта 1 категории оформляется накладная для получения продукции и утверждается начальником отдела сбыта.

Отгрузка на самовывоз

После отгрузки по накладной оформляются следующие документы:

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

После обработки справок об отгруженной продукции из цехов зам. нач. отдела сбыта составляется отчет о ежесуточной отгрузки инженером сбыта 1 категории.

В конце месяца экономистом отдела сбыта 1 категории проводится сверка данных ежесуточных отчетов и сведений из цехов, выявляются причины возможных расхождений, и формируется ежемесячный отчет.

  1.  Контроль выполнения контрактов/заказов

Основанием для исполнения договора, кроме него самого, служит заявка на оказание услуг или отпуск материалов.

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

  1.  Формирование отчетов

В конце месяца формируются отчеты по цехам необходимые для выписки счетов-фактур.

  1.  Интеграция между отделами в процессе поставок

Прием заявки покупателя.

Прием заявок покупателей ведется на постоянной основе тремя подразделениями предприятия: отделом маркетинга и отделом договоров – заявки на поставку на внутренний рынок, отдел конъюнктуры внешнего рынка - заявки на поставку на экспорт. Заявка от покупателя поступает в свободной форме по любому средству связи (телефон, факс, E-mail) и при личном обращении. Первичные заявки не регистрируются.

Рассмотрение заявки и заключение договора (сделки).

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

  •  Отдел маркетинга, отдел договоров, Управление сбыта на основании информации о работе с покупателем в предыдущие периоды и маркетинговой информации формируют предложения по ценам, формам, видам и порядку оплаты;
  •  Финансовое управление формирует предложения по ценам, формам, видам и порядку оплаты;
  •  Планово-экономическое управление  на основании данных о фактической себестоимости, действующих прейскурантов цен, предложений по ценам рассчитывает плановую себестоимость по всей программе продаж;
  •  Отдел маркетинга на основании расчета Планово-экономического управления проводит анализ эффективности планируемого договора (сделки);
  •  Коммерческая служба на основании заявки покупателя определяет потребность в сырье и подтверждает возможность исполнения заказа в предполагаемые сроки (для крупных заказов);
  •  Отдел технического контроля рассматривает возможность изготовления заказа по качественным характеристикам;
  •  Финансовое управление и Главная бухгалтерия сверяет состояние взаиморасчетов с покупателем и правильность указанных банковских реквизитов;
  •  Юридическое управление  контролирует правильность оформления договора;
  •  Отдел маркетинга, отдел договоров, Управление сбыта проводят необходимые дополнительные согласования с покупателем и руководителями вышеперечисленных подразделений по существу заказа и срокам его исполнения.
  •  Подписывается договор, Соглашение, Таблица соглашений, формируется спецификация по форме.

Планирование продаж.

Отдел маркетинга и отдел договоров формируют таблицу заявок на основании заключенных договоров и согласованных заявок покупателей. Планово-экономическое  управление передает в отдел маркетинга баланс металла на месяц. Отдел конъюнктуры внешнего рынка и отдел экспорта на основании заключенных контрактов и спецификаций, данных о переходящих заказах, баланса металла  формируют проект экспортного плана продаж. Проект экспортного плана передается в отдел маркетинга для согласования. Отдел маркетинга на основании всей полученной информации формирует месячный план отгрузки на внутренний рынок. План продаж на экспорт и план отгрузки на внутренний рынок проходит итерационную процедуру согласования в Планово-экономическом управлении, Производственном управлении, Коммерческой службе, отделе маркетинга.

При приеме текущих заказов план продаж и производственная программа подвергаются оперативной корректировке. Текущие заказы покупателей на внутреннем рынке должны проходить процедуру согласования, приведенную выше. Покупатели, сроки выполнения заказов которых изменились в связи с проведением корректировки, в известность ставятся по их запросу в подразделения Службы маркетинга и сбыта. При выдаче заказа отдел договоров сверяет состояние взаиморасчетов с покупателем в Финансовом управлении. Управление сбыта готовит распоряжение спец. цены, описи заказа, спецификации – основание для сбыта.

Отгрузка продукции.

Контроль исполнения заказа и оперативное информирование покупателя осуществляют отдел маркетинга, отдел договоров, отдел сбыта – для покупателей внутреннего рынка; отдел конъюнктуры внешнего рынка, отдел экспорта – для покупателей внешнего рынка. Контроль выполнения заказа по стадиям затруднен ввиду отсутствия документированных форм передачи оперативных данных о сдаче продукции по сортаменту из производственных подразделений в Службу маркетинга и сбыта. Проведение недокументированных корректировок в производственной программе и таблице заявок вносит дополнительные трудности при определении сроков реальной готовности того или иного заказа. Сотрудники и руководители Службы маркетинга и сбыта осуществляют контроль выполнения заказов, запрашивая в устной форме у руководителей Производственного управления информацию о фактических результатах на переделах.

При получении информации о готовности заказа к отгрузке отдел договоров, отдел маркетинга, Финансового управления и Главная бухгалтерия осуществляют сверку взаиморасчетов с покупателем. При получении Разрешения на отгрузку продукции отдел договоров и отдел маркетинга готовят задание на отгрузку продукции. При получении сдаточных документов, задания и разрешения на отгрузку производственный цех, Управление железнодорожного транспорта или Автотранспортное управление организуют отгрузку продукции. Управление сбыта оформляет все документы на отгрузку (комплект ж/д накладных, пропуск на вывоз, сертификаты и др.). При получении счета-фактуры на выполнение работ отдел договоров и Управление сбыта сверяют состояние взаиморасчетов с покупателем в Финансовом управлении и закрывают заказ. В случае возникновения претензий у покупателя их рассмотрение проводят Управление сбыта и отдел договоров совместно с Юридическим управлением, по необходимости привлекаются отдел технического контроля, производственный цех, Финансовое управление, Главная бухгалтерия.

Анализ эффективности договора (сделки).

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

Рис. . Схема взаимодействия между отделами


  1.  Участники системы управления

В результате обследования были определены участники системы управления. Состав участников системы управления представлен в .

Табл. . Состав участников системы управления поставками

Участник

Выполняемая функция

Менеджеры

Подготовка контракта, переговоры с покупателями

Контрактный отдел(бюро СНГ,Дальнее Зарубежье)

Оформление контрактов,

расчет денежных средств , заявки на план перевозок,

заявки на производство, -

оформление заказов,

учет отгрузки и отправки

вагонов,

информирование покупателя об отгрузке.

Контрактный отдел Фингруппа

Подготовка аккредитивов, получение чек-листов

выставление счет-проформы покупателю,

учет отгрузки по аккредитивам и предоплате и фактического поступления денежных средств

Контрактный отдел Информационное бюро

Ввод информации по отгрузке из цехов в общую базу данных, корректировка информации в базе данных, выдача информации по загрузке, отгрузке и отправке

Отдел поставок

Оформление и выдача приказ-счетов, работа с цехами, контроль денежных средств,

заявка на план перевозок СНГ, учет загрузки, отгрузки и отправки  

Отдел маркетинга Бюро информации и

рекламы

Реклама, презентации, выставки, буклеты, каталоги

Отдел маркетинга Бюро маркетинговых

исследований рынков

сбыта

Исследование рынков сбыта, анализ, рекомендации по ценовой политике, Обеспечение сбыта КХП, и прочей продукции

Отдел маркетинга Аналитическое бюро

Подготовка отчетов.

Начальники отделов

Отслеживание хода выполнения работ своего отдела, утверждение табелей исполнителям. Ввод оценки сроков и трудозатрат до окончания работ.

  1.  Обзор существующих систем планирования ресурсов предприятий

На российском рынке представлено много программных пакетов обеспечения бизнеса. Их можно отнести к трем классам.

Системы малого класса - предназначены для решения отдельных функциональных задач или операций, таких как ведение главной книги, расчет зарплаты, выписка счетов или накладных, архив документов, расчет себестоимости на производстве одного вида. Производители этих пакетов за редким исключением имеют небольшой опыт развития и внедрения (не более 5-7 лет), что является одной из причин их отставания от систем более высокого класса. Большинство российских систем соответствуют этому классу. Основные черты этих пакетов таковы:

невозможность ведения учета для нескольких юридических лиц в рамках одной системы

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

использование при разработке простых программных систем и систем управления базами данных (Clipper, FoxPro, Clarion…), что позволяет быстро осуществить внедрение, но, с другой стороны, лишает гибкости при настройке и расширении функциональности

ограничение в наращиваемости размера системы (по объему информации, по количеству рабочих мест и организационных единиц, географическому распределению).

К этой группе относятся пакеты: 1С, ИНФИН, АБАКУС, Pegasus Capital, Ledger 2000 .

Системы среднего класса - предназначены для поддержки группы функциональных задач в рамках отдельных областей бизнеса, таких как финансовая бухгалтерия, офисный документооборот, складской учет, учет на производстве и т.д. Пакеты этой группы, как правило, имеют большую предысторию развития и в значительной степени используют старую базу программных разработок. Хотя в мире установлено очень большое количество таких систем, они отстают от “лидеров” в решении современных проблем интеграции информации крупных компаний. Особенности:

не достаточно развитая функциональность системы, необходимая для организации управления крупной компанией в России

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

ограничение наращиваемости системы - объема проводок, количества и территориального удаления рабочих мест.

Сюда относят пакеты: Нордис/2, Scala, Platinum, SOCAP, CA AccPak, CA Masterpiece/2000.

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

наличие развитой функциональности системы, настроенной на разные виды бизнес-процессов и автоматизированную взаимосвязь между ними

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

развитая методика внедрения, направленная на достижение конкретных целей проекта, основанная на встроенных моделях внедрения и моделях бизнес-процессов

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

сложность настройки при внедрении систем с расширенной функциональностью приводит к большой длительности внедрения (6-18 месяцев) и значительной величине затрат при внедрении.

Сюда относят пакеты: Галактика, Oracle Applications, SSA BPCS, BaaN IV, JD Edwards, SAP R/2-R/3, CA ManMan/X, CSBI ЕЕ MFGPRO-PROMIS и другие.

Обзор программных пакетов.

1C

Пакет "1С: Бухгалтерия" является одним из самых популярных на рынке бухгалтерских систем для малого бизнеса, обеспечивая компании 1С лидирующее место среди российских компаний - производителей бухгалтерского программного обеспечения. Однако, данная система предоставляет только отдельные бухгалтерские функции, не позволяя осуществлять интеграцию учета в целом, и не обладает возможностями аналитики. Кроме того, система рассчитана на малое количество пользователей.

ИНФИН

Бухгалтерская система ИНФИН распространяется одноименной российской аудиторской компанией. Это чисто бухгалтерская система, не предусматривающая возможности поддержки некоторых функций, необходимых для поддержки деятельности крупного предприятия в целом. ИНФИН не поддерживает международный стандарт бухучета, невозможно вести учет для нескольких компаний одновременно.

Нордис/2

Это базирующаяся на технологии клиент/сервер финансовая система, предложенная к разработке и внедрению в нефтегазовых и других компаниях Сибири Экономическим Центром Новосибирского университета. Поддерживаемые пакетом функции включают бухучет, обработку заказов на закупку и поставку, управление персоналом. В предложении Центра косвенно указывается, что часть функциональности пакета не доведена до продуктивной версии, находясь на стадии программной разработки. Многие расширенные возможности (аспекты аналитики и консолидации) пока еще нигде не внедрены, что повышает риск внедрения пакета в 1997-98 годах.

Platinum

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

Scala

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

SSA BPCS

Фирма SSA является ведущей в области разработки программных продуктов для платформы AS/400.

BPCS (Business Planning and Control System) - система планирования и управления предприятием любого профиля. Система BPCS разработана для компьютеров AS/400 фирмы IBM и предназначена для автоматизации бухгалтерского учета, коммерческой деятельности предприятия (сбыт и снабжение), планирования и управления производством, поддержки принятия решений.

Система BPCS в общей сложности состоит из более чем 40 взаимосвязанных программных продуктов-модулей, созданных на базе специально разработанного CASE-средства. Эта система предназначена для управления как непрерывными, так и дискретными производствами, а также поддерживает деятельность предприятия, состоящего из нескольких самостоятельных независимых производств. Есть средство внедрения BASIS - BPCS Advanced Systems Implementation Strategy.

Русифицирована версия, работающая на платформе AS/400, клиент-серверная версия на UNIX-платформе пока не русифицирована. В России заключено 9 контрактов с фирмами, занимающимися в основном торговой деятельностью.

Галактика

Программный комплекс "Галактика", разработанный совместно компаниями "Новый Атлант" (Москва) и "Топ софт" (Минск), появился на российском рынке в 1995 году. Это интегрированная система управления предприятием, предлагаемая в виде набора из 4 главных модулей: бухгалтерия (главная книга, основные средства, зарплата, финансовая отчетность), администрация (маркетинг, планирование финансов, управление персоналом), оперативное управление (продажи и закупки, складской учет) и планирование производства. "Галактику" можно рассматривать как одну из наиболее развитых интегрированных систем, разработанных в России. Всего - около 50 установок. Поддерживаемыми на данный момент платформами являются Novell и Windows NT.

JD Edwards

Компания JD Edwards & Co., образованная в Денвере, Колорадо в 1977 году, является крупным производителем программного обеспечения для поддержки бухучета, производства и сбыта на базе AS/400. На европейском рынке наиболее известна ее версия "One World", внедряемая на платформах UNIX и NT, поддерживающая трехуровневую архитектуру клиент-сервер, она пока не русифицирована. В США наиболее популярна версия "World Software", внедряемая на платформе AS/400, она полностью русифицирована.  В системах реализованы: управление финансами, производством, сбытом и доставкой продукции.

Локализованный продукт появился на российском рынке в 1996, заключен первый контракт (на Украине), но пока еще нет ни одной завершенной инсталляции на русском языке. Англоязычная версия установлена в Казахстане в 1995 г.

Oracle Applications

Корпорация Oracle является лидером мирового рынка реляционных баз данных и третьим по величине производителем программного обеспечения. Система управления персоналом была выпущена в 1988 году, финансовая система в 1989 и система управления производством в 1990 году.

Приложения Oracle доступны на многих платформах, но в качестве СУБД используют только Oracle. В данный момент GUI-интерфейс существует для модулей главной книги, управления персоналом, зарплаты, продаж и маркетинга. Для разработки приложений используется CASE-средство Oracle Forms 4.

Продукт локализован в части бухгалтерии и финансового учета, перевод на русский язык модулей сбыта и закупок - конец 1996 года. Модуль производство будет локализован к концу первой половины 1997 года. Сейчас уже продано 4 лицензии на продукт, начало промышленной эксплуатации в наиболее далеко продвинувшемся проекте запланировано на середину третьего квартала 1997 года.

BaaN IV

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

Основная область применения этой системы - промышленное производство как непрерывного, так и дискретного типа. Кроме того система хорошо проявила себя при проектной форме учета (Boeing). Ведущий клиент в России - ВАЗ (основное производство). Существует встроенное средство внедрения системы по заданной модели бизнес-процессов.

SAP R/3

Фирма SAP после создания продукта R/3 в 1992 г. стала лидером мирового рынка клиент-серверных решений для бизнеса. По состоянию на июнь 1996 SAP - 5-я фирма по обороту среди компаний, разрабатывающих программное обеспечение, и 1-я по объему продаж бизнес приложений на платформе клиент-сервер. SAP предлагает широкий спектр услуг по обслуживанию своих клиентов как при внедрении своих систем, так и в ходе промышленной эксплуатации.

Функциональность R/3 включает: бухгалтерию (FI), контроллинг (CO), снабжение и складской учет (MM), сбыт (SD), управление производством (PP), техобслуживание и ремонт (PM), управление персоналом (HR), учет основных средств (AM), а также управление проектами (PS) и документооборотом (WF). SAP предлагает также встроенные средства управления внедрением (процедурная модель внедрения SAP R/3), а дополнительно - решения в разных отраслях, включая область нефтегазовой промышленности. В систему интегрирован язык 4-го поколения ABAP/4, на котором были разработаны многие из существующих приложений R/3. Есть библиотека моделей бизнес-процессов (R/3 Reference Model).

Опыт внедрения в России

В настоящее время на рынке России представлены следующие продукты:

Компания / Пакет

Год выхода на рынок России

Количество консультантов в России (чел)

SAP R/2, R/3

1991

30-50

SSA BPCS

1992

5-15

BaaN IV

1995

20-30

Oracle Applications

1996

10-20

JD Edwards

1996

5-10

На конец 1996 в России и странах СНГ завершены следующие проекты по внедрению ведущих систем управления предприятием (из рассмотренных выше):

SAP

Компания

Модули

Дата пуска

АЭС Чернобыль

FI, CO*

01.96

DLW Урал

FI, CO, MM

12.95

Донецкий металлургический завод

FI, CO, MM

01.96

Master Foods

FI, CO, MM, PS, SD, HR

04.95

Химинтер-инжиниринг

FI, CO, AM, HR

11.95

Сургутнефтегаз (R/2)

RF, RK, RM

04.94

Туламашзавод (R/2)

RF, RK, RM

12.95

JD Edwards

Тенгиз-Шеврон, Казахстан, англо-язычная версия

BaaN IV

ВАЗ

Архангельский леспромхоз

Юганскнефтегаз (Нефте-Юганск)

BPCS

“Органон”, Углич (Учет в торговом офисе)

Oracle Applications

Центральный Банк Узбекистана

Сравнение интегрированных информационных пакетов.

Основной критерий выбора интегрированного информационного пакета включает три аспекта

наиболее полное удовлетворение функциональных требований, определяемых задачами, стоящими перед компанией

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

учет большого масштаба компании, что влияет на возможности применения требуемой функциональности.

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

В Таблице 1 представлена информация об интеграции модулей информационных пакетов. Под интеграцией здесь понимается обмен информацией между модулями в электронном виде без применения дополнительных средств. Представленная информация свидетельствует о высокой интеграции всех трех пакетов. Небольшие отличия связаны с отсутствием модуля “зарплата” в пакете BaaN  IV.

При подробном сравнении функциональных возможностей различия между тремя пакетами также незначительны. В Таблице 2, как пример, приведены данные о функциях, исполняемых при ведении главной книги и обработке заказов клиентов. BaaN IV: нет модуля “зарплата”; JD Edwards: не полная реализация функций связи планирования производства с продажами, предварительного планирования производства и учета затрат по контрактам. Эти недостатки не входят в состав критических требований, но могут повлиять на возможности дальнейшего расширения требований к информационной системе в процессе развития компании в будущем.

Основные и решающие различия между тремя пакетами возникают при сравнении их системных характеристик и возможностей их применения в России. Эти данные представлены в Таблице 3.

Пакет JD Edwards: отсутствие графического интерфейса пользователей и ограниченность платформных решений - продукт пока устанавливается только на платформе АS/400. Отсутствие положительного опыта внедрения пакета в России.

Пакет BaaN IV полностью локализован для работы в российских условиях, но его недостатком является малый опыт внедрения в России. Хотя пакет появился на нашем рынке еще в 1995 году, за это время сменилось два эксклюзивных дилера этой системы, что говорит об отсутствии в настоящее время ресурсов для адекватной поддержки внедрения этой системы. Нет еще пока в нашей стране установок этого пакета в нефтегазовой отрасли.

Пакет SAP R/3 положительно выделяется среди остальных по опыту внедрения в России: R/3 - более 45 продаж и 5 установок, доведенных до фазы эксплуатации. Большой опыт внедрения всех трех пакетов за рубежом (тысячи установок каждого пакета) говорит об их "внедряемости" и "надежности", однако картина внедрения рассматриваемых пакетов в СНГ говорит о значительно меньшем риске при внедрении в крупной компании SAP R/3 по сравнению с внедрением других пакетов.

Рис 8 Сравнение систем управления

  1.  Существующие проблемы 

В процессе интервьюирования сотрудников холдинга и при детальном анализе основных функций был выявлен ряд проблем (см. таблицу 3), вызывающих снижение эффективности деятельности сотрудников “Кармет”.

Таблица 3. Проблемы

Проблемы

Источники проблем

1

Пр.: Высокие затраты времени на обработку информации

  •  Использование различных разрозненных программ, информационных ресурсов, названий и обозначений управляющих элементов, формы представления результатов поиска информации.
  •  Отсутствие классификатора информации или использование классификатора, не удовлетворяющего требованиям пользователя

2

Пр.: Высокие временные затраты на передачу информации

Сложный процесс обмена информацией

3

Пр.: Отсутствие доступа пользователей к некоторым информационным ресурсам

Отсутствие согласованной/единой политики назначения прав пользователей

4

Пр.: Высокие затраты времени на обработку документов

  •  Использование различных разрозненных программ
  •  Отсутствие автоматизации
  •  Отсутствие возможности оперативного доступа пользователей к информации о ходе выполнения

5

Пр.: Высокие трудозатраты на согласование документов

отсутствие возможности оперативного ознакомления с информацией

6

Пр.: Неполнота сведений необходимых для контроля степени выполнения операции

Отсутствие  учета и контроля статистики выполнения операций

7

Пр.: Формирование документов  с ошибками

Отсутствие возможности оперативной корректировки

8

Пр.: Высокие временные затраты на регистрацию сведений о новом  клиенте

Отсутствие единого справочника

9

Пр.: Высокие временные затраты на формирование отчетов

Отсутствие автоматизации. Отчеты создаются вручную Exel, Word на основании различной первичной документации из разных таблиц.

10

Пр.: Трудности при заполнении отчета одновременно несколькими пользователями

Отсутствие возможности в используемом ПО

  1.  Выводы

На основании обследования объекта автоматизации и анализа существующих решений формулируется задание на разработку специальной конфигурации в системе SAP v 4.7.

  1.  
    Техническое задание на подсистему управления поставками
    1.  Общие сведения

Название подсистемы: Подсистема управления поставками.

Заказчик: организация «КАРМЕТ».

Плановый срок начала работ: 13.09.06

Плановый срок окончания работ: 20.06.07

  1.  Исходные данные для выполнения работ

  1.  Решение по созданию конфигурации системы SAP : Подсистема управления Сбытом на металлургическом предприятии КАРМЕТ на основе прототипа  SAP модуль SD.
  2.  Результаты обследования: организационная структура, структуры ролей, ресурсов, обобщенная технология выполнения работ.
  3.  Обзор и анализ базового модуля Сбыт;
  4.  Договор № 001/23-00.
    1.  Цели и назначение системы управления
      1.  Цели подсистемы управления Сбытом

Целями подсистемы управления Сбытом являются:

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

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

  1.  Введение единого номенклатурного справочника холдинга для всех запасов;
  2.  Автоматизированное управление поставками;
  3.  Возможность отражения сложных структурированных продуктов, состоящих из нескольких уровней компонентов, с использованием классификатора;
  4.  Введение товаров в нескольких единицах измерения;
  5.  Возможность сложного пересчета из одной единицы измерения в другую;
  6.  Возможность анализа информации по выполненным процедурам в разрезе заложенных в систему управления показателей;
  7.  Формирование отчетной информации на основе данных, хранящихся в системе управления, с требуемым уровнем детализации;
  8.  Введение качественных характеристик;
  9.  Ограничение доступа к информации по проектным работам, в соответствии с функциями участников в системе управления.
    1.  Термины и определения

Балансовая единица – организационная единица, которая самостоятельно готовит отдельную бухгалтерскую отчетность для внутреннего потребления или полный пакет отчетности, требуемый законодательством для предоставления в налоговые органы, банки и др.

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

Группа сбыта – отдел сбытового подразделения предприятия, отвечающий за продажу определенной номенклатуры материалов или услуг, например «Коммерческий отдел» в «КУ». Группы сбыта присваиваются соответствующему отделу сбыта.

Завод – организационная единица, отображающая производственный участок на предприятии. Завод в системе R/3 является организационной единицей в рамках предприятия, на котором производятся или заготавливаются материалы, товары или услуги.

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

Компания – это самостоятельная в правовом отношении единица (юридическое лицо), состоящее из одной или нескольких балансовых единиц.

Отдел сбыта определяет сферу привлечения клиентов и является сбытовым подразделением сбытовой организации, например «Коммерческое управление». Отделы сбыта присваиваются рынкам сбыта.

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

Пункт отгрузки – организационный элемент. Это может быть физическое или логическое место, на котором обрабатывается сбытовая поставка. Соответствующий пункт отгрузки присваивается заводу.

Рынок сбыта – является комбинацией сбытовой организации, канала сбыта и сектора. С помощью рынка сбыта можно указать, какие материалы разрешается реализовывать по данному каналу сбыта. Для какого рынка сбыта можно определить все данные, относящиеся к продажам.

Сбытовая организация – организационная единица предприятия, отвечающая за продажу материалов и услуг, в рамках предприятия, является торговым подразделением (или группой подразделений), отвечающим за отношения с клиентами – потребителями продукции и услуг предприятия. Обработка всех хозяйственных операций происходит в рамках сбытовой организации. Каждая сбытовая организация, присваивается к БЕ, соответствующей данному структурному подразделению.

Сектор представляет собой группу продуктов, т.е. сектора и может быть определен для широкой номенклатуры продуктов, например «ТМЦ», «УСЛУГИ». Сектор присваивается к сбытовой организации.

Склад – место хранения, для которого в установленном для конкретного предприятия порядке, ведется учет движения материалов и определено материально-ответственное лицо.

Транзакция – элементарная программа, позволяющая пользователю выполнять функцию или группу функций в продуктивной, тестовой системе или системе разработок проекта.

Функциональная область – укрупненный элемент бизнес-процесса, состоящий из конечного множества функций, объединенных достижением единой цели и выполняемых согласно единым требованиям.

Функция – элементарная операция, выполняемая пользователем в продуктивной, тестовой системе или системе разработок проекта.

  1.  Характеристика объекта автоматизации

Основные процедуры, которые предполагается вести в подсистеме управления – это процессы поставки готовой продукции и маркетинг, которые включают в себя:

  •  Организационные структуры сбыта
  •  Информационные системы по закупкам и управлению запасами
  •  Классификация продукции и услуг предприятия
  •  Ведение основных данных продукции (с точки зрения сбыта)
  •  Ведение основных данных дебиторов (с точки зрения сбыта)
  •  Ценообразование сбыта (схема калькуляции, надбавки и скидки.....
  •  Ведение документов сбыта (предложения, договоры, накладные на поставку, фактуры)
  •  Операции, связанные с оформлением заказов (проверка доступности продукции на    складе, планирование поставок)
  •  Операции, связанные с отгрузкой продукции (проводка отпуска, комплектация, маршруты)
  •  Операции, связанные с фактурированием поставок (виды фактур, бухгалтерские    проводки, объединение поставок)
  •  Информационная система сбыта

  1.  Требования к системе управления
    1.  Требования к подсистеме Сбыта
      1.  Общие требования

Использование единого промышленного программного продукта SAP R/3 для реализации функциональности подсистем.

Формирование информационных ресурсов подсистем в рамках единой базы данных продукта R/3.

Применение в работе разрабатываемых подсистем  НСИ, ведущейся средствами централизованных подсистем.

Функционирование всех разрабатываемых подсистем в архитектуре «клиент-сервер» с использованием единого сервера системы объекта автоматизации и универсальных рабочих мест.

  1.  Требования к надежности

Параметры надежности программно – аппаратных средств, на которых установлен программный продукт R/3 должны быть достаточны для бесперебойной работы системы в режиме доступности функций системы с 8:00 до 22:00 по местному времени и круглосуточно на центральном узле системы. С учетом проведения регламентных работ, согласно расписанию.

  1.  Требования к функциям, выполняемым подсистемой

Перечисленные требования актуализируют наличие в Подсистеме автоматизации следующих компонентов:

  1.  Технологические компоненты
    1.  графический пользовательский интерфейс
      1.  реляционные базы данных
        1.  коммуникационные компоненты
          1.  система управления вычислительным центром
          2.  система новых разработок типа CASE-средства
          3.  система администрирования и разграничения доступа.
          4.  При поэтапном внедрении системы необходимо предусмотреть преемственность развития системы. На втором этапе следует продолжить дальнейшее развитие функций Сбыта, а также рассмотреть внедрение новых функций.
        2.  Требования к защите информации от несанкционированного доступа

Необходимый уровень защиты информации должен быть обеспечен штатными средствами информационной системы R/3.

Защита данных должна быть реализована путем использования средств операционной системы, СУБД.

Санкционированность использования данных обеспечивают:

  •  стандартный метод, применяемый в ОС по управлению доступом к данным - идентификация пользователя в системе;
  •  защита данных при помощи паролей, реализованная в используемой СУБД;

Сохранность информации должна быть обеспечена дублированием хранимых данных и перечнем периодически выполняемых процедур по копированию структуры и состава информационных массивов системы. Периодичность выполняемых процедур должна быть определена соответствующим Регламентом.

  1.  Требования к эргономике и технической эстетике

Требования к эргономике и технической эстетике включают:

  1.  Требования к интерфейсной части программы (её внешнему виду):
    1.  Программа должна иметь набор стандартных элементов управления, как, например, управляющее меню и набор панелей управления, и статусная строка в нижней части.
    2.  Нежелательно использовать пёстрое оформление интерфейса программы (множество элементов ярких цветов и т.п.).
  2.  Требования к работе программы со стандартными устройствами ввода информации (клавиатурой ПК и манипулятором «мышь»):
    1.  Необходимо избегать зависимости выполнения некоторых операций от конкретного устройства ввода (мыши или клавиатуры), т.е. по возможности дублировать функции. Это необходимо для обеспечения доступа ко всем функциям пользователей с физическими недостатками или пользователей, работающих на конфигурациях без одного из устройств ввода.
    2.  Набор основных комбинаций клавиш должен соответствовать аналогичным комбинациям в наиболее распространённых программных продуктах. Например, перемещение между элементами должно осуществляться с помощью комбинаций «Tab» — в прямом и «Shift + Tab» — в обратном. Пользователь должен иметь возможность доступа к любому элементу окна (кроме декоративных, панелей инструментов и т.п.) с помощью этих комбинаций.
    3.  Следует использовать комбинации клавиш, употребляемые в стандартном пакете.
    4.  Необходимо предусмотреть возможность смены раскладки, посредством настроек. Так как программа предусматривает работу в среде Windows 95/98/NT, то необходимо предусмотреть возможность работы с манипулятором «мышь», а также поддержку стандартных функций: щелчка, двойного щелчка, операции «drag and drop» и клавиатурно зависимые манипуляции с мышью (комбинации Ctrl + одинарный щелчок левой клавишей мыши и т.п.).
    5.  Необходимо обеспечить доступность базовых функций с помощью левого щелчка мыши.
    6.  Щелчок правой клавишей мыши должен вызывать контекстно-зависимое меню, поэтому не рекомендуется использовать его для других целей (кроме операции drag and drop).
      1.  Требования по стандартизации и унификации

При разработке и документировании подсистемы Сбыта нужно учитывать требования стандартов:

  1.  Российских:
    1.  ГОСТ 19.ХХХ Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
    2.  ГОСТ 34.ХХХ Информационная технология. Комплекс стандартов и руководящих документов на АС. (РД 50.ХХХ)
    3.  ГОСТ 15.ХХХ Система разработки и постановки продукции на производство. (Р 50-ХХХ-ХХХ)
    4.  СТП АРГ001-97 Программная документация. Оформление.
  2.  Международных (для выхода на внешние рынки):
    1.  ISO 9000-3 Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. (Стандарт ISO 9001 описывает модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании.)
    2.  ISO 12.207 Процессы жизненного цикла программного обеспечения.
    3.  ISO 10011-1 Руководящие указания по проверке системы качества.
    4.  IEEE 830 Рекомендации по составлению спецификаций.
    5.  IEEE 829 Стандарт на документацию по тестированию ППО.

  1.  Требования к видам обеспечения
    1.  Требования к программно-техническому обеспечению

Требования к конфигурации этих компьютеров приведены ниже.

Продуктивная машина ( центральная система )

RS/6000 R50

- четыре двух-процессорные платы PowerPC 604e 200Mhz;

- кэш1-го уровня 32kB инструкций + 32kB данных;

- кэш 2-го уровня 1MB на каждый процессор;

- оперативная память 1256 MB;

- дисковая внутренняя память 4.5 GB (SCSI-2 F/W);

- два Ethernet 10/100 Mb/s адаптера;

- SSA адаптер для подключения внешней дисковой памяти;

- дисковод 3,5’’ ;

- 8-и скоростной CD-ROM;

- 5 GB стриммер;

- внешняя дисковая память 36 GB;

- оптическая библиотека.

Тестовая машина ( сервер приложений )

RS/6000 J50

- одна двух процессорная плата PowerPC 604e 200Mhz;

- кэш1-го уровня 32kB инструкций + 32kB данных;

- кэш 2-го уровня 1MB на каждый процессор;

- оперативная память 512 MB;

- дисковая внутренняя память 4.5 GB (SCSI-2 F/W);

- два Ethernet 10/100 Mb/s адаптера;

- SSA адаптер для подключения внешней дисковой памяти;

- дисковод 3,5’’ ;

- 8-и скоростной CD-ROM;

- 5 GB стриммер;

На компьютерах должно быть установлено следующее программное обеспечение:

- операционная система AIX 4.2.

- HACMP кластерное программное обеспечение.

- Perfomance Toolbox, Perfomance Aide.

- компилятор С.

Аппаратные и общесистемные программные средства уровня

          “Клиент”.

На уровне рабочей станции та же степень гибкости обеспечивается применением IBM-совместимых персональных компьютеров.

Персональные компьютеры исходя из требований R/3 должны быть двух классов:

- рабочее место разработчика: IBM PC300GL Pentium166

      кэш 256 kb, RAM 32MB, HDD 1.2 GB, 8xCD, 17’’ Monitor

- рабочее место клиента R3: IBM PC300GL Pentium133

      кэш 256 kb, RAM 16MB, HDD 1.2 GB, 15’’ Monitor.

На всех компьютерах должна быть установлена операционная система Microsoft Windows.

40% рабочих мест должны комплектоваться принтерами.

5.3.2 Оборудование вычислительной сети.

Сетевое оборудование состоит из двух основных частей:

- оборудование для обеспечения удаленной связи между предприятиями;

- оборудование для локальных сетей предприятий.

Оборудование глобальной вычислительной сети.

Глобальная сеть корпорации создается на базе:

- радио-релейных станций ( для связи ТоАЗ и ВЦМ, ТоАЗ и Керамика );

- станций спутниковой связи ( для связи ТоАЗ и ШКДП );

- синхронных модемов ( для дублирования связи ТоАЗ и ШКДП ).

- аппаратуры IDNX ( мультиплексор голос-видео-данные );

- мультипротокольных маршрутизаторов IBM 2210.

Оборудование локальной вычислительной сети.

Кабельная система магистральной сети (backbone), должна строиться на основе оптоволоконного кабеля. Применение оптоволоконной кабельной системы для магистральной сети имеет следующие преимущества:

- высокая устойчивость к помехам;

- повышенная устойчивость к помехам;

- возможность использования высоко-скоростных протоколов.

Кабельная система локальной сети, должна строиться на основе оптоволоконного кабеля и  кабеля “витая пара”.

Для построения ЛВС должно использоваться двухслойное решение, обеспечивающее гибкость построения и управления.

  Первым слоем является ЛВС рабочих мест (DeskTop LAN), предоставляющая сетевые услуги конечным пользователям и серверам рабочих групп. В ее качестве предлагается Ethernet 10Mb/s, построенная на основе концентраторов  модели IBM 8222 и IBM 8224, а также коммутаторов (Ethernet LAN Switch ) IBM 8273 и IBM 8271.

  Второй слой - это объединяющая сеть (Backbone LAN), функцией которой является объединение DeskTop LAN различных зданий и этажей зданий, а также предоставления сетевых услуг общим информационным ресурсам ( теле-конференции, АСУТП и т.д. ). В ее качестве  предлагается Fast Ethernet 100 Mb c возможностью в будущем безболезненно перейти на ATM 155 - 622 Mb/s , строящаяся  на основе коммутаторов (Nways LAN RouteSwitch) IBM 8274.

Работа удаленных  рабочиех мест  будет организована по телефонным линиям. Для обеспечения доступа таких рабочих мест к локальной сети предприятия, предлагается сервер удаленного доступа к локальным сетям по коммутируемым каналам (Dial in Access to LANs) IBM 8235.

Использование имеющихся на предприятии технических средств.

Существующий парк персональных компьтеров частично может быть использован  в  качестве  рабочих  мест R/3  -  компьютеры  класса  Pentium. Компьютеры класса 386 и 486 могут быть использованы как рабочие станции информационных    пользователей  R/3  с усеченной функциональностью. Существующие сети Ethernet  могут быть  подключены к backbone. Для обеспе-чения функционирования существующих информационных систем, должен быть обеспечен доступ к сетям Arcnet. Он может быть организовать при помощи роутеров.

  1.  Требования к организационному обеспечению

Для обеспечения работы системы управления должны быть выполнены следующие условия:

  •  приняты организационные решения, обеспечивающие процесс создания и запуска в эксплуатацию системы управления;
  •  сформирована рабочая группа системы управления;
  •  выбран «пилотный проект», на базе которого будет отрабатываться функциональность системы управления;
  •  на стадии разработки системы управления обеспечен доступ специалистов Исполнителя к рабочим местам системы управления на территории металлургического предприятия «КАРМЕТ».
    1.  Требования к методическому обеспечению

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

  1.  Требования к персоналу системы

Для обеспечения разработки и эксплуатации системы управления на стадиях разработки и эксплуатации предполагается участие рабочей группы.

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

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

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

Операторы системы должны овладеть базовыми знаниями о пользовательских интерфейсах продукта R/3.

Администраторы системы должны овладеть базовыми знаниями по администрированию справочных баз данных продукта R/3.

  1.  Объем автоматизации и архитектура системы управления
    1.  Объем автоматизации системы управления

Для обеспечения работы модуля и автоматизации функций предполагается использовать следующее программное обеспечение:

Функциональность модуля SD  – для планирования, контроля и анализа поставок

Можно выделить четыре группы операций:

предварительные сбытовые операции:

ведение контактов с клиентами

ведение заявок на заказ

ведение предложений клиентам

договорно-позаказные операции:

проверка доступности запасов, необходимых для заказа

оформление заказа

ведение долгосрочных договоров (бартер, предоплата, общее количество или график поставки

операции отгрузки:

оформление отгрузки (создание "Приказа...")

проводка отпуска товара

операции реализации:

оформление счета клиенту, кредитового авизо, реализации с взаимозачетом

проводка счета в бухгалтерию (фактурирование)

учет реализации в бухгалтерии (по оплате счетов, по кредиту, по взаимозачету).

Операции ведутся в модулях SD и FI.

Продажа

Подсистема продаж является центральным компонентом модуля Сбыта (SD), где оформляются заказы клиентов на поставку товаров.  Модуль полностью интегрирован с остальными компонентами системы и поддерживает все фазы управления этой операции:

ведение базы данных запросов клиентов (для тех заявок, которые не могут сразу быть реализованы);

подготовка предложений клиентам в виде "прейскурант" и "коммерческого предложения".

языковая перекодировка для экспортных торговых документов - осуществляется путем оформления текстов документов на нескольких языках, а код языка копируется из записи грузополучателя, заказчика, плательщика;

автоматическое определение номера торговых документов в заранее заданных диапазонах, зависящих от типа документа;

определение партии поставки для многоэтапных поставок по долгосрочному контракту;

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

долгосрочный договор о поставке (контракт) - с постоянными клиентами;

определение категорий срока действия договора;

стандартные заказы для всех клиентов;

стандартные заказы возврата товара клиентами;

различные виды условий договоров - во внутренней валюте, экспортный, предоплата, взаимозачет, консигнация;

определение правил расчета дат;

определение и присвоение схем неполноты данных для управления документооборотом;

определение представления списков для заказов, запросов, предложений, контрактов и сбытовых потребностей;

копирование данных открытых заказов для ускорения ввода информации;

использование ассортиментов - списков стандартной номенклатуры заказа постоянных клиентов.

Отгрузка

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

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

Отпуск материалов

Отпуск материала - движение материала, при котором осуществляется проводка отпуска или расхода материала, поставки товаров покупателю. Отпуск материала ведет к уменьшению складского запаса. Бухгалтерская проводка осуществляется автоматически на заранее установленный счет. Возможны несколько вариантов отпуска:

отпуск со склада из свободного запаса;

отпуск из запаса заранее зарезервированного на заказ клиента;

отпуск из консигнационного запаса, к которому может быть отнесен неоцененный запас или некондиционный товар.

Отпуск материалов производится с соответствующим видом движения (601) при проведении операции "Проводка Отпуска Товара" после комплектования. Проводки отпуска Готовой Продукции, Тарных и Упаковочных материалов осуществляются на разные субсчета

Примечание

Порядок работы со всеми счетами уточняется на этапе тестирования прототипа.

Фактурирование

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

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

Здесь поддерживаются также следующие функции сбытового документооборота:

ведение документов фактурирования и их видов;

поддержка печати документов;

управление фактурированием с помощью разветвленной процедуры блокирования;

управление групповыми фактурами;

управление незавершенными фактурами;

создание фактуры по графику фактур;

управление списками фактур.

Печать документов сбыта

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

Данные документа определяются как из основной записи клиента, так и из дополнительных условий.

Для экспортных документов необходимо задать иноязычный текст документа.

Существуют следующие группы документов:

торговые документы (заказы, контракты, договоры, запросы, предложения);

документы поставок;

документы комплектации (комплектовочные листы);

расчетные документы (счета-фактуры, ...);

другие.

Поддержка сбыта

Для поддержки сбытовых операций применяется ряд функций, а также система отчетов, объединенных в Информационную систему Сбыта. К этим функциям относятся:

ведение базы данных контактов;

управление неполнотой  данных документов;

электронный обмен данными (EDI);

обработка сообщений при поступлении заказа;

ведение торговых ассортиментов клиентов.

Информационная система Сбыта

Информационная система Сбыта представляет собой набор стандартных и "гибких" отчетов о показателях сбытовой деятельности предприятия в различных разрезах. В основном эти отчеты предназначены для анализа материального оборота по сбыту и обеспечения маркетинговых исследований. Для работы этой системы необходимо вести статистические группы клиентов и готовой продукции.

Маркетинг

В целях маркетинга возможно ведение информации по сферам сбыта в разрезах: отраслей клиентов, классификации клиентов, рыночных цен конкурентов и др.

  1.  Архитектура системы управления 
    1.  Описание архитектуры системы управления (не пойму в какую часть засунуть???)

Программное обеспечение базисного модуля R/3 предназначено для использования в многоуровневых структурах клиент-сервер, в данном случае в рамках трехуровневой концепции (см. рис. 3.2-1.), где компоненты R/3 распределяются по уровням.

Рис. . Трехуровневая структура системы R/3 предприятия КАРМЕТ

С точки зрения аппаратных средств задачи, решаемые системой, можно разложить на три типа:

представление данных пользователям - презентация

выполнение логических функций  - приложения

хранение данных    - база данных.

Презентация, приложение и база данных могут работать каждая на своей ЭВМ.

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

С сервером базы данных связано два сервера приложений. На серверах приложений осуществляется обработка собственно логики приложений.

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

Пользователи равномерно распределяются по серверам приложений при входе в систему R/3. Каждый сервер приложений назначается группе пользователей, работающих с одним и тем же приложением.

На сервере базы данных (Production System) создается центральная инстанция R/3, на которой инсталлируются сервер сообщений и сервер коммуникаций, на серверах приложений (Server 1 и Server 2) - диалоговые инстанции.

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

Через сервер сообщений серверы приложений могут обмениваться краткими внутренними сообщениями. Сервер коммуникаций позволяет обеспечить связь R/3 с внешними приложениями.

В тестовой системе проводятся разработки, которые тестируются и деблокируются затем в продуктивную систему, где находятся в стабильном состоянии.

Для обеспечения непротиворечивости различных версий системных параметров (пользовательской настройки) внутри тестовой системы создаются 3 манданта: учебный, для разработок и тестовый.

В продуктивной системе создается продуктивный мандант, в котором запрещено ведение каких-либо разработок.

На последующих этапах развития системы возможно увеличение количества серверов приложений продуктивной системы.

Рис. . Архитектура системы управления

  1.  Требования к информационно-техническому оснащению

Для обеспечения нормального функционирования системы управления в объеме архитектуры, описанной в пункте 2.6.2.1., необходимо обеспечить исполнение следующих требований к информационно-техническому оснащению.

  •  компьютеры, установленные на рабочих местах пользователей, работающих с системой управления, должны удовлетворять программно-техническим требованиям соответствующего программного обеспечения.
  •  Сервер БД должен удовлетворять следующим программно-техническим требованиям:
    •  процессор Pentium IIl 600МГц и выше, 512Мб ОЗУ и выше, 1Гб свободного дискового пространства только для поддержки баз данных, не включая СУБД MS SQL 2000 и прочее ПО, не менее 200 Мб для библиотеки документов;
    •  операционная система Microsoft Windows NT Server 4.0 с SP 5.0 и выше или Windows 2000 Server с SP 1.0 и выше.

Табл. . Программно-технические требования к ПО системы управления

 

Модель

Описание

Кол

Цена, долл.США

Стоимость, долл.США

ОБОРУДОВАНИЕ

7013-J50

PowerPC Server

1

77550

77550

2415

SCSI-2 Fast/Wide Adapter

1

1410

1410

2650

POWER GXT150M

1

2490

2490

2734

Keyboard/Mouse Adapter

1

405

405

2934

Async Terminal/Printer Cable (EIA-232)

1

57

57

2994

Ethernet 10/100 Mbps MC Adapter - SMP

1

1190

1190

3011

9.1 GB Fast/Wide Disk Drive

2

6385

12770

3613

P70 Color Monitor

1

1920

1920

4166

256 MB DIMM Kit

3

8090

24270

4224

Ethernet Twisted Pair Transceiver

1

347

347

4234

13W3 to 13W3 Display Cable

1

159

159

4324

Dual 604e Processor Card

1

17235

17235

6010

Keyboard - English (US)

1

258

258

6041

Mouse

1

126

126

9138

4.5 GB Base SCSI-2 Fast/Wide Disk Drive

1

нет

 

9165

Base 256 MB DIMMs on 1 GB Card

1

нет

 

9212

Enhanced SCSI-2 Differential Fast/Wide Adapter

1

нет

 

9221

Base 3.5" Diskette Drive

1

нет

 

9300

Language - English (US)

1

нет

 

9402

Base Dual 604e Processor Card, 2MB L2

1

нет

 

9441

Differential Cable to Internal Devices

1

нет

 

9607

Base 8x Speed SCSI-2 CD-ROM (4x before 11/96)

1

нет

 

9820

Power Cord - EMEA (250V, 16A)

1

нет

 

7013-J50, Стоимость

140187

7209-003

Оптический дисковод

1

5650

5650

2842

SCSI-2 Fast/Wide Adapter Cable

1

278

278

8294

Five 2.3GB 512B/S Rewritable

2

524

1048

9128

SCSI-2 Fast/Wide Adapter Cable

1

нет

 

9300

Language - English (US)

1

нет

 

9820

Power Cord - EMEA (250V, 16A)

1

нет

 

7209-003, Стоимость

6976

9910-U13

Prestige EXT 1000VA, 220-240V, 50/60Hz

1

2200

2200

2103

ConnectUPS Twisted Pair Ethernet Adapter w/ IEC

1

760

760

2900

Additional EXT Battery Pack

1

830

830

2923

Power Cord Adapter for 7013-Jxx

1

25

25

9001

Onlinet Network for AIX, RS-232 Cable

1

нет

9910-U13, Стоимость

 

 

3815

Программное обеспечение

5765-423

C

1

нет

5996

CD-ROM

1

нет

V0SUBH

1 Basic Per User, Сумма

1

737

737

5765-423, Сумма

 

 

737

5765-654

Performance Toolbox V2.2

1

нет

V2DPBG

Performance Aide Usepack - 1 Client

1

614

614

5765-654, Сумма

 

 

614

5765-C34

AIX 4 (Repackaged)

1

нет

5013

Bonus Pack 40 Bit - Int'l Encrypt / CD

1

нет

5016

Lotus Domino 64 Bit - Int'l Encrypt / CD

1

нет

V2SHBG

AIX 4.2 (Rpk) for 1-2 Users

1

нет

5765-C34, Сумма

 

 

0

5692-AIX

System Software

1

нет

714

Performance Toolbox V2.2

1

нет

822

Bonus Pack - Workgroup/Server

1

нет

852

AIX 4.2.x User 1-2

1

нет

1004

CD-ROM

1

75

75

2924

Primary US English Language

1

нет

5692-AIX, Сумма

 

 

75

ОБОРУДОВАНИЕ, Сумма

150978

Программное обеспечение, Сумма

1426

ИТОГО (CIP, долл.США)

152404

  1.  Обмен данными между участниками системы управления.

Участники системы управления должны иметь возможность передавать и получать данные по проектным работам посредством:

  •  электронной почты;
  •  интернет – соединения;
  •  телекоммуникаций;
  •  гибких носителей.
    1.  Состав этапов и работ разработки подсистемы

Состав этапов и работ разрабатывался с учётом ГОСТа 34.601-90 (Стадии создания автоматизированных систем):

Таблица 4. Состав этапов и работ по созданию системы.

N

Этапы

Работы

1.

Техническое проектирование

Разработка проектных решений по системе и её частям;

Разработка документации на систему и её части;

Задание на рабочее проектирование

2.

Рабочее проектирование

Разработка рабочей документации на систему и её части;

Разработка адаптация программ;

Тестирование программных модулей.

3.

Внедрение

Подготовка объекта автоматизации;

Пусконаладочные работы;

Проведение опытной эксплуатации;

Проведение приёмочных работ;

Обучение персонала.

4.

Сопровождение и развитие

Выполнение гарантийных работ;

Послегарантийное обслуживание

Модернизация и развитие

Рис. . Диаграмма старта системы

Рис. . Схема этапов внедрения системы

  1.  Порядок приёмки и контроля системы управления

По завершении этапов разработки системы управления должен проводиться контроль выполнения требований технического задания.

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

При проведении испытаний необходимо выполнить следующие шаги:

  •  Создание тестовой среды;
  •  Установка тестового инструментария;
  •  Репетиция переноса данных;
  •  Построение сценариев системных тестов;
  •  Выполнение системных тестов;
  •  Мониторинг тестов;
  •  Каталогизация тестовых сценариев для повторного использования;
  •  Проведение причинно-следственного анализа результатов системного тестирования;
  •  Проведение регрессивных тестов системы.

К испытаниям должны предъявляться:

  •  проектная и технологическая документация;
  •  технические и программные средства;
  •  комплект эксплуатационной документации;
  •  организационно-распорядительная документация;
  •  программа и методика испытаний.

Приемочные испытания должны проводиться в условиях подразделений, реализующих функции испытываемой системы управления. Сроки и место проведения испытаний должны определяться планами-графиками, согласованными с организацией «КАРМЕТ». Приемочные испытания должны проводиться комиссией, состав которой назначается и утверждается организацией «КАРМЕТ». Результаты работы комиссий должны оформляться протоколами испытаний и согласований, актами приемки в опытную или промышленную эксплуатацию.

  1.  Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Для ввода системы управления в действие необходимо определить опытную зону для отладки технологии и оборудования и проведения опытной эксплуатации.

Предприятие  «КАРМЕТ» должно организовывать с привлечением организации-исполнителя подготовку и повышение квалификации специалистов.

Для ввода системы управления действие необходимо провести следующие подготовительные мероприятия:

  •  подготовить объект автоматизации к условиям функционирования в системе управления;
  •  организовать дополнительные рабочие места или переоборудовать существующие.
    1.  Требования к документированию

Проектно-техническая документация системы управления, выполненная в соответствии с требованиями ГОСТ «Информационная технология комплекса стандартов и руководящих документов на автоматизированные системы» должна быть оформлена надлежащим образом.

Передача прототипа подсистемы должна осуществлятся по следующим критериям:

  •  соответствие прототипа требованиям к его функциональности.

Наличие следующей документации:

  •  «Концептуальный проект»;
  •  описание настройки системы;
  •  руководство для администратора системы;
  •  руководство по использованию.

  1.  
    Исследовательская часть

Одним из важных отличий металлургической отрасли является большое количество вариантов выпускаемой и продаваемой продукции из-за наличия у нее множества признаков- характеристик. Ведение этих признаков представляет собой весьма серьезную проблему. Они указываются в заказе клиента и должны быть переданы по всей цепочке обеспечения: от сбыта к закупкам, производству и поставке. В течении этого процесса могут устанавливаться и изменяться значения сотен признаков, что приводит к большому объему данных. Необходимо ограничить объем данных, использовать интегрированный конфигуратор вариантов, позволяющий определить требуемые признаки для каждого клиента. Нужен справочник конфигурируемых материалов , который можно было бы использовать во всех хозяйственных операциях( для обработки заказов, управления запасами). Конфигурация вариантов помогает клиенту или продавцу определить характеристики продукта.

Рис. . Структура модуля конфигурации

  1.  Теоретические основы конфигурации производственных объектов

Классификация - это выделение на основе существенных признаков из некоторого множества понятий универсального класса всех входящих в него подмножеств (подклассов) и установление между выделенными подмножествами отношения порядка. Признаки, на основе которых производится выделение из универсального класса всех его подклассов, называется классификационными. Если К0 - некоторый класс, а К1, К2, ..., Кn - его подклассы, то

K0= Ki, i=1...n,  Ki Kj=.

Однако в общем случае не обязательно, чтобы выполнялось соотношение

Ki Kj=.

Каждый из классов Ki в свою очередь может быть подвергнут дальнейшему разбиению на подклассы Kj, так что

Ki = Kj, j=1...ni,  Kpi  Kqi =.

И т.д. В результате возникает определенная структура взаимосвязей между классами, которая содержит важную семантическую информацию о предметной области. В частности, между классами устанавливается отношение порядка

К0 Кi  Kj ...

Полученная структура классов полностью характеризуется их экстенсионалами, так как определяется вхождением сущностей ПО в классы и их взаимосвязями друг с другом. Это экстенсиональный аспект классификации. На экстенсиональном уровне классификацию можно рассматривать как алгебру К = < Ki , > с теоретико-множественной операцией включения.

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

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

  1.  Таксономия и мерономия

В классификационных системах класс сходных сущностей называют классификационным таксоном, а способ членения этих сущностей на отдельные части, позволяющий установить их сходство, -мерономией. Таким образом, таксон - это объем (экстенсионал) некоторого класса, а мерономия - содержание (интенсионал) понятия, связываемого с данным классом. Если таксономия определяет знание о внешней структуре связей между классами сущностей ПО, используя многоуровневую абстракцию обобщения и отношение ЕСТЬ-НЕКОТОРЫЙ, то мерономия задает внутреннее устройство классов с помощью отношения ЧАСТЬ-ЦЕЛОЕ.

  1.  Типы классификаций

Как уже указывалось ранее, между таксонами существуют определенные взаимосвязи. Наиболее простая связь между двумя таксонами - отношкние включения. Таксон Тi содержится в таксоне Тj, если все виды таксона Тi принадлежат таксону Тj. Кроме того, таксоны могут быть связаны отношением пересечения.

Если таксоны Тi и Тj имеют непустое пересечение и один из них содержится в другом, то классификационная структура таксонов в этой структуру принадлежит определенному уровню в дереве (рис. 3). Наиболее ярким примером древовидной классификации является Универсальная десятичная классификация (УДК). Как будет показано ниже, алгебраическая структура архетипов может быть как древовидной, так и иметь более сложное строение.

Рис. . Алгебраическая структура таксонов древовидной классификации

Возможна и противоположная ситуация: архетипы образуют структуру типа дерево, а множество всех таксонов организовано не в виде дерева, а устроено более сложно. Например, этими свойствами обладает рубрикатор реферативных журналов. Так, выпуск «Теоретическая кибернетика» входит как в раздел «Математика», так и в раздел «Автоматика и телемеханика», т.е. древовидность таксонов не выполняется, однако архетипы, как показано ниже, организованы в виде древовидной структуры.

Наконец, в заключение рассмотрим два случая, когда древовидной структурой не обладают ни таксоны, ни архетипы. Данный тип классификации является наиболее универсальным. Строение множества таксонов и определяющих его архетипов задается более сложными алгебраическими структурами, известными как решетки. Решетки могут быть определены как множества, для любой пары элементов которых можно указать наибольший и наименьший элементы. Это определение фактически задает на исходном множестве двойное отношение порядка: «сверху вниз» и «снизу вверх». Это позволяет установить глубокую связь между таксономией и мерономией, присущей классификационным схемам данного типа. Простейшими классификационными структурами данного типа являются булевы классификации. К другому типу таксономической структуры относятся фасетная или комбинативная классификации. В качестве фасет (аспектов) такой классификации выступают признаки понятий, имеющие различные имена. Каждый признак определяет разбиение множества сущностей на непересекающиеся подмножества первого уровня. По парные пересечения таксонов первого уровня, которые задаются признаками с различными именами, дают таксоны второго уровня, тройные пересечения - таксоны третьего уровня и т.д. В результате таксон может быть взаимосвязан с двумя и более таксонами верхнего уровня.

Следовательно, комбинативная классификационная структура не является древовидной. Как и в случае булевых классификаций, алгебраическая структура комбинативных классификаций является решеткой.

  1.  Выбор системы классификации
    1.  Основные термины

Классификатор - систематизированный свод наименований и кодов классификационных группировок.

Классификация объектов – это процедура группировки на качественном уровне, направленная на выделение однородных свойств

  1.  Назначение классификатора

Классификатор необходим для:

  •  систематизации наименований кодируемых объектов;
  •  однозначной интерпретации одних и тех же объектов в различных задачах;
  •  Обобщения информации по совокупности признаков;
  •  сопоставления одних и тех же показателей, содержащихся в формах статистической отчетности;
  •  возможности поиска и обмена информацией между внутренними и внешними информационными системами

  1.  Методы классификации

При помощи методов классификации проводится структурирование информации по конкретным отраслям деятельности.

В классификаторах применяется два метода классификации: иерархический и фасетный. Выбор между этими двумя методами зависит от особенностей конкретной предметной области. Существуют следующие требования для выбранной системы классификации:

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

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

Выбор последовательности признаков зависит, прежде всего, от характера информации. При построении классификации выбор последовательности признаков зависит от вероятности обращения к тому или иному признаку. При этом наиболее вероятным обращениям должны соответствовать высшие уровни классификации.

Требования к классификатору, построенному на иерархическом методе классификации:

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

Основными преимуществами иерархического метода является большая информационная емкость, традиционность и привычность применения, возможность создания для объектов классификации мнемонических кодов, несущих смысловую нагрузку.

Значительным недостатком иерархической классификации является слабая гибкость структуры, обусловленная фиксированным основанием деления и заранее установленным порядком следования, не допускающим включение новых объектов и классификационных группировок. Таким образом, при изменении состава объектов классификации и характеристик с помощью классификационных задач, требуется коренная переработка всей классификационной схемы.

  1.  Фасетный метод классификации или

Фасетный метод классификации подразумевает параллельное разделение множества объектов на независимые классификационные группировки. При этом не предполагается жёсткой классификационной структуры и заранее построенных конечных группировок. Классификационные группировки образуются путем комбинации значений, взятых из соответствующих фасетов. Последовательность расположения фасетов при образовании классификационной группировки задается фасетной формулой. Количество фасетных формул определяется возможными сочетаниями признаков.

К классификатору, построенному на фасетном методе классификации, предъявляются следующие требования:

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

Основным преимуществом классификации с использованием фасетного метода является гибкость структуры ее построения. Изменения в любом из фасетов не оказывают существенного влияния на все остальные. Большая гибкость обуславливает хорошую приспособляемость классификации к меняющемуся характеру решаемых задач, для которых она создается. При фасетной классификации появляется возможность агрегации объектов и осуществления информационного поиска по любому сочетанию фасетов.

Недостатками фасетного метода классификации являются неполное использование емкости, нетрадиционность и иногда сложность применения.

  1.  Методы кодирования в классификаторах

Под кодированием понимается присвоение кода классификационной группировке или объекту классификации. Кодирование предназначено для формализованного описания наименований различных аспектов данных. Обычно кодирование представляет собой процесс обозначения исходного множества объектов или сообщений набором символов заданного алфавита на основе совокупности определенных правил.

Порядковый метод — каждый из объектов множества кодируется с помощью текущего номера по порядку. Обеспечивает простоту добавления новых объектов и краткость кода, однако такой код не несёт никакой информации об объекте. Используется в случаях, когда не требуется сложного деления на множества, например, в классификаторе валют.

Серийно-порядковый метод — кодами служат числа натурального ряда с закрепленной отдельной серией этих чисел за объектами классификации с одинаковыми признаками. Чаще всего используется для идентификации объектов в сочетании с классификационным методом (классификатор должностей и служащих).

Последовательный метод — в кодовом обозначении знаки на каждой ступени деления зависят от результатов разбиения на предыдущих ступенях. В результате кодовое обозначение группировки дает информацию о последовательности признаков, характеризующих эту группировку. Наиболее подходит иерархическому методу классификации.

Параллельный метод — признаки классификации кодируются независимо друг от друга определенными разрядами или группой разрядов кодового обозначения. Метод параллельного кодирования чаще всего используется при фасетной классификации, но применяется также и в иерархической классификации. При этом либо соподчиненные признаки, обладая полной однородностью, располагаются параллельно во всех звеньях иерархической цепи, либо несоподчиненные параллельные признаки искусственно устанавливаются в определенной последовательности.

  1.  Обзор существующих систем классификации

Несмотря на относительно молодой возраст рынка НСИ-решений, на нем уже появилось большое количество игроков, предлагающих свои продукты. Достаточно упомянуть вышедшие в данный сегмент компании SAP, Oracle и IBM, чтобы понять его потенциальный объем и перспективность. В этой нише нашли свое место также DWL, Siebel, Siperian и многие другие известные поставщики ПО.

Российские поставщики НСИ -решений

  1.  Способы хранения данных

Сравнивая различные варианты реализации систем поддержки нормативно-справочной информации, можно разделить их по способу хранения данных:

  •  централизованные;
  •  децентрализованные;
  •  смешанные.

Рассмотрим для сравнения, как обычно организована работа со справочной информацией в отсутствие специальной системы поддержки НСИ.

Если специализированной системы НСИ на предприятии нет, хранение справочных данных осуществляется хаотичным образом в одной или нескольких уже использующихся там системах (как правило, в ERP- или CRM-системе). Если для небольших компаний это экономически целесообразно, то для средних и крупных организаций, где эксплуатируется большое количество разнородных ИС, опирающихся по сути на одну и ту же базовую информацию, такой подход чреват ошибками и дополнительными затратами, связанными с повторным вводом данных. А бессистемная настройка взаимодействия приложений неоправданно усложняет интеграционные схемы (см. рис. 1). Впоследствии внести изменения в них будет очень сложно, а подчас даже невозможно.

Рис. 1. В отсутствие системы поддержки НСИ обмен справочной информацией между приложениями носит хаотический характер

Централизованное хранение информации 

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

Рис. 2. Архитектура централизованного хранения НСИ

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

  •  IBM Client Information Integration Solution (IBM CIIS). Представляет собой хранилище данных, поддерживающее как пакетный режим, так и обработку в реальном времени. Управление моделью данных НСИ осуществляется через специальную графическую оболочку, что позволяет снизить требования к квалификации сотрудников, отвечающих за ведение НСИ. Использование данного решения типично для банков и страховых компаний;
  •  Oracle Customer Data Hub (Oracle CDH). Является первым в семействе специализированных хранилищ основных данных, разрабатываемых компанией Oracle. Продукт подходит для управления реестрами клиентов, сотрудников, населения отдельных регионов и страны в целом и т. д. Примеры его внедрения можно встретить в телекоммуникационных и высокотехнологичных компаниях;
  •  SAP MDM на  базе SAP NetWeaver – это комплексная интеграционная платформа, являющаяся технологической основой всех решений SAP. SAP NetWeaver - следующее поколение платформы mySAP Technology, предоставляющее средства интеграции на всех уровнях взаимодействия сотрудников и бизнес-приложений вне зависимости от технологических и организационных рамок, в том числе на уровне информации.

Децентрализованное хранение (виртуальное хранилище) 

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

Рис. 3. Архитектура виртуального хранилища НСИ

Ярким представителем, реализующим виртуальное хранилище данных, является решение компании MetaMatrix, состоящее из двух продуктов - MetaBase и MetaMatrix Server.

Смешанные хранилища данных 

На рынке систем НСИ находят свое место и смешанные решения, реализующие одновременно принципы централизованного и децентрализованного хранения. Такой подход используется в следующих продуктах:

  •  Initiate Systems Identity Hub. Решение компании Initiate Systems, ранее реализованное в централизованной архитекторе, благодаря покупке ею фирмы Journee/ улучшило свои интеграционные возможности и перешло в ранг смешанных хранилищ данных. Осталась на высоте и хорошо зарекомендовавшая себя подсистема сверки данных. Данное решение популярно среди фармацевтических компаний и организаций здравоохранения, однако благодаря динамичному развитию стремится занять и другие ниши рынка НСИ;
  •  DWL Customer. Гибридное хранилище данных, обладающее самой лучшей среди представленных в настоящем обзоре систем поддержкой сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA). Компания DWL имеет богатый опыт внедрения своих систем в финансовых организациях, но позиционирует данное решение также для сферы телекоммуникаций и здравоохранения;
  •  Siebel Universal Customer View (Siebel UCM). Так же как и DWL Customer, обладает развитой поддержкой архитектуры SOA; в составе продукта насчитывается около 140 Web-сервисов. А для решения интеграционных задач у фирмы Siebel имеется собственная платформа - Universal Application Network (UAN);
  •  Siperian Master Reference Manager (Siperian MRM). Представляет собой систему с гибкой моделью хранения. Основные данные, необходимые для идентификации сущности, а также таблица ключей соответствия между используемыми источниками информации хранятся в эталонной БД, а операционные и другие характеристики сущности загружаются непосредственно из источников. Для увеличения быстродействия данные могут кэшироваться.

  1.  Исследование конфигурации продукции в разных системах классификации и возможности интеграции SAP системы с системами классификации.

Рассмотрим следующие системы классификации:

  •  Ontologic
  •  Каталит
  •  NIKA
  •  SAP на базе SAP Netweaver

Для чистоты эксперимента возьмем один и тот же вариант продукта Сталь холоднокатаную рулон. Рассмотрим возможность конфигурации данного варианта в заказе клиента.

  •  Система классификации Ontologic: Возможность передать напрямую просто отсутствует. Вывод: передать можно только разработав соответствующий интерфейс, позволяющий синхронизировать справочники систем.
  •  система "Каталит": Возможность передать напрямую просто отсутствует, система узкоспециализирована и просто «не понимает» представления моделей конфигурации SAP. Работает только со своими БД. Генерация вручную возможна, но трудоемка и бессмысленна. Вывод: передать можно только разработав соответствующий интерфейс, позволяющий передать код материала ,компонентов и присвоить их соответствующему продукту в справочнике материалов SAP
  •  Система каталогизации «NIKA»: Возможность передать напрямую просто отсутствует, система узкоспециализирована и просто «не понимает» представления моделей конфигурации SAP. Работает только со своими БД. Генерация вручную возможна, но трудоемка и бессмысленна. Вывод: передать можно только разработав соответствующий интерфейс, позволяющий передать код материала ,компонентов и присвоить их соответствующему продукту в справочнике материалов SAP
  •  Система классификации SAP на базе SAP Netweaver: Возможность передать напрямую  имеется.

Вывод: Базовая система классификации решает проблемы несовместимости данных. Так как встроена в платформу SAP.

  1.  Выбор системы классификации

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

Наиболее привлекательной представляется система классификации SAP.

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

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

Также данное решение позволит избежать трудности при интегрировании различных программных продуктов.

  1.  Структура Базовой системы классификации SAP на базе платформы SAP Netweaver

SAP NetWeaver – это комплексная интеграционная платформа, являющаяся технологической основой всех решений SAP. SAP NetWeaver - следующее поколение платформы mySAP Technology, предоставляющее средства интеграции на всех уровнях взаимодействия сотрудников и бизнес-приложений вне зависимости от технологических и организационных рамок, в том числе на уровне информации.

Интеграцию информации обеспечивают следующие компоненты платформы:

  •  хранилище бизнес-информации (SAP Business Warehouse, SAP BW),
  •  управление знаниями (SAP Knowledge Management, SAP KM) и
  •  управление основными данными (SAP Master Data Management, SAP MDM).

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

Рис. . База знаний SAP

Система классификации SAP  является инструментом, предоставляющим также коды поиска и мнемонические номера для создания соответствующей системы классификации.

Система позволяет создавать так называемых иерархические сети, т.е. у одного класса может быть несколько предшествующих.

Базовая система классификации SAP  подразделяется на 4 области.
- ведение признаков
- ведение классов
- классификация (присвоение/присвоение значений признакам)
- поиск объектов

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

Например, поиск материала можно начинать из заказа клиента.

  1.  Основные понятия

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

Рис. . Основные данные в SAP/R3

Класс – группа объектов с одинаковыми или подобными свойствами.

Объект – классифицируемая единица.

Признак – описывает свойства объекта(длина, вес).

Значение признака – характеристика признака(10м, 7 кг)

Вы описываете объекты с помощью признаков класса.

Объект можно одновременно присвоить одному или нескольким классам.

После этого возникает возможность целенаправленного поиска объекта в системе классов.

Если классу присвоено несколько признаков, то возможно задать  критерий поиска - признаки.

Возможность создания иерархических сетей.

  1.  Связи между признаками и их значениями

Связи или отношения описывают взаимозависимости между объектами. Это может относиться к зависимостям между признаками и значениями признаков.

Описание связей осуществляется в редакторе отношений с помощью специального синтаксиса на языке ABAP/4.

  1.  Список процедур

Для того, чтобы создать конфигуратор необходимо:

  •  Добавление новых признаков
  •  Объединение признаков в справочный класс
  •  Отношения между признаками
  •  Коэффициент пересчета

  1.  Возможности

При получении заказа вводятся признаки заказанного клиентом продукта, а также вся необходимая информация, касающаяся требуемого срока поставки, цен и условий поставки. Проверка соответствия между данными клиента, конфигурацией продукта и условиями поставки играет важную роль. Базовая система классификации позволяет эффективно решать эту задачу – для облегчения ввода больших объемов данных условия для проверки могут хранится в таблицах вариантов, например, по каждому клиенту. Признаки конфигурированных материалов используются для определения продажной цены. Данная система классификации позволяет обрабатывать допуски на размеры продуктов в заказе клиента., т.е. общая площадь или количество могут покрываться различными комбинациями длин или ширины, но в пределах заданных допусков.

Дополнительные возможности:

  •  Указание до 10 значений признаков для каждой позиции заказа
  •  Выполнение автоматической проверки доступности продуктов на складе при изменении значений признаков
  •  Специфический для клиента расчет цены ( характеристики вариантов оцениваются по-разному)
  •  Интеграция с SAP CRM. Клиент может разместить свой заказ используя варианты в Интернет – магазине. Основные данные и информационная база ведутся в единой системе и автоматически синхронизируются с CRM

  1.  Основная продукция – классы, признаки.

Классификация – это инструмент в SAP/R3, который  представляет собой иерархическое группирование объектов со схожими признаками (например, товары) вместе в определенной структуре. Система классификации позволяет классифицировать все типы объектов в системе.

Целью классификации является анализ товарных потоков в разрезе элементов классификации и назначение условий ценообразования для операций закупки и операций продаж в модуле Сбыт.

В ИСУ Сбыта классификация основана на системе классов SAP.  Это инструмент, позволяющий группировать определенные объекты (например, товары) в упорядоченную структуру. Основная функция классификации – являться репозитарием для всех признаков, которые могут иметь различные виды объектов. Эти признаки затем могут быть использованы для группирования схожих объектов в классы для  того, чтобы система легче находила  их при выполнении операций.

Каждая независимая структура классификации определяется видом класса. Вид класса в системе определяет следующее:

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

Рис. . Классификация готовой продукции на предприятии КАРМЕТ

Рис. . Общая схема работы

  1.  Средства разработки

Основная концепция разработки приложений в системе R/3 заключается в возможности многократного использования объектов данных различными пользователями сети. Для этого в язык ABAP/4 было введено понятие "внутренняя таблица", которая является временным "моментальным снимком" таблиц базы данных или представлений этих таблиц. (В других реляционных СУБД аналогом этого понятия может служить курсор.) К отличительной особенности R/3 относится понятие логической базы данных (Logical Database), позволяющей генерировать отчеты и осуществлять быстрый поиск информации в основной БД, а также использовать сколь угодно изощренные критерии отбора. Неординарной, с точки зрения пользователя реляционной базы данных, является концепция так называемой расширенной транзакции R/3, которая служит основой разработки многоэкранных прикладных программ и обеспечивает целостность данных в базе. Известно, что в прикладных программах интерфейс с конечным пользователем имеет первостепенное значение. Development Workbench позволяет строить диалог с помощью таких экранных элементов, как линейки меню, пиктограммы, экранные кнопки и специальные сообщения об ошибках. Интерфейсы, поддерживаемые в языке ABAP/4, обеспечивают связь написанных на нем программ с различными внешними компонентами, начиная от простейших операций с файлом и кончая мощными средствами вызова удаленных функций (Remote Function Call) для запуска приложений в стандарте OLE, или программ, написанных на языке С++. Встроенная в средства Development Workbench утилита Workbench Organizer предназначена для управления совместной разработкой проектов в распределенной среде, обеспечивая не только аутентификацию прав и управление доступом, но и контроль версий.

Название ABAP/4 - сокращение от Advanced Business Application Programming 4GL (развитый язык программирования коммерческих приложений четвертого поколения). На этом языке разработаны все приложения R/3 и даже часть базовых компонент системы. Главной особенностью ABAP/4 является его ориентированность на обработку событий, которые инициируют обработку объектов.

Открытость приложений и независимость их от используемых платформ обеспечиваются собственными механизмами R/3. Например, применение расширения вызова функции - вызова удаленных функций (Remote Function Call) - дает возможность разрабатывать программы для распределенной обработки данных с участием нескольких систем R/3, а также внешних систем. Интегрированное в язык ABAP/4 подмножество SQL (так называемый открытый SQL - Open SQL) и интерфейс с базой данных R/3 образуют "связной" уровень, который располагается между СУБД и прикладной программой. Использование возможностей исполнительной системы ABAP/4 и многоуровневой архитектуры позволяет разработчику сконцентрировать свои усилия на предметном содержании задачи и не заботиться о таких технических деталях, как управление распределением памяти, вычисление указателей или организация работы в сети.

Несмотря на то, что по сути, язык ABAP/4 является простым интерпретатором, он поддерживает не только набор элементарных типов (символьное, целое, дата), но и более сложные структуры - записи и внутренние таблицы. Кроме того, концепция использования внутренних таблиц, которая заключается в отображении постоянных таблиц БД на объекты, существующие во время исполнения, и, наоборот, является его ключевой особенностью. Это значительно упрощает многие проблемы программирования для реляционных и нереляционных баз данных. Многократное использование неэлементарных типов и структур данных обеспечивается за счет хранения их определений в интегрированном словаре ABAP/4 Dictionary.

В отличие от обычных таблиц базы данных, которые существуют вне зависимости от того, обращается пользователь к ним или нет, внутренние таблицы формируются только на время исполнения программы. Они часто используются в качестве "моментальных снимков" таблиц БД или "контейнеров" для временного хранения данных в программе. Одним из наиболее привлекательных для разработчика свойств внутренней таблицы является ее "безразмерность", поскольку по правилам языка ABAP/4 в ней может содержаться любое число строк (или элементов) одинакового типа. При добавлении строк к таблице исполнительная система ABAP/4 автоматически выделяет новую область памяти, поэтому нет необходимости заранее вычислять, какое число строк будет записано в таблицу во время исполнения программы. Внутренние таблицы особенно удобно использовать для временных копий элементов БД и их частей, а также комбинирования содержимого различных таблиц и строительства объектов, называемых "временными представлениями" (temporary view). Кроме того, внутренние таблицы могут быть вообще не связаны с таблицами базы (например, при создании и выводе на экран структур типа "дерева" или общих связанных списков).

Еще одной особенностью языка ABAP/4 является специальное поле типа Field-Symbols, которое служит для хранения других полей и различных объектов данных. Применение такого поля не требует выделения памяти, так как, по сути, поле Field-Symbols служит указателем, в котором хранится адрес объекта данных, назначенный этому объекту при исполнении программы. Связь поля Field-Symbols с объектом данных обеспечивается с помощью операций присвоения (assign). После присвоения полю Field-Symbols значения объекта оно наследует все свойства последнего, поэтому работать с ним можно так же, как с самим объектом.

  1.  Разработка структуры базы знаний

Структура  справочной  информации  включает  объекты.  Объект – это  абстрактное  понятие,  которое  есть  некоторая  совокупность  атрибутов. Справочные  объекты – это  готовые  изделия.  Они  должны  строиться  в  виде  иерархических  классификаторов.  Все  связи,  как  правило,  род – вид.

Информация  включает: основной  объект – изделие, характеристики. В  свою  очередь,  состав  характеристик  тоже  является  объектом-вариантом  и  его  можно  аналогично  рассмотреть  как  объект,  который  состоит  из  выбранных признаков  .  Выбранный  вариант  состоит  из  признаков.  В  свою  очередь,  каждый  из  них  может  иметь  свой  набор  свойств.  Связи  здесь -  часть – целое.  

  1.  Описание отношений на примере рулонной стали

Вся продукция разделена на группы товаров .Посредством групп товаров выполняется классификация и структурирование по всем аспектам материалов на предприятии. Для этого определяется иерархия групп товаров, которая будет состоять из групп товаров и наивысших уровней иерархии групп товаров. Все элементы уровней иерархии групп товаров определяются как классы и присваиваются внутреннему системному виду класса 001 «Иерархия групп материалов».

В зависимости от группы товаров можно определить специфические признаки, которые имеют классифицирующую функцию и влияют на создание вариантов родовых товаров. Также признаки являются средством, с помощью которого объекты различаются друг от друга внутри вида класса, и могут быть использованы в качестве критериев поиска. Признаки являются важным параметром в классификации, так как позволяют описывать любую особенность объекта.

Рис. . Признаки Стали

База данных состоит из определенного набора таблиц.

Важной особенностью представления информации является хранение минимального количества информации. Поясним это на примере. Допустим, пользователь желает сохранить в информацию о готовой продукции - стали, причем имеется базовая модель и множество ее модификаций, различающихся значениями 1..2 характеристик:

№ Модели

Хар-ка№1

..

Хар-ка№(n-1)

Хар-ка№(n)

Модель Баз.

Знач. 1

..

Знач. К-1

Знач. Кбаз.

Модель 1

--//--//--

..

--//--//--

Знач. К1

..

Модель м

--//--//--

..

--//--//--

Знач. Км

Если хранить в БД информацию о каждом варианте продукта полностью, то большинство информации оказывается избыточной. В реализованной версии хранится только необходимая информация, т.е. для приведенного выше примера в БД хранилась бы полная информация о Базовом варианте продукта, а для каждой разновидности – только значения Характеристики №(n). Причем при просмотре пользователем характеристик любой модели информация, естественно, предоставляется ему в полном объеме.

Описание отношений в данном примере

Описание отношений:

000010 $ self.COMPACTNESS=7.650 if $ self.z_k07 in (‘08ПС’,’3ПС/СП’),

000020 $ self.COMPACTNESS=7.80 if $ self.z_k07 eq ‘08Ю’,

000030 $ self.COMPACTNESS=0.064 if $ self.z_k01 in (‘CОЦЛ14918’,’СОЦЛБГ’,’CОЦР14918’,’СОЦРБГ’) or

$ self.z_k01a in (‘CОЦЛ14918’,’СОЦЛБГ’),

000040 $ self.COMPACTNESS=0.110 if $ self.z_k01 eq ‘СППРБ’or

$ self.z_k01b eqCППБ’

База данных состоит из определенного набора таблиц. Рассмотрим подробнее  состав таблиц БД системы классификации.

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


  1.  Алгоритм сбора значений свойств выбранного объекта

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

( SELECT  *  FROM  DATA_TEXT

WHERE KOD_OBJECT =  <номер объекта> )

 недостаточно для получения полной информации об объекте. Ниже приводится алгоритм решения этой задачи, реализованный в данной версии.

Входной информацией для алгоритма является номер объекта (kod_object). По завершении работы алгоритма формируется таблица SERVICE, содержащая полную информацию о свойствах и значениях объекта. Выполнение инструкций алгоритма возложено на серверную часть (хранимые процедуры СУБД). Для решения задачи выдачи пользователю информации об объекте используется 2 специальные таблицы БД (служат только для показа свойств объекта ) . Суть алгоритма – в просмотре свойств всех объектов цепочки  <объект (0)>-<родитель объекта0 (1)>..<root>  начиная с интересующего объекта и сохранении тех из них, которые, согласно наследованию и принципам хранения информации об объектах, можно отнести к интересующему нас объекту в специальной таблице. При движении по цепочке <объект>..<root>  на каждом итерационном шаге  существует текущий объект. Для текущего объекта из ТБД DATA_ считывается поочередно запись о свойстве и его значении. Если такая запись уже есть в ТБД SERVICE, то только что прочитанная запись не сохраняется и считывается следующая (согласно тому, что значение свойства объекта отменяет значение соответствующего свойства родителя), если нет то запись помещается в спец. ТБД BUFF. По завершении обработки всех записей, относящихся к текущему объекту, содержимое ТБД BUFF записывается в ТБД SERVICE, вычисляется объект-родитель текущего объекта (обращение к ТБД LINK) и этот объект становится текущим. Алгоритм завершается когда текущим оказывается  объект <root> - вершина дерева объектов.

  1.  Алгоритм сбора состава выбранного объекта… . 

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

Алгоритм состоит из двух частей. Первая часть выполняется средствами СУБД (хранимая процедура). Вторая часть выполняется клиентской частью (процедура системы классификации). На вход первой части алгоритма подается значение номера интересующего объекта (kod_object). На выходе формируется таблица LINK_SERV, содержащая связи (link), описывающие состав объекта. Эта часть реализована с помощью хранимой процедуры и триггера. Процедура записывает в таблицу все записи таблицы LINK, которые описывают связь ЦЕЛОЕ-ЧАСТЬ (имеет зарезервированный тип – 0), где целым является интересующий нас объект. Далее срабатывает триггер (активен после добавления записи в таблицу LINK_SERV), который выполняет то же, что и описанная выше процедура, но входной информацией для триггера является номер объекта, взятый из только что добавленной записи.

Далее выполняется вторая часть алгоритма, которая по сформированной таблице LINK_SERV строит дерево состава объекта.

  1.  Алгоритм работы базы знаний

  1.  Текст программы работы базы знаний

FUNCTION Z_CLASS_2_QUART.
*"--------------------------------------------------------------------
*"*"
Локальный интерфейс:
*" IMPORTING
*" VALUE(I_AREA) TYPE UPC_Y_AREA
*" VALUE(I_VARIABLE) TYPE UPC_Y_VARIABLE
*" VALUE(I_CHANM) TYPE UPC_Y_CHANM
*" VALUE(ITO_CHANM) TYPE UPC_YTO_CHA
*" EXPORTING
*" REFERENCE(ETO_CHARSEL) TYPE UPC_YTO_CHARSEL
*"--------------------------------------------------------------------

CONSTANTS:
L_SOURCE_VAR TYPE UPC_Y_VARIABLE VALUE 'YMONTH',
L_SOURCE_AREA TYPE UPC_Y_AREA VALUE 'YUBM',
L_USE_RESTRICTED_VALUES TYPE BOOLE-BOOLE VALUE 'X',
L_BUFFER_CALL TYPE BOOLE-BOOLE VALUE ' '.

DATA:
Q TYPE C LENGTH 5,
M TYPE C LENGTH 6,
M1 TYPE N LENGTH 2,
L_SUBRC LIKE SY-SUBRC,
LS_RETURN LIKE BAPIRET2,
L_TYPE LIKE UPC_VAR-VARTYPE,
LTO_VARSEL_ALL TYPE UPC_YTO_CHARSEL,
LTO_VARSEL TYPE UPC_YTO_CHARSEL,
LTO_VAR TYPE UPC_YTO_CHARSEL,
LS_VARSEL TYPE UPC_YS_CHARSEL,
LS_LINE LIKE LINE OF LTO_VARSEL,
LTO_CHANM TYPE UPC_YTO_CHA.

*
Читает значение переменной
CALL FUNCTION 'Z_VARIABLE_GET_DETAIL'
EXPORTING
I_AREA = L_SOURCE_AREA
I_VARIABLE = L_SOURCE_VAR
I_BUFFER = L_BUFFER_CALL
IMPORTING
E_SUBRC = L_SUBRC
ES_RETURN = LS_RETURN
E_TYPE = L_TYPE
ETO_VARSEL_ALL = LTO_VARSEL_ALL
ETO_VARSEL = LTO_VARSEL
ETO_CHANM = LTO_CHANM.

REFRESH ETO_CHARSEL.
LOOP AT LTO_VARSEL INTO LS_LINE.
LS_VARSEL-CHANM = '0CALQUARTER'.
LS_VARSEL-SIGN = LS_LINE-SIGN.
LS_VARSEL-SEQNO = LS_LINE-SEQNO.
M = LS_LINE-LOW.
Q+0(4) = M+0(4).
M1 = M+4(2).
IF ( M1 >= 1 ) AND ( M1 <= 3 ).
Q+4(1) = '1'.
ELSEIF ( M1 >= 4 ) AND ( M1 <= 6 ).
Q+4(1) = '2'.
ELSEIF ( M1 >= 7 ) AND ( M1 <= 9 ).
Q+4(1) = '3'.
ELSEIF ( M1 >= 10 ) AND ( M1 <= 12 ).
Q+4(1) = '4'.
ELSE.
Q = ''.
ENDIF.
LS_VARSEL-LOW = Q.
M = LS_LINE-HIGH.
Q+0(4) = M+0(4).
M1 = M+4(2).
IF ( M1 >= 1 ) AND ( M1 <= 3 ).
Q+4(1) = '1'.
ELSEIF ( M1 >= 4 ) AND ( M1 <= 6 ).
Q+4(1) = '2'.
ELSEIF ( M1 >= 7 ) AND ( M1 <= 9 ).
Q+4(1) = '3'.
ELSEIF ( M1 >= 10 ) AND ( M1 <= 12 ).
Q+4(1) = '4'.
ELSE.
Q = ''.
ENDIF.
LS_VARSEL-HIGH = Q.
LS_VARSEL-OPT = LS_LINE-OPT.
APPEND LS_VARSEL TO ETO_CHARSEL.
ENDLOOP.

ENDFUNCTION.

 


  1.  Концептуальное проектирование
    1.  Цели создания информационной системы управления поставками

Главная цель создания системы

На основании требований заказчика, главной целью (см. рисунок 5) создания подсистемы “Управления поставками” является:

Повышение экономической эффективности отдела поставок за счет повышения уровня обслуживания клиентов, т.е. наиболее полного удовлетворения всех их потребностей.

Первоочередные цели создания системы

Достижение главной цели создания системы “Управления поставками” обеспечивается достижением целей второго уровня (см. рисунок ), которыми являются:

  •  Повышение эффективности использования информации внутри холдинга;
  •  Снижение временных затрат при формировании заказа клиента;
  •  Достижение подцели “Снижение временных затрат пользователей информационных ресурсов” становиться возможным при решении следующих задач (см. рис 5):
  •  Сокращение количества проведения процедур авторизации в системе;
  •  Сокращение времени на обмен информацией;
  •  Сокращение времени поиска информации;
  •  Сокращение временных затрат на формирование отчетности и выходных форм;
  •  Сокращение временных затрат при совместной работе пользователей;
  •  Сокращение временных затрат при ведении данных и последующей корректировки.

Дерево

  1.  Цели создания системы классификации

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

Узкие места предприятия:

  •  Множество бессистемной и децентрализованной нормативно-справочной информации (НСИ)
  •  Одни и те же объекты кодируются по – разному
  •  Отсутствует возможность хранения качественных характеристик материала
  •  Отсутствует возможность отражения различных конфигураций продукта.

что существенно тормозит работу отделов. Это приводит к проблемам информационного взаимодействия между различными системами и подсистемами, за которыми стоит несогласованность действий участников разделения труда внутри одного предприятия, конкретной производственно-поставочной цепочки и, соответствующие, весьма немалые, затраты ресурсов на преодоление последствий такой несогласованности. Необходимо выработать "общий язык данных" при организации эффективного взаимодействия персонала на всем предприятии. Соответствующая призвана обслуживать потребности всех участников устойчивой деловой цепи, и должна быть отчуждена от конкретики бизнес-процедур каждого отдельного ее участника. Вторая, не менее актуальная задача такой системы - распространение НСИ в масштабах организации, которая в свою очередь территориально – распределена, и обеспечение обмена справочниками с внешними контрагентами предприятия, а также с поставщиками.
Для отдела сбыта, предоставляющего широкий спектр металлопродуктов со сложными взаимосвязями, необходимо выстроить гибкое соответствие между продуктами, которые предоставляются клиентам, и ресурсами, на базе которых эти продукты реализованы. Для решения поставленной задачи необходимо исследовать и определить технологию классификации.

Реорганизация и технологическое переоснащение служб НСИ является весьма экономичным и реально достижимым способом повышения эффективности использования управленческой информации - это целенаправленная ликвидация узкого места.

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

  1.  Основные принципы разработки информацонной системы системы 

В ходе проведения системно-аналитических работ было выявлено, что заказчик предъявляет ряд требований не только к системе “Информационный портал”, но и к проекту по её созданию. Были сформулированы следующие требования:

Проект по созданию системы проводится в несколько этапов;

Для принятия окончательного решения со стороны руководства всех компаний холдинга о запуске проекта необходим успешный запуск в эксплуатацию прототипа “Информационного портала” с ограниченной функциональностью на базе наименее затратной программной платформе;

Финансирование проекта осуществляется поэтапно. Финансирование нового этапа осуществляется по результатам приёмо-сдаточных работ предыдущего этапа;

Для демонстрации целевого использования средств, выделенных на финансирование работ по созданию “Информационного портала”, необходим скорейший запуск в эксплуатацию вновь создаваемых системно-технических решений. При этом допускается функциональность не полностью отвечающая установленным требованиям к системе, которая будет доведена до соответствия этим требованиям к моменту окончания соответствующего этапа разработки.

Опираясь на переставленные выше требования к проекту со стороны заказчика, опыт разработки подобного рода систем и ограничение по количеству разработчиков (5-7 человек), было принято решение о проведении работ по созданию “Подсистемы управления поставками” в соответствии с основными принципами ASAP-методологии (Accelerated SAP) [5], а именно:

1. Экспресс-обследование
Обследование, которое обычно продолжается не больше 3-х недель, позволяет понять ключевые потребности клиента в функциональности ERP-системы, оценить состояние материальных и временных ресурсов и условий проекта внедрения. В результате обследования определяется конфигурация необходимой функциональности системы, программных и технических средств, а также концепция развертывания системы.

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

3. Детальный анализ бизнес-процессов
Анализу предшествует детальное обследование: определяются информационные потоки предприятия и модели бизнес-процессов, осуществляется сбор всей необходимой для настроек информации. Особое внимание уделяется вопросам интеграции внедряемой системы с другими системами, которые используются на предприятии. Результатом анализа является согласованный с клиентом план проекта и техническое задание.

4. Развертывание системы и разработка концептуальной модели
На этом этапе, в соответствие с концепцией развертывания системы и планом проекта, формируется техническая инфраструктура проекта и инсталлируется система R/3. По завершению инсталляции начинается настройка, в результате которой создается концептуальная модель будущей системы, включающая организационную структуру предприятия, справочники и процедуры учета ранее определенных бизнес процессов. Разработка модели включает в себя также определение пользователей и полномочий, процедур безопасности, систему отчетности и администрирования данных.

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

6. Тестовая эксплуатация
Тестовая эксплуатация проводится по согласованной с клиентом программе и методике испытаний, и завершается оформлением протокола, подтверждающего достижение поставленных целей по отдельным участкам и системе учета в целом.

7. Опытная эксплуатация
Опытная эксплуатация системы дает заказчику возможность максимально оценить ее эффективность, выявить и устранить недостатки. В результате принимается решение о вводе системы в продуктивную эксплуатацию и передаче ее на сопровождение.

8. Сопровождение системы
В рамках сопровождения системы проводятся работы по развитию системы, обновлению версий, созданию дополнительных отчетов, переподготовке пользователей и администрирования данных.

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

6. Тестовая эксплуатация
Тестовая эксплуатация проводится по согласованной с клиентом программе и методике испытаний, и завершается оформлением протокола, подтверждающего достижение поставленных целей по отдельным участкам и системе учета в целом.

7. Опытная эксплуатация
Опытная эксплуатация системы дает заказчику возможность максимально оценить ее эффективность, выявить и устранить недостатки. В результате принимается решение о вводе системы в продуктивную эксплуатацию и передаче ее на сопровождение.

8. Сопровождение системы
В рамках сопровождения системы проводятся работы по развитию системы, обновлению версий, созданию дополнительных отчетов, переподготовке пользователей и т.д.

К основным достоинствам данного подхода можно отнести:

  •  ускорение запуска в эксплуатацию работоспособного варианта системы;
  •  участие заказчика в процессе разработки;
  •  снижение риска неудовлетворённости заказчика.

К основным недостаткам данного подхода можно отнести

  •  сложность планирования (определения количества и длительности итераций);
  •  сложность управления процессом разработки;
  •  напряженный режим проектной работы.

  1.  Основные принципы заложенные в разрабатываемую систему

Основные принципы, заложенные в разрабатываемую систему [6]:

  1.  Принцип соответствия

Архитектура информационной системы должна соответствовать текущим и перспективным целям и функциональным задачам, создаваемой системы;

  1.  Открытость

Для обеспечения перспективы развития информационной системы необходимо предусматривать возможность “бесшовной ” интеграции гетерогенных вычислительных компонент и различных приложений, а также предусматривать мобильность приложений на различные аппаратные и операционные платформы на основе стандартов открытых систем;

  1.  Принцип модульности

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

  1.  Принцип индивидуализации

Необходимо обеспечить максимально удобный индивидуальный доступ к информационной системе для всех потенциальных групп пользователей с функциональностью соответствующей задачам, решаемым этими группами пользователями.

  1.  Принцип управляемости

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

  1.  Принцип безопасности и надёжности

Должны быть обеспечены безопасность функционирования информационной системы и надёжная защита данных от ошибок, от преднамеренного разрушения или потери информации, а также авторизация пользователей, управление рабочей нагрузкой, резервированием и оперативным восстановлением функционирование информационной системы после сбоев.

  1.  Принцип системности

Архитектура системы должна быть построена таким образом, чтобы все взаимосвязанные подсистемы строились по единой методологии и отвечали единым принципам взаимодействия, надёжности и управления.

  1.  Выбор Case средств при создании системы

Для применения процессного подхода при внедрении ERP-системы необходимо иметь методологию моделирования и анализа бизнес-процессов, а также крайне желательно иметь средство моделирования бизнес-процессов и инструментарий, позволяющий осуществить его интеграцию со средствами конфигурации ERP-системы. Подобное комплексное решение позволит добиться сокращения времени и затрат при описании, моделировании, внедрении, эксплуатации, мониторинге и оптимизации бизнес-процессов.

Продукт ARIS for SAP NetWeaver является именно таким решением, позволяя легко управлять изменениями в моделях процессов, обеспечивая прозрачную и гибкую интеграцию конфигурационных и выполняемых моделей, сокращение затрат и непрерывное пополнение базы знаний о бизнес-процессах. Он основан на платформе управления бизнес-процессами ARIS компании IDS Scheer, содержащей интегрированный набор программных продуктов ARIS для проектирования, внедрения и управления бизнес-процессами, и предоставляющей доступ к стандартным методам, инструментам и «ноу-хау», обеспечивающим оптимальное решения задач внедрения информационных систем и предназначен для управления бизнес-процессами при помощи приложений, основанных на платформе SAP NetWeaver.

ARIS for SAP NetWeaver – решение, совместно разработанное компаниями IDS Scheer и SAP, содержащее последовательное описание процессной архитектуры следующего поколения: от бизнес-моделей до внедрения процессов при помощи SAP Solution Manager, до интеграции приложений и выполняемых процессов в инфраструктуре SAP Exchange Infrastructure (SAP XI) при помощи средства управления потоками работ SAP Business Workflow.

Данный продукт позволяет создать на этапе проектирования
системы архитектурную модель процесса, позволяющую описать процессную стратегию компании и переформулировать ее в нужном виде. Затем создается конфигурационная модель для описания структуры процессов до уровня отдельных шагов, относящихся к сценариям mySAP с использованием различных компонентов mySAP Business Suite. При помощи ARIS for SAP NetWeaver можно выбирать бизнес-сценарии и бизнес-процессы, поддерживаемые SAP-системами, из числа предлагаемых примеров с учетом собственных требований к управлению бизнесом, при этом модели бизнес-процессов могут быть синхронизированы между ARIS for SAP NetWeaver и SAP Solution Manager, что гарантирует поддержку системой бизнес-процессов компании.
Следующей стадией разработки решения на основе SAP NetWeaver является создание выполняемой модели процесса, с помощью которой смоделированные потоки процессов используются инфраструктурой SAP XI для выполнения моделей процессов. На этой стадии сквозные межсистемные процессы интегрируются с прикладными процессами отдельных информационных систем (в том числе и не имеющих отношения к SAP), а также с системами управления потоками работ.

Таким образом, совместное решение компаний SAP и IDS Scheer позволяет применять единый метод интеграции бизнес-процессов, начиная с общего обзора бизнеса и кончая технической реализацией в виде информационной системы. Следовательно, указанное решение дает возможность быстро внедрять инновационные стратегии и бизнес-процессы, снижать операционные расходы и обеспечивать защиту вложений в проектирование, создание и внедрение информационной системы за счет повторного использования созданных моделей в будущем.

  1.  Функциональная структура TO-BE

Модель основных функций подсистемы “Управления поставками” (см. рисунок 7) разработана на основе функциональной модели “Управления поставками as is” (см. рисунок 3) с учётом целей и задач, решение которых должно обеспечить внедрение системы. При разработке новой функциональной модели учитывались следующие принципы функционального проектирования [1], [2]:

Устранение избыточных функций;

Перераспределение функций между сотрудниками, обеспечивающими нормальное функционирование системы, с учётом количества функций, выполняемых каждым сотрудником (не более 5-7);

Передача функций, несвойственных должностным обязанностям одних сотрудников, тем сотрудникам, в чьи должностные обязанности входит выполнение данных функций;

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

Функциональная модель подсистемы представлена в виде диаграммы TO-BE” на рисунке 7.

Рис. 7. Функциональная схема работы подсистемы

  1.  Состав подсистемы управления поставками

Состав подсистем системы “управление поставкми” разработан в соответствии с функциональными возможностями системы и с учётом “Основных принципов, заложенных в разрабатываемую систему” . В подсистему “Управления поставками” входят следующие функциональные модули (см. рисунок 7):

  1.  Управление заказами;
  2.  Поставка товара
  3.  Фактурирование

  1.  Целевое задание на разработку

Модель основных функций системы “Управление поставками TO-BE” (см. рисунок 7) разработана на основе функциональной модели “Управление поставками AS-IS” (см. рисунок 3) с учётом целей и задач, решение которых должно обеспечить внедрение системы. При разработке новой функциональной модели учитывались следующие принципы функционального проектирования [1], [2]:

Устранение избыточных функций;

Перераспределение функций между сотрудниками, обеспечивающими нормальное функционирование системы, с учётом количества функций, выполняемых каждым сотрудником (не более 5-7);

Передача функций, несвойственных должностным обязанностям одних сотрудников, тем сотрудникам, в чьи должностные обязанности входит выполнение данных функций;

Включение в систему функциональности, отвечающей современным потребностям с учётом поставленных перед системой целей и задач.

  1.  Информационная модель подсистемы 

  1.  Техническое проектирование
    1.  Блок-схема алгоритма работы подсистемы 

На  приведена блок-схема работы подсистемы создание заказа клиента.

Рис. . Блок-схема работы подсистемы управления заказами

  1.  Описание алгоритма работы подсистемы управления заказами.

Рассмотрим этапы работы алгоритма.

Запуск приложения GUI. На этапе происходит соединения с системой R/3.

Ввод пользовательских данных. Система R/3 является многомандантной системой. Согласно концепции мандантов, можно вести хозяйственную деятельность нескольких отдельных предприятий одновременно в одной системе R/3. Каждый режим пользователя получает доступ к данным только того манданта, который был указан при входе в систему.

  •  Чтобы войти в систему R/3, пользователь должен иметь основную запись пользователя, созданную для него в соответствующем манданте.
  •  Из соображений защиты доступа к данным при входе в систему R/3 нужно ввести пароль. Система не показывает пароль при его вводе.

Система R/3 является многоязычной. Языком по умолчанию установлен английский (EN). Для получения на экране интерфейса пользователя, например, на русском языке нужно ввести RU.

  •  Мандант является автономной организационной единицей в системе R/3. Он имеет свою собственную среду данных и, следовательно, свои собственные основные данные пользователя и переменные данные, назначенные основные данные пользователя, план счетов и конкретные параметры настройки.
  •  Пользователи разных мандантов сосуществуют независимо и изолированно в одной системе R/3. Пользователи могут увидеть и обработать данные только того манданта, на который они имеют полномочия.
    Такая спецификация, позволяющая локализовать данные, зафиксирована в конструкции таблиц системы
    R/3, а также на уровне прикладных таблиц и таблиц настройки.
    (Настройка = корректировка системы R/3 под индивидуальные требования пользователей.)

Выбор действия. Вызов меню.

Просмотреть наличие договора. Процедура, которая проверяет наличие договоров с БД.

Создать заказ. В этой транзакции вводятся данные заказа клиента, запускается алгоритм поиска подходящего варианта- на вход поступает номер материала, осуществляется поиск в БД, формируются таблицы с признаками и значениями. Затем выбранные значения копируются в таблицу БД – вычисляется класс и формируется готовый продукт с выбранными характеристиками.

Запись результатов в БД. Выполняется запись данных: дополнительных связей в базу данных R/3.

Выход из приложения. На этом этапе происходит выход из системы. Связь с БД прерывается.

  1.  Рабочее проектирование
    1.  Руководство пользователя Для начала работы с подсистемой требуется войти в систему.

Соединение с ситемой R3.

  1.  Для входа в систему необходимо нажать на кнопку вход.

Рис. . Вход в систему

  1.  
  2.  Необходимо авторизоваться в системе

Система R/3 является многомандантной системой. Согласно концепции мандантов, можно вести хозяйственную деятельность нескольких отдельных предприятий одновременно в одной системе R/3. Каждый режим пользователя получает доступ к данным только того манданта, который был указан при входе в систему.

  •  Чтобы войти в систему R/3, пользователь должен иметь основную запись пользователя, созданную для него в соответствующем манданте.
  •  Из соображений защиты доступа к данным при входе в систему R/3 нужно ввести пароль. Система не показывает пароль при его вводе.
  •  Система R/3 является многоязычной. Языком по умолчанию установлен английский (EN). Для получения на экране интерфейса пользователя, например, на русском языке нужно ввести RU.

Рис. . Окно авторизации

  1.  После входа в систему на экране появляется главное меню SAP-уровня системы R/3.  Когда пользователь выбирает один из пунктов меню, на экране появляется спускающееся меню . Из него можно выбрать уровни прикладной области Сбыт. Система предоставляет список функций, которые можно вызвать для каждого приложения (создать контракт,например).При выборе требуемой функции появляется первый экран , где можно редактировать объект для выбранного приложения. В этом случае пользователь находится в специальном SAP-приложении, называемом транзакция.

 Рис. . Главное меню

Рис. . Транзакция создания заказа клиента

  1.  В процессе заполнения данных заказа клиента, требуется ввести продукт с необходимыми характеристиками. Появляется окно со списком признаков заданного продукта. Последовательно один за другим необходимо выбрать значения каждого появившегося признака.

Рис. . Окно классификации

Рис. . Сформированный вариант

  1.  После того как вариант продукта выбран необходим запустить проверку доступности запаса на складе, которая покажет свободное количество на данный момент.

Рис. . Проверка доступности

  1.  Если требуемое количество доступно в данный момент и документ заполнен. Необходимо запустить проверку документа и сохранить заказ в БД.
  2.  Если никаких действий в системе более не требуется. Приложение закрыть.

  1.  Основные модули программы и их свойства

Поскольку разработка велась в среде ABAP, то была использована модульная структура построения программы. Вся подсистема была разделена на несколько модулей, сгруппированных по выполняемым функциям. Описание этих модулей представлено ниже.

  1.  SAP GUI – модуль связи с БД. Осуществляет установление сеанса связи с БД и синхронизацию таблиц приложения с таблицами БД, а также прерывание сеанса связи с БД.
  2.  Сбыт – модуль основных функций сбыта.
  3.  Отчеты – модуль программ статистики – информация по складу.
  4.  Классификация – модуль управления над классами, признаками и их значениями.
  5.  SPRO – модуль настроек администратора.
  6.  Main menu – модуль главной формы приложения.
  7.  User – модуль настроек пользователя.
    1.  Текст программы «Подсистема создания заказа клиента»

Подсистема создания заказа клиента реализована в среде разработки ABAP. Текст программы приведен в Приложении 1.

  1.  
    Сравнительный анализ подсистемы управления поставками.

Анализ проведен на примере внедрения системы управления поставками в организации «КАРМЕТ»

  1.  Сравнение систем управления поставками

Был проведен сравнительный анализ систем управления поставками с точки зрения эффективности их работы.

Рассматриваемые системы управления:

  •  (1) - До внедрения SAP/R3 когда не осуществлялось автоматизированного управления.
  •  (2) - С SAP/R3 в качестве автоматизированной системы управления.
  •  (3) - Применение SAP/R3 вместе с подсистемой классификации.

При сравнительном анализе сравнивались такие величины как длительность работ, пиковая и средняя загрузка ресурсов при различных системах управления.

Данные для сравнительного анализа о системе управления  до внедрения SAP получены в организации «КАРМЕТ» по опыту выполнения аналогичного вида работ. Данные о системе управления поставками с использованием SAP/R3 получены на основе сценария тестирования. Данные о системе управления проектными работами с использованием SAP/R3 и подсистемы классификации получены на основании моделирования – применения подсистемы классификации при формировании заказа клиента.

  •  Трудозатраты на выполнения основных операций . На Рис. 45 приведена диаграмма трудозатрат при различных системах управления поставками. Как видно из диаграммы при использовании системы (1) есть значительный перерасход ресурсов в размере 20%, то есть сотрудники время от времени работают по 9 часов, при использовании систем (2) и (3) не допускается перерасход ресурсов.

Рис. . Трудозатраты

  •  Увеличение объема продаж.(за счет повышения уровня обслуживания клиентов) На Рис. 46 приведена диаграмма объема продаж. Как видно из диаграммы применение SAP/R3 с дополнительной подсистемой классификации позволяет повысить уровень обслуживания.

Рис. . Объем продаж

  •  Продолжительность выполнения основных работ. На Рис. 47 приведена диаграмма продолжительности выполнения работ. Это основной паказатель эффективности системы управления хозяйственной деятельностью. Результаты показали, что применение SAP/R3 позволило уменьшить продолжительность hf,jn на 16%, а использование SAP с дополнительной подсистемой классификации на 23%.

Рис. . Продолжительность работ

Итак применение подсистемы управления поставками позволяет уменьшить длительность работ за счет автоматизации процессов их основной деятельности, и использования электронного документооборота.

  1.  Оценка среднего объема базы знаний и времени поиска информации
    1.  Расчет среднего объема базы знаний SAP

Для того, чтобы рассчитать средний возможный объем базы, зададимся  количеством информации, хранящимся в базе.

Установим для каждой таблицы необходимый объем для хранения одной записи. Для этого необходимо просуммировать объемы, занимаемые каждым полем таблицы. Зная объем, отводимый  для хранения данных

  •  Integer  отводится 4 байта
  •  Float отводится 4 байта
  •  Date отводится 8 байт
  •  Blob – неограниченный размер. Полагаем в среднем 500 Кбайт

А также зная состав полей каждой таблицы, получаем размер 1-ой записи

Для таблицы OBJECT   8 байт

Для таблицы LINK       16 байт

Для таблицы PARAM  58 байт

Для таблицы DATA_TEXT  85 байт

Для таблицы DATA_FLOAT 64 байт

Для таблицы DATA_INT 64 байт

Для таблицы DATA_BLOB 100033 байт

Полагая, что в Базе знаний  хранится описание 1000 свойств, на 1 хранимый объект приходится в среднем 2 записи в таблице LINK, 10 записей в таблице DATA_TEXT, 10 записей в таблице DATA_FLOAT, 10 записей в таблице DATA_INT, 1,3 записи в таблице DATA_BLOB, получаем, что для сохранения одного объекта необходимо в среднем 132 Кбайт (2170 байт без учета подчиненных OLE-объектов, сохраняемых в поле Blob).

Полагая, что в базе хранится информация о 5000 объектах, получаем искомый средний объем  660 Мбайт.

  1.  Расчет времени поиска информации

Расчет времени поиска будем производить также для условия максимального заполнения базы информационно-справочной системы.

Для этого рассмотрим вначале время, затрачиваемое тестовым примером системы. Прогон тестового примера будет осуществляться на компьютере, обладающем следующими характеристиками:

процессор – Pentium MMX с тактовой частотой 233 МГц;

размер оперативной памяти - 64 Мбайт;

жесткий диск - 4,3 Гбайт с временем считывания около 2,8 Мбайт в секунду.

Замер будет производится при работе с БД, работающей под управлением Windows XP при отсутствии в памяти каких либо других приложений. При замере работы системы в режиме диалога среднее время выполнения запроса равнялось 2-4 сек. Как видно из расчета максимального объема базы и предположив линейную зависимость между объемом и временем получим, что для различных таблиц имеем увеличение размера от 10 до 20 раз, следовательно, из этих значений получаем время, затрачиваемое системой на выполнение запроса - от 4 до 8 сек.

  1.  
    Экономическая часть
    1.  Организация и планирование процесса разработки программного продукта

Разработка программного обеспечения остается до сих пор достаточно трудоемким процессом. Более того, из опыта известно, что проектирование не является точной наукой.

Организация и планирование процесса разработки программного продукта или программного комплекса при традиционном методе планирования предусматривает выполнение следующих работ:

  •  формирование состава выполняемых работ и группировка их по стадиям разработки;
  •  расчет трудоемкости выполнения работ;
  •  установление профессионального состава и расчет количества исполнителей;
  •  определение продолжительности выполнения отдельных этапов разработки;
  •  построение календарного графика выполнения разработки;
  •  контроль выполнения календарного графика.

Укрупненный состав работ по стадиям разработки программного продукта приведен в .

Табл. . Укрупненный состав работ по стадиям разработки программного продукта

Стадия разработки программного продукта

Состав выполняемых работ

1

2

Техническое задание

Постановка задач, выбор критериев эффективности. Разработка технико-экономического обоснования разработки. Определение состава пакета прикладных программ, состава и структуры информационной базы. Выбор языков программирования. Предварительный выбор методов выполнения работы. Разработка календарного плана выполнения работ.

Эскизный проект

Предварительная разработка структуры входных и выходных данных. Разработка общего описания алгоритмов реализации решения задач. Разработка пояснительной записки. Консультации разработчиков постановки задач. Согласование и утверждение эскизного проекта.

Технический проект

Разработка алгоритмов решения задач. Разработка пояснительной записки. Согласование и утверждение технического проекта. Разработка структуры программы. Разработка программной документации и передача ее для включения в технический проект. Уточнение структуры, анализ и определение формы представления входных и выходных данных. Выбор конфигурации технических средств.

Рабочий проект

Комплексная отладка задач и сдача в опытную эксплуатацию. Разработка проектной документации. Программирование и отладка программ. Описание контрольного примера. Разработка программной документации. Разработка, согласование программы и методики испытаний. Предварительное проведение всех видов испытаний.

Внедрение

Подготовка и передача программной документации для сопровождения с оформлением соответствующего Акта. Передача программной продукции в фонд алгоритмов и программ. Проверка алгоритмов и программ решения задач, корректировка документации после опытной эксплуатации программного продукта.

Трудоемкость разработки программной продукции зависит от ряда факторов, основными из которых являются следующие: степень новизны разрабатываемого программного комплекса, сложность алгоритма его функционирования, объем используемой информации, вид ее представления и способ обработки, а также уровень используемого алгоритмического языка программирования. Чем выше уровень языка, тем трудоемкость меньше.

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

По степени сложности алгоритма функционирования проект относится к 1 группе сложности - программная продукция, реализующая оптимизационные и моделирующие алгоритмы.

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

Планируемый срок разработки – 1 год. Исходные данные:

Количество разновидностей входной информации - 4, в том числе:

  •  переменной - 2.
    •  информации, получаемой от решения смежных задач - 1.
    •  справочной, условно-постоянной информации - 1.

Количество разновидностей форм выходной информации - 4. Вся информация выводится на машинные носители. Вид используемой информации:

  •  количество разновидностей форм входной информации - 3.
    •  количество разновидностей форм переменной информации - 2.
    •  объем входной информации - 5 тыс. документо-строк.

Языки программирования – ABAP/4

Использование типовых проектных решений, типовых решений, типовых программ и стандартных программ в размере 60%, находим коэффициент 0,6.

Трудоемкость разработки программной продукции может быть определена как сумма величин трудоемкости выполнения отдельных стадий разработки программного продукта из выражения:

=  +  +  +  + , где

- трудоемкость разработки технического задания на создание программного продукта;

- трудоемкость разработки эскизного проекта программного продукта;

- трудоемкость разработки технического проекта программного продукта;

- трудоемкость разработки рабочего проекта программного продукта;

- трудоемкость внедрения разработанного программного продукта.

Трудоемкость разработки технического проекта зависит от функционального назначения программного продукта, количества разновидностей форм входной и выходной информации и определяется по формуле:

= * * , где

- норма времени, затрачиваемого на разработку технического проекта;

- коэффициент учета вида используемой информации;

- коэффициент учета режима обработки информации.

Трудоемкость разработки рабочего проекта зависит от функционального назначения программного продукта, количества разновидностей форм входной и выходной информации, сложности алгоритма функционирования, сложности контроля информации, степени использования готовых программных модулей, уровня алгоритмического языка программирования и определяется по формуле:

= ***** , где

- коэффициент учета сложности контроля информации;

- коэффициент учета режима обработки информации;

- коэффициент учета уровня используемого алгоритмического языка программирования;

- коэффициент учета степени использования готовых программных модулей;

- коэффициент учета вида используемой информации и сложности алгоритма программного продукта;

- норма времени, затраченного на разработку рабочего проекта на алгоритмическом языке высокого уровня, человеко-дни.

Трудоемкость выполнения стадии “Внедрение” может быть рассчитана по формуле:

=  *  *  *  , где:

- норма времени, затрачиваемого разработчиком на выполнение процедур внедрения программного продукта.

Табл. . Затраты времени по стадиям разработки

Стадия разработки

Затраты времени

Поправочный коэффициент

Затраты времени

проекта

Значение (чел  дней)

Основание

Значение

Основание

с учетом поправочного коэффициента

(чел.дней)

1

2

3

4

5

6

  1.  Разработка технического задания

табл. 4.1

  1.  Затраты времени разработчика постановки задачи

50

управление НТ информацией

0.65

  1.  Затраты времени разработчика программного обеспечения

50

управление НТ информацией

0.35

  1.  Разработка эскизного проекта

табл. 4.2

  1.  Затраты времени разработчика постановки задачи

151

управление НТ информацией

0.7

  1.  Затраты времени разработчика программного обеспечения

151

управление НТ информацией

0.3

  1.  Разработка технического проекта

  1.   Разработка технического проекта

  1.   Затраты времени разработчика постановки задачи

53

табл. 4.18

1

  1.  Затраты времени разработчика программного обеспечения

17

табл. 4.19

1

  1.  Разработка рабочего проекта

  1.   Затраты времени разработчика постановки задачи

18

табл. 4.43

1.2*1.07

табл. 1.2 1.4

  1.  Затраты времени разработчика программного обеспечения

82

табл. 4.44

1.2*1.07

табл. 1.2 1.4

  1.  Внедрение

  1.  Затраты времени разработчика постановки задачи

44

1.07

табл. 1.4

  1.  Затраты времени разработчика программного обеспечения

37

1.07

табл. 1.4

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

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

Расчёт производится по формуле:

, где i — трудоёмкость i-й работы, чел.дни; Q — трудоёмкость дополнительных работ, выполняемых исполнителем, чел.дни; ni—количество исполнителей, выполняющих i-ю работу. Так как дополнительные работы на всех этапах отсутствуют, то получаем.

Tтз=50/2=25

Tэп=151/2=75,5

Tтп=70/2=35

Tрп=128,4/2=64,2

Tвнедр=86,67/2= 43,34

  дня

  1.  Определение стоимости разработки программной продукции 

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

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

Ц=KC+Пр

где C- затраты на разработку ПП (сметная себестоимость)

K - коэффициент учета затрат на изготовление опытного образца ПП как продукции производственно-технического назначения (K=1,1).

Пр - нормативная прибыль, рассчитываемая по формуле:

ПР =  С *rН / 100,

где - норматив рентабельности, 30 %;

Затраты, образующие себестоимость продукции (работ, услуг), группируются в соответствии с их экономическим содержанием по следующим элементам:

  1.  материальные затраты (за вычетом стоимости возвратных отходов);
  2.  затраты на оплату труда;
  3.  отчисления на социальные нужды;
  4.  амортизация основных фондов;
  5.  прочие затраты.

Материальные затраты.

В данной статье учитываются суммарные затраты на материалы, приобретенные для разработки данной программной продукции. Затраты состоят из стоимости материалов (без учета НДС) и транспортно-заготовительных расходов. Цены указаны по состоянию на 1 января 2007 года.

Результаты расчетов приведены в .

Табл. . Результаты расчетов стоимости

Наименование материала

Единица измерения

Кол-во

Цена за единицу, руб.

Сумма, руб.

Примечание

2

Комплектующие для ПЭВМ

150000

3

Лицензии SAP

5376000

Всего

5526000

Итого с учётом транспортно-заготовительных расходов (Ктр=1,04)

5747040

Затраты на оплату труда.

В данную статью включаются заработная плата всех исполнителей, непосредственно занятых разработкой данного программного продукта с учетом их должностных окладов и времени участия. Расчет проводится по формуле:

Сзо = Зi ti/21 где

Зi - месячный оклад i-го исполнителя, руб.

ti - трудоемкость работ, выполняемых i-м исполнителем, чел.дни. - определяются из таблицы 1.

Расчет затраты на оплату труда каждого исполнителя.

Сзо 1 = 27500 * 243.04/21 = 318266 руб.

Сзо 2 = 20250 * 243.04/21 = 234360 руб.

Общая заработная плата равна:

Сзо = 552626 руб.

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

Сзд = Сзод, где

Ад - коэффициент отчислений на дополнительную заработную плату.

Ад = 0.2

Сзд = 552626*0.2 = 110525 руб.

Отчисления в ФСС

В статье учитываются отчисления в бюджет социального страхования по установленному законодательством тарифу от суммы основной и дополнительной заработной платы. Расчет производится следующим образом:

  Ccc=Acc*(Cзо+Cзд) ,      

где Асс – коэффициент отчислений на социальное страхование:

0.28 – отчисления в пенсионный фонд;

0,04 – в фонд социального страхования;

0,036 – в фонд медицинского страхования;

Асс = 0.356

Ссс = 0.356 * (552626 + 110525) = 236081.83

Результат Ссс =236081.83 руб.

Амортизационные отчисления.

В элементе “Амортизация основных фондов” отражается сумма амортизационных отчислений на полное восстановление основных производственных фондов, исчисленная из балансовой стоимости и утвержденных в установленном порядке норм, включая и ускоренную амортизацию их активной части, производимую в соответствии с законодательством.

Са = А/Fд*Т,

где А - годовые амортизационные отчисления;

Т - время работы оборудования;

Fд - действительный годовой фонд рабочего времени на ПЭВМ, час/год.

Цена ПЭВМ (на 1 января 2007 года)

22500

% на амортизационные отчисления

12%

Годовой фонд рабочего времени на ПЭВМ (5-ти дневная неделя, 8-и часовой рабочий день)

2080 час.

А = 0.12*22500 = 2700 руб.

Т - время работы оборудования Т = 11 мес. =231 дней= 1848 часов.

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

Са = 2700/2080*1848 = 2399 руб.

Накладные расходы.

В данную статью входят другие затраты, входящие в состав себестоимости продукции (работ, услуг), но не относящиеся к ранее перечисленным элементам затрат.

Сп = Анзо, где:

Ан - коэффициент накладных расходов из [3] Ан = 1,8

Сп = 1,8*552626= 994727 руб.

Итоговые результаты.

Результаты расчетов затрат на разработку программного продукта приведены в .

Табл. . Результаты расчетов затрат на разработку программного продукта

№п/п

Наименование статьи

Сметная стоимость, руб.

Примечание

1

Материальные затраты

5747040

2

Затраты на оплату труда

663151

3

Отчисления в ФСС

236081.83

4

Амортизация оборудования

2399

5

Накладные расходы

994727

Итого

7643398,83

Вывод: затраты на разработку программы составляют: 7643398,83 рубля.

Цена создания определяется следующим образом:

Ц=KC+Пр

где C- затраты на разработку ПП.

K - коэффициент учета затрат на изготовление опытного образца ПП как продукции производственно-технического назначения (K=1,1).

Пр - нормативная прибыль, рассчитываемая по формуле:

ПР =  С *rН / 100,

где - норматив рентабельности, 30 %;

Пр = 7643398,83 *30 / 100 = 2293019,65

Ц = 1.1*7643398,83 + 2293019,65 = 4978909997,9

Вывод: Цена создания разрабатываемой программы: 4978909997,9 рубля.

Заключение к экономической части

В рамках организационно-экономической части были проведены расчеты по трудозатратам работ создания системы. Были проведены расчеты по следующим статьям затрат: материальные затраты; основная заработная плата исполнителей - дополнительная заработная плата исполнителей; отчисления на социальное страхование; амортизационные отчисления; накладные расходы.

В результате расчетов было получены данные по суммарным затратам на создание ПП, которые составили 7643398,83 рубля.

В результате расчетов была определена цена создания ПП, которая составила 4978909997,9 рубля.


  1.  Промышленная экология и безопасность
    1.  Введение.

Усложнение производственной деятельности в связи с применением ПЭВМ предъявляют новые требования к организму человека. Неправильное или невнимательное отношение к выполнению требований техники безопасности при работе на ПЭВМ неизбежно отражается на показателях деятельности и здоровье работников.

Рабочее место (РМ) оператора ПЭВМ представляет собой совокупность физических, химических, биологических, социально-психологических и эстетических факторов внешней среды, воздействующих на оператора.

Основные требования к факторам рабочей среды заключаются в следующем:

  •  факторы рабочей среды при их комплексном воздействии на человека не должны оказывать отрицательного влияния на его здоровье при профессиональной деятельности его в течение длительного времени;
  •  факторы рабочей среды не должны вызывать снижения надежности и качества деятельности оператора при действии их в течение рабочего дня.

На человека, работающего в зоне действия ПЭВМ, действует большое количество вредных факторов. Такими являются:

  •  повышенный уровень шума, источниками которого являются вентиляционные  устройства ПЭВМ, устройства ввода-вывода, агрегаты кондиционирования и вентилирования воздуха, другие электрические приборы;
  •  высокие уровни электростатического и электромагнитного излучения, источниками которого являются видеотерминалы.

Также необходимо обеспечивать благоприятный микроклимат, чистоту воздуха, освещенность в помещении, где проходят работы с применением ПЭВМ.

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

  1.  Требования безопасности при работе с подсистемой управления поставкми

  1.  Требования к видеодисплейным терминалам и персональным электронно-вычислительным машинам.

Визуальные эргономические параметры ВДТ являются параметрами безопасности, и их неправильный выбор приводит к ухудшению здоровья пользователей. Конструкция ВДТ, его дизайн и совокупность эргономических параметров должны обеспечивать надежное и комфортное считывание отображаемой информации в условиях эксплуатации ВДТ. Конструкция ВДТ должна обеспечивать возможность фронтального наблюдения экрана путем поворота корпуса в горизонтальной плоскости вокруг вертикальной оси в пределах ±30 градусов и в вертикальной плоскости вокруг горизонтальной оси в пределах ±30 градусов с фиксацией в заданном положении. Дизайн ВДТ должен предусматривать окраску корпуса в спокойные мягкие тона с диффузным рассеиванием света. Корпус ВДТ и ПЭВМ, клавиатура и другие блоки и устройства ПЭВМ должны иметь матовую поверхность одного цвета с коэффициентом отражения 0,4 - 0,6 и не иметь блестящих деталей, способных создавать блики. На лицевой стороне корпуса ВДТ не рекомендуется располагать органы управления, маркировку, какие-либо вспомогательные надписи и обозначения. При необходимости расположения органов управления на лицевой панели они должны закрываться крышкой или быть утоплены в корпусе.

Для обеспечения надежного считывания информации при соответствующей степени комфортности ее восприятия должны быть определены оптимальные и допустимые диапазоны визуальных эргономических параметров. Визуальные эргономические параметры ВДТ и пределы их изменений, в которых должны быть установлены оптимальные и допустимые диапазоны значений, приведены в . 

Табл. . Визуальные эргономические параметры ВДТ и пределы их изменений

Визуальные эргономические параметры ВДТ
и пределы их изменений

Наименование параметров

Пределы значений параметров

min (не менее)

Max (не более)

Яркость знака (яркость фона), кд/м2 

(измеренная в темноте)

35

120

Внешняя освещенность экрана, лк

100

250

Угловой размер знака, угл.мин.

16

60

Примечания:

  1.  Оптимальным диапазоном значений визуального эргономического параметра называется диапазон, в пределах которого обеспечивается безошибочное считывание информации при времени реакции человека-оператора, превышающем минимальное, установленное экспериментально для данного типа ВДТ, не более чем в 1,2 раза.
  2.  Допустимым диапазоном значений визуального эргономического параметра называется диапазон, при котором обеспечивается безошибочное считывание информации, а время реакции человека-оператора превышает минимальное, установленное экспериментально для данного типа ВДТ, не более чем в 1,5 раза.
  3.  Угловой размер знака - угол между линиями, соединяющими крайние точки знака по высоте и глаз наблюдателя.

Угловой размер знака определяется по формуле:

, где

h - высота знака;

l - расстояние от знака до глаза наблюдателя.

При работе с ВДТ для профессиональных пользователей необходимо обеспечивать значения визуальных параметров в пределах оптимального диапазона, но разрешается кратковременная работа при допустимых значениях визуальных параметров. Оптимальные и допустимые значения визуальных эргономических параметров должны быть указаны в технической документации на ВДТ для различных режимов работы пользователей. При отсутствии в технической документации на ВДТ данных об оптимальных и допустимых диапазонах значений эргономических параметров эксплуатация ВДТ не допускается.  Конструкция ВДТ должна предусматривать наличие ручек регулировки яркости и контраста, обеспечивающих возможность регулировки этих параметров от минимальных до максимальных значений. В технической документации на ВДТ должны быть установлены требования на визуальные параметры (дополнительно к параметрам, перечисленным в таблице 1.2.), соответствующие действующим на момент разработки или импорта ГОСТ и признанным в Российской Федерации международным стандартам.

Перечень и значения визуальных параметров приведены в .

Табл. . Перечень и значения визуальных параметров

п/п

Наименование параметров

Значения параметров

1.

Контраст (для монохромных ВДТ)

от 3:1 до 1,5:1

2.

Неравномерность яркости элементов знаков, %

не более 25

3.

Неравномерность яркости рабочего поля экрана,%

не более 20

4.

Формат матрицы знака для прописных букв и цифр

(для отображения диакритических знаков и строчных букв с нижними выносными элементами формат матрицы должен быть увеличен сверху или снизу на 2 элемента изображения)

Не менее 7-9 элементов изображения

Не менее 5-7 элементов изображения

5.

Отношение ширины знака к его высоте для прописных букв

от 0,7 до 0,9

(допускается от 0,5 до 1,0)

6.

Размер минимального элемента отображения (пикселя) для монохромного ВДТ, мм

0,3

7.

Угол наклона линии наблюдения, град.

не более 60 град. Ниже горизонтали

8.

Угол наблюдения, град

не более 40 град. от нормали к любой точке экрана дисплея

9.

Допустимое горизонтальное смещение однотипных знаков,% от ширины знака

не более 5

10.

Допустимое вертикальное смещение однотипных знаков, % от высоты матрицы

не более 5

11.

Отклонение формы рабочего поля экрана ВДТ от правильного прямоугольника не должно превышать:

по горизонтали

по вертикали

по диагонали

где B1 и B2 – значения длин верхней и нижней строк текста на рабочем поле экрана, мм;

H1 и H2 – значения длин крайних столбцов на рабочем поле экрана, мм;

D1 и D2 – значения длин диагоналей рабочего поля экрана, мм;

12.

Допустимая пространственная нестабильность изображения (дрожание по амплитуде изображения) при частоте колебаний в диапазоне от 0,5 до 30 Гц, мм

не более 2L10E-4

(L –расстояние наблюдения, мм)

13.

Допустимая временная нестабильность изображения (мерцание)

не должно быть зафиксировано 90% наблюдателей

14.

Отражательная способность, зеркальное и смешанное отражение (блики), % (допускается выполнение требования при использовании приэкранного фильтра)

не более 1

Под неравномерностью яркости понимаются отношения:
U+=  (положительная неравномерность),
U-=  (отрицательная неравномерность),

n - число измеренных значений яркости,
Lmax - максимальное значение яркости,
Lmin - минимальное значение яркости.

Размер элемента изображения (пикселя) определяется фотометрически на уровне 50% максимальной яркости.

Важнейшим визуальным эргономическим параметром, определяющим утомляемость зрительного аппарата, является мерцание изображения. СанПиН не регламентируют оптимальное значение частоты обновления, поскольку восприятие мерцания на экране монитора субъективно. Тем не менее, практика показывает, что в подавляющем большинстве случаев наиболее безопасна для здоровья частота обновления от 85 Гц и выше. Именно с учетом этой особенности проектируются все современные мониторы на ЭЛТ. Т.е. заявленному производителем «рабочему» разрешению монитора всегда соответствует частота обновления 85 Гц и выше (стандарты TCO’95 и TCO’99).

В нашем случае используются 17-ти дюймовые мониторы NEC FE755+ и Samsung SyncMaster 765MB, которые при рабочем разрешении 1024х768 точек на дюйм обеспечивают частоту обновления экрана 85 Гц и 100 Гц соответственно.

  1.  Требования к помещениям для эксплуатации ВДТ и ПЭВМ.

Согласно СанПиН 2.2.2.542-96, помещения с ВДТ и ПЭВМ должны иметь естественное и искусственное освещение, расположение рабочих мест с ВДТ и ПЭВМ для взрослых пользователей в подвальных помещениях не допускается. Площадь на одно рабочее место с ВДТ или ПЭВМ для взрослых пользователей должна составлять не менее 6,0 кв.м, а объем не менее 20,0 куб.м.

Для внутренней отделки интерьера помещений с ВДТ и ПЭВМ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка - 0.7 - 0.8; для стен - 0.5 - 0.6; для пола - 0.3 - 0.5. Полимерные материалы, используемые для внутренней отделки интерьера помещений с ВДТ и ПЭВМ, должны быть разрешены для применения органами и учреждениями Государственного санитарно-эпидемиологического надзора.

Поверхность пола в помещениях эксплуатации ВДТ и ПЭВМ должна быть ровной, без выбоин, нескользкой, удобной для очистки и влажной уборки, обладать антистатическими свойствами.

  1.  Требования к микроклимату, содержанию аэроионов и вредных химических веществ в воздухе помещений эксплуатации ВДТ и ПЭВМ.

Помещения с ВДТ и ПЭВМ должны оборудоваться системами отопления, кондиционирования воздуха или эффективной приточно-вытяжной вентиляцией.

Системы отопления, кондиционирования воздуха или приточно-вытяжная вентиляция необходимы для обеспечения оптимальных норм микроклимата и воздушной среды помещения с ВТД и ПЭВМ. Рекомендуется:

• применять увлажнители воздуха, заправляемые ежедневно дистиллированной или прокипяченной питьевой водой (для повышения влажности воздуха)

• проветривать помещения с ВДТ и ПЭВМ (обеспечивает улучшение качественного состава воздуха, в том числе и аэроионный режим).

• устраивать системы общеобменной приточно-вытяжной механической вентиляции. Последняя должна обеспечивать:

объём подаваемого воздуха в единицу времени не менее 20 м.куб./час;

температура подаваемого воздуха должна быть не ниже 10° Цельсия;

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

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

Вид работы с компьютером зависит от задач решаемых программным комплексом. В нашем случае, в соответствии с СанПиН 2.2.2.542-96, вид работы – основной, так как работа оператора с программным комплексом подразумевает непрерывную работу в режиме диалога и занимает более 50% времени от смены.

При использовании программного продукта «Подсистема управления поставкми» характер труда оператора ПО БК относиться к категории 1а, потому что работы производятся сидя и не требуют физического напряжения, расход энергии составляет до 120 ккал/ч, следовательно, необходимо проектировать помещение с учетом оптимальных норм микроклимата для категории работ 1а .

Табл. . оптимальных норм микроклимата для категории работ 1а

Оптимальные нормы микроклимата для помещений с ВДТ и ПЭВМ

Период года

Категория работ

Температура воздуха, С не более

Относительная влажность воздуха, %

Скорость движения воздуха, м/с

Холодный

легкая -1а

22-24

40-60

0,1

Теплый

легкая -1а

23-25

40-60

0,1

Данный микроклимат может обеспечиваться системой общеобменной приточно-вытяжной механической вентиляции, которая должна обеспечить объём подаваемого воздуха в единицу времени не менее 20 м.куб./час и температуру подаваемого воздуха не ниже 10° Цельсия. В приточной ветви нужно предусмотреть использование фильтров очистки воздуха, для удаления из воздуха вредных веществ перед его подачей на рабочие места. Для повышения влажности воздуха в помещениях с ВДТ и ПЭВМ следует применять увлажнители воздуха, заправляемые ежедневно дистиллированной или прокипяченной питьевой водой.

Уровни положительных и отрицательных аэроионов в воздухе помещений с ВДТ и ПЭВМ должны соответствовать нормам, приведенным в 9. 

Табл. . Уровни положительных и отрицательных аэроионов в воздухе помещений с ВДТ и ПЭВМ

Уровни ионизации воздуха помещений при работе на ВДТ и ПЭВМ

Уровни

Число ионов в 1 см. куб. воздуха

n+

n-

Минимально необходимые

400

600

Оптимальные

1500-3000

3000-5000

Максимально допустимые

50000

50000

Содержание вредных химических веществ в производственных помещениях, работа на ВДТ и ПЭВМ в которых является основной (диспетчерские, операторские, расчетные, кабины и посты управления, залы вычислительной техники и др.), не должно превышать "Предельно допустимые концентрации загрязняющих веществ в атмосферном воздухе населенных мест". ГН 2.1.6.695-98 (ПДК: окись углерода –3,0 мг/м3, окислы азота 0,04 мг/м3).

  1.  Требования к шуму и вибрации.

Производственные помещения, в которых для работы используются преимущественно ВДТ и ПЭВМ (диспетчерские, операторские, расчетные и др.) не должны граничить с помещениями, в которых уровни шума и вибрации превышают нормируемые значения (механические цеха, мастерские и т.п.). При использовании программного продукта работа ведется в помещениях, где исключено соседство с помещениями, где уровни шума превышают нормируемые значения.

Уровень звука в помещениях ВЦ не должен превышать 50 дБА; в помещениях, где размещаются агрегаты, создающие повышенный звуковой фон, - не более 75 дБА.

Вибрация на рабочих местах не должна превышать допустимых норм вибрации . 

Табл. . Допустимые нормы вибрации

Допустимые нормы вибрации на всех рабочих местах с ВДТ и ПЭВМ

Среднегеометрические частоты октавных полос, Гц

Допустимые значения оси X, Y

по виброускорению

по виброскорости

мс-2

ДБ

мс-1

ДБ

Мс-1

2

5,3x10

25

4,5x10

79

4

5,3x10

25

2,2x10

73

8

5,3x10

25

1,1x10

67

16

1,0x10

31

1,1x10

67

31,5

2,1x10

37

1,1x10

67

63

4,2x10

43

1,1x10

67

Корректированные значения и их уровни

9,3x10

30

2,0x10

72

Для снижения  вибрации в помещениях оборудование, аппараты и приборы необходимо устанавливать на амортизирующие прокладки. Также могут быть использованы средства индивидуальной защиты.

Шумящее оборудование (АЦПУ, принтеры и т.п.), уровни шума которого превышают нормированные, должно находиться вне помещения с ВДТ и ПЭВМ.

Снизить уровень шума в помещениях с ВДТ и ПЭВМ можно использованием звукопоглощающих материалов с максимальными коэффициентами звукопоглощения в области частот 63 - 8000 Гц.

Дополнительным звукопоглощением служат однотонные занавеси из плотной ткани, гармонирующие с окраской стен и подвешенные в складку на расстоянии 15 - 20 см от ограждения. Ширина занавеси должна быть в 2 раза больше ширины окна.

  1.  Требования к освещению помещений и рабочих мест с ВДТ и ПЭВМ.

Помещения с ВДТ и ПЭВМ должны иметь естественное и искусственное освещение.

Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1.2% в зонах с устойчивым снежным покровом и не ниже 1.5% на остальной территории (указанные значения КЕО нормируются для зданий, расположенных в III световом климатическом поясе). Расположение рабочих мест по отношению к световым проемам приведены на Рис. 48.

Рис. . Схема расположения рабочих мест относительно светопроемов

Искусственное освещение в помещениях эксплуатации ВДТ и ПЭВМ должно осуществляться системой общего равномерного освещения. В производственных и административно-общественных помещениях, в случаях преимущественной работы с документами, допускается применение системы комбинированного освещения (к общему освещению дополнительно устанавливаются светильники местного освещения, предназначенные для освещения зоны расположения документов).

Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 - 500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк.

Следует ограничивать прямую блесткость от источников освещения, при этом яркость светящихся поверхностей (окна, светильники и др.), находящихся в поле зрения, должна быть не более 200 кд/кв.м.

Следует также ограничивать отраженную блесткость на рабочих поверхностях (экран, стол, клавиатура и др.) за счет правильного выбора типов светильников и расположения рабочих мест по отношению к источникам естественного и искусственного освещения, при этом яркость бликов на экране ВДТ и ПЭВМ не должна превышать 40 кд/кв.м и яркость потолка, при применении системы отраженного освещения, не должна превышать 200 кд/кв.м.

Показатель ослепленности для источников общего искусственного освещения в производственных помещениях должен быть не более 20.

Следует ограничивать неравномерность распределения яркости в поле зрения пользователя ВДТ и ПЭВМ, при этом соотношение яркости между рабочими поверхностями не должно превышать 3:1 - 5:1, а между рабочими поверхностями и поверхностями стен и оборудования - 10:1.

В качестве источников света при искусственном освещении должны применяться преимущественно люминесцентные лампы типа ЛБ. При устройстве отраженного освещения в производственных и административно-общественных помещениях допускается применение металлогалогенных ламп мощностью до 250 Вт. Допускается применение ламп накаливания в светильниках местного освещения.

Общее освещение следует выполнять в виде сплошных или прерывистых линий светильников, расположенных сбоку от рабочих мест, параллельно линии зрения пользователя при рядном расположении ВДТ и ПЭВМ. При периметральном расположении компьютеров линии светильников должны располагаться локализовано над рабочим столом ближе к его переднему краю, обращенному к оператору.

Для освещения помещений с ВДТ и ПЭВМ следует применять светильники серии ЛПО36 с зеркализованными решетками, укомплектованные высокочастотными пускорегулирующими аппаратами (ВЧ ПРА). Допускается применять светильники серии ЛПО36 без ВЧ ПРА только в модификации "Кососвет", а также светильники прямого света - П, преимущественно прямого света - Н, преимущественно отраженного света - В (31). Применение светильников без рассеивателей и экранирующих решеток не допускается.

Светильники общего освещения.

Яркость светильников общего освещения в зоне углов излучения от 50 до 90 градусов с вертикалью в продольной и поперечной плоскостях должна составлять не более 200 кд/кв.м, защитный угол светильников должен быть не менее 40 градусов.

Светильники местного освещения должны иметь не просвечивающий отражатель с защитным углом не менее 40 градусов.

Коэффициент запаса (Кз) для осветительных установок общего освещения должен приниматься равным 1.4.

Коэффициент пульсации не должен превышать 5%, что должно обеспечиваться применением газоразрядных ламп в светильниках общего и местного освещения с высокочастотными пускорегулирующими аппаратами (ВЧ ПРА) для любых типов светильников. При отсутствии светильников с ВЧ ПРА лампы многоламповых светильников или рядом расположенные светильники общего освещения следует включать на разные фазы трехфазной сети.

При отсутствии светильников серии ЛПО 36 с ВЧ ПРА и без ВЧ ПРА в модификации "кососвет" допускается применение светильников общего освещения серий:

Табл. . Светильники общего освещения

ЛПО13

2х40/Б

01

ЛПО13

4х40/Б

01

ЛСП13

2х40

06

ЛСП13

2х65

06

ЛСО05

2х40

001

ЛСО05

2х40

003

ЛСО04

2х36

008

ЛПО34

4х36

002

ЛПО34

4х58

002

ЛПО31

2х40

002

а также их отечественных и зарубежных аналогов.

Для обеспечения нормируемых значений освещенности в помещениях использования ВДТ и ПЭВМ следует проводить чистку стекол оконных рам и светильников не реже двух раз в год и проводить своевременную замену перегоревших ламп.

  1.  Требования к организации и оборудованию рабочих мест с ВДТ и ПЭВМ.

Рабочие места с ВДТ и ПЭВМ по отношению к световым проемам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева (см. схема расположения рабочих мест относительно светопроемов). Схемы размещения рабочих мест с ВДТ и ПЭВМ должны учитывать расстояния между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), которое должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м. Рабочие места с ВДТ и ПЭВМ в залах электронно-вычислительных машин или в помещениях с источниками вредных производственных факторов должны размещаться в изолированных кабинах с организованным воздухообменом. Оконные проемы в помещениях использования ВДТ и ПЭВМ должны быть оборудованы регулируемыми устройствами типа: жалюзи, занавесей, внешних козырьков и др.

Шкафы, сейфы, стеллажи для хранения дисков, дискет, комплектующих деталей, запасных блоков ВДТ и ПЭВМ, инструментов, следует располагать в подсобных помещениях. При отсутствии подсобных помещений допускается размещение шкафов, сейфов и стеллажей в помещениях непосредственного использования ВДТ и ПЭВМ при соблюдении требований к площади помещений и требований, изложенных в настоящем разделе.

Конструкция рабочего стола должна обеспечивать оптимальное размещение на рабочей поверхности используемого оборудования с учетом его количества и конструктивных особенностей (размер ВДТ и ПЭВМ, клавиатуры, пюпитра и др.), характера выполняемой работы. При этом допускается использование рабочих столов различных конструкций, отвечающих современным требованиям эргономики.

Высота рабочей поверхности стола для взрослых пользователей должна регулироваться в пределах 680 - 800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм. Модульными размерами рабочей поверхности стола для ВДТ и ПЭВМ, на основании которых должны рассчитываться конструктивные размеры, следует считать: ширину 800, 1000, 1200 и 1400 мм, глубину 800 и 1000 мм при нерегулируемой его высоте, равной 725 мм. Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, шириной - не менее 500 мм, глубиной на уровне колен - не менее 450 мм и на уровне вытянутых ног - не менее 650 мм.

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

Конструкция его должна обеспечивать:

  •  ширину и глубину поверхности сиденья не менее 400 мм;
  •  поверхность сиденья с закругленным передним краем;
  •  регулировку высоты поверхности сиденья в пределах 400 - 550 мм и углам наклона вперед до 15 град. и назад до 5 град.;
  •  высоту опорной поверхности спинки 300 ± 20 мм, ширину - не менее 380 мм и радиус кривизны горизонтальной плоскости - 400 мм;
  •  угол наклона спинки в вертикальной плоскости в пределах ±30 градусов;
  •  регулировку расстояния спинки от переднего края сиденья в пределах 260 - 400 мм;
  •  стационарные или съемные подлокотники длиной не менее 250 мм и шириной - 50 - 70 мм;
  •  регулировку подлокотников по высоте над сиденьем в пределах 230 ± 30 мм и внутреннего расстояния между подлокотниками в пределах 350 - 500 мм.

Рабочее место должно быть оборудовано подставкой для ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах до 150 мм и по углу наклона опорной поверхности подставки до 20 градусов. Поверхность подставки должна быть рифленой и иметь по переднему краю бортик высотой 10 мм.

Рабочее место с ВДТ и ПЭВМ должно быть оснащено легко перемещаемым пюпитром для документов.

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

Конструкция клавиатуры должна предусматривать:

  •  исполнение в виде отдельного устройства с возможностью свободного перемещения;
  •  опорное приспособление, позволяющее изменять угол наклона поверхности клавиатуры в пределах от 5 до 15 градусов;
  •  высоту среднего ряда клавиш не более 30 мм;
  •  расположение часто используемых клавиш в центре, внизу и справа, редко используемых - вверху и слева;
  •  выделение цветом, размером, формой и местом расположения функциональных групп клавиш;
  •  минимальный размер клавиш - 13 мм, оптимальный - 15 мм;
  •  клавиши с углублением в центре и шагом 19 ±1 мм;
  •  расстояние между клавишами не менее 3 мм;
  •  одинаковый ход для всех клавиш с минимальным сопротивлением нажатию 0,25 Н и максимальным - не более 1,5 Н;
  •  звуковую обратную связь от включения клавиш с регулировкой уровня звукового сигнала и возможности ее отключения.

Экран видеомонитора должен находиться от глаз пользователя на оптимальном расстоянии 600 - 700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов.

В помещениях с ВДТ и ПЭВМ ежедневно должна проводиться влажная уборка.

  1.  Требования к организации режимов труда и отдыха при работе с ВДТ и ПЭВМ.

Режимы труда и отдыха при работе с ПЭВМ и ВДТ должны организовываться в зависимости от вида и категории трудовой деятельности.

Виды трудовой деятельности разделяются на 3 группы: группа А - работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом; группа Б - работа по вводу информации; группа В - творческая работа в режиме диалога с ЭВМ. При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ПЭВМ и ВДТ следует принимать такую, которая занимает не менее 50% времени в течение рабочей смены или рабочего дня.

Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ВДТ и ПЭВМ (), которые определяются: для группы А - по суммарному числу считываемых знаков за рабочую смену, но не более 60 000 знаков за смену; для группы Б - по суммарному числу считываемых или вводимых знаков за рабочую смену, но не более 40 000 знаков за смену; для группы В - по суммарному времени непосредственной работы с ВДТ и ПЭВМ за рабочую смену, но не более 6 часов за смену.

Табл. . Категории тяжести и напряженности работы с ВДТ и ПЭВМ

Время регламентированных перерывов в зависимости
от продолжительности рабочей смены

Категория работы с ВДТ или ПЭВМ

Уровень нагрузки за рабочую смену при видах paбoт с ВДТ

Суммарное время регламенти-
рованных перерывов мин.

группа А, количество знаков

группа Б, количество знаков

группа В, часов

при 8-ми часовой рабочей смене

при 12-ти часовой рабочей смене

I

до 26000

до 15000

до 2,0

30

70

II

до 40000

до 30000

до 4,0

50

90

III

до 60000

до 40000

до 6,0

70

120

Время перерывов дано при соблюдении требований настоящих Санитарных правил и норм. При несоответствии фактических условий труда требованиям настоящих Санитарных правил и норм, время регламентированных перерывов следует увеличить на 30%.

В нашем случае работа оператора относится к группе В, поскольку проходит в режиме диалога с ЭВМ; к III категории, т.к. оператор работает с ЭВМ 6 часов в смену, в условиях 8-ми часовой рабочей смены. Суммарное время регламентированных перерывов принимаем равным 70 минутам.

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

Для обеспечения оптимальной работоспособности и сохранения здоровья профессиональных пользователей, на протяжении рабочей смены должны устанавливаться регламентированные перерывы. Суммарное время регламентированных перерывов в течение рабочей смены следует установить 70 мин., согласно таблице 2.7.1. При работе с ВДТ и ПЭВМ в ночную смену (с 22 до 6 часов), независимо от категории и вида трудовой деятельности, продолжительность регламентированных перерывов должна увеличиваться на 60 минут.

При 8-ми часовой рабочей смене и работе на ВДТ и ПЭВМ III категории регламентированные перерывы следует установить через 1.5 - 2.0 часа от начала рабочей смены и через 1.5 - 2 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

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

Работающим на ВДТ и ПЭВМ с высоким уровнем напряженности во время регламентированных перерывов и в конце рабочего дня показана психологическая разгрузка в специально оборудованных помещениях (комната психологической разгрузки).

  1.  Требования к организации медицинского обслуживания пользователей ВДТ и ПЭВМ.

Профессиональные пользователи ВДТ и ПЭВМ должны проходить обязательные предварительные (при поступлении на работу) и периодические медицинские осмотры в порядке и в сроки, установленные Минздравмедпромом России и Госкомсанэпиднадзором России. К непосредственной работе с ВДТ и ПЭВМ допускаются лица, не имеющие медицинских противопоказаний.

Женщины со времени установления беременности и в период кормления ребенка грудью к выполнению всех видов работ, связанных с использованием ВДТ и ПЭВМ, не допускаются. Трудоустройство беременных женщин следует осуществлять в соответствии с "Гигиеническими рекомендациями по рациональному трудоустройству беременных женщин".

  1.  Требования электробезопасности.

В соответствии с правилами устройства электрических установок в помещениях без повышенной электрической опасности заземлению подлежат токоприемники с напряжением U380В при переменном токе, а в помещениях с повышенной электрической опасностью – токоприемники с напряжением U42В при переменном токе. К помещениям с повышенной электрической опасностью относятся помещения с токопроводящими полами или при наличии токопроводящей пыли, с повышенной влажностью (75%) или жаркие помещения (35С), а также помещения, где существует опасность касания токоприемников или их элементов. Если оператор будет находиться в помещении с повышенной электрической опасностью, то ПЭВМ и ВДТ необходимо заземлять (220В42В), если же помещение будет относиться к категории помещений без повышенной электрической опасности, то ВДТ и ПЭВМ заземлять не надо (220В380В). Необходимо, также использовать заземленные защитные экраны и фильтры.

  1.  Требования пожарной безопасности.

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

  1.  Расчет общего искусственного освещения на рабочем месте оператора

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

Размеры помещения примем 4х6 м. при высоте 2.9 м., а высоту светильников общего освещения над рабочим местом 2.7 м.

Потребный световой поток лампы Фл (лм) для каждой люминесцентной лампы находится по формуле:

,

где Ен - минимальная нормированная освещенность, лк;

kз - коэффициент запаса, находится по таблицам; учитывает старение ламп, запыление и загрязнение светильников.

S - площадь освещаемой поверхности;

z - коэффициент минимальной освещенности, равный отношению средней освещенности к минимальной, значение которого для ламп накаливания - 1.15, для люминесцентных - 1.1. В нашем случае – люминесцентные лампы. z = 1.1.

N - число светильников в помещении;

 n - коэффициент использования светового потока ламп (%), зависящий от типа светильника, коэффициента отражения потолка Roп и стен Roc и индекса i формы помещения.

Индекс помещения:

,

где A и B - ширина и длина помещения; h - высота подвеса светильников над рабочей поверхностью. Для нашего случая:

Для помещения Roп = 70% (побеленный потолок), Roc = 50% (чистые светлые стены) находим коэффициент использования светового потока для светильников ЛПО (с люминесцентными лампами типа ЛБ) Et = 43% [4]. Коэффициент запаса для люминесцентных ламп k = 1.5 по таблицам для пультов операторов (характеристика помещения: помещение с малыми выделениями пыли, дыма или копоти (механические цеха, бытовые помещения и т.п.)).

Нормированная световая освещенность Ен=300 лк (допустимые значения Ен – от 300 до 500 лк) для данного вида работ. Выбираем N = 8.

Находим потребный световой поток для люминесцентных ламп:

Параметры люминесцентных ламп общего назначения для ламп типа ЛБ приведены в .

Табл. . Параметры люминесцентных ламп общего назначения для ламп типа ЛБ

Мощность, Вт

Сила тока, А

Напряжение, В

Световой поток, лм

30

0,35

104± 10,4

2180

40

0,43

103± 10,3

3200

65

0,67

110± 10,0

4800

80

0,87

102± 10,2

5400

Примем люминесцентные лампы белого света ЛБ65 мощностью 65 Вт.

  1.  
    Заключение

В рамках дипломного проекта выполнено следующее:

  •  Проведено обследование организации «КАРМЕТ», построена функциональная модель управления поставками. Разработано техническое задание на систему управления поставками SAP/R3.
  •  Сформулирована постановка задачи создания ситемы классификации. Проанализирована работа подсистемы.
  •  Подсистема классификации разработана в среде ABAP. Разработана информационная модель подсистемы и схема физической базы данных.
  •  Проведен анализ и настройка значений параметров алгоритма работы систем, проанализирована эффективность его работы.
  •  Проведено сравнение систем управления до внедрения системы управления поставками, после внедрения SAP с дополнительной подсистемой классификации. Сделан вывод, что применение подсистемы управления поставками позволяет уменьшить длительность основных работ за счет автоматизации и интеграции системы управления поставками со смежными модулями системы.

Таким образом, разработана подсистема управления поставками, которая позволяет увеличить объем продаж за счет повышения уровня обслуживания клиентов.

В заключении можно отметить, что разработанная подсистема показала хорошие результаты при работе в организации «КАРМЕТ», что позволяет сделать вывод о применимости данной подсистемы при управлении поставками в организациях аналогичного профиля.

  1.  
    Список литературы

  1.  Точно вовремя для России./С.В. Питеркин, И.А. Оладов, Д.В. Исаев. Справочное пособие./ Под редакцией И.Н.Букреева – Альпина, 2006 – 368 с.: илл., ISBN 5-9614-0303-3.
  2.  Проектирование информационных систем./В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. Учебное пособие./ Интернет-Ун-т Информ. Технологий, 2005 – 304 с.: илл., ISBN 5-9556-0033-7.
  3.  ERP системы Современное планирование и управление ресурсами предприятия/Даниэль О’Лири[Пер. с англ. Ю.И.Водяновой]-Вершина,2004.-272 с, ISBN 5-94696-067-9.
  4.  Менеджмент процессов/Под редакцией Й.Беккера, Л.Вилкова, В.Таратухина,М. Кугелера, М.Роземенна;[Пер. с нем.компания САП в России, Л.А.Вилков]-Эксмо,2007.-384 с, ISBN 5-699-19492-4.
  5.  Разработка приложений SAP/R3/ Рюдегер Кречмер, Вольфганг Вейс /Под редакцией В.Алеев;[Пер. с нем.компания М.Алиева]-Лори,1998.-349 с, ISBN 5-85582-034-9.
  6.  ГОСТ 34.602–89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
  7.  ГОСТ 34.601–90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания автоматизированной системы».
  8.  РД 50–682–89 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения».
  9.  РД 50–680–88 «Методические указания. Автоматизированные системы. Общие положения».
  10.  РД 50–34.698–90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
  11.  Козьяков А.Ф., Смирнов С. Г., Использование основной нормативно-технической документации по охране труда в дипломном проектировании. М: МВТУ,1987.
  12.  СанПиН 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам (ВДТ) и персональным электронно-вычислительным машинам (ПЭВМ) и организации работы. – М. : Информационно-издательский центр Госкомэпиднадзора России, 1996.
  13.  СНиП 23-05-95. Естественное и искусственное освещение - М. Информационно-издательский центр Госкомэпиднадзора России, 1995.
  14.  Методические указания к выполнению лабораторной работы «Исследование производственного освещения» ПИО МВТУ им. Баумана, М., 1991.
  15.  Арсеньев В.В., Сажин Ю.Б. Методические указания к выполнению организационно-экономической части дипломных проектов по созданию программной продукции. М.: изд. МГТУ им. Баумана, 1994. 52 с.
  16.  Под ред. Смирнова С.В. Организационно-экономическая часть дипломных проектов исследовательского профиля. М.: изд. МГТУ им. Баумана, 1995. 100 с.


 

А также другие работы, которые могут Вас заинтересовать

79111. Предмет социологии, ее основные категории и законы 94.5 KB
  Поэтому буквально социология означает учение об обществе. Что является предметом социологии Или какую сторону в обществе выделяет для изучения именно социология На этот вопрос можно ответить так: предметом социологии является социальная жизнь как особая реальность. Социология таким образом изучает отношения между всеми этими общностями – пролетариями и предпринимателями между различными нациями и религиозными...
79112. Общество как система 395.5 KB
  В связи социальные связи и отношения С – единое целое общество в целом Расшифруем что значит социальные явления. Это во-первых социальные группы и общности во-вторых личности и их социальные роли в-третьих социальные нормы и ценности. Социальные связи и отношения мы в дальнейшем рассмотрим специально. В зависимости от того какими будут эти связи и отношения и от того какие социальные группы и общности этими связями и отношениями объединяются мы получаем тот или иной исторический тип...
79113. Социальная структура общества, социальные группы и слои 999 KB
  Социальная группа есть совокупность индивидов, взаимодействующих определенным образом на основе разделяемых ожиданий каждого члена группы в отношении других.
79114. Методика социологического исследования 92.5 KB
  Методика социологического исследования. Программа социологического исследования. Методы социологического исследования наблюдение опрос анализ документов эксперимент. Программа социологического исследования.
79115. Понятие социального института, его характерные признаки 91 KB
  Понятие социальной организации. Формальные и неформальные организации. Это учреждения и организации связанные с осуществлением и распределением политической власти: государство партии армия правоохранительные учреждения профсоюзы политические движения в том числе различные женские молодежные расовые и национальные движения – за равноправие женщин за права молодежи национально-освободительные организации. Понятие социальной организации.
79116. Баптистское движение 15.32 KB
  Основные положения вероучения были разработаны бывшим католическим священником Ульрихом Цвингли. В сотериологии Цвингли придерживался учения о спасении через веру в заместительную жертву Христа. Разногласие Цвингли и Лютера Цвингли первым из всех протестантов выступил против благодатных таинств. Цвингли первый богословски обосновал что Евхаристия это знак символ что субстанционально Христос в Евхаристии не присутствует.
79117. Вероучение анабаптистов 14.49 KB
  Они считали что получали личные откровения от Самого Бога и в свете их необходимо толковать Писание. Или только Писание или же что Писание следует толковать в свете внутренних озарений. Во всяком случае каждый человек мог толковать Писание. Писание ставилось в зависимость от внутреннего состояния человека.