1.3.2.Выбор и обоснование стратегии автоматизации задачи
Далее определим стратегию автоматизации технологии работы с заявками клиентов ООО «СИТИЛИНК».
В настоящее время принята классификация стратегий автоматизации на следующие виды [11]:
- Хаотичная (кусочная) автоматизация;
- Автоматизация по участкам;
- Автоматизация по направлениям;
- Полная автоматизация.
Проведем более подробный анализ данных стратегий.
Хаотичная стратегия автоматизации подразумевает отсутствие единой стратегии функционирования информационной системы предприятия. Каждый специалист, либо группа специалистов в рамках данной стратегии принимает решение о внедрении той или иной информационной системы, что приводит полному отсутствию управляемости системой, сложностям в администрировании и невозможности интеграции различных направлений работы специалистов. Такая стратегия автоматизации характерна для малых предприятий, зачастую не имеющих в штате ИТ-специалистов, когда каждый специалист устанавливает себе системное, офисное, антивирусное ПО, а также отвечает за функционал прикладного ПО. Например, бухгалтер самостоятельно выбирает более удобную с его точки зрения программу, не согласовывая свои действия, например, с кадровой службой, которая также имеет свой функционал, например, при учете сотрудников или табелей рабочего времени. Такая стратегия автоматизации является неэффективной, ведет к росту расходов на программное обеспечение, увеличивает трудозатраты в случае необходимости интеграции различных участков работы, значительно повышает уязвимость системы и усложняет администрирование.
Стратегия автоматизации «по участкам» предполагает единый подход при внедрении программного обеспечения в рамках выполнения единого функционала. Так, в данном случае, например в технологии учета заработной платы, единое ПО уже будут использовать бухгалтер и специалист по кадрам, что позволит объединить функционал данных специалистов в единую технологическую цепочку. При этом и в данном случае остается ряд недостатков, характерных для хаотичной автоматизации, так как не предполагается единый подход к использованию информационных ресурсов системы (так как в данном случае не используется единая СУБД, аппаратная платформа, системное ПО, что также увеличивает расходы на использование системы) [13].
Стратегия автоматизации «по направлениям» предполагает единые подходы к внедрению информационных систем согласно направлениям деятельности предприятия. Например, блок бухгалтерии при данной стратегии будет использовать базу «1С: Комплексная автоматизация», в которой реализован функционал всего бухучета – учета заработной платы, основных средств, оперативного, складского учета и при этом все это объединено в единую базу и позволяет получать сводную информацию о состоянии данного объекта управления. При этом в рамках единого ПО отражена вся технологическая цепочка подразделения (от ввода первичных данных до формирования отчетности и электронного документооборота).
Стратегия полной автоматизации предполагает автоматизацию всех направлений деятельности на единой платформе управления. Подобный тип автоматизации является оптимальным, хотя встречается довольно редко – в крупных компаниях, так как требует наличия собственного штата разработчиков ПО [14].
Основываясь на том, что нам необходимо автоматизировать бизнес процесс поддержки принятия решений, целесообразно выбрать стратегию автоматизации «по направлениям». Так как работа организация работы с заявками клиентов представляет собой целостную технологическую цепочку, целесообразна её полная автоматизация.
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач
Определим способ приобретения программного обеспечения для автоматизации документооборота.
Покупка готовых решений имеет следующие преимущества [9]:
- Отсутствие необходимости расходов на разработку ПО;
- Готовые решения, как правило, соответствуют стандартным технологиям работы специалистов;
- Приобретение лицензионного ПО предполагает возможность технической поддержки конечных пользователей, доработки ПО в соответствии с изменениями законодательства.
Также в настоящее время возможно приобретение «облачных» решений, что предполагает аренду ПО, развернутого на удаленном сервере. При этом не требуется временных затрат на установку и обслуживание ПО, но имеются риски, связанные со стабильностью каналов связи, а также с нахождением данных организации на сервере сторонней фирмы. При этом в случае возникновения проблемных ситуаций возможна блокировка доступа к ресурсам.
К недостаткам готовых решений относят необходимость адаптации под специфику организации, зачастую наличие неиспользуемого функционала. Риски, связанные с зависимостью от фирмы-разработчика.
Также возможно использование стратегии ПО, связанной с покупкой и доработкой существующих решений. В этом случае приобретается ядро системы (например, в бухгалтерии это проводки), а остальной функционал дорабатывается.
К преимуществам данной стратегии можно отнести [6]:
- Покупаемое ядро является отлаженным и законченным компонентом
- Возможная доработка именно требуемой функциональности
- Не надо платить за то, что компании не нужно
К недостаткам:
- Необходимость наличия в штате фирмы отдела информационных технологий
- Эффективность данной схемы можно достичь при относительно небольших объемах доработок
- Доработки возможны только в рамках реализованного ядра готовой системы
Стратегия собственной разработки программного обеспечения имеет преимущества:
- Возможность адаптации к предъявляемым требованиям
- Индивидуализация проекта
- Возможность реализации изменений под требования организации
Недостатки данной стратегии [10]:
- Необходимость создания команды, либо создания дополнительной нагрузки на специалистов ИТ отдела;
- Отсутствие профессиональных постановщиков задач может вносить ошибки в бизнес-логику уже на стадии технического задания;
- Проект может захлебнуться:
- Из-за недостаточной квалификации разработчиков и специалистов – профильных отделов
- Из-за ухода ведущих специалистов
- Из-за нехватки внутренних ресурсов
- Смена руководства компании может привести к решению о закрытии проекта
- Часто плохая документированность системы
В данном случае оптимален способ автоматизации путем покупки ядра системы и ее последующей доработки.
В результате рассмотрения параметров основных стратегий автоматизации было принято решение о разработке собственной автоматизированной системы, учитывающей особенности бизнеса предприятия, так как в рассмотренных выше существующих разработках отсутствует интегрированное решение всех поставленных задач, а если покупать готовые решения разных производителей, ориентирующиеся на решение отдельных задач, тогда получим недостатки, характерные для хаотичной автоматизации. Кроме того, руководством ООО «СИТИЛИНК» было принято решение о рассмотрении возможности снижения расходов на приобретение программного обеспечения. Кроме разработки программного обеспечения было принято решение об интеграции программного продукта с бесплатным офисным пакетом OpenOffice.org для экономии расходов бюджета на приобретение лицензий на MSOffice.
1.4. Обоснование проектных решений
1.4.1 Обоснование проектных решений по техническому обеспечению
Под техническим (аппаратным) обеспечением информационной системы понимается весь комплекс электронных, электрических и механических устройств, входящих в состав системы и/или сети, исключая программное обеспечение и хранимую информацию. В этот комплекс входят: компьютеры, периферийные устройства ввода/вывода и хранения информации, а также сетевое оборудование различных типов и энергетическое оборудование (батареи и аккумуляторы) [3].
Требования к техническому обеспечению формировались исходя из аппаратных требований используемого программного обеспечения, и представлены в таблице 6.
Таблица 6
Аппаратные требования информационной системы
Параметры аппаратного обеспечения серверной части определены согласно требованиям к СУБД, требования к рабочей станции – по оценке нагрузки на рабочую станцию приложения для автоматизации системы документооборота.
Анализ аппаратных требований дает основание утверждать, что существующих средств технического обеспечения для функционирования создаваемой информационной системы автоматизации работы с заявками клиентов достаточно, необходимость в модернизации и замене отсутствует.
1.4.2 Обоснование проектных решений по информационному обеспечению
Информационное обеспечение – совокупность проектных решений по объемам, размещению, формам организации информации (единой системы классификации и кодирования информации унифицированных систем документации, схем информационных потоков), циркулирующей в организации, а также методология построения баз данных. [8]
Все информационного обеспечения можно разделить на два типа: внемашинное и внутримашинное информационное обеспечение.
Внемашинное информационное обеспечение включает показатели, необходимые для решения управленческих задач; их объемно-временные характеристики и информационные связи; различные классификаторы и коды; унифицированную систему документации для отражения показателей; формы вывода результатов обработки.
Автоматизация управленческих операций требует приведения всего множества показателей в единую, целостную систему, установления их содержательного и терминологического единства (однозначности), а также четких взаимодействий между ними.
В процессе проектирования экспертной системы ООО «СИТИЛИНК» потребуется использование ряда классификаторов:
- Локальный классификатор видов обслуживаемого кассового оборудования;
- Локальный классификатор видов аварийных ситуаций;
- База знаний по устранению аварий.
В качестве входных документов информационной системы используются:
- Заявка на устранение аварийной ситуации;
Выходной информацией будет являться сформированная отчетность по:
- порядку устранения аварийной ситуации;
В большинстве случаев, использование унифицированных форм в управлении системой документооборота не представляется возможным, так как такие формы отсутствуют.
1.4.3 Обоснование проектных решений по программному обеспечению
Программное обеспечение — совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ. [6]
В таблице 7 приведен перечень проектных решений по видам программного обеспечения, используемых в данной работе.
Таблица 7
Перечень программного обеспечения, используемого в проекте автоматизации документооборота ООО «СИТИЛИНК»
Таким образом, при расчете требований к параметрам технического обеспечения необходимо учитывать системные требования для обеспечения функционирования всего комплекса программного обеспечения, используемого в условиях ООО «СИТИЛИНК».
II. Проектная часть
2.1 Основные этапы жизненного цикла информационной системы
2.1.1 Этапы жизненного цикла проекта автоматизации
Проведем выбор концепции жизненного цикла в рамках проектирование экспертной системы автоматизированного управления.
Понятие «жизненный цикл проекта» можно интерпретировать как период времени от зарождения идеи проекта до его завершения, который можно разделить на соответствующие фазы или этапы [8]:
- Стадия замысла
- Стадия разработки
- Стадия производства
- Стадия применения
- Стадия поддержки применения
- Стадия прекращения применения и списания
Не бывает одного оптимального способа определить наиболее подходящий жизненный цикл и структуру проекта. У некоторых организаций существуют принятые принципы, согласно которым для каждого проекта подразумевается один и тот же жизненный цикл, в то время как остальные организации позволяют команде управления проектом самим выбирать жизненный цикл, наиболее подходящий для проекта.
Модель жизненного цикла программного обеспечения — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Модели жизненного цикла:
- Каскадная модель — подразумевает последовательное выполнение всех этапов проекта в строго определенном порядке. Переход на следующий этап выполняется только после полного завершения работ на предыдущем.
- Итерационная модель — подразумевает разделение жизненного цикла проекта на определенную последовательность итераций, напоминающих «мини-проект», каждый из которых включает все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программного продукта, включающей функциональность, определённую интегрированным содержанием всех предыдущих, и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта.
- Спиральная модель — складывается из нескольких итераций (витков спирали) путем создания прототипов (черновых версий программы). Каждая итерация соответствует созданию фрагмента или версии программного обеспечения, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
Для разработки требуемого приложения автоматизации документооборота выбрана спиральная модель, представленная на рисунке 11. Структура модели жизненного цикла программного обеспечения приведена в соответствии со стандартом ГОСТ Р МЭК 62304 —2013. Информационная технология. Процессы жизненного цикла программных средств [14, с.90].
Рисунок 9 — Спиральная модель
Концепция спиральной модели, разработанная Барри Боэмом в 1986 году, применяется в рамках разработки большого количества информационных систем [8]. Она выступает в роли технологии разработки программного обеспечения, сочетающей в себе как стадии проектирования, так и постадийного прототипирования с целью сочетания достоинств восходящих и нисходящих алгоритмов, в которой делается упор на работу с начальными этапами жизненного цикла: стадий анализа и проектирования.
На каждом витке спирали производится создание фрагмента или версии программного продукта. Производится уточнение целей и характеристик проекта, определение его качеств и планирования работ на следующем витке спирали.
Каждый виток разбивается на секторы [20, c.36]:
- Определение перечня целей
- Оценивание вероятности рисков
- Осуществление разработки и тестирования
- Планирование
На каждом из витков спирали могут использоваться различные модели технологии разработки программного обеспечения. В конечном итоге на выходе получается готовый продукт. Модель включает в себя ряд возможностей моделей прототипирования и каскадной модели. Процесс итеративной разработки отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом из этапов позволяет переходить к следующему этапу, не дожидаясь полного окончания работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации.
Главная задача — как можно быстрее показать Заказчику системы работоспособный продукт, таким образом активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения потребуется ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена.
В перспективе разрабатываемое web-приложение будет дополняться новым функционалом, поэтому данная модель жизненного цикла вполне подходит для разработки стартовой версии интернет-магазина.
При разработке проекта автоматизации технологии документооборота был составлен календарный план внедрения автоматизированной информационной системы, представленный в таблице 8.
Таблица 8
Хронологический порядок внедрения программного продукта в технологию работы
На первом этапе производится первоначальное ознакомление с объектом автоматизации, изучение бизнес-процессов, технологии документооборота. На этом этапе задействован разработчик-автор дипломного проекта, необходимые материалы предоставляются специалистами по работе с клиентами ООО ООО «Ситилинк», других структурных подразделений, руководителем предприятия.
На следующем этапе происходит проектирование информационной системы – определение информационных объектов, их свойств, установление взаимосвязи между ними. На этом этапе задействован разработчик – автор дипломного проекта.
Третий этап – определение стратегии автоматизации. После определения комплекса задач происходит оценка возможностей внедрения самостоятельного разработанного, либо приобретенного программного обеспечения, проводится технологическая и экономическая оценка. На этом этапе задействованы: руководитель организации, специалисты экономического отдела (2 чел.) и отдела делопроизводства (1 чел.), разработчик дипломного проекта.
Четвертый этап – приобретение ПО, в нашем случае – написание программного продукта для работы с информационной системой специалиста по работе с заявками клиентов на обслуживание кассового оборудования. Задействован автор дипломного проекта.
Следующий этап – опытная эксплуатация программного продукта –разработанное программное обеспечение устанавливается на тестовые рабочие станции и происходит проверка всего функционала программы с целью выявления ошибок в её работе, соответствия заявленной технологии, определения возможностей усовершенствования. На данном этапе задействованы: руководитель организации, специалист отдела делопроизводства, автор данного проекта.
На последнем этапе после исправления неточностей в работе, выявленных в ходе опытной эксплуатации, происходит внедрение программного продукта в промышленную эксплуатацию через развертывание базы данных, установку программы на рабочие станции пользователей. Задействован разработчик данного проекта.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На различных этапах жизненного цикла экспертной системы различные риски могут реализовываться по-разному. Ожидаемые риски на этапах жизненного цикла и план реагирования при возникновении рисковых ситуаций представлены в таблице 9 [21].
Таблица 9
Ожидаемые риски на этапах жизненного цикла
2.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
Разрабатываемая информационная система должна удовлетворять требованиям защиты информации, утвержденным на данном предприятии, а также требованиям законодательства.
Выделим основные виды угроз, возникающие в процессе функционирования информационной системы документооборота:
— Внутренние – возникающие в результате некорректных действий пользователя. При анализе потенциала данного вида угрозы было выявлено, что основным пользователем системы является единственный специалист, применение системы жесткого разграничения доступа нецелесообразно. Для снижения потенциала угроз необходимо проведение инструктажа под роспись с пользователем о правилах информационной безопасности;
-Внешние – возникающие в результате внешних воздействий (Интернет-угроз, технических сбоев, вирусной активности, несанкционированного копирования)
Таким образом, в разрабатываемую информационную систему должны быть включены компоненты парольной защиты, резервного копирования базы данных. На рабочей станции специалиста, на которой будет развернута база данных специалиста по делопроизводству, должны применяться общие для организации политики безопасности.
После экспертизы проекта на наличие компонент информации конфиденциального характера возможно принятие решения о применении организационных и технических мер защиты информации:
-Опечатывания рабочей станции;
-Отключение USB-портов для ограничения возможности несанкционированного копирования информации;
-Отнесения помещения, где находится рабочая станция с базой данных, к разряду выделенных помещений.
Для организационного обеспечения защиты информации в ООО «СИТИЛИНК» были разработаны документы:
-«Положение о пропускном режиме в ООО «СИТИЛИНК» — ограничивает доступ посторонних лиц в помещения, где происходит обработка данных;
-«Положение об антивирусной защите в ООО «СИТИЛИНК»;
-«Положение об обороте носителей информации в ООО «СИТИЛИНК» (предотвращает несанкционированное копирование);
-«Положение о пользовании ресурсами Интернета в ООО «СИТИЛИНК»
За нарушения положении данных документов предусматривается дисциплинарная ответственность в рамках трудового законодательства.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
На рисунке 12 приведена информационная модель экспертной системы.
Рисунок 10 – Информационная модель системы
Как показано на рисунке 10, информационная модель системы включает области:
1 – Область администратора, связанная с заполнением базы знаний, куда вводится информация о проблемных ситуациях, вариантах решения, а также проводится настройка переходов;
2 – Область работы оператора, в которой проводится поиск решения проблемных ситуаций с использованием экспертной системы.
- – Область формирования отчетности.
2.2.2. Характеристика нормативно-справочной, входной и оперативной информации
В рамках анализа информационной системы учета заявок на выполнение работ с оборудованием ООО «Ситилинк», определим ключевые сущности информационной системы, их атрибуты, установим связи между ними.
Ключевыми сущностями информационной системы являются:
— ремонтники;
— виды кассового оборудования;
— подразделения;
— неисправности;
— заявки на устранение неисправностей;
— специалисты.
Определим типы связей между сущностями информационной системы по учету заявок на приобретение запчастей.
В каждое обращений входит множество обоснований. Связь 1:N.
Каждой обращение соответствует подразделению. Связь 1:1.
Каждый ремонтник может регистрировать множество обращений. Связь 1:N.
Каждый специалист может подать множество обращений. Связь 1:N.
Установим связи между сущностями разрабатываемой информационной системы.
Диаграмма «Сущность — Связь» приведена на рисунке 18.
Каждый вид кассового оборудования включает в себя множество моделей оборудования. Связь 1:N.
Каждой модели оборудования соответствует множество объектов оборудования. Связь 1:N.
На каждый объект оборудования может быть составлено множество заявок на проведение ремонтных и профилактических работ. Связь 1:N.
Каждой заявке соответствует множество проведенных работ. Связь 1:N.
Каждый специалист может провести множество работ. Связь 1:N.
Каждое подразделение предприятия использует множество объектов оборудования. Связь 1:N.
Рисунок 11 — Диаграмма «Сущность — Связь»
Структура нормативно-справочной информации подсистемы и система кодирования справочной информации представлена в таблице 10.
Таблица 10
Структура нормативно-справочной информации система кодирования справочной информации
Код модели оборудования. Длина кода ХХХХХ, где ХХХХХ – порядковый номер модели кассового оборудования в системе предприятия.
Код экземпляра техники. Длина кода ХХХХХ ХХХ, где ХХХХХ – порядковый номер модели, ХХХ – номер соответствующего ему экземпляра.
Код документа. Длина кода ХХХ ХХХ, где ХХХ – порядковый номер модели оборудования, ХХХ – код соответствующего документа на модель оборудования.
Код проведенной работы. Длина кода ХХХХХХ, где ХХХХХХ – порядковый номер проведенной работы с обслуживаемым кассовым оборудованием.
Код типа техники. Длина кода ХХ, где ХХ -порядковый типа оборудования.
Код подразделения. Длина кода ХХХ, где ХХХ – порядковый номер подразделения предприятия.
Код специалиста. Длина кода ХХХХ, где ХХ – порядковый номер специалиста.
Описание свойств объектов информационной модели данных приведено ниже.
Таблица 11
Атрибуты сущности «Виды оборудования»
Таблица 12
Атрибуты сущности «Модели оборудования»
Таблица 13
Атрибуты сущности «Картотека техники»
Таблица 14
Атрибуты сущности «Клиенты»
Таблица 15
Атрибуты сущности «Специалисты»
Таблица 16
Атрибуты сущности «Заявки на техобслуживание»
Таблица 17
Атрибуты сущности «Работы по заявкам»
Инфологическая модель приведена на рисунке 12.
Рисунок 12 — Логическая модель базы данных
2.2.3. Характеристика результатной информации
Результативная информация содержит информацию о порядке решения проблемы и включает реквизиты:
— Направление обращения;
— Алгоритм решения проблемы.
Отчет по результату работы экспертной системы содержит поля:
— Код проблемной ситуации;
— Наименование проблемной ситуации;
— Алгоритм решения;
— Данные о результативности решения.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Схема «Дерево функций» позволяет наглядно показать иерархию функций управления и обработки данных, которые автоматизированы в разработанном программном продукте.
Выделяется два подмножества функций программы (рисунок 13) [9]:
- служебные функции (проверка пароля, управление окнами и др.);
- основные функции обработки данных (ввода первичной информации, обработки, ведения справочников, подготовки и распечатки документов и др.).
Рисунок 13 — Дерево функций
На рисунке 14 приведен сценарий диалога системы.
Рисунок 14 — Сценарий диалога системы
Таким образом, интерфейс разрабатываемого программного продукта должен соответствовать показанной структуре и включать перечень указанных основных и служебных функций.
2.3.2. Характеристика базы данных
Структура таблиц создаваемой базы данных приведена ниже.
Таблица 18
Структура справочника видов оборудования
Таблица 19
Структура таблицы «model»
Таблица 20
Структура таблицы «podr»
Таблица 21
Структура таблицы «kartotek»
Таблица 22
Структура таблицы «spc»
Таблица 23
Структура таблицы «zayav»
Таблица 24
Структура таблицы «rab_zay»
Таблица 25
Структура таблицы «material»
Таблица 26
Структура таблицы «vid_rab»
Таблица 27
Структура таблицы «mat_rab»
Рисунок 15 — Физическая модель данныхФизическая модель данных приведена на рисунке 15.
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
На рисунке 17 показано дерево вызова программных модулей.
Рисунок 16 – Дерево вызова программных модулей
2.3.4 Описание программных модулей
В таблице 14 приведено описание программных модулей системы.
Таблица 28
Описание программных модулей
2.4. Контрольный пример реализации проекта и его описание
Таким образом, интерфейс разрабатываемого программного продукта должен соответствовать показанной структуре и включать перечень указанных основных и служебных функций.
Рассмотрим основные режимы работы созданного программного обеспечения для автоматизации работы с заявками на гарантийное и сервисное обслуживание реализуемой техники ООО «Ситилинк». На рисунке 18 приведена главная форма.
Рисунок 18 — Главная форма
На рисунке 19 приведен справочник видов работ.
Рисунок 18 — Справочник видов работ
На рисунках 19-20 показан справочник клиентов.
Рисунок 19 — Справочник клиентов (список)
Рисунок 20 — Справочник клиентов (добавление)
На рисунках 21-22 показан режим справочника кассового оборудования.
Рисунок 21 — Режим справочника кассового оборудования (список)
Рисунок 22 — Режим справочника кассового оборудования (добавление)
На рисунках 23-25 приведен режим приема в ремонт кассового оборудования.
Рисунок 23 — Режим приема в ремонт кассового оборудования (режим ввода)
На рисунке 25 приведен режим списка заявок на ремонт кассового оборудования.Рисунок 24 — Режим приема в ремонт кассового оборудования (печатная форма)
Рисунок 25 — Режим списка заявок на ремонт кассового оборудования
На рисунках 26-27 приведен режим справочника сотрудников.
Рисунок 26 – Справочник сотрудников (список)
Рисунок 27 – Справочник сотрудников (добавление)
На рисунках 28-29 показан режим учета выполненных работ по заявкам.
Рисунок 28 – Ввод данных о ремонтных работах
Рисунок 29 – Ремонтные работы (список)
На рисунке 30 приведен отчет «Список оборудования в ремонте».
Рисунок 31 – Отчет «Список оборудования к выдаче»Рисунок 30 — Отчет «Список оборудования в ремонте»
На рисунке 32 приведен отчет «Стоимость работ по сотрудникам»
Рисунок 32 — Отчет «Стоимость работ по сотрудникам»
На рисунке 33 приведен отчет «Стоимость работ по заявкам»
Рисунок 33 — Отчет «Стоимость работ по заявкам»
Таким образом, все поставленные задачи автоматизации выполнены.