SQL Server
2000/2005,
PostgreSQL
8.1
место
AstroSoft
HelpDesk
web
MS Internet
Information
Server
Microsoft
SQL Server
нет
Astrosoft
HelpDesk
Enterprise
Edition
(безограниче
ний) $5000
FrontRange IT
ServiceManage
ment 5.0
console/
web
MS Internet
Information
Server
Oracle 9,
Microsoft
SQL Server
2000
Incident,
Problem,
Change,
Configuratio
n,
Availability,
Release,
SLM
Итилиум
console/
web
платформа
1С:Предпри
ятие 8.0
Microsoft
SQL
Server/файл
овая
система
нет
14900 рублей
(~$550)
Поэтому было принято решение о самостоятельной разработке системы учета и
обработки обращений в отдел техподдержки ООО «Газпром Добыча Ноябрьск».
Основной задачей создания системы учета обработки заявок становится
автоматизирование процесса обработки заявок от клиентов.
К создаваемой системе будут предъявляться следующие требования:
• Составление, прием, обработка заявок от пользователей на реализацию
технического обслуживания или ремонта оргтехники;
• Составление плановых отчетов;
• Наличие механизма отслеживания заявок в системе.
Сама ИС должна включать в себя следующие функции:
1. Обработка и учет заявок
• Составление заявки пользователем;
• Проверка пользователя по его регистрационным данным;
• Передача заявок сотруднику ИТ-отдела;
Отчетность и текущие итоговые формы:
• ЖЦ заявки;
• другие аналитические отчёты.
2. База знаний
• Распорядок работы отдела;
• Правила работы с системой;
• Последовательность решения наиболее типичных проблемных вопросов;
• Доступность создания новых разделов, подразделов и статей в базе
знаний;
• Остальные вопросы.
3. Отслеживание выполнения заявок:
• Отслеживание последовательности реализации работ, потраченного
времени и ресурсов;
• Выделение приоритетных запросов в зависимости от типа запроса,
каждого пользователя или других обстоятельств;
• Огласка запросов и инцидентов, уведомление соответствующих
администраторов;
• Сохранение базы знаний по предыдущим запросам, позволяющей
специалистам быстро разрешать проблемы, аналогичные уже возникавшим.
1.3.2. Выбор и обоснование стратегии автоматизации задачи
Для реализации проекта можно выделить следующие этапы:
1. Анализ существующих процессов учета деятельности IT-отдела компании.
Заключается в сборе и анализа следующих показателей: количество невыполненных
заявок; количество выполненных заявок в день; количество времени, потраченное на
принятие и обработку заявок.
2. Определение полной совокупности функционала, который предстоит
автоматизировать.
3. Выбор стратегии автоматизации. Анализ существующих типов стратегий
автоматизации и подбор наиболее подходящего к структуре и бизнес-процессам
предприятия.
4. формирование Технического задания и графика выполнения работ.
Выбор стратегии автоматизации:
Существует четыре варианта стратегии автоматизации: хаотичная
автоматизация, автоматизация по участкам, автоматизация по направлениям и полная
автоматизация.
Хаотичная стратегия не подходит, т.к. автоматизируем целый отдел. При этом
используется несколько составляющих ИС, такие как СУБД, клиент-серверное
приложение. Нельзя автоматизировать только часть из них, эффекта от этого не
будет. Полная стратегия автоматизации тоже не подходит в нашем случае, так как мы
автоматизируем одно из направлений деятельности компании. Стратегия
автоматизации по участкам лучше всего подходит для автоматизации учета и
обработки заявок, так как в этом случае необходимо внедрить систему автоматизации
только в одном из отделов компании. Автоматизировав данный процесс, можно будет
значительно снизить время на обработку заявок .[11]
1.3.3. Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Способы приобретения ИС – это последующие действия от определения и
формализации решения о необходимости ИС до момента пока ИС не будет внедрена
на предприятия. Существуют следующие способы приобретения ИС [6]:
разработка (самостоятельная и заказная);
покупка ИС (покупка отечественной или зарубежной ИС);
покупка + доработка (самостоятельная или заказная);
аренда.
В таблице 1.5 приведен сравнительный анализ способов приобретения.
Таблица 0.5
Сравнительный анализ способов приобретения
Критери
й
Разработка
«с нуля»
Коробочная версия с
дополнительным по
Покупка и доработка
Стоимос
ть
продукта
Дорога из-за
необходимости
привлечения
большого
Коробочная версия имеет
среднюю стоимость.
Большой объем затрат
пойдет на покупку
Средняя стоимость
коробочной версии.
Для последующей
доработки требуется
количества
сотрудников для
разработки
дополнительных модулей.
привлечение
собственного
персонала, либо
персонала
разработчика.
Время на
создание
и
внедрени
е
Разработка
занимает несколько
месяцев
Разработка готовая и
необходимость лишь в ее
внедрении, занимает около
недели. Плюс докупка
дополнительного ПО и его
интеграция в течении
последующей
эксплуатации.
Доработка основных
модулей займет
примерно месяц.
Дальнейшее изменение
системы возможно в
период ее
использования.
Кем
исполняе
тся
Собственные силы
заказчика, либо
специалисты
организации -
разработчика
Специалистами
поставщика
Собственными силами
Согласно рассмотренным способам приобретения системы обработки
обращений, можно сделать вывод о том что:
Закупка коробочной версии с последующей докупкой дополнительного ПО –
не эффективна, так как представляет собой хаотичную стратегию автоматизации,
которая привлечет со временем к убыткам. После внедрения система не будет
полностью удовлетворять всем требованиям, соответственно, в последствии ее
придется дорабатывать и модифицировать.
Закупка коробочной версии, и ее доработка – способ достаточно экономичный,
но не выгоден в связи с тем, что на доработку системы придется привлечь большое
количество собственных сотрудников. На разбор работы системы уйдет большое
количество времени, плюс потребуется некоторое время, чтобы реализовать в ней
необходимые возможности.
В связи с этим следует остановить на разработке «с нуля». Способ
дорогостоящий и продолжительный, но на выходе система будет удовлетворять всем
требованиям автоматизируемого предприятия.
ИС будет создаваться собственными силами фирмы, поскольку компания имеет
квалифицированных сотрудников для разработки и внедрения подобной ИС.
Создаваемая ИС включает весь необходимый функционал, а также учитывает все
особенность работы и пожелания сотрудников данной компании, поскольку является
индивидуальным (уникальным) продуктом, позволяющим быстро модифицировать
функциональность в рамках требований внутреннего заказчика.
II Проектная часть
2.1Обоснование проектных решений
2.1.1 Обоснование проектных решений по информационному обеспечению
В качестве информационной базы будет выбрана интегрированная база данных
под управлением СУБД. Документооборот в организации достаточно велик,
документы копируются и изменяются по нескольку раз в день. Пользователям
необходима свежая информация с постоянным обновлением, а совокупность
локальных файлов не сможет предоставить этой возможности.
Существуют следующие способы организации информации в базе данных:
1. Иерархическая модель
2. Сетевая модель
3. Реляционная модель
Реляционная модель данных организует и представляет данные в виде таблиц и
реляций. Все отношения в модели имеют собственный Наименование поля таблицы,
что позволяет исключить дублирование информации. Такие модели просты в
использовании, легко модифицируются и их реализация не занимает много времени.
Существует два подхода к проектированию реляционной базы данных:
На этапе концептуального проектирования создается не концептуальная модель
данных, а непосредственно реляционная схема БД, состоящая из определений
реляционных таблиц, подвергающихся нормализации.
Функциональная модель, преобразовывается в нормализированную
реляционную. Такой подход чаще используется припостроение больших баз данных
для крупных информационных систем. [8]
Исходя из вышеперечисленного можно сделать выбор в пользу реляционной
базы данной, она легко корректируется, удобна в использование и проста по своей
структуре.
Весь цикл обработки заказов состоит из двух этапов:
• Получение, обработка и ввод начальной входящей информации (данные
пользователей, оргтехники, управлений компании);
• Составление документов (списков заявок и так далее).
Обработка входящих документов включает в себя:
· прием и первичную обработку документов;
· предварительное рассмотрение и распределение документов;
· рассмотрение документов руководством;
· передачу на исполнение.
Идентификация унифицированной формы проводится через классификацию
(классификаторы инцидентов, классификатор комплектующих).
В проектном решении будет использована операционная система семейства
MicrosoftWindows10. Данная ОС достаточно надежна, за время ее существования
показала себя как постоянно обновляемая и удобная для пользователей. Помимо
этого все специализированное программное обеспечение, используемое на
предприятие, разработано именно под Windows, что делает проблематичным
использование его под другие операционные системы. ОС включает в себя все
модификации предыдущих версий этого семейства, плюс добавление новых
функциональных возможностей, позволяющих быстрее и качественнее обрабатывать
информацию. Windows7 имеет «дружественный» интерфейс, понятный
пользователям.
Система управления базами данных (СУБД) – специализированная программа,
предназначенная для создания и ведения баз данных.
СУБД подразделяются на 3 вида:
1. Файл – серверные СУБД.
Все файлы хранятся на Файл-сервере. Сама СУБД располагается на клиентской
машине и с нее же функционирует. Доступ осуществляется через локальную сеть (в
случае если Файл-сервер и компьютер, на котором установлена СУБД являются
разными машинами). Преимущество данной архитектуры – низкая нагрузка на
центральный процессор сервера. ИЗ примеров таких СУБД - MicrosoftAccess,
BorlandParadox
2. Клиент-серверные СУБД.
СУБД такого уровня состоят из двух частей: клиентской и серверной.
Клиентская часть входит в состав прикладной программы. Такие СУБД обеспечивают
разграничение прав доступа к информации и практически не загружают сеть. В
настоящее время клиент-серверные СУБД одни из самых популярных, на рынке
представлены десятки различных вариантов. Вот некоторые из них: Firebird, Interbase,
MSSQLServer, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.
3. Встраиваемые СУБД.
Встраиваемый СУБД представляют собой библиотеку, которая позволяет
специальных образом хранить большие объемы данных на локальной машине. Доступ
к таким данным осуществляется либо через SQL, либо через функции СУБД. Вот
несколько примеров таких СУБД: OpenEdge, SQLite, BerkeleyDB, MySQL [5]
Все компьютеры в организации объединены в локально-вычислительную сеть,
что позволяет им обмениваться информацией друг с другом. Существование такой
сети позволит использовать клиент-серверную СУБД MySQL. Выбор остановился
именно на ней в связи со следующими факторами: в организации имеется
сертифицированный персонал, который может своимисилами корректировать и вести
базу данных. Помимо этого эта СУБД является достаточно надежной и предоставляет
возможность хорошей защиты хранимой и обрабатываемой информации.
2.1.2 Обоснование проектных решений по программному обеспечению
В настоящее время актуальной версией данной СУБД является 5.6.
Преимущества MySQL[9]:
наилучшая скорость обработки данных на объеме до 500000 записей;
бесплатные открытые лицензии;
простота использования;
поддержка большинством хостинговых компаний;
возможность использования на различных платформах (Unix, Windows,
др.).
Специальное (прикладное) программное обеспечение предназначено для
решения прикладных задач. Рассмотрим основное программное обеспечение,
используемое при реализации проекта.
Для реализации приложения пользователя выбран язык программирования
PHP.
PHP — это язык программирования для динамической генерации HTML кода
со стороны сервера. В нём имеется встроенная поддержка базы данных MySQL, что
позволяет считать выбранную связку MySQL-PHP наиболее оптимальной. PHP-
скрипты интерпретируется и выполняются на сервере[3].
2.1.3 Обоснование проектных решений по техническому обеспечению
Для достижения наилучшего результата, серверную и клиентскую часть
необходимо объединить в единую локальную сеть, а для обеспечения желаемого
результата связь необходимо осуществить на основе технологии Ethernet, пропускная
способность сети должна быть не менее 100 Мб/сек.
Техническое обеспечение серверной части.
Выбор предлагается произвести из серверов средней ценовой категории.
Интересующие характеристики:
процессор IntelCore 2 2.2 GHz или выше;
оперативная память не менее 4.00 Гб;
Жесткие диски не менее двух с объёмом от 500 Гб;
Материнская плата с технологией RAID;
Цена до 1500 у.е.
Выбор сервера предложен в таблице 1.5.
Таблица 0.6
Выбор сервера
Фирма
Процессор
ОЗУ
Жесткий
диск
RAID
Цена($)
ASUS
2.4
4.00
2*500Гб
+
1270
HP
2.2
4.00
2*1Тб
+
1490
Gigabyte
2.6
4.00
2*1Тб
+
1241
Был выбран сервер фирмы Gigabyte, так как он полностью отвечает
требованиям для внедрения системы обработки заявок.
Техническое обеспечение клиентской части.
Для организации рабочей станции понадобятся:
Процессор не ниже Pentium 4 1,2 Ghz;
Материнская плата со встроенной видеокартой и Lan;
Жесткий диск не менее 40 Гб;
Оперативная память не менее 512 Мб;
Монитор LCD с диагональю 19 дюймов;
Мышь;
Клавиатура.
Рабочими станциями со сходными параметрами сотрудники компании уже
оснащены, поэтому закупка дополнительных клиентских рабочих мест не
потребуется. Также в наличии есть и многофункциональные устройства, что
позволяет не закупать новое оборудование этого типа.
2.2 Разработка проекта автоматизации
2.2.1 Этапы жизненного цикла проекта автоматизации
Этапы жизненного цикла РПА:
Этап 1 - Идентификация
Стратеги и архитекторы RPA определяют бизнес-процесс с бизнес-командами
для разработки RPA. Разработка следует гибкой и индивидуальной методологии.
Этап 2 - Обнаружение / Анализ
. Архитектор процессов анализирует и идентифицирует требования клиентских
процессов. Степень автоматизации определяется этим анализом и сложностью
процесса. Преимущества / результаты автоматизации, таким образом, выделяются
автоматически.
Этап 3 - Проектирование
На основе анализа требований архитекторы процессов и технические
специалисты создают PDD (документ определения процесса), в котором описывается
информация о каждом этапе каждого процесса. Следующим шагом является создание
диаграммы объектной модели или блок-схемы, чтобы понять ход процесса. Как
только блок-схема будет готова, будет выбран инструмент RPA для автоматизации
процесса.
Этап 4 - Разработка
В процессе / фазе разработки сценарии и коды автоматизации создаются
разработчиками с помощью выбранных инструментов RPA (UiPath, Blue Prism и т. Д.)
И технологий наряду со ссылкой на PDD.
Этап 5 - Тестирование Тестирование
после разработки проводится командой тестирования, которая включает в себя
контроль качества, подобный нормальному потоку SDLC. Лучше всего иметь
специальную команду тестирования для выполнения QA. Бот тестируется в пред-
производственной среде, чтобы убедиться, что он работает в соответствии с
требованием, которое заключается в автоматизации конкретной задачи.
Этап 6 - Внедрение
После того, как все компоненты собраны, следует провести модульное
тестирование. Все компоненты протестированы, чтобы сгладить интеграцию. Если
при диагностике возникают какие-либо проблемы, бот возвращается к командам
разработчиков и тестировщиков для разрешения. Рекомендуемая архитектура UiPath
включает в себя среды разработки и тестирования, которые позволяют тестировать
процессы вне систем реального времени.