Размещено на http://www.allbest.ru/

функциональные требования для информационной системы компании «доставка»



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

Предметом исследования является компания, предоставляющая услуги по перевозке - «Доставка».

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

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

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



Введение

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

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

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

Объектом исследования является деятельность компании «Доставка».

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

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

описать деятельность и структуру исследуемой компании;

описать и смоделировать основные бизнес-процессы компании;

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

на основе метода анализа иерархий выявить наиболее важный бизнес-процесс для его дальнейшей автоматизации;

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



Глава 1. Анализ методик управления требованиями

1.1 Задачи управления требованиями

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

Разработка требований является важной и неотъемлемой частью разработки и внедрения информационной системы. Разработанные в соответствии с распространенным стандартом качества IEEE 830-1998, функциональные требования дают следующие преимущества:

· высокое качество требований к проекту;

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

· понижение количества доработок;

· повышение скорости разработки системы;

· соблюдение сроков плана проекта;

· уменьшение затрат на поддержку и обслуживание системы;

· упрощение процесса и уменьшение сроков написания сценариев тестирования;

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

1.2 Важность разработки качественных требований

информационный система организационный взаимодействие

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

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

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



Рисунок 1 - Относительная стоимость исправления ошибок в требованиях

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

1.3 Классификация требований

Согласно Карлу ВигерсуКарл И. Вигерс «Разработка требований к программному обеспечению» Русская редакция, 2004 требования к ИС делятся на следующие уровни:

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

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

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

нефункциональные требования - требования, определяющие работу системы в целом. Нефункциональные требования включают в себя:

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

o внешние системы и интерфейсы

o ограничения

o атрибуты качества - дополнительное описание характеристик системы, значимые для пользователей и разработчиков. [1]

1.4 Показатели качества требований к ИС

Помимо состава требований необходимо определить критерии их качества. Характеристики качественных требований к внедряемой информационной системе могут быть следующими [2]:

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

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

3. Единичность - одно требование описывает одну единственную вещь.

4. Завершенность - вся необходимая информация имеется в требовании, требование находится в одном разделе.

5. Последовательность - согласованность всех требований между собой, соответствие с внешней документацией.

6. Актуальность - требование не становится устаревшим с течением времени.

7. Выполнимость - возможность реализации требования в условиях работы и ограничениях системы.

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

9. Атомарность - требование не может быть разбито на более детальные без потери завершенности.

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

Кроме характеристик самих требований можно определить характеристики спецификации требований:

1. Полнота - максимальное покрытие необходимой функциональности.

2. Согласованность - непротиворечивость

3. Возможность модификации

4. Трассируемость - возможность проведения анализа, проверки корректности реализации.

1.5 Процессы разработки требований к ИС

В создании требований могут быть выделены четыре основных этапа:

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

2. Анализ требований - детализация, обеспечивающая одинаковое понимание требований всеми заинтересованными лицами и проверка наличия ошибок.

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

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

Выявление требований

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

Также существуют такие источники данных для сбора требований как:

1. Законодательные основы, оказывающие влияние на деятельность компании

2. Внутренние нормы и документы, влияющие на деятельность компании - корпоративные стандарты предприятия

3. Внутреннее устройство организации

4. Бизнес-процессы компании

5. Отчеты по использованию уже существующих на предприятии программных и аппаратных средств

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

· определить процесс формулирования требований;

· определить образ и четкие границы проекта;

· разграничить классы пользователей;

· выбрать сторонника данного продукта;

· создать фокус группы;

· определить с заказчиком назначение и цели продукта;

· проводить с заказчиком совместные семинары;

· проводить наблюдения за пользователями для анализа необходимости применения продукта;

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

Анализ требований

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

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

Документирование требований

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

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

Стандартами, которые обычно используются для регламентирования этапа Документирование требований, являются: ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», стандарт IEEE 830-1998 и ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению».

Проверка требований

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

1.6 Выводы по первой главе

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

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

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



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

2.1 Краткая характеристика компании

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

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

ООО «Доставка» было образовано в 1996 году и начало свою деятельность с доставки обычных грузов по Москве. С течением времени компании удалось расширить спектр услуг и выйти на рынок междугородней доставки.

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

ООО «Доставка» имеет центральный офис в Москве и 7 региональных филиалов в различных федеральных округах Российской Федерации. Компания имеет широкую сеть автомобильных маршрутов.

2.2 Описание статической модели компании

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



2.3 Организационная структура компании

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

Существует несколько видов организационных структур: линейные, функциональные, линейно-функциональные, дивизиональные, адаптивные[3].

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

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

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

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

· отдел информационных технологий и телекоммуникаций;

· отдел развития и маркетинга;

· отдел логистики;

· отдел охраны.

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

· бухгалтерия;

· юридический отдел;

· отдел по персоналу.

Организационная структура центрального офиса компании «Доставка» представлена на рисунке 2.

Рисунок 2 - Организационная структура центрального офиса компании «Доставка»

Руководитель филиала осуществляет руководство деятельностью регионального филиала компании «Доставка». На втором уровне находятся начальники следующих профильных отделов:

· финансовый отдел;

· бухгалтерия;

· отдел по персоналу;

· отдел по обучению;

· производственный отдел;

· отдел организации перевозок;

· отдел обработки.

Организационная структура регионального филиала компании «Доставка» представлена на рисунке 3.

Рисунок 3 - Организационная структура регионального филиала компании «Доставка»

2.4 Функциональная структура

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

Функциональная структура компании «Доставка» представлена на рисунке 4.

Рисунок 4 - Функциональная структура компании «Доставка»

2.5 Производственная структура компании

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

К основному производству относятся: производственный отдел, отдел организации перевозок, логистика.

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

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

Производственная структура компании «Доставка» представлена на рисунке 5.

Рисунок 5 - Производственная структура компании «Доставка»

2.6 Взаимодействие организационных единиц предприятия

Таблица 1 - Матрица ответственности компании «Доставка»

Матрица ответственности

Бухгалтерский учет

Финансовый учет

Информационно- техническое обеспечение

Развитие и управление персоналом

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

Прием отправлений

Обработка и сортировка отправлений

Выдача отправлений на маршрут

Оптимизация и поддержка маршрутов

Анализ затрат

Разработка и внедрение новых технологий

Прием и выдача автомобилей

Техническое обслуживание

Обработка данных по каждому автомобилю

Перевозка и доставка

Поддержка маршрутов

Мониторинг отправлений

Финансовый отдел

Х

Бухгалтерия

Х

Отдел по персоналу

Х

Отдел по обучению

Х

Отдел информационных технологий и телекоммуникаций

Х

Автобаза

Х

Х

Х

Отдел развития и маркетинга

Отдел обработки

Х

Х

Х

Отдел перевозок

Х

Отдел организации перевозок

Х

Логистика

Х

Х

Х

Х

2.7 Схема функциональных взаимодействий

В данном разделе указывается состав функциональной структуры компании, взаимодействие ее функциональных элементов. Данная схема выполнена в нотации IDEF0 и представляет основные направления деятельности компании. Схема функциональных взаимодействий компании «Доставка» представлена на рисунке 6.

Рисунок 6 - Схема функциональных взаимодействий компании «Доставка»

2.8 Описание динамической модели компании (модели бизнес-процессов)

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

Бизнес-процессы компании «Доставка» будут смоделированы в нотации описания бизнес-процессов «BPMN». BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) -- система условных обозначений (нотация) для моделирования бизнес-процессов [5].

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

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

· подготовка консолидированных финансовых данных.

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

2.9 Доставка отправлений

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

Бизнес-процесс «Доставка отправлений» представлен на рисунке 7.

Рисунок 7 - Модель бизнес-процесса «Доставка отправлений»

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

· отсутствует возможность мониторинга отправлений на всех этапах процесса доставки, а также доведения оперативной информации до отправителя о вручении отправлений получателю;

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

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

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

· в имеющейся системе мониторинга отсутствует единый справочник маршрутов;

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

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



2.10 Подготовка консолидированных финансовых данных

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

Бизнес-процесс «Подготовка консолидированных финансовых данных» представлен на рисунке 8.

Рисунок 8 - Модель бизнес-процесса «Подготовка консолидированных финансовых данных»

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

· нет единого источника финансовых данных;

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

· большие временные затраты на подготовку финансовых данных;

· большая вероятность расхождений в данных.

2.11 Выводы по второй главе

Объектом исследования является компания ООО «Доставка» - компания, занимающаяся приёмом, обработкой, хранением и доставкой стандартной корреспонденции и грузов, ценных посылок, опасных отправлений.

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

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

· подготовка консолидированных финансовых данных.

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

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



Глава 3. Разработка требований к системе

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

3.1 Описание метода анализа иерархий

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

В методе анализа иерархий Томас Саати использует математическую обработку экспертных оценок на основе матричных вычислений и аддитивной свертки критериев [6].

Для решения задач многокритериального уровня необходимо:

1. Построить качественную модель выбора в виде иерархии, которая должна включать цель - вершина иерархии, критерии для оценки качества альтернатив - средний уровень и альтернативные варианты для достижения цели - нижний уровень иерархии

2. Использовать метод парных сравнений для определения приоритетов критериев для оценки качества альтернатив и оценки каждой альтернативы по критериям

3. Провести подсчет глобальных приоритетов альтернатив

4. Принять решение, основываясь на полученных результатах

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

После формирования иерархической структуры необходимо определить экспертные оценки для критериев и альтернатив[7].

Для формирования оценок экспертов в данном методе вводится специальная шкала оценок - шкала относительной важности приоритетов, которая представлена в таблице 2.

Таблица 2 - Шкала относительной важности приоритетов

Значения	Определение
1	Значение не существенно
3	Небольшое значение
5	Большое значение
7	Значительное значение
9	Максимальное значение
2, 4, 6, 8	Промежуточные значения между двумя смежными суждениями

После определения экспертных оценок строится матрица попарных сравнений размерности n x n:



,

Где = a (для i, j = 1, 2,…, n ) отношения между весами и суждениями a i, j.

Далее для каждой матрицы определяется нормализованный вектор локальных приоритетов с компонентами:

,

где n размерность матрицы -- aji элемент -j-ой строки матрицы. Таким образом, матрице Wi сопоставляется вектор ai. Компоненты нормируются с помощью деления каждой компоненты вектора ai на сумму всех компонент этого вектора:

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

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

Далее вычисляется индекс согласованности:

ИС = ( лmax ?n)/( n?1)

После этого вычисляется отношение согласованности (ОС) - Отношение ИС к среднему случайному индексу (СИср) согласованности для матрицы того же порядка.

ОС = ИС/СИср.

Ниже представлена таблица со средними значениями СИ.

Таблица 3 - Таблица средних значений СИ

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0,00 0,00 0,58 0,90 1,12 1,24 1,32 1,41 1,45 1,49 1,51 1,48 1,56 1,57 1,59

Значение ОС меньшее или равное 0,10 считается приемлемым, если же значение больше следует пересмотреть оценки приоритетов[8].

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

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

После изучения метода МАИ, разработанного Томасом Саати, необходимо применить его для решения задачи, представленной в данном проекте - определение бизнес-процесса для автоматизации.

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

1. Степень важности для бизнеса

2. Ключевой процесс или, если нет, то степень его воздействия на ключевые процессы

3. Степень влияния процесса на конкурентоспособность компании

4. Заинтересованность владельца бизнес-процесса в прозрачности и лучшей координации работ через автоматизацию

5. Количество узких мест в бизнес-процесс

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

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

1. Доставка отправлений

2. Консолидация финансовых данных

Для построения матрицы попарных сравнений критериев и альтернатив был проведен опрос среди экспертов компании «Доставка» для определения оценки критериев и альтернатив. Эксперты формировали оценки, опираясь на шкалу относительной важности приоритетов (Таблица 2). Ниже представлена матрица попарных сравнений для критериев с числовыми оценками. Для вычисления всех значений использовалась программа MS Excel.



Таблица 3 - Матрица попарных сравнений для критериев

КРИТЕРИИ	Степень важности	Ключевой процесс	Конкурентоспособность	Прозрачность	Количество проблем
Степень важности	1	3	5	6	7
Ключевой процесс	1/3	1	1	7	6
Конкурентоспособность	1/5	1	1	5	5
Прозрачность	1/6	1/7	1/5	1	3
Количество проблем	1/7	1/6	1/5	1/3	1

Отношение согласованности для данных значений будет равно 9,66%, что считается приемлемым.

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

Таблица 4 - Матрица попарных сравнений альтернатив для критерия «Степень важности»

	Доставка	Консолидация	Нормализованные оценки вектора приоритета
Доставка	1	8	0,696730
Консолидация	1/8	1	0,303270

Таблица 5 - Матрица попарных сравнений альтернатив для критерия «Ключевой процесс»

	Доставка	Консолидация	Нормализованные оценки вектора приоритета
Доставка	1	9	0,812268
Консолидация	1/9	1	0,187732



Таблица 6 - Матрица попарных сравнений альтернатив для критерия «Конкурентоспособность»

	Доставка	Консолидация	Нормализованные оценки вектора приоритета
Доставка	1	7	0,875000
Консолидация	1/7	1	0,125000

Таблица 7 - Матрица попарных сравнений альтернатив для критерия «Прозрачность»

	Доставка	Консолидация	Нормализованные оценки вектора приоритета
Доставка	1	1	0,500000
Консолидация	1	1	0,500000

Таблица 8 - Матрица попарных сравнений альтернатив для критерия «Количество проблем»

	Доставка	Консолидация	Нормализованные оценки вектора приоритета
Доставка	1	6	0,857143
Консолидация	1/6	1	0,142857

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



Таблица 9 - Таблица итоговых значений

Альтернативы	Критерии
	Степень важности	Ключевой процесс	Конкурентоспособность	Прозрачность	Количество проблем
	Численное значение вектора приоритета
0,489989	0,228846	0,186257	0,057716	0,037192
Доставка	0,696730	0,812268	0,875000	0,500000	0,857143
Консолидация	0,303270	0,187732	0,125000	0,500000	0,142857

Исходя из данных таблицы итоговых значений, можно сделать вывод, что значение глобального приоритета бизнес-процесса «Доставка отправлений» больше, чем значения бизнес-процесса «Консолидация финансовых данных». Соответственно для решения данной задачи необходимо выбрать бизнес-процесс «Доставка отправлений» и автоматизировать именно его.

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

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

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

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

1. Повышение эффективности процессов, связанных с мониторингом транспорта и отправлений

2. Повышение контроля над процессами доставки отправлений

3. Реализация доведения оперативной информации до отправителя о вручении отправлений получателю

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

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

3.3 Разработка требований

В рамках применения метода анализа иерархий был выбран бизнес-процесс «Доставка отправлений» для автоматизации. Далее необходимо сформировать требования для внедрения информационной системы.

Бизнес-требования:

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

· повышение эффективности работы с клиентом;

· повышение контроля над бизнес-процессом;

· сокращение ручной обработки информации.

Пользовательские требования:

· простота обучения работе с решением;

· интуитивно понятный интерфейс;

· удобство пользования;

· стабильность работы.

Нефункциональные требования:

отказоустойчивость;

надежность;

масштабируемость;

простота сопровождения;

удобство использования;

защищенность;

соответствие стандартам;

отказоустойчивость и устойчивость к ошибкам;

работоспособность;

переносимость;

документируемость.

Для разработки функциональных требований необходимо построить и описать модель бизнес-процесса «как должно быть».

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

Бизнес-процесс «Доставка отправлений» представлен на рисунке 11.



Рисунок 11 - Модель бизнес-процесса «Доставка отправлений» (как должно быть)

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

Таблица 10 - Разработка функциональных требований

Название функционального требования	Автоматизируемое узкое место в БП	Автоматизированный участок процесса
Учет отправлений - регистрация отправления, его времени получения, адреса нахождения отправления, адреса назначения	Отсутствие единого массива данных мониторинга
Расчет времени доставки и выявление отклонений от сроков	Отсутствие единого справочника маршрутов; отсутствие возможности мониторинга отправлений на всех этапах процесса доставки
Мониторинг статуса отправления	отсутствие возможности мониторинга отправлений; информация может быть получена только с помощью телефонного звонка и ничем не подтверждается
Заполнение курьером статуса о доставке в системе своевременно после выполнения заказа	Невозможность заполнения статуса о доставке до возвращения в офис
Отслеживание местоположения транспорта, отправления и сотрудника, выполняющего транспортировку	Отсутствие возможности мониторинга отправлений на всех этапах процесса доставки, а также доведения оперативной информации до отправителя о вручении отправлений получателю; отсутствие возможности фиксации техническими средствами местоположения курьера
Поиск отправлений в единой системе	Отсутствие единого массива данных мониторинга, сложность получения агрегированных, отчетных и аналитических данных
Получение информации о дате и времени приёма, виде отправления, его приёмном номере	Отсутствие единого массива данных мониторинга, сложность получения агрегированных, отчетных и аналитических данных
Возможность получения отчетов по отдельному транспортному средству или по направлению со всем транспортом на нем	Отсутствие единого массива данных мониторинга, сложность получения агрегированных, отчетных и аналитических данных
Мониторинг клиентом статуса заявки и статуса отправления	Отсутствие возможности доведения оперативной информации до отправителя о вручении отправлений получателю
Актуальность и доступность информации об отправлении для клиента	Отсутствие возможности мониторинга отправлений и соответственно возможности доведения оперативной информации до отправителя о вручении отправлений получателю
Получение информации о режимах работы агрегатов и механизмов (обороты двигателя, разгоны/торможения и т.д.), наличии и расходе топлива, включении дополнительного оборудования.	Отсутствие единого массива данных мониторинга, сложность получения агрегированных, отчетных и аналитических данных

3.4 Обзор рынка систем GPS-мониторинга

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

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

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

· 1C:Предприятие 8. Центр спутникового мониторинга ГЛОНАСС/GPS

· GPS трекинг от GLOBAL HOUSE

· GPS трекинг от AvantTech

· Система GPS мониторинга от Kronas

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

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

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

Рисунок 12 - Схема обмена информацией в системе мониторинга транспорта

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

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

3.5 1C:Предприятие 8. Центр спутникового мониторинга ГЛОНАСС/GPS

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

Система спутникового мониторинга обладает следующими возможностями:

· контролировать текущее местоположение и пробег транспорта, курьера и отправления на маршруте мониторинг следования маршруту и фактического пробега объектов;

· контролировать фактический пробег транспорта;

· создавать отчетность по расходу топлива;

· возможность фиксации заправок и сливов топлива;

· мониторинг скоростного режима транспорта и превышение допустимого значения скорости;

· передача сигнала SOS с помощью тревожной кнопки;

· возможность передавать все данные с бортовых датчиков такие как: расход топлива, скорость движения, количество топлива, пробега, и т.д. с помощью взаимодействия с can-шиной;

· пресечение отклонений от маршрутов;

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

3.6 GPS трекинг от GLOBAL HOUSE

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

GPS трекинг от GLOBAL HOUSE позволяет:

· контролировать текущее местонахождение, скорость и маршрут транспорта;

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

o схема маршрута, парковки, остановки во время поездки и пробег;

o количество часов работы двигателя;

o необходимость ремонта.

· использование спутников автоматизирует расход топлива, используя следующие данные:

o количество часов работы двигателя;

o превышение допустимой скорости;

o расход топлива;

o карты и схемы маршрута.



3.7 GPS трекинг от AvantTech

Система спутникового мониторинга обладает следующими возможностями:

· Мониторинг. Отслеживание текущего местоположения, следования маршруту и скорости транспортных средств с помощью GPS и ГЛОНАСС навигации. Система GPS и ГЛОНАСС может отслеживать координаты расположения транспорта, курьера или отправление в режиме реального времени;

· Контроль. Мониторинг маршрута движения транспорта и пресечения попытки о...