Разработка интегрированной корпоративной информационной системы

Введение
1. Основная часть. Разработка интегрированной корпоративной информационной системы
1.1 Комплексный подход построения ИКИС
1.1.1 Необходимость комплексного подход построения ИКИС
1.1.2 Необходимые системообразующие факторы функционирования ИКИС
1.1.3 Основные процессы формирования ИКИС
1.1.4 Требуемая концепция формирования ИКИС
1.1.4.1 Уровень автоматизации 1
1.1.4.2 Уровень автоматизации 2-3
1.2 Постановка задачи
1.2.1 Планирование производства
1.2.2 Формирование основного плана
1.2.3 Формирование заказов на узлы и компоненты
1.2.4 MRP с пересчетом и с учетом чистых изменений
1.2.5 Плановая длительность цикла
1.2.6 Этап выполнения
1.2.7 Диспетчирование производства
1.2.8 Закупки
1.2.8.1 Параметры управления закупками
1.2.9 Планирование выпуска продукции
1.2.10 Формирование бизнес-плана
1.2.11 Годовой бюджет
1.2.12 Планирование сбыта и выпуска продукции
1.2.13 Основной план производства
1.2.14 Финансовые средства
1.2.15 Проверка выполнимости
1.2.16 Выполнимость длительности цикла
1.2.17 Системы формирования основного плана производства
1.2.18 Организация процесса планирования
1.2.19 Предпосылки к достижению успеха внедрения MRP II на ОАО «КЭМЗ»
1.2.20 Осознание важности задачи
1.2.21 Разработка графика внедрения
1.2.22 Точность данных
1.3 ЛИПРО, MRP II – внедрение на ОАО «КЭМЗ» - «пилотный» проект Цех 7
1.3.1 Цели создания Системы
1.3.2 Место создаваемой Системы в общей системе управления предприятием
1.3.3 Общая характеристика производства
1.3.4 Организация производства
1.3.5 Бизнес-процессы управления производством
1.3.6 Управление внешними заказами
1.3.7 Управление материальными ресурсами
1.3.8 Контроль затрат
1.3.9 Информационная поддержка
1.3.10 Требования к системе
1.3.11 Требования к Системе в целом
1.3.11.1 Общие требования к функционированию Системы
1.3.11.2 Требования к структуре Системы
1.3.11.3 Требования к безопасности и надежности Системы
1.3.11.4 Требования к функциональности Системы
1.3.12 Управление внешними заказами
1.3.13 Планирование заданий
1.3.14 Управление материальными ресурсами
1.3.15 Управление заказом материалов
1.3.16 Контроль выполнения заданий
1.3.17 Контроль затрат
1.3.18 Информационная модель управления производством
1.3.19 Производство
1.3.20 Технологический процесс
1.3.21 Переменные данные
1.4. Техническая сторона внедрения LS PROD NT
1.4.1. Миграция данных
1.4.2 Подготовка данных.
1.4.3 Технология миграции данных.
1.4.4. Механизм приема конструкторского состава из САПР КД
1.4.5. Методика работы с LS Prod NT в цехе №7.
2. Экономическая часть
2.1 Определение TCO
2.1.1 История возникновения
2.1.2 Направление развития
2.2 Упрощенная методика расчета ТСО
2.2.1 Составляющие затрат
2.2.2 Статистическая информация
2.2.3 Прямые затраты на оборудование и ПО
2.2.4 Развитие
2.2.5 Связь
2.2.6 Непрямые затраты
2.3. Расчет затрат по пилотному проекту ИКИС LS PROD dept 7 KEMP
2.3.1 Затраты на выполнение работ по проекту
2.3.2 Расчет окупаемости проекта
3. Охрана труда. Определение оптимальных условий труда инженера–программиста
3.1 Опасные и вредные производственные факторы в вычислительных центрах.
3.2 Определение оптимальных условий труда инженера-программиста.
3.3 Расчет освещенности
3.4 Расчет вентиляции.
Заключение
Список литературы
Приложение 1 Тема, цель и задачи дипломного проектирования
Приложение 2 Основные бизнес-процессы управления производством и общие информационные потоки
Приложение 3 Схема используемых на предприятии средств автоматизации
Приложение 4 Схема единой информационной системы управления предприятием
Приложение 5 Экономический эффект от внедрения подсистемы
Приложение 6 Сертификат на LS PROD от SAP

Продолжительность этапа – 3 дня, временные затраты электрика – 10%, системного администратора – 30%, разработчика – 70%, диспетчера – 10%.
Установка ПС включает в себя программную организацию рабочего места и состоит из следующих этапов:
установка системного программного обеспечения – ОС Windows XP SP2, пакета Microsoft Office 2003 с MS Access, выполняется системным администратором, продолжительность 2 часа;
установка ПС на рабочее место, выполняется разработчиком, продолжительность 2 часа;
настройка разграничения прав доступа пользователей, выполняется разработчиком и диспетчером, продолжительность 2 часа;
проверка работоспособности ПС и базы данных, выполняется разработчиком, продолжительность 2 часа.
Продолжительность этапа – 1 день, временные затраты системного администратора – 20%, разработчика – 80%, диспетчера – 20%.
Приемка ПС включает в себя оценку результатов квалификационного тестирования ПС и включает в себя следующие этапы:
проведение квалификационного испытания, выполняется системным администратором, диспетчером, разработчиком, продолжительность 2 часа;
составление протокола испытаний, оценка результатов испытания, выполняется системным администратором, диспетчером, разработчиком, продолжительность 1 час;
составление заключения по испытаниям с вынесением рекомендаций по устранению выявленных замечаний, выполняется системным администратором, диспетчером, разработчиком, продолжительность 1 час;
устранение замечаний, выполняется разработчиком, продолжительность 1 день;
проверка устраненных замечаний, выполняется системным администратором, диспетчером, разработчиком, продолжительность 1 час;
начальное обучение работе в системе, выполняется разработчиком и диспетчером, продолжительность 2 часа;
передача программной документации на систему заказчику, выполняется разработчиком и системным администратором, продолжительность 0,5 часа;
составление и подписание акта приемки системы, выполняется разработчиком и системным администратором, продолжительность 0,5 часа;
Продолжительность этапа – 2 дня, временные затраты системного администратора – 20%, разработчика – 100%, диспетчера –30%.
1.5.5. Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ
Процесс эксплуатации охватывает действия и задачи оператора системы и начинается после процесса ее внедрения. Процесс эксплуатации представлен на Рис. 1.24. [11, с.69].
Рис. 1.24. Процесс эксплуатации ПС
Подготовительная работа включает проведение следующих этапов работ:
планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов, выполнятся разработчиком, продолжительность 3 дня;
разрешение проблем, возникающих в процессе эксплуатации, выполняется разработчиком, продолжительность – процесс эксплуатации.
Эксплуатационное тестирование включает в себя проверку работоспособности ПС, после внесения в него доработок по требованиям пользователей. После тестирования новая версия ПС передается в эксплуатацию. Выполняется разработчиком, совместно с диспетчером, продолжительность – процесс эксплуатации.
Эксплуатация системы происходит в предназначенной для этого среде в соответствии с пользовательской документацией. Выполняется диспетчером до момента вывода ПС из эксплуатации.
Поддержка пользователей заключается в оказании помощи и консультаций при обнаружении ошибок в процессе эксплуатации ПС. Выполняется разработчиком на протяжении эксплуатации системы.
1.5.6. Ожидаемые риски на этапах жизненного цикла и их описание
В связи с тем, что в качестве платформы для разработки было выбрано достаточно стандартное средство проектирования – Microsoft Access 2003, количество возможных рисков по сравнению с риском использования языков высокого уровня типа Delphi или Visual Studio сократилось.
В рамках данного проекта автоматизации можно рассмотреть наиболее распространенные риски для стандартных программных средств.
Риски на стадии работы над проектом:
Ошибки планирования стоимости, окупаемости и сроков.
Данный риск не является критически важным при реализации проекта, в связи с очевидностью решаемых задач и отсутствия значительных капитальных вложений.
Отсутствие долгосрочной стратегии ИТ и нереальные планы внедрения.
В связи с небольшим сроком внедрения ПС вероятность возникновения данных рисков сведена к минимуму.
Факторы риска на стадии реализации и эксплуатации:
Увеличение нагрузки на персонал и сопротивление персонала нововведениям.
Вероятность возникновения данного риска достаточно велика, в связи с тем, что переход от бумажной технологии к безбумажной или к оптимизированной бумажной всегда на первых этапах связан с увеличением нагрузки на персонал. Поэтому необходимо предусмотреть обучение персонала, снабдить его исчерпывающими эксплуатационными документами, предусмотреть меры материального стимулирования.
Отсутствие на предприятии четкой иерархии.
Вероятность возникновения данного риска достаточно мала, в связи с тем, что системой будут пользоваться всего 2 сотрудника.
Затруднения с интеграцией в существующую систему
Интеграция с существующей системой на первом этапе не планируется.
Конфликты заказчика и консультанта.
Вероятность возникновения данного риска достаточно мала, так как разработчик является сотрудником предприятия, круг решаемых задач достаточно хорошо определен, а в качестве заказчиков выступают 2 человека со сходной спецификой выполняемой работы.
Отсутствие поддержки у ключевых фигур на предприятии.
Данная разработка ведется для строго определенных нужд производственного отдела под кураторством начальника производственного отдела, поэтому нуждается только в его поддержке, следовательно, вероятность возникновения такого риска достаточно мала.
Факторы риска на этапе эксплуатации и развития:
Моральное устаревание продукта
ПС разработан на платформе MS Office 2003, которая полностью совместима с MS Office 2007, и, следовательно, ближайшие 3-4 года будет функционировать на достаточно современном базовом программном обеспечении. В дальнейшем планируется перевести функциональность ПС в систему управления производством более высокого уровня.
Смена собственников.
Должностные обязанности диспетчеров производства достаточно типизированы и в малой степени зависят от конкретного собственника продукта, следовательно, актуальность ПС будет сохраняться до сохранения задач производственного отдела.
Трудности после ухода консультантов.
Функциональность продукта достаточно специфицирована под конкретные задачи и при наличии эксплуатационной документации осваивается персоналом с навыками оператора ЭВМ за 2-3 дня.
Зависимость от разработчиков ИС
ПС разработан на открытой платформе MS Access, поддержку продукта может осуществлять любой сотрудник предприятия с навыками разработчика в MS Access и VBA. [24].
Целесообразно выделить основные мероприятия, направленные на предотвращение возникновение рисков при внедрении ПС. Это планирование и документирование изменений, повышение мотивации сотрудников, и их обучение.
1.5.7. Оценка стоимостных параметров проекта автоматизации
Общая стоимость проекта складывается из фиксированной стоимости ресурсов и задач и стоимости назначений, которая, в свою очередь, определяется ставками ресурса, трудозатратами и стоимостью использования ресурса. Стоимость назначения определяется стоимостью ресурса, умноженной на длительность назначения. При создании назначения Ms Project определяет его стоимость и стоимость задачи, складывая стоимость всех ее назначений и добавляя к ним фиксированную стоимость задачи, если она указана. Суммарная стоимость задач определяет стоимость проекта в целом. [16].
При создании АРМ диспетчера производственного отдела в качестве трудовых ресурсов выступало 3 человека: программист в качестве разработчика системы, диспетчер в качестве заказчика и консультанта по предметной области и системный администратор на этапе внедрения системы. Затраты на работу данных специалистов рассчитываются исходя из того, что заработная плата программиста и системного администратора равна 20 000 руб., диспетчера – 15 000 руб. При этом необходимо учесть все дополнительные расходы, связанные с оплатой труда: это начисление единого социального налога (ЕСН) – 26% и накладные расходы – в среднем 50% от заработной платы. Т.е. затраты на оплату труда необходимо умножить на коэффициент 1,76. Рассчитаем стоимость 1 часа работы сотрудников.
Программист и Системный администратор: 20 000*1,76/ 21 день/ 8 часов = 210 руб./час
Диспетчер: 15 000 * 1,76/21 день/8 час = 157 руб./час
На рис.1.25 показана сводная таблица ресурсов, занятых в автоматизации проекта.
Рис.1.25. Таблица ресурсов, занятых в проекте автоматизации
Учитывая эти затраты и занятость ресурсов в проекте, Microsoft Project позволит составить стоимостной план проекта, который представлен в Приложение В.
Показательным для анализа также будет диаграмма Ганта с суммарными показателями стоимости, представленная в Приложение Г.
Подводя итоги, можно отметить, что суммарная стоимость разработки и внедрения АРМ диспетчера производственного отдела складывается из стоимости трех ресурсов (программиста, диспетчера и системного администратора) и составляет 106 456,61 руб.
Более детальный анализ капитальных и эксплуатационных затрат будет произведен на этапе оценки экономической эффективности проекта автоматизации в третьей главе дипломного проекта.
1.6. Информационное обеспечение задачи
1.6.1. Информационная модель и её описание
Информационная модель системы представляет собой структурное представление движения информационных потоков с момента поступления входной информации до момента выдачи выходных форм.
Информационная модель включает в себя совокупность первичных и выходных документов, файлов входной оперативной, постоянной и результатной информации.
Построение информационной модели необходимо для точного и полного отображения реальной ситуации при формировании структуры базы данных. Модель должна отвечать следующим требованиям:
Обеспечивать адекватное отображение предметной области и давать возможность получить интегрированное представление о предметной области;
Содержать информацию о предметной области, достаточную для дальнейшего проектирования.
Информационная модель нового варианта организации информационной системы диспетчирования представлена на рис.1.26.
Рис. 1.26. Информационная модель
На основе входной информации в информационной модели происходит несколько типов расчетов:
расчет подетального плана и АВС подетального плана;
формирование сменных заданий;
закрытие сменных заданий;
расчет размера НЗП;
расчет показателей выполнения плана производства.
На основе полученных в ходе расчетов данных формируются выходные документы:
подетальный план и АВС подетальный план;
сменное задание;
диспетчерский лист;
отчет о НЗП по участкам и по производству в целом;
отчет о выполнении плана производства по участкам и по производству в целом.
Основным входным документом информационной модели является месячный план производства. Месячный план производства в разрезе сборок (узлов) подготавливается плановым отделом на основании квартального плана производства. Содержание квартального плана с помесячной разбивкой представлено в Приложение А (Рис.А.1). На основе месячного плана, справочника деталей и спецификаций система автоматически создает подетальный план, где рассчитывается необходимое количество деталей для производства сборок, входящих в месячный план (Приложение А, Рис.А.2).
В системе имеется возможность автоматического формирования АВС подетального плана, в котором в зависимости от общей трудоемкости выполнения деталей за месяц производится присвоения класса номенклатурной позиции детали: А, В или С. Этот класс определяет приоритет изготовления деталей при составлении сменных заданий. Если приоритетность детали определяется не трудоемкостью ее изготовления, то пользователь имеет возможность самостоятельно присвоить класс детали. Пример АВС подетального плана представлен в Приложение А (Рис.А.3).
На основании составленного АВС подетального плана на месяц пользователь ежедневно составляет сменные задания для каждой бригады каждого производственного участка на следующий рабочий день. При этом также используется информация из справочников участков, бригад, деталей, мест их обработки, а также из справочника сотрудников компании. Дата сменного задания по умолчанию указывает на следующий рабочий день, однако пользователь при необходимости может ее изменить. В сменном задании указывается конструкторский номер детали, количество и ответственный за выполнение. Конструкторский номер выбирается из раскрывающегося списка, в котором содержаться все номера деталей, которые необходимо сделать в отчетном месяце. В список попадают только те детали, которые имеют возможность обрабатываться данной бригадой. По конструкторскому номеру автоматически в форму попадает информация о названии детали, о трудоемкости и о количестве, которое осталось произвести в отчетном месяце. Ответственный исполнитель также выбирается из списка, в котором содержаться сотрудники, относящиеся к данной бригаде. Готовое сменное задание (Приложение А, Рис.А.4) можно распечатать и передать исполнителям.
По результатам рабочего дня диспетчер закрывает выданные сменные задания и производит учет выполненных деталей и производственного брака. Выбирается дата выдачи сменного задания (по умолчанию это текущая дата) и бригада, на которую выдавалось задание. В списке деталей на выполнение появляется возможность проставить количество сделанных деталей и количество брака. При этом в таблице подетального плана увеличивается количество сделанных деталей.
Ежедневно для анализа текущей ситуации пользователем составляется диспетчерский лист на каждый производственный участок. В нем отражается общая картина выполнения производственного плана на текущий день. При этом указываются все детали, включенные в подетальный план и обрабатываемые на данном производственном участке, трудоемкость, приоритет изготовления, их плановое количество, произведенное количество на текущую дату, остаток и процент выполнения плана. Диспетчерский лист отражает всю оперативную информацию о ходе производства и помогает принимать решения о дальнейшей организации производства. Отчетная форма диспетчерского листа представлена в Приложение Д, рис. Д.5.
Другой формой отчетности выступают отчеты о незавершенном производстве (НЗП) и отчеты о выполнении плана. Имеется возможность составления данных отчетов в разрезе производственных участков и по производству в целом. Отчет о выполнении плана производства (Приложение Д, рис. Д.6) за определенный месяц позволит получить сводную информацию обо всех деталях, необходимых произвести в отчетный период, о сданных деталях и о браке. Относительные показатели процента выполнения плана и процента брака помогут пользователям в анализе ситуации. Отчет о НЗП (Приложение Д, рис. Д.7) позволяет вывести информацию о невыполненном количестве деталей в отчетный месяц и рассчитать средний процент НЗП для конкретного участка или производства в целом. Эти отчеты могут создаваться как за прошедшие периоды времени, так и за текущий отчетный период. В последнем случае будет отражаться информация с начала отчетного периода и по текущую дату составления отчета. Это позволит пользователям принять решение о текущем состоянии производства, оценить процент выполнения (или невыполнения) плана и принять решения по возможной корректировке последующей организации производства с целью достижения 100%-го выполнения плана к концу отчетного периода.
Автоматизированный способ создания рассмотренных выходных документов существенно экономит время и позволяет производить качественный анализ за ходом производственного процесса.
1.6.2. Используемые классификаторы и системы кодирования
При реализации АРМ диспетчера использовались следующие системы классификации и кодирования:
Классификация сборочных узлов.
Классификация деталей.
Кодирование табельных номеров.
Кодирование номеров производственных бригад.
Кодирование месяцев года.
Состав кодовых обозначений данных объектов представлен в таблице 1.1.

Таблица 1.1
Описание классификаторов
Наименование кодируемого множества объектов Значимость кода Система кодирования Система классификации Вид классификатора Код сборочной единицы 11 Комбинированная Многоаспектная Локальный Код детали 11 Комбинированная Многоаспектная Локальный Табельный номер 4 Порядковая Отсутствует Локальный Номер участка 2 Порядковая Отсутствует Локальный Код бригады 4 Комбинированная Отсутствует Локальный Номер месяца 2 Порядковая Отсутствует Международный
Классификация сборочных узлов и деталей производится в соответствии с ГОСТ 2.201-80. Для конкретного предприятия разработана система кодирования каждой сборочной единицы, из которых состоит готовое оборудование и для деталей, входящих в состав сборочной единицы. В коде зашифрована информация о классификационной принадлежности в соответствии с классификатором ЕСКД и порядковый регистрационный номер, который присваивают по классификационной характеристике от 001 до 999. Детали закодированы таким образом, что по коду определяется место их обработки (участок производственного отдела). Связь деталей и производственных участков находится в справочнике «Место обработки». Фрагмент классификатора сборочных единиц представлен в Таблице 1.2, классификатора деталей в Таблице 1.3.
Классификация табельных номеров позволяет однозначно идентифицировать каждого сотрудника. Каждому новому сотруднику присваивается следующий за последним табельный номер. Производственным участкам также номера присваиваются по порядку и служат в качестве краткого обозначения участка и ключа в таблице БД.
Таблица 1.2
Фрагмент классификатора сборочных единиц Таблица 1.3
Фрагмент классификатора деталей Код сборочной единицы Название Код детали Название 210.32.66С Модуль управления 1М.15.153-02 Стержень 400.03.12С Суппорт 1М.19.140 Пруток 401.12.14С Поводок 1М.20.349 Плита
В коде бригады содержится информация о производственном участке, к которому она относится и ее порядковый номер. Так как у бригады нет своего имени, эта классификация позволяет однозначно определить принадлежность к производственному участку. Фрагмент классификатора участков представлен в Таблице 1.4.
Таблица 1.4.
Фрагмент классификатора бригад
Код бригады Название участка К1, К2 Кузница М1, М2, М3 Механический участок Св1, Св2 Сварочный участок Сб1, Сб2 Сборочный участок
Классификация номеров месяцев года стандартна: 1 - Январь, 2 – Февраль, …, 12 – Декабрь. Эта классификация позволяет использовать номер месяца в качестве первичного и вторичного ключа в связях БД.
1.6.3. Характеристика нормативно-справочной и входной оперативной информации
Использование справочников в системе позволит использовать условно-постоянную информацию, избегая проблем с дублированием данных. Все справочники едины для предприятия и используются различными информационными системами. Справочная информация доступна в основном только для чтения. Только ответственные подразделения имеют доступ к дополнению и редактированию справочников. Сводная таблица используемых в разрабатываемой системе справочников представлена в Таблице 1.4.
Таблица 1.4
Характеристика справочников
Название справочника Ответственный Средний объём справочника Средняя частота актуализации Средний объем актуализации Сборки Главный конструктор 1 000 1 раз в год 5-10 записей Детали Главный конструктор 5 000 1 раз год 50-100 записей Входимости Главный конструктор 10 000 1 раз в год 300-500 записей Производственные участки Системный администратор 5 - - Бригады Системный администратор 12 1 раз в год 1 запись Места обработки Главный технолог 5 000 1 раз в год Сотрудники Начальник отдела кадров 130 1 раз в месяц 1 запись Месяцы Системный администратор 12 - - Справочник сборочных единиц «Сборки». В этом справочнике хранится информация обо всех сборочных узлах, из которых собирается готовое оборудование. Актуализация этого справочника происходит по мере освоения новых конструкций. Структура и реквизитный состав справочника представлен в Таблице 1.6.

Таблица 1.6
Структура справочника «Сборки»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код сборочной единицы ID_ass Текстовый 12 байта 2 Название Assem_name Текстовый 20 байта Справочник Детали. Здесь хранится информация о всех деталях, которые входят в состав сборочных единиц. Актуализация этого справочника происходит по мере освоения новых конструкций. Структура и реквизитный состав справочника представлен в Таблице 1.7.
Таблица 1.7
Структура справочника «Детали»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код детали ID_part Текстовый 15 байта 2 Название детали Name_part Текстовый 20 байта 3 Трудоемкость изготовления Labor Числовой с плав. точкой 6 байт 4 Масса детали Massa Числовой с плав. точкой 6 байт Справочник Входимости. Этот справочник определяет спецификации, т.е. позволяет связать сборочные единицы и детали. В одну сборку может входить несколько деталей в различном количестве. Структура и реквизитный состав справочника представлен в Таблице 1.8.
Таблица 1.8
Структура справочника «Входимости»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код детали ID_vhodimosti Числовой счетчик 6 байт 2 Код сборки ID_ass Текстовый 12 байта 3 Код детали ID_part Текстовый 15 байт 4 Количество Quantity Числовое целое 4 байта
Справочник производственных участков. В данном справочнике содержится информация о существующий участках в производственном отделе. Структура и реквизитный состав справочника представлен в Таблице 1.9.
Таблица 1.9
Структура справочника «Производственные участки»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код участка ID_ychastka Числовой 1 байт 2 Название участка Name_ ychastka Текстовый 20 байт
Справочник мест обработки. В данном справочнике содержится связь деталей с местом их обработки (производственным участком). Это при составлении подетального плана позволяет четко определить, на каком участке должна обрабатываться конкретная деталь. Структура и реквизитный состав справочника представлен в Таблице 1.10.
Таблица 1.10
Структура справочника «Место обработки»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код записи ID_obrabotki Числовой
счетчик 6 байт 2 Код детали ID_part Текстовый 15 байт 3 Код участка ID_ychastka Числовой 1 байт
Справочник бригад. В этом справочнике содержатся названия бригад и их принадлежность к производственным участкам. Структура и реквизитный состав справочника представлен в Таблице 1.11.
Таблица 1.11
Структура справочника «Бригады»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код записи ID_brigadi Текстовый 4 байт 2 Код участка ID_ychastka Числовой 1 байт
Справочник сотрудников. В этом справочнике содержится информация о каждом сотруднике, работающем в компании. Для работы автоматизированной системы диспетчирования необходим следующий состав справочника «Сотрудники» (Таблица 1.12):
Таблица 1.12
Структура справочника «Сотрудники»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Табельный номер ID_worker Текстовый 4 байт 2 ФИО FIO Текстовый 70 байт 3 Разряд Skill_ worker Числовой 1 байт 4 Бригада ID_brigadi Текстовый 4 байт
Справочник месяцев. Содержит в себе номер и название всех месяцев года. Структура и реквизитный состав справочника представлен в Таблице 1.13.
Таблица 1.13
Структура справочника «Месяцы»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Номер месяца ID_month Числовой 1 байт 2 Название месяца Name_ month Текстовый 10 байт
Все справочники находятся в отдельных таблицах БД. Т.к. у АРМ диспетчера не будет доступа к серверу, информация из справочников будет импортироваться на рабочее место диспетчера и актуализироваться по мере необходимости. Актуализацией БД диспетчера будет заниматься системный администратор компании.
Входной документ «Месячный план». Созданием годового и квартального плана с помесячной разбивкой занимается служба Коммерческого директора. Форма документа представлена в Приложение А, рис. А.1. Месячный план поступает к диспетчеру производственного отдела в разрезе сборочных единиц. Реквизитный состав входного документа «Месячный план» представлен в Таблице 1.14.
Таблица 1.14
Структура входного документа «Месячный план»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код записи ID_pos_plan Числовой
счетчик 4 байт 2 Номер месяца ID_month Числовой 1 байт 3 Код сборки ID_ass Текстовый 12 байт 4 Количество Plan_quantity Числовой 4 байт
Месячный план будет приноситься в диспетчерскую службу в электронном виде на съемных носителях и экспортироваться в таблицу БД «Месячный план». В разрабатываемой системе будет предусмотрена возможность просмотреть месячный план, но внесение в него изменений будет запрещено.
1.6.4. Характеристика базы данных
На основании построенной модели бизнес-процессов при помощи Case-средства Erwin Data Modeler была разработана логическая и физическая модель базы данных (БД) для решения комплекса поставленных задач. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. [18]. На рис.1.27 представлена полная атрибутивная модель. Это наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Рис. 1.27. Инфологическая модель базы данных
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. [18] . С помощью Erwin на основании построенной логической модели была получена физическая модель для СУБД Microsoft Access 2003 (рис.1.28). Все имена атрибутов и таблиц в данной модели переименованы для удобства дальнейшего оперирования данными. На схеме можно видеть тип данных каждого атрибута.
Рис.1.28. Физическая модель БД
Окончательная схема БД, полученная в результате генерации БД в Microsoft Access 2003, представлена на рис.1.29.
Рис.1.29. Схема данных в СУБД Microsoft Access
1.6.5. Характеристика результатной информации
В качестве результатной информации будут выступать следующие документы:
Подетальный план и АВС подетальный план
Сменное задание
Диспетчерский лист
Отчет о выполнении плана
Отчет о незавершенном производстве
Подетальный план и АВС подетальный план создается на основании месячного плана производства и справочника входимостей деталей в сборочные единицы. Создание подетального плана происходит автоматически при вызове соответствующего пункта меню. Для всех сборочных единиц, входящих в подетальный план, рассчитывается необходимое количество деталей. Если в подетальный план попадают одинаковые детали, их количество суммируется и в таблицу БД попадает только одна запись. Перед сохранением подетального плана можно его изучить и при необходимости вручную изменить расчетное количество деталей. Форму документа подетального плана можно посмотреть в Приложение А (Рис. А.2). Реквизитный состав подетального плана представлен в Таблице 1.15. Поля 1, 2, 3, 6 заносятся в таблицу БД «Подетальный план». Хранить в таблице поля 4 и 5 нет необходимости, т.к. по связи с таблицей «Детали» значение этих показателей можно будет подключить в любой момент.
Таблица 1.15
Структура результатного документа «Подетальный план»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код записи ID_part_plan Числовой
счетчик 4 байт 2 Номер месяца ID_month Числовой 1 байт 3 Код детали ID_part Текстовый 15 байт 4 Название детали Name_part Текстовый 20 байт 5 Трудоемкость Labor Числовой 6 байт 6 Количество Quantity_plan Числовой 4 байт
После сохранения подетального плана имеется возможность произвести его АВС-анализ и создать на его основе АВС подетальный план. В результате анализа будет произведен расчет общей трудоемкости каждой номенклатурной позиции подетального плана в натуральном и процентном отношении. Далее все номенклатурные позиции будут отсортированы по значению общей трудоемкости изготовления и в соответствии с процентом общей трудоемкости нарастающим итогом будет присвоен класс детали: А, В или С. Это будет означать приоритет детали при составлении подетального плана. Как уже говорилось ранее, может возникнуть необходимость поменять приоритет изготовления детали вручную. Это будет легко сделать при помощи списка значений. Форму документа АВС подетального плана можно посмотреть в Приложение А (Рис. А.3). Реквизитный состав подетального плана совпадает с представленным в Таблице 1.15. Однако при этом в таблицу «Подетальный план» дописывается два дополнительных показателя: процент общей трудоемкости изготовления детали и класс детали.
С учетом АВС подетального плана ежедневно создаются сменные задания на каждую рабочую бригаду. Сменное задание, как правило, создается накануне, поэтому датой по умолчанию является дата следующего дня. Для составления сменного задания необходима связь с таблицами БД «Бригада», «Производственный участок», «Месяц», «Подетальный план», «Место обработки». Из списка выбирается номер бригады, а для информации в соседнем поле появляется название производственного участка. На основании подетального плана и справочника мест обработки можно выбрать детали, изготовлением которых занимается данный участок. Выбор детали осуществляется из раскрывающегося списка, где детали отсортированы по приоритету класса. Для выбранной номенклатурной позиции автоматически появится информация о названии детали, трудоемкости и количестве, которое осталось произвести в текущем отчетном месяце. Пользователю остается только указать количество деталей для выполнения за планируемую смену и выбрать ответственного за исполнения сотрудника из раскрывающегося списка, в который попадают только сотрудники данной бригады. В одном сменном задании может быть несколько номенклатурных позиций. Форму документа сменного задания можно посмотреть в Приложение А (Рис. А.4). Реквизитный состав подетального плана представлен в Таблице 1.16. Поля 1, 2, 3, 5, 9, 10 заносятся в таблицу БД «Сменное задание». Хранить в таблице поля 4, 6, 7 и 8 нет необходимости, т.к. по связи с таблицей «Детали» и «Подетальный план» значение этих показателей можно будет подключить в любой момент.
Таблица 1.16
Структура результатного документа «Сменное задание»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Код записи ID_task Числовой
счетчик 4 байт 2 Дата Date_task Дата 6 байта 3 Код бригады ID_brigadi Текстовый 4 байта 4 Название участка Name_ychastka Текстовый 20 байт 5 Код детали ID_part Текстовый 15 байт 6 Название детали Name_part Текстовый 20 байт 7 Трудоемкость Labor Числовой 6 байт 8 Оставшееся количество по плану Quantity_plan - Quantity_made Числовой 4 байт 9 Количество Quantity_task Числовой 4 байт 10 Табельный номер сотрудника ID_worker Текстовый 4 байта В конце рабочего дня происходит закрытие сменного задания, где для каждой номенклатурной позиции указывается количество принятых ОТК деталей и количество брака. На основании сданных деталей происходит увеличение значения количества сделанных в данном отчетном месяце деталей данной номенклатурной позиции в подетальном плане. Результаты расчета записываются в таблицу БД «Подетальный план» в поле Quant_made.
Диспетчерский лист является отчетной формой документа, необходимой для ежедневного контроля и анализа выполнения плана. Для формирования диспетчерского листа необходимо указать номер производственного участка. Отчет формируется на основании запроса на выборку из таблиц БД «Детали», «Подетальный план», «Месяц», «Производственные участки», «Место обработки». Форму отчета Диспетчерский лист можно посмотреть в Приложение Д, рис. Д.5. Реквизитный состав диспетчерского листа представлен в Таблице 1.17.
Таблица 1.17
Структура результатного документа «Диспетчерский лист»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Дата отчета Date Дата 6 байта 2 Название участка Name_ychastka Текстовый 20 байт 3 Код детали ID_part Текстовый 15 байт 4 Название детали Name_part Текстовый 20 байт 5 Трудоемкость Labor Числовой 6 байт 6 План Quantity_plan Числовой 4 байт 7 Сдано Quantity_made Числовой 4 байт 8 Осталось Quantity_plan - Quantity_made Числовой 4 байта 9 % выполнения Plan% Процентный 4 байта
Данные диспетчерского листа необходимы для оперативного анализа и нет необходимости их хранения в БД.
Отчет о выполнении плана может быть построен как в разрезе производственного участка, так и по производству в целом. Его формирование основано на запросе на выборку, который соединяет таблицы БД «Детали», «Подетальный план», «Месяц», «Производственные участки», «Место обработки», «Бригады», «Сменное задание». Форму отчета о выполнении плана можно посмотреть в Приложение Д, рис. Д.6. Реквизитный состав отчета представлен в Таблице 1.18.
Таблица 1.18
Структура результатного документа «Подетальный план»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Отчетный месяц ID_month Числовой 1 байт 2 Название участка Name_ychastka Текстовый 20 байт 3 Код детали ID_part Текстовый 15 байт 4 Название детали Name_part Текстовый 20 байт 5 План Quantity_plan Числовой 4 байт 6 Сдано Quantity_made Числовой 4 байт 7 Брак Quantity_brak Числовой 4 байта 8 % выполнения Plan% Процентный 4 байта 9 % брака Brak% Процентный 4 байта 10 Средний % выполнения SPlan% Процентный 4 байта 11 Средний % брака SBrak% Процентный 4 байта
Отчет о незавершенном производстве отражает количество деталей, которые необходимо произвести для полного выполнения плана. Он также может быть построен как в разрезе производственного участка, так и по производству в целом. Его формирование основано на запросе на выборку, который соединяет таблицы БД «Детали», «Подетальный план», «Месяц», «Производственные участки», «Место обработки», «Бригады», «Сменное задание». Форму отчета о выполнении плана можно посмотреть в Приложение Д, рис. Д.7. Реквизитный состав отчета представлен в Таблице 1.19. Поля 6 и 8 являются расчетными. Поле 7 остается пустым для заполнения вручную по итогам инвентаризации на местах.
Таблица 1.19
Структура результатного документа «Подетальный план»
№
п/п Наименование поля Идентификатор Тип поля Размер поля
1 Отчетный месяц ID_month Числовой 1 байт 2 Название участка Name_ychastka Текстовый 20 байт 3 Код детали ID_part Текстовый 15 байт 4 Название детали Name_part Текстовый 20 байт 5 План Quantity_plan Числовой 4 байт 6 НЗП нормативное NZP_norm Числовой 4 байт 7 НЗП фактическое NZP_fakt Числовой 4 байта 8 Средний % НЗП NZP% Процентный 4 байта
Данные рассмотренных отчетов необходимы для оперативного анализа и нет необходимости их хранения в БД. Они могут создаваться по мере необходимости получения информации для анализа хода производства продукции.
1.7. Программное обеспечение задачи
1.7.1. Общие положения (дерево функций)
Разработка АРМ диспетчера производственного отдела производилась средствами Micr