IX Международная студенческая научная конференция Студенческий научный форум - 2017

Введение

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

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

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

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

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

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Анализ автотранспортного предприятия, основные характеристики и организационная структура

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

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

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

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

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

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

Главные задачи технической службы предприятия:

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

• главный инженер решает вопросы укрепления производственно-технической базы предприятия, выполняет допуск транспорта на линию;

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

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

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

Техническая служба имеет право контролировать техническое состояние подвижного состава, снимать его с эксплуатации, планировать и проводить технические осмотры, привлекать к материальной ответственности за неправильную эксплуатацию транспортного средства, а также лимитировать расходы ГСМ [²].

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

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

Бухгалтерия проводит учет наличия средств, выделенных на распоряжение предприятия, отвечает за их сохранность и за уровень их использования, проверяет финансовое состояние предприятия. Главный бухгалтер несёт ответственность за уместность и законность расходования средств [³].

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

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

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

1.2. Аналитический обзор существующих систем для автотранспортного предприятия

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

1.2.1. Программный продукт «1С: Предприятие 8. Управление автотранспортом. Стандарт»

Программа «1С:Управление автотранспортом Стандарт» состоит из восьми основных подсистем:

• Подсистема диспетчерская;

• Подсистема ПТО;

• Подсистема учета ГСМ;

• Подсистема учета ремонтов;

• Подсистема складского учета;

• Подсистема взаиморасчетов;

• Подсистема учета работы водителей;

• Подсистема учета затрат.

Подсистема «диспетчерская» предназначена для принятия заказов на автотранспорт, выписки разнарядки на выпуск ТС и формирование маршрутных листов, формирования и обработки путевых листов.

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

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

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

Подсистема учета ГСМ предназначена для настройки норм расхода ГСМ, учета поступления, выдачи и расхода ГСМ.

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

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

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

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

Расчет стоимости оказанных транспортных услуг выполняется при обработке путевых листов в товарно-транспортных документов (аналоги талонов заказчиков, ТТН). Программа автоматически рассчитывается стоимость услуг на основании введенных тарифов.

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

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

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

Прямые затраты определяются на основании путевых и ремонтных листов: стоимость ГСМ, стоимость ремонтов и технического обслуживания, износ автомобилей и шин. Кроме того отдельным документом можно учитывать любые другие затраты на автомобили [⁴].

Недостатки:

1. Отсутствие мониторинга в стандартной версии продукта. Есть возможность приобрести специальный модуль «1С: Предприятие 8. Центр спутникового мониторинга ГЛОНАСС/GPS», но его необходимо покупать отдельно для каждого рабочего места, либо приобрести профессиональную версию, которая уже включает этот модуль, что является почти в два раза дороже стандартной версии «1С:Предприятие 8. Управление автотранспортом»;

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

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

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

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

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

7. Громоздкость и сложность системы, которая включает множество багов [⁵].

1.2.2. Программный продукт «ПАРУС»

В программном продукте «ПАРУС» имеется модуль«Управление автотранспортом», который реализует функции учета и управления специфичными бизнес-процессами автотранспортных предприятий, возникающими при оказании услуг по перевозке грузов и пассажиров, а также услуг по предоставлению механизмов специального назначения (бурильные установки, снегоуборочные приспособления и т.д.) [⁶].

Работа с модулем обеспечивает:

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

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

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

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

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

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

• учет горюче-смазочных материалов по заправочным ведомостям и путевым листам;

• учет и обработку заявок заказчиков на транспортные средства с последующим формированием на их основе суточных планов;

• формирование и учет суточных планов автотранспортного предприятия с последующим формированием путевых листов;

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

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

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

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

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

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

• учет парка автомобилей, механизмов и агрегатов;

• сбор фактических данных по эксплуатации автотранспортных средств, т.е. учета пробега и моточасов работы по путевым листам [⁷].

Архитектура модуля «Управление автотранспортом» представлена на рисунке 1.3.

Рисунок 1.3 - Архитектура управления автотранспортом

Недостатки:

•  

  1. Отсутствие мониторинга транспортного средства;

  2. Отсутствие возможности анализа отклонений во время работы транспорта;

  3. Не предусмотрено введение учёта ПДД и выписанных штрафов для водителей;

  4. Не автоматизирован процесс планирования заявок;

  5. Возможность формирования только суточных планов;

  6. Нет возможности оформления заявки клиентом с помощью программы;

  7. Необходимо докупать отдельные модули;

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

1.2.3. Информационная система «Олимп»

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

Работа с модулем обеспечивает:

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

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

• учет эксплуатации прицепов и основного оборудования и агрегатов;

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

• контроль окончания сроков действия документов, выданных на водителей и транспортные средства (медицинские справки, полисы ОСАГО, талон ТО и др.);

• учет горюче-смазочных материалов по заправочным ведомостям и путевым листам;

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

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

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

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

• ведение картотеки учета шин и учет аккумуляторов, аптечек и произвольного оборудования;

• учета поступления, выдачи и расхода ГСМ. Расчет расхода топлива ведется в путевых листах [⁸].

Система имеет те же недостатки, что и у программного продукта «Парус»:

•  

  1. Отсутствие мониторинга транспортного средства;

  2. Отсутствие возможности анализа отклонений во время работы транспорта;

  3. Не предусмотрено введение учёта ПДД и выписанных штрафов для водителей;

  4. Не автоматизирован процесс планирования заявок диспетчером;

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

  6. Необходимо докупать отдельные модули;

  7. Нет возможности оформления заявки клиентом с помощью программы.

1.3. Окружение и функциональные требования, предъявляемые к автотранспортному предприятию

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

Рисунок 1.4 – Схема взаимодействия отделов АТП

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

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

На рисунке 1.5 представлена схема взаимодействия сотрудников отдела диспетчеризации при планировании заявки.

Рисунок 1.5 – Схема взаимодействия сотрудников отдела диспетчеризации

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

• Приём и обработка заявок;

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

• Планирование выпуска транспортного средства на линию;

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

• Допуск транспортного средства;

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

• Допуск водителя;

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

• Выпуск автомобилей с выпиской путевых листов;

Диспетчер выписывает разнарядку на выпуск транспортных средств, при этом формируя маршрутные и путевые листы. Затем передаёт путевые листы водителям.

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

• Выполнение перевозок грузов и пассажиров, оказание услуг спецтехникой;

• Анализ выполненных работ;

Диспетчер обрабатывает путевые листы при возвращении транспортных средств, введёт учёт поступления и расхода ГСМ.

1.4. Обоснование необходимости разработки интеллектуальной системы

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

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

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

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

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

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

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

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

1.5. Выводы по главе

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

1. Ускорить процесс подачи заявки клиентом;

2. Ускорить и сделать более удобным информирование клиента о статусе заявки;

3. Сделать работу компании более гибкой;

4. Автоматизировать процесс планирования заявки;

5. Повысить качество контроля работы водителей;

6. Автоматизировать процесс передачи заявки между сотрудниками предприятия;

7. Ускорить процесс заполнения путевых листов.

1. ПРОЕКТИРОВАНИЕ И МОДЕЛИРОВАНИЕ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ

2.1. Концептуальное моделирование автотранспортного предприятия

На рисунке 2.1 представлена концептуальная модель отдела диспетчеризации автотранспортного предприятия.

Рисунок 2.1 – Концептуальная модель отдела диспетчеризации

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

• информацию о клиентах (к какой организации относится клиент);

• информацию о заявках (дата, тип работы, пункт назначения и т.д.);

• характеристики автопарка (тип транспорта, модель транспорта, техосмотр, ремонт);

• информацию о водителях (расписание водителей);

• данные мониторинга (отклонения в работе транспорта).

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

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

2.2. Функциональное моделирование работы автотранспортного предприятия с использованием нотации eEPC

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

1.  
   1.  
      1.  
         1.  

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

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

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

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

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

            6. Благодаря мониторингу транспортного средства появятся следующие преимущества:

• появится возможность наблюдать за работой транспортного средства в реальном времени;

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

• появится возможность наблюдать отклонения в работе транспорта.

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

• Доступность – облака доступны всем из любой точки, где есть Интернет;

• Мобильность - сотрудники Компаний становятся более мобильными так, как могут получить доступ к своему рабочему месту из любой точки земного шара, используя ноутбук, нетбук, планшетник или смартфон;

• Круглогодичная безотказно устойчивая работа предприятия;

• Повышение безопасности за счет консолидации вычислительных ресурсов, сведение до минимума «человеческого фактора» и подотчетность пользователей к несанкционированному доступу в систему и скачиванию данных;

• Повышение качества предоставляемых ИТ-услуг при меньшем количестве высококвалифицированных специалистов;

• Экономия на внедрении системы на предприятии;

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

• Оперативное выборочное наращивание мощности [⁹].

Необходимо провести функциональное моделирование автотранспортного предприятия, прежде введя все вышеперечисленные задачи в работу АТП. Для проведения функционального моделирования автотранспортного предприятия была выбрана методологии ARIS, а метод описания eEPC (англ. extended event-driven process chain).

Методология ARIS реализует принципы структурного анализа и позволяет определить и отразить в моделях основные компоненты организации, протекающие процессы, производимую и потребляемую продукцию, используемую информацию, а так же выявить взаимосвязи между ними [¹⁰].

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

1. Клиент создает и отправляет заявку;

2. Система планирует заявку;

3. Диспетчер анализирует заявку;

4. Главный инженер проверяет работоспособность ТС;

5. Медработник проводит допуск водителя к работе;

6. Диспетчер выпускает ТС на линию;

7. Транспортировка автомобиля, прослеживание выполнения работы посредством мониторинга;

8. Диспетчер принимает ТС.

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

Рисунок 2.2 - Процесс выполнения заявки в методологии eEPC

Рисунок 2.3 - Планирование заявки

Рассмотрим подробнее допуск транспортного средства к работе. Когда клиент формирует заявку, он выбирает конкретный тип транспорта, который ему необходим для выполнения определенной работы. Главный инженер проверяет транспорт на работоспособность, не подходит ли время проведения ТО или не требуется ли ремонт. Приведем пример, клиент отправил заявку на строительство автокраном. Автокраны на предприятии ограничиваются двумя-тремя. Допустим, что в автопарке есть только один свободный автокран, но главный инженер обнаружил, что этот автокран в данный момент должен проходить плановый техосмотр. В таком случае выполнение данной заявки не возможно, и главный инженер её отклоняет. Далее главный диспетчер пытается подобрать транспортное средство из других автопарков (рисунок 2.4).

Рисунок 2.4 - Допуск транспортного средства

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

Рисунок 2.5 - Допуск водителя

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

Рисунок 2.6 - Выпуск транспортного средства

После завершения работы диспетчеры принимают транспортные средства, обрабатывают путевые листы, анализируют отклонения уровня топлива и т.д. Также формируются отчёты о проделанной работе, которые хранятся в базе (рисунок 2.6).

Рисунок 2.7 - Приём транспортного средства

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

Рисунок 2.8 - Техобслуживание

2.3. Описание модели разрабатываемой интеллектуальной системы с использованием методологии UML

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

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

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

Если требуется несколько ТС, то цикл подбора транспорта и водителя будет повторяться до тех пор, пока не подберётся необходимое количество.

Рисунок 2.9 – Алгоритм подбора транспорта и водителя

Для описания модели разрабатываемой системы была использована методология UML.

UML (англ. Unified Modeling Language) – унифицированный язык моделирования. Применяется для проектирования, визуализации и документирования информационных систем [¹¹].

Преимущества UML:

• Объектно–ориентированный язык;

• Позволяет описать систему со всех возможных точек зрения;

• Простота чтения диаграмм;

• Позволяет вводить собственные текстовые стереотипы.

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

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

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

На рисунке 2.11 представлена диаграмма вариантов использования системы. В овалах (сервисах) указаны функции предоставляемые системой для конкретного пользователя. Сама система представлена в виде прямоугольника. Отношения между пользователями и сервисами указаны простой линией.

Рисунок 2.11 - Диаграмма вариантов использования системы

Диаграмма последовательностей описывает взаимодействие между объектами в терминах обмена сообщениями во времени. Вертикальные прямоугольники или активации представляют собой время, необходимое объекту для выполнения задания. Вертикальные штриховые линии показывают присутствие объекта во времени и называются линиями жизни. Непрерывная стрелка представляет собой нормальный вызов процедуры, а штриховая стрелка представляет собой возврат сообщения. На рисунке 2.12 представлена диаграмма последовательности выполнения заявки [¹²].

Рисунок 2.12 - Диаграмма последовательности выполнения заявки

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

Рисунок 2.13 - Диаграмма взаимодействия сервера и браузера

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

В качестве языка программирования был выбран объектно-ориентированный язык C#.

С# разработан в 1998—2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework и впоследствии был стандартизирован как ECMA-334 и ISO/IEC 23270.

C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java.

Переняв многое от своих предшественников — языков C++, Pascal, Модула, Smalltalk и, в особенности, Java — С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем, например, C# в отличие от C++ не поддерживает множественное наследование классов (между тем допускается множественное наследование интерфейсов).

Язык C# является молодым языком и продолжает интенсивно развиваться. Каждая новая версия языка включает принципиально новые свойства.

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

• С# применим ко многим операционным системам, в том числе к Windows, Linux, Mac OS, Apple iOS и другие.

• C# создавался и развивается параллельно с каркасом Framework.Net и в полной мере учитывает все его возможности;

• C# является полностью объектно-ориентированным языком;

• C# является мощным объектным языком с возможностями наследования и универсализации;

• C# является наследником языка C++. Общий синтаксис, общие операторы языка облегчают переход от языка С++ к C#. Сохранив основные черты своего родителя, язык стал проще и надежнее;

• C# поддерживается средой разработки Visual Studio. Visual Studio предоставляет полный функционал для удобной и продуктивной работы с языками семейства С.

Благодаря каркасу Framework.Net, ставшему надстройкой над операционной системой, программисты C# получают преимущества работы с виртуальной машиной. Framework.Net поддерживает разнообразие типов приложений на C# [¹³].

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

Для работы на С# был выбран такой инструмент линейки Microsoft, как Visual Studio 2013 Professional.

Microsoft Visual Studio — линейка продуктов компании Microsoft, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Windows, Windows Mobile, Windows CE, .NET Framework, Xbox, Windows Phone.NET Compact Framework и Silverlight.

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

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

Visual Studio включает функцию поддержки нескольких мониторов, которая позволяет наиболее удобно организовать работу. Также Visual Studio можно использовать для реализации идей и решений для широкого спектра платформ, включая Windows, Windows Server, веб-среду, облачную среду, Office и SharePoint и многое другое [¹⁴].

Преимущества Visual Studio:

• Быстрое создание высококачественного кода;

• Функция поддержки нескольких мониторов;

• Использование вычислительных мощностей локального компьютера и облака;

• Простая реализация общих задач и индивидуальный подход;

• Возможность реализации идей и решений для широкого спектра платформ.

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

База данных - это специально разработанное хранилище для различных типов данных. Каждая база данных, имеет определённую модель (реляционная, документно-ориентированная), которая обеспечивает удобный доступ к данным. Системы управления базами данных (СУБД) - специальные приложения (или библиотеки) для управления базами данных различных размеров и форм.

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

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

PostgreSQL - это мощная объектно-реляционная система управления базами данных с открытыми исходными текстами. Она разрабатывается на протяжении более 15 лет и улучшает архитектуру, чем завоевала репутацию надежной, интегрированной и масштабируемой СУБД. PostgreSQL запускается на всех основных платформах, включая Linux, UNIX и Windows.

Сильными сторонами PostgreSQL считаются:

• поддержка БД практически неограниченного размера;

• мощные и надёжные механизмы транзакций и репликации;

• расширяемая система встроенных языков программирования;

• наследование;

• легкая расширяемость.

PostgreSQL свободно распространяемая СУБД и максимально соответствует стандартам SQL. PostgreSQL или Postgres стараются полностью применять ANSI/ISO SQL стандарты своевременно с выходом новых версий.

От других СУБД PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, полная поддержка надежных транзакций, т.е. атомарность, последовательность, изоляционность, прочность (Atomicity, Consistency, Isolation, Durability (ACID).) Благодаря мощным технологиям Postgre очень производительна. Параллельность достигнута не за счет блокировки операций чтения, а благодаря реализации управления многовариантным параллелизмом (MVCC), что также обеспечивает соответствие ACID. PostgreSQL очень легко расширять своими процедурами, которые называются хранимые процедуры. Эти функции упрощают использование постоянно повторяемых операций.

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

PostgreSQL обеспечивает надежность и целостность данных, а также имеет встроенную поддержку для пользовательский процедур. По сравнению с другими открытыми СУБД PostgreSQL предоставляет больше возможностей для создания сложных структур данных без необходимости, жертвовать какими либо аспектами [¹⁵].

Достоинства PostgreSQL:

• Открытое ПО соответствующее стандарту SQL - PostgreSQL - бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой;

• Большое сообщество - существует довольно большое сообщество в котором вы запросто найдёте ответы на свои вопросы;

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

• Расширения - существует возможность расширения функционала за счет сохранения своих процедур;

• Объектность - PostrgreSQL это не только реляционная СУБД, но также и объектно-ориентированная с поддержкой наследования и много другого.

2.6. Создание логической модели данных

Выделим следующие сущности базы данных (таблица 2.1):

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

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

Водители - полная информация о водителях, а так же привязка к автопарку;

Расписание водителей – график работы водителей и их смены;

Автопарки - список всех автопарков предприятия;

Ремонты - список транспортных средств находящихся на ремонте, а так же типы ремонта;

Техосмотр – список транспортных средств проходящих техосмотр;

Заявки – все данные по заявке;

Статус заявки – список всех возможных статусов заявки;

Организации – список организаций, с которыми работает предприятие.

Ниже на рисунке 2.14 представлена схема взаимодействия сущностей:

Рисунок 2.14 – Схема взаимодействия сущностей

Таблица 2.1 – Атрибуты и первичные ключи сущностей информационной модели

Сущность	Первичный ключ	Атрибуты
Autoparks (Автопарки)	AutoparkId	AutoparkId – код автопарка; Name – наименование автопарка; Address – адрес.
BidSeviceStatuses (статусы заявок)	BidSeviceStatusId	BidSeviceStatusId – код статуса заявки; Name – наименование статуса заявки.
BidServices (обслуживание заявок)	BidServiceId	BidServiceId – код операции над заявкой; BidId – код заявки; CarTypeId – код типа транспорта; CarId – код ТС; DriverId – код водителя; ServiceName – тип работы; Destination – пункт назначения; WorkTimeBegin – начало работы; WorkTimeEnd – окончание работы; Responsible – ответственный; BidServiceStatusId – код статуса заявки; AutoparkId – код автопарка; CarModelId – код модели ТС.
Bids (заявки)	BidId	BidId – код заявки; CreateDate – дата создания заявки; OrganizationId – код организации.
CarMaintenances (ТО транспорта)	CarId MaintenanceId	CarId – код ТС; MaintenanceId – код ТО; LastValueDate – дата последнего ТО; LastValueLengthInKm – значение пробега машины при последнем ТО.
CarModels (модели ТС)	CarModelId	CarModelId – код модели ТС; Name – наименование модели ТС.
CarTypes (типы трансопрта)	CarTypeId	CarTypeId – код типа транспорта; Name – наименование типа транспорта.
Cars (ТС)	CarId	CarId – код ТС; StateNumber – гос. номер ТС; CarTypeId – код типа транспорта; CarModelId – код модели ТС; IsDeleted – ячейка для изъятия ТС из системы; Vin – vin код ТС; ReleaseYear – год выпуска; Engine number – номер двигателя; ChassisNumber – номер шасси; BodyNumber – номер кузова; ColorName – цвет машины; PassportNumber – номер паспорта; PassportReleaseDate – дата выпуска паспорта; OldStateNumber – старый гос. номер; RegistrationDate – дата регистрации; GarageNumber – номер гаража; StateNumberRegion – гос. региональный норер; FuelNorm – норма топлива; TSCategory – категория ТС; EnginePower – мощность двигателя; EngineType – тип двигателя; EcologicClass – класс экологичности; MaxMass – максимальная масса; UnladenMass – масса без нагрузки; NumberTdTpo – номер ТД и ТПО; CarMfr – производитель авто; OutputCountry – страна в которой был выпущен транспорт.
CarsInAutoparks (ТС автопарка)	CarId AutoparkId	CarId – код ТС; AutoparkId – код автопарка.
Change (смена)	ChangeId	ChangeId – код смены; Name – наименование смены; SmallName – сокращенное наименование смены.
DriverCarTypes (категория транспорта водителя)	DriverId CarTypeId	DriverId – код водителя; CarTypeId – код типа транспорта.
Drivers (водители)	DriverId	DriverId – код водителя; FirstName – имя водителя; LastName – фамилия водителя; Patronymic – отчество водителя; CertificateNumber – номер водительского удостоверения; HireDate – дата выдачи; Post – разряд; ShelfLifeDate – дата окончания действия водительского удостоверения; FullCertificateData – полное описание удостоверения.
DriverInAutoparks (водители автопарка)	DriverId AutoparkId	DriverId – код водителя; AutoparkId – код автопарка.
DriversShedule (расписание водителей)	DriversSheduleId	DriversSheduleId - код расписания водителя; DriverId – код водителя; DayDate – дата; ChangeId – смена водителя.
Maintenances (техобслуживание)	MaintenanceId	MaintenanceId – код ТО; Name – наименование ТО; PeriodicityDate – периодичность проведения ТО по дате; PeriodicityLengthInKm – периодичность проведения ТО по пробегу.
Organizations (организации)	OrganizationId	OrganizationId – код организации; Name – наименование организации; Phone – телефон организации; Inn – ИНН организации; Kpp – КПП организации; Adress – адрес организации.
Repairs (ремонт)	RepairId	RepairId – код ремонта; RepairTypeId – код типа ремонта; CarId – код ТС; DriverId - код водителя; Description – описание ремонта; StartDateTime – дата и время начала ремонта; EndDateTime – дата и время окончания ремонта.
RepairsTypes (типы ремонта)	RepairsTypeId	RepairsTypeId – код типа ремонта; Name – наименование ремонта.
Tariffs (Тарифы)	TariffId	TariffId – код тарифа; CarId – код ТС; Value – значение тарифа.

2.7. Создание физической модели данных

Далее на рисунках 2.20 – 2.33 приставлен физический вид всех таблиц информационно-логической модели.

Рисунок 2.20 - Физическая реализация таблицы «Модели машин» в PostgreSQL

Рисунок 2.21 - Физическая реализация таблицы «Типы машин» в PostgreSQL

Рисунок 2.22 - Физическая реализация таблицы «Машины» в PostgreSQL

Рисунок 2.23 - Физическая реализация таблицы «Машины автопарка» в PostgreSQL

Рисунок 2.24 - Физическая реализация таблицы «Смена» в PostgreSQL

Рисунок 2.25 - Физическая реализация таблицы «Категория транспорта водителя» в PostgreSQL

Рисунок 2.26 - Физическая реализация таблицы «Водители» в PostgreSQL

Рисунок 2.27 - Физическая реализация таблицы «Водители автопарка» в PostgreSQL

Рисунок 2.28 - Физическая реализация таблицы «Расписание водителей» в PostgreSQL

Рисунок 2.29 - Физическая реализация таблицы «Техобслуживание» в PostgreSQL

Рисунок 2.30 - Физическая реализация таблицы «Организации» в PostgreSQL

Рисунок 2.31 - Физическая реализация таблицы «Ремонты» в PostgreSQL

Рисунок 2.32 - Физическая реализация таблицы «Типы ремонтов» в PostgreSQL

2.8. Выводы по главе

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

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

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

1. РАЗРАБОТКА ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ

3.1. Структура системы и её модули

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

1. web-сервер, для обмена данными;

2. база данных, для хранения данных;

3. браузер, для работы с системой.

Общая схема работы системы наглядно представлена на рисунке 3.1.

Рисунок 3.1 – Общая схема работы системы

Система имеет следующие модули:

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

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

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

• Учёт ГСМ - данный модуль предназначен для учета поступления и расхода ГСМ автотранспортом предприятия. Учет осуществляется на уровне обработки путевых листов так и на данных поступающих из GPS/ГЛОНАСС трекеров. Нормативный расход считается согласно нормам расхода, которые настраиваются в справочнике. Есть возможность настроить нормы расхода топлива для конкретного транспортного средства.

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

1.  
   1. Реализация системы
      1. Работа с пользователями и организациями в системе

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

В меню «Администрирование» помимо пункта «Пользователи», есть пункт «Клиенты и организации», в котором можно привязать пользователей с ролью «Клиент» к организациям, добавленным в систему (рисунок 3.5).

Рисунок 3.5 – Клиенты и организации

1.  
   1.  
      1. Работа с транспортными средствами

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

Для транспортного средства можно указать норму топлива, которая будет являться критерием при транспортировке (рисунок 3.7). Если при выполнении работы на данном транспортном средстве будет превышена норма, то модуль мониторинга сообщит об этом диспетчеру.

Рисунок 3.7 – Норма топлива

1.  
   1.  
      1. Работа с водителями

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

1.  
   1.  
      1. Административные единицы

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

• автоколонн;

• организаций;

• цехов;

• объектов на карте.

Пункт меню «Административные единицы» - «Управление автоколоннами» позволяет привязывать, а так же менять принадлежность водителей, транспортных средств и пользователей к автоколоннам.

Рисунок 3.9 – Привязка транспортных средств к автоколонне

Объекты на карте — это географические объекты одного из трех типов: объекты, азс и автопарки (рисунок 3.9).

Объекты — это рабочие объекты, на которые выезжает транспорт. Это могут быть скважины, или другие географические объекты.

Рисунок 3.10 – Объекты на карте

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

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

1.  
   1.  
      1. Техобслуживание

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

Рисунок 3.11 – Создание нового ТО

Далее открывается форма редактирования ТО, куда заносятся данные о проделанной работе. После завершения ТО или ремонта можно скачать лист завершенное ТО, который представлен на рисунке 3.12.

Рисунок 3.12 – Отчёт по ТО

1.  
   1.  
      1. Экономический отдел

Сотрудник экономического отдела занимается формированием отчётов.

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

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

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

3.3. Работа с заявками в системе 3.3.1. Создание заявки клиентом

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

Рисунок 3.16 – Добавление заявки клиентом

Далее откроется форма добавления заявки, которая представлена на рисунке 3.17.

Рисунок 3.17 – Форма добавления заявки

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

Рисунок 3.18 – Выбор типа техники

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

Рисунок 3.19 – Количество техники

Далее идет поле «Место дислокации», в котором может быть более одного географического объекта, на котором будут выполняться работы по создаваемой заявке. Если ранее объекты были добавлены в систему, то можно быстро и просто их найти - для этого нужно всего лишь начать набирать название объекта (рисунок 3.20).

Рисунок 3.20 – Место дислокации

В случае, если необходимый объект отсутствует в списке, всегда можно быстро и просто добавить его с помощью карты (рисунок 3.21).

Рисунок 3.21 – Добавление геоточки

Следующее поле на форме создания заявки — тип работ, это текстовое поле, куда нужно вписать тип работ для данной заявки на транспорт.

Рисунок 3.22 - Календарь

Два следующих поля — начало работы и окончание работы —используют календарь для удобства (рисунок 3.22).

Также имеется форма добавления заявки, где отображаются все созданные клиентом заявки на транспорт (рисунок 3.23).

Рисунок 3.23 – Добавленные заявки

Если заявка создается не от пользователя с ролью «Клиент», то будет запрошена организация, для которой создается заявка.

3.3.2. Планирование заявки

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

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

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

Если к заявке, по каким либо причинам невозможно назначить транспортное средство или водителя, то статус заявки меняется на «Невозможно выполнить».

3.3.3. Планирование диспетчером

Следующий шаг в цепочке планирования — планирование диспетчером.

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

Форма планирования диспетчером располагается в меню «Планирование» и выглядит следующим образом.

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

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

Также можно редактировать заявку, для этого нужно нажать на кнопку редактирования в столбце «Новый статус». При нажатии появится модальное окно, где нужно задать водителя и машину из одной автоколонны.

Система предлагает наилучшие варианты для выбора в выпадающем списке (рисунок 3.25).

Рисунок 3.25 – Выбор машины

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

Можно также отклонить заявку на транспорт, и указать для этого причину. Для этого нужно нажать на кнопку с крестиком в столбце «Новый статус» и в появившемся модальном окне ввести комментарий (рисунок 3.26).

Рисунок 3.26 – Комментарий к отклоненной заявке

3.3.4. Подтверждение главным инженером

Рисунок 3.27 – Подтверждение главным инженером

Главный инженер может подтвердить либо отклонить заявки на транспорт, используя кнопки в столбце «Новый статус», либо кнопки внизу таблицы «Принять все», «Отклонить все» (рисунок 3.27). После подтверждения заявки главным инженером, клиент автоматически уведомляется о принятии заявки.

3.3.5. Заявки клиента

Рисунок 3.28 – Статус заявок клиента

Для пользователей с ролью «Клиент» доступен пункт «Заявки клиента». Где можно просмотреть все заявки на организацию клиента. Данная форма необходима только для ознакомления клиентом со статусом своих заявок. Статус заявок представлен на рисунке 3.28.

3.3.6. Медицинское освидетельствование

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

Медицинский работник может подтвердить заявку либо отклонить ее, со своим комментарием относительно причин. Статус заявки автоматически меняется на «Подтверждена медработником».

3.3.7. Выпуск машин диспетчером

Рисунок 3.30 –Выпуск машин

Форма выпуска автотранспорта представлена на рисунке 3.30. В последнем столбце «Путевой лист» для каждой из заявок можно скачать как путевой лист, так и справку. Чтобы выпустить транспорт по заявке, необходимо в столбце «Новый статус» использовать кнопку с галочкой «Принять позицию».

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

3.3.8. Прием машин диспетчером

Рисунок 3.32 – Приём машин диспетчером

Чтобы принять транспорт, в столбце «новый статус» нужно нажать на кнопку с галочкой (рисунок 3.32). Появится модальное окно для ввода данных, куда нужно ввести действительные значения уровня топлива, показаний одометра, ГСМ, моточасов, в том числе время и дату выпуска транспорта, и время и даты приема транспортного средства. После нажатия кнопки «Сохранить» под формой ввода данных о транспорте, произойдет «прием» машины диспетчером. Статус заявки автоматически изменится на «Выполнена».

3.3.9. Работа с архивом заявок

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

3.3.10. Информация о проделанных рейсах

Форма информации о проделанных рейсах представлена на рисунке 3.35.

Рисунок 3.35 – Информация о рейсах

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

Рисунок 3.36 – Просмотр результатов

На открывшейся форме будет представлен подробный анализ выполненной заявки — будут указаны остановки, изменения уровня топлива, посещение геообъектов и текстовое описание проделанных действий.

3.4. Выводы по главе

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

1. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

1.  
   1. Понятие информационной безопасности

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

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

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

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

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

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

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

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

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

Угрозы можно классифицировать по нескольким критериям:

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

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

• по способу осуществления (случайные/преднамеренные, действия природного/техногенного характера);

• по расположению источника угроз (внутри/вне рассматриваемой ИС).

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

1. законодательный – законы, нормативные акты и прочие документы РФ и международного сообщества;

2. административный – комплекс мер, предпринимаемых локально руководством организации;

3. процедурный уровень – меры безопасности, реализуемые людьми;

4. программно-технический уровень – непосредственно средства защиты информации.

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

1.  
   1. Виды информационных рисков и методы защиты от них

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

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

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

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

Информационный риск – это возможность наступления случайного события в информационной системе предприятия, в результате которого предприятию будет нанесён ущерб [¹⁸].

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

Информационные риски можно разделить на две категории:

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

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

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

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

Спекулятивные риски выражаются в возможности получения как положительного, так и отрицательного результата. К ним относятся финансовые риски, являющиеся частью коммерческих [¹⁹].

Также риски делятся на природно-естественные, экологические, политические, транспортные и коммерческие.

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

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

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

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

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

• функциональные;

• структурные;

• временные;

• риски влияния.

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

• риск сбора информации;

• риск обобщения и классификации;

• риск обработки информации;

• риск представления.

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

• риски бухгалтерского учета;

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

• риски планирования;

• риски анализа и контроля.

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

• риски разработки;

• риски согласования;

• риски реализации;

• риски завершения.

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

• случайные риски;

• вынужденные.

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

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

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

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

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

Правило №3. Информационная система, от которой напрямую зависит деятельность компании, должна работать бесперебойно даже в случае кризисной ситуации [²⁰].

Были разработаны специальные программные продукты защиты от информационных рисков, такие как: CRAMM, Risk Watch и ГРИФ.

Метод CRAMM (CCTA Risk Analysis and Managment Method) был разработан Агентством по компьютерам и телекоммуникациям Великобритании (Central Computer and Telecommunications Agency) по заданию Британского правительства и взят на вооружение в качестве государственного стандарта. Данный программный продукт используется с 1985 г. правительственными и коммерческими организациями Великобритании. За это время CRAMM приобрел популярность во всем мире [²¹].

Метод CRAMM использует комплексный подход к оценке рисков, сочетая количественные и качественные методы анализа. Метод является универсальным и подходит как для больших, так и для мелких организаций, как правительственного, так и коммерческого сектора. Версии программного обеспечения CRAMM, ориентированные на разные типы организаций, отличаются друг от друга своими базами знаний (profiles). Для коммерческих организаций имеется Коммерческий профиль (Commercial Profile), для правительственных организаций - Правительственный профиль (Government profile). Правительственный вариант профиля, также позволяет проводить аудит на соответствие требованиям американского стандарта ITSEC («Оранжевая книга»).

CRAMM предполагает разделение всей процедуры на три последовательных этапа. Задачей первого этапа является ответ на вопрос: «Достаточно ли для защиты системы применения средств базового уровня, реализующих традиционные функции безопасности, или необходимо проведение более детального анализа?» На втором этапе производится идентификация рисков и оценивается их величина. На третьем этапе решается вопрос о выборе адекватных контрмер.

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

• использование метода CRAMM требует специальной подготовки и высокой квалификации аудитора;

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

• аудит по методу CRAMM - процесс достаточно трудоемкий и может потребовать месяцев непрерывной работы аудитора;

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

• CRAMM не позволяет создавать собственные шаблоны отчетов или модифицировать имеющиеся;

• отсутствует возможность внесения дополнений пользователями в базу знаний CRAMM;

• программное обеспечение CRAMM существует только на английском языке;

• дорогая стоимость лицензии.

Далее рассмотрим программное обеспечение RiskWatch, разрабатываемое американской компанией RiskWatch.

В методе RiskWatch в качестве критериев для оценки и управления рисками используются «предсказание годовых потерь» (Annual Loss Expectancy — ALE) и оценка «возврата от инвестиций» (Return on Investment — ROI).

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

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

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

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

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

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

(4.1)

где p — частота возникновения угрозы в течение года, v — стоимость ресурса, который подвергается угрозе.

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

RiskWatch имеет следующие недостатки:

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

• ПО RiskWatch существует только на английском языке.

• Высокая стоимость лицензии.

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

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

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

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

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

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

На последнем этапе необходимо ответить на вопросы по политике безопасности, реализованной в системе, что позволит оценить реальный уровень защищенности системы и детализировать оценки рисков [²²].

Система ГРИФ имеет следующие недостатки:

• Отсутствие привязки к бизнесс-процессам (запланировано в следующей версии).

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

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

1.  

   1. Расчет уровня уязвимости системы и вероятности возникновения информационных угроз

Для анализа защищенности информационных ресурсов системы, расчета затрат на поддержание ее безопасности была использована комплексная система управления рисками «ГРИФ».

При работе с моделью информационных потоков, на первом этапе в систему была внесена полная информация обо всех ресурсах с ценной информацией, о пользователях, имеющих доступ к этим ресурсам, о видах и правах до­ступа. Были занесены данные обо всех средствах защиты каждого ресурса, се­тевые взаимосвязи ресурсов, а также характеристики политики безопасности компании [²³].

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

Таблица 4.1 – Риск ресурсов по угрозам и уязвимостям

Ресурс	Угроза	Уязвимость	Уровень риска, ур. %
Сервер хранения данных	Аппаратные отказы	Подверженность колебаниям напряжения	20
	Доступ к БД несанкционированных пользователей	Незащищенные таблицы паролей	1
		Незащищенные потоки конфиденциальной информации	8
	Использование программных модулей несанкционированными пользователями	Незащищенные таблицы паролей	1
		Незащищенные потоки конфиденциальной информации	9
	Технические неисправности сетевых компонент	Подверженность колебаниям напряжения	39
	Искажение информации	Отсутствие эффективного контроля внесения изменений	2
		Отсутствие резервных копий	23
		Незащищенные потоки конфиденциальной информации	36
	Потеря информации	Отсутствие резервных копий	55
	Ввод в систему заранее ложных данных	Отсутствие эффективного контроля внесения изменений	41
	Ввод в систему ошибочных данных	Отсутствие резервных копий	50
Рабочая станция системного администратора	Аппаратные отказы	Подверженность колебаниям напряжения	5
	Вредоносное программное обеспечение	Изменение структуры данных	18
	Использование программных модулей несанкционированными пользователями	Незащищенные таблицы паролей	2
		Незащищенные потоки конфиденциальной информации	10
Рабочая станция главного диспетчера	Аппаратные отказы	Подверженность колебаниям напряжения	19
	Вредоносное программное обеспечение	Изменение структуры данных	11
	Технические неисправности сетевых компонент	Подверженность колебаниям напряжения	14
Рабочая станция диспетчера	Аппаратные отказы	Подверженность колебаниям напряжения	25
	Вредоносное программное обеспечение	Изменение структуры данных	16
	Технические неисправности сетевых компонент	Подверженность колебаниям напряжения	18
Рабочая станция главного инженера	Аппаратные отказы	Подверженность колебаниям напряжения	15
	Вредоносное программное обеспечение	Изменение структуры данных	10
	Технические неисправности сетевых компонент	Подверженность колебаниям напряжения	12
Рабочая станция медработника	Аппаратные отказы	Подверженность колебаниям напряжения	10
	Вредоносное программное обеспечение	Изменение структуры данных	7
	Технические неисправности сетевых компонент	Подверженность колебаниям напряжения	9
Рабочая станция сотрудника экономического отдела	Аппаратные отказы	Подверженность колебаниям напряжения	14
	Вредоносное программное обеспечение	Изменение структуры данных	12
	Технические неисправности сетевых компонент	Подверженность колебаниям напряжения	13

Далее был определен уровень безопасности данных, хранящихся на сервере (таблица 4.2).

Таблица 4.2 – Уровень безопасности хранящихся данных и потоков информации

№	Вид информации	Конфиденциальность, ур. %	Целостность, ур. %	Доступность, ур. %
1	Показатели надежности	36	16	30
2	Обработка информации	28	19	29
3	База данных	35	14	32

В итоге был рассчитан комплексный риск проблемно-ориентированной системы распределенный по классу угроз потери данных (таблица 4.3).

Таблица 4.3 – Комплексный уровень безопасности данных внедряемой системы

Конфиденциальность, ур. %	Целостность, ур. %	Доступность, ур. %
33	16	30

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

1.  

   1. Перечень контрмер и расчет их эффективности

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

Таблица 4.4 – Ущерб от возможной реализации угроз по каждому ресурсу

Ресурс	Ущерб, ур. %
Сервер хранения данных	23
Рабочая станция системного администратора	18
Рабочая станция главного диспетчера	9
Рабочая станция диспетчера	15
Рабочая станция главного инженера	12
Рабочая станция медработника	6
Рабочая станция сотрудника экономического отдела	8

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

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

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

Таблица 4.5 – Перечень предлагаемых контрмер

№	Контрмера	Стоимость контрмеры, руб.	Эффективность по системе, ур. %
1	Шифрование данных	2 500 руб.	90
2	Резервное копирование	1 500 руб.	96
3	Установка RAID-контроллера (RAID 6)	11 900 руб.	100
4	Установка брандмауэра	15 000 руб.	97
5	Использование ИБП	9 000 руб.	100
	ИТОГО:	39 900 руб.	96,6

Также была рассчитана эффективность от применения каждой контрмеры (таблица 4.6).

Таблица 4.6 – Рассчитанная эффективность контрмер по каждому ресурсу

№	Ресурс	Значение риска до всех контрмер, %		Значение риска после всех контрмер, %	Эффективность комплекса контрмер, %
1	Сервер хранения данных	23		0	100
2	Рабочая станция системного администратора	18		0	100
3	Рабочая станция главного диспетчера	9		0,7	92,2
4	Рабочая станция диспетчера	15		1,2	92
5	Рабочая станция главного инженера	12		0,8	93,3
6	Рабочая станция медработника	6		0,6	90
7	Рабочая станция сотрудника экономического отдела	8		0,7	91,2
Проблемно-ориентированная система			91	4		94,1

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

(4.2)

где N - общее количество значимых рисков, p_i - вероятность i- го риска, u_i- ожидаемая величина ущерба в денежном исчислении при наступлении i- го риска, J - количество информационных рисков, для которых используются механизмы предотвращения рисковых событий путем финансовых затрат на при­обретение требуемых механизмов, ν_j- затраты на предотвращение j- го инфор­мационного риска, K - количество информационных рисков, для минимизации ущерба от которых применяются нефинансовые механизмы,ω_k - затраты на нефинансовые механизмы (трудовые затраты, затраты аппаратной и программной частей) [²⁴].

Таким образом, обозначенные контрмеры обеспечивают увеличение показателя защищенности системы до 94,1%.

4.4. Выводы по главе

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

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

1. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ

5.1. Расчёт расходов на разработку и сопровождение системы

Существуют следующие расходы на разработку системы:

1. Расходы на программное обеспечение;

2. Расходы на техническое обеспечение;

3. Расходы на оплату интеллектуального труда;

4. Расходы на эксплуатацию помещения;

5. Расходы на информационную безопасность.

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

Таблица 5.1 – Расходы на программное обеспечение

№ п/п	Наименование программного обеспечения	Стоимость, руб.	Стоимость за три лицензии, руб.
1	MS Windows 8.1 профессиональная	7 790	23 370
2	PostgreSQL	0	0
3	Visual Studio 2013 Professional	21 270	63 810
Итого:		33 084	99 252

Расходы на техническое обеспечение составляют покупка персонального компьютера для выполнения на нём серверного программного обеспечения и его амортизация. Амортизация оборудования в год составляет 10%, тогда за 1 месяц, она составляет 0,83%.

Сводные данные по выделению средств на техническое обеспечение представлены в таблице 5.2.

Таблица 5.2 – Выделение средств на техническое обеспечение

№ п/п	Наименование технического обеспечения	Стоимость
1	Персональный компьютер	25 000
2	Амортизация ПК	207

Расходы на оплату интеллектуального труда, представленные в таблице 5.3, составляют выплату разработчику системы (программисту) и отчисления в бюджет [²⁵].

Таблица 5.3 – Расчёт средств на оплату интеллектуального труда

№ п/п	Наименование	Ед. изм.	Количество
1	Заработная плата программиста в месяц	руб./мес.	25 000
2	Длительность разработки	мес.	3
3	Страховые взносы	%	30
4	Заработная плата программиста за весь период разработки	руб.	75 000
5	Страховые взносы за весь период	руб.	22 500
Итого:		руб.	97 500

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

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

R_эксп.=Sk_вспСТ_разр, (5.1)

где S – площадь помещения, приходящаяся на рабочее место разработчиков, м²;

k_всп – коэффициент учета площади вспомогательных помещений от основных, м²;

С – аренда помещения, руб./м² в месяц;

Т_разр – период разработки, мес.

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

Площадь помещения, приходящаяся на одно рабочее место, составляет 4 м², то есть 12 м² на троих разработчиков, коэффициент учета вспомогательных площадей оставляет для данного предприятия – 1,4 для 1 кв. м основной площади.

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

R_экс.п.=121,44503=22 680 (руб.).

Расходы на информационную безопасность сервера включают: шифрование данных, резервное копирование, установка RAID-контроллера, использование ИБП. Стоимость контрмер указана в таблице 4.5.

R_инф.б.= 2 500 + 1 500 + 11 900 + 9 000 = 24 900 (руб.).

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

R_общ. = 99 252 +621 + 25 000 + 292 500 +22 680 + 24 900 = 464 953 (руб.).

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

1. Расходы на техническое обеспечение (амортизация);

2. Расходы на эксплуатацию помещения;

3. Расходы на интеллектуальный труд.

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

R_экс.п.=41,44501=2 520 (руб.).

Расходы на оплату интеллектуального труда в полставки указаны в таблице 5.4.

Таблица 5.4 – Расчёт средств на оплату интеллектуального труда

№ п/п	Наименование	Ед. изм.		Количество
1	Заработная плата админа	руб./мес.		5 000
2	Длительность	мес.		1
3	Страховые взносы	руб.		1 500
Итого:			руб.		6 500

Расходы на сопровождение в год:

R_сопр. = (6 500 + 207 + 2 520)12 = 110 724 (руб.).

1.  
   1. Расчёт прибыли в результате внедрения системы

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

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

Исходя из анализа цен на аналогичную продукцию конкурирующих фирм, цена на аренду интеллектуальной системы установлена на уровне: Ц=105 000 (руб/год). Интеллектуальная система может заинтересовать как малых так и крупных предприятий. Необходимо завладеть как минимум тремя предприятиями в год, что реально учитывая количество автотранспортных предприятий в Набережных Челнах и других городах России.

Приток средств в проект формируется из доходов от реализации программного продукта. Отток средств формируется из следующих статей: инвестиционные затраты на разработку, налог на прибыль равный 20% от прибыли, расходы на сопровождение, налог на добавленную стоимость равный 18% от прибыли. Затраты на разработку и сборку являются инвестиционными затратами, осуществляемыми в начальном периоде. Выручка от реализации для трёх предприятий составит: 315 000 (руб/год).

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

Показатели проекта представлены в таблице 5.5.

Таблица 5.5 – Показатели проекта

Наименование	Сумма, руб.
1. Выручка от реализации	315 000
2. Затраты на сопровождение	110 724
3. Налог на прибыль	63 000
4. НДС	56 700
5. Чистый денежный поток	84 576

1.  
   1. Оценка эффективности капиталовложений.

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

• чистая текущая стоимость (ЧТС);

• внутренний коэффициент окупаемости (ВКО);

• срок окупаемости инвестиций (СО);

• дисконтированный срок окупаемости инвестиций (ДСО);

• коэффициент рентабельности инвестиций (КР);

• коэффициент эффективности инвестиций (КЭI).

Коэффициент дисконтирования (KD_k)

KD_k = , (5.2)

где r = 8,25 % – ставка дисконтирования (численно равна ставке рефинансирования центрального Банка РФ);

i = 12,5 % – годовой темп инфляции (на будущий год);

р – доля премии за риск;

k– порядковый номер года, k = 0, 1, 2 …Т_сл;

р = r i;

р = 0,0825 0,125 = 0,0103;

Тогда .

Чистая текущая стоимость (ЧТС)

ЧТС определяет величину отдачи от инвестиций. Чистая текущая стоимость – это сумма текущих стоимостей с учетом ставки дисконтирования, денежных потоков.

ЧТС = (Р_k KD_k ) – I (5.3)

где k – порядковый номер года, k = 0, 1, 2 ,3;

P_k – годовой доход k – того года, руб.;

KD_k – коэффициент дисконтирования;

I – размер инвестиций, руб.;

Сущность показателя «Чистая текущая стоимость»:

Если ЧТС>0, то капиталовложения являются эффективными;

Если ЧТС 0, из этого следует, что капиталовложения являются эффективными.

Внутренний коэффициент окупаемости (ВКО)

Внутренний коэффициент окупаемости (ВКО) – ставка дисконтирова­ния, при которой эффект от инвестиций равен нулю (ЧТС=0). ВКО показывает максимально допустимый уровень расходов.

(5.4)

где r₀ – ставка дисконтирования, откорректированная на инфляцию и риск;

r₀₁ – значение откорректированной ставки дисконта, при котором ЧТС1>0;

r₀₂ – значение откорректированной ставки дисконта, при котором ЧТС2 СК – капиталовложения являются эффективными;

ВКО 0;

r₀₂ =0,16 + 0,125 + 0,075=0,36; ЧТС₂ = -21 996< 0.

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

r=0,16

Год	Чистый денежный поток, тыс. руб.		Суммар. чистый денежный поток, тыс. руб.	Коэффициент дисконтирования	Дисконт. денежный поток, тыс. руб.		Дисконт. чистый денежный поток, тыс. руб.
	Расходы, тыс.руб.	Чистая прибыль, тыс.руб.			Расходы, тыс.руб.	Чистая прибыль, тыс.руб.
1	2	3	4	5	6	7	8
0	-464,953		-464,953	1,00	-464,953		-464,953
1		84,576	-380,377	0,76628		64,809	-400,144
2		279,876	-100,501	0,58719		164,341	-235,803
3		475,176	374,675	0,449954361		213,808	-21,996
Итого	-464,953	279,876	374,675		-464,953	147,652	-21,996

Таким образом, рассчитаем ВКО по формуле 5.4:

.

Таким образом, учитывая, что ставка коммерческих банков СК = 20% годовых, то капиталовложения являются эффективными.

Срок окупаемости инвестиций (СО)

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

СО = , (5.5)

где k – порядковый номер года, k = 0, 1, 2 ,3;

P_k – годовой доход k – того года, руб.;

I – размер инвестиций, руб.

Таким образом, рассчитаем срок окупаемости инвестиций по формуле 5.5:

СО = (лет).

Для полной окупаемости инвестиций необходимо 1 год и 8 месяцев.

Дисконтированный срок окупаемости инвестиций (ДСО)

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

ДСО = (5.6)

где k – порядковый номер года, k = 0, 1, 2 ,3;

P_k – годовой доход k – того года, руб.;

KD_k – коэффициент дисконтирования;

I – размер инвестиций, руб.

Рассчитаем дисконтированный срок окупаемости инвестиций по формуле 5.6:

ДСО = (лет).

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

Коэффициент рентабельности (КР)

КР = Р_к / З (5.7)

где Р_к = 279 876 руб. – среднегодовой размер чистой прибыли;

З = 464 953 руб. – размер инвестиций;

КР = 279 876 / 464 953= 0,6.

Коэффициент эффективности инвестиций (КЭI)

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

KЭI = , (5.8)

где П_ср – чистая прибыль, руб.;

I – размер инвестиций, руб.;

ОС – остаточная стоимость инвестиционных вложений, руб.

Произведем расчет коэффициента эффективности инвестиций по формуле 5.8:

КЭI =

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

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

Таблица 5.8 - Показатели оценки экономической эффективности

№ пп	Наименование показателей	Ед. изм.	Числовые значения
1	2	3	4
1	Чистая текущая стоимость	тыс. руб.	374,675
2	Индекс рентабельности	-	0,6
3	Внутренний коэффициент окупаемости	-	0,32
4	Срок окупаемости инвестиций	лет	1,661
5	Дисконтированный срок окупаемости	лет	2,676
6	Коэффициент эффективности инвестиций	-	1,2

1.  
   1. Выводы по главе

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

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

Заключение

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

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

1. Выполнен анализ существующих информационных систем управления автотранспортным предприятием;

2. Разработана структура и определен состав интеллектуальной системы управленческого и оперативного учета для автотранспортного предприятия;

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

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

Список использованных источников

1. Экономика предприятия – преимущества от внедрения комплексной информационной системы управления // Инженерный клуб: [сайт]. [2012]. URL: http://www.enginclub.ru/kis (дата обращения 25.05.2015).

2. Организационная структура автотранспортного предприятия // Sike. Корпоративные системы: [сайт]. [2015]. URL: http://sike.ru/node/57 (дата обращения 06.04.2015).

3. Шаихов Р.Ф. Организационно-производственные структуры технической эксплуатации автомобилей: Учеб пособие. - ИжГТУ, 2012. - 81 с

4. 1С: Предприятие 8. Управление Автотранспортом. Стандарт. // ООО «1С»: [сайт]. [2011-2014]. URL: http://solutions.1c.ru/catalog/autotransport-standart (дата обращения 07.04.2015).

5. Кинзябулатов Р.А. Почему 1С это плохо // Хабрахабр: [сайт]. [2006-2015]. URL: http://m.habrahabr.ru/post/244727 (дата обращения: 10.04.2015).

6. Технический паспорт программного продукта «ПАРУС». - Москва, 2007. – 30 с

7. Модуль «Управление автотранспортом» // Корпорация «Парус»: [сайт]. [2010]. URL: http://www.parus.com/products/system/logistics/338 (дата обращения 07.04.2015).

8. Управление автотранспортом // Информационная система Олимп. Градиент – новые технологии: [сайт]. [2011-2013]. URL: http://olimp.udm.ru/index.php/about-company/news/14-sample-data-articles (дата обращения 07.04.2015).

9. Клементьев И.П., Устинов В.А. Введение в Облачные вычисления: – УГУ, 2009.- 233 с

10. Белоусова И.Д. Моделирование бизнес-процессов жизненного цикла предприятия с использованием методологии ARIS: - Магнитогорск, 2014. – 62 с

11. UML // Свободная энциклопедия Википедия. URL: https://ru.wikipedia.org/wiki/UML (дата обращения 15.04.2015).

12. Буйвол П.А. Управление в реальном времени: Учеб-метод пособие. – СТС, 2012. – 54 с

13. Герберт Ш. Полный справочник по C#: Пер. с англ. – М. : Издательский дом «Вильямс», 2004. – 752 с

14. Microsoft Visual Studio 2010 // Microsoft: [сайт]. [2015]. URL: http://www.microsoft.com/rus/business/smb/products-list/visualstudio2010 (дата обращения 16.04.2015).

15. SQLite vs MySQL vs PostgreSQL: сравнение систем управления базами данных // DEVACADEMY: [сайт]. [2015]. URL: http://devacademy.ru/posts/sqlite-vs-mysql-vs-postgresql

16. Асаул А.Н. Организация предпринимательской деятельности: Учебник. –СПб.: АНО ИПЭВ, 2009. – 336 с

17. Галатенко В.А. Основы информационной безопасности // ИНТУИТ.ру: Интернет-университет информационных технологий. М., 2008. URL: http://www.intuit.ru/studies/courses/697/553/lecture/12442 (дата обращения: 10.05.2015).

18. Системное управление информационными рисками. Выбор механизмов защиты / Завгородний В.И. // Проблемы управления. – 2009. - №1. – С. 53-58.

19. Королев А.В. Экономика предприятий технического сервиса: Учеб пособие. - Мн. БГАТУ, 2006. – 224с

20. Мишель М. Управление информационными рисками // Институт экономической безопасности [сайт]. [2000-2014]. URL: http://bre.ru/security/20718.html (дата обращения 15.05.2015).

21. Зегжда В.П. Основы безопасности информационных систем / Д.П. Зегжда, А.М. Вамшко. – М.: Горячая линия – Телеком, 2000. -452 с

22. Современные методы и средства анализа и контроля рисков информационных систем компании // IT-Среда. 2015. URL: http://www.ixbt.com/cm/informationsystem-risks012004.shtml (дата обращения 16.05.2015).

23. Малюк А.А. Информационная безопасность – концептуальные и методологические основы защиты информации. – М: Горячая линия – Телеком, 2004. – 280 с

24. Митченко И.А. Методические основы оценки информационных рисков в предпринимательстве // Журнал АГТУ. – 2007. - №3. – С. 25-33.

25. Федосеев В.В. Экономико-математические методы и прикладные модели: - Москва «Юнити», 2001. - 555 с

26. Демченко А.А. Маркетинговые стратегии в бизнесе // Маркетинг. – М.: АСТ, 2005. – 45 с

Код для цитирования: Скопировать