РАЗРАБОТКА ПРОЕКТА ПО ВНЕДРЕНИЮ СИСТЕМЫ REDMINE В ДЕЯТЕЛЬНОСТЬ ОТДЕЛА ПРОГРАММИРОВАНИЯ ООО «КОРПОРАТИВНЫЕ СИСТЕМЫ ПЛЮС»

Якшимбаева С.А. 1, Старков А.Н. 1

1ФГБОУ ВПО «Магнитогорский государственный технический университет им. Г.И.Носова»

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

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

Работа состоит из введения, двух глав и заключения. В первой главе дана характеристика ООО «Корпоративные системы Плюс», а также рассмотрены схема и структура работы службы Service Desk. Во второй главе произведен анализ систем управления технической поддержкой, был разработан план по внедрению системы Redmine и произведена оценка экономической эффективности внедрения системы.

Результаты работы могут быть использованы в деятельности ООО «Корпоративные системы Плюс» с высокой степенью эффективности.

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

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

В качестве недостатков работы следует отметить, что Якшимбаева С. А. не полностью раскрыла понятия «Управление Инцидентами» и «Управление проблемами».

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

Руководитель: ____________/канд. пед. наук, доц. кафедры ИТ Старков А.Н

«____» _____________ 2014 г.

РЕФЕРАТ

Выпускная квалификационная работа по теме «Разработка проекта по внедрению системы Redmine в деятельность отдела программирования ООО «Корпоративные системы Плюс» содержит 69 страниц текстового документа, 1 приложение, 41 использованный источник, 16 таблиц, 13 иллюстраций, 20 формул и расчетов.

SERVICE DESK, ITIL, ITSM, УПРАВЛЕНИЕ ИНЦИДЕНТАМИ, УПРАВЛЕНИЕ ПРОБЛЕМАМИ, Redmine, СЛУЖБА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ.

Объектом исследования является отдел программирования ООО «Корпоративные системы Плюс».

Целью бакалаврской работы является внедрение системы Redmine в деятельность отдела программирования ООО «Корпоративные системы Плюс».

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

Для внедрения был разработан план-график работ. Работы будут происходить в течение 31 дня. Общие трудозатраты составляют 285 часов. Единовременные затраты на внедрение системы Redmine составят 43104,7 рублей.

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

Содержание

ОТЗЫВ РУКОВОДИТЕЛЯ 5

Содержание 7

ВВЕДЕНИЕ 9

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ИСПОЛЬЗОВАНИЯ СИСТЕМ SERVICE DESK 12

1.1. Анализ деятельности отдела программирования ООО «Корпоративные системы Плюс» 12

1.2. Моделирование бизнес-процессов отдела программирования 29

1.3. Service Desk. Возможности, схема и структура работы службы 37

ВЫВОДЫ ПО ГЛАВЕ 1 46

ГЛАВА 2. ПРОЕКТ ВНЕДРЕНИЯ СИСТЕМЫ Redmine В ДЕЯТЕЛЬНОСТЬ ОТДЕЛА ПРОГРАММИРОВАНИЯ 47

2.1. Анализ существующих систем Service Desk 47

2.2. Проект внедрения системы Redmine 56

2.3. Экономическая эффективность внедрения системы Redmine 62

ВЫВОДЫ ПО ГЛАВЕ 2 70

ЗАКЛЮЧЕНИЕ 71

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 74

ПРИЛОЖЕНИЕ А 78

Цель проекта 83

Задачи проекта 83

Общие сведения 84

1.1 Наименование темы 84

1.2 Наименования Исполнителя и Заказчика работ 84

1.3 Этапы работ по внедрению программного обеспечения 84

1.4 Методика проведения обучения 85

Требования к техническому и программному обеспечению 87

2.1 Требования к техническим средствам серверов 87

2.2 Требования к техническим средствам рабочих станций 87

2.3 Требования к программному обеспечению 88

Внедрение Redmine 89

3.1 Общие требования 89

3.2 Обследование Объекта внедрения 89

3.3 Подготовка Объекта внедрения к началу внедрения 89

3.4 Организация процесса внедрения Redmine 90

3.5 Обучение пользователей работе с Redmine 90

3.6 Ввод в действие Redmine на Объекте внедрения 91

3.7 Сопровождение Redmine 92

Перечень условных обозначений, сокращений и терминов 93

ВВЕДЕНИЕ

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

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

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

Простые системы для отслеживания заявок.
Системы средней сложности с возможностью групповой работы, автоматизации действий, поддержки базы знаний, учета SLA (Service Level Agreement – Соглашение об уровне услуг), создания отчетов.
Комплексные решения, поддерживающие ITSM/ITIL, предназначенные для управления процессами, связанными с технической поддержкой и разработкой продуктов в больших компаниях.

При выборе системы поддержки пользователей важно обращать внимание:

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

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

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

Кроме этого, Service Desk формирует разнообразную управленческую информацию, в том числе:

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

На данный момент, на российском рынке существует около 20 отечественных и десятки зарубежных систем.

Объектом исследования является отдел программирования ООО «Корпоративные системы Плюс».

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

Целью бакалаврской работы является автоматизация процесса технической поддержки за счет внедрения системы Redmine в деятельность отдела программирования ООО «Корпоративные системы Плюс».

В соответствии с поставленной целью необходимо решить следующие задачи.

Дать краткую характеристику отделу программирования ООО «Корпоративные системы Плюс».
Изучить основы работы систем Service Desk.
Провести сравнительный анализ среди наиболее популярных систем для внедрения в деятельность отдела.
Разработать план работ по внедрению выбранной системы.

Бакалаврская работа состоит из введения, двух глав и заключения.

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

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

На защиту выносится проект внедрения системы Redmine в деятельность отдела программирования ООО «Корпоративные системы Плюс», техническое задание на внедряемую систему.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ИСПОЛЬЗОВАНИЯ СИСТЕМ SERVICE DESK 1.1. Анализ деятельности отдела программирования ООО «Корпоративные системы Плюс»

Общество с ограниченной ответственностью «Корпоративные системы Плюс», существует на рынке программного обеспечения с 1997 года. Основная деятельность компании изначально была направлена на создание информационных систем с использованием современных инструментов разработки приложений и баз данных. Сегодня деятельность компании «Корпоративные системы Плюс» концентрируется на трёх основных направлениях. Это разработка, продажа и внедрение программного обеспечения для комплексной автоматизации предприятия, разработка мультимедийных обучающих систем и продажа, установка и сопровождение систем контроля над работой автотранспорта (GPS-Глонасс), предназначенных для мониторинга и охраны движимой техники.

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

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

Направления деятельности компании:

1) GPS

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

Задачи направления:

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

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

2) Автопарк

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

Задачи направления:

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

3) Зарплата и кадры

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

Задачи направления:

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

4) Финансы и бухгалтерский учёт

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

Задачи направления:

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

5) Мультимедийные обучающие системы

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

Задачи направления:

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

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

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

Выделяют такие связи как:

линейные;
функциональные;
межфункциональные, или кооперационные.

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

- линейная;
- функциональная;
- линейно-функциональная;
- матричная;
- дивизиональная;
- множественная.

Существующая организационная структура «Корпоративные системы Плюс» является линейно-функциональной (штабной).

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

Достоинства линейно-штабной структуры:

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

Недостатки линейно-штабной структуры:

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

На рисунке 1 приведена организационная структура управления ООО «Корпоративные системы Плюс»:

Рисунок 1 – Организационная диаграмма ООО «Корпоративные системы Плюс»

Отдел программирования является структурным подразделением ООО «Корпоративные системы Плюс».

В своей деятельности отдел руководствуется действующим законодательством Российской Федерации и Челябинской области, Трудовым Кодексом РФ, уставом ООО «Корпоративные системы Плюс», правилами внутреннего распорядка.

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

Основные направления деятельности отдела:

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

Основными задачами отдела являются разработка программного обеспечения, сопровождение и дальнейшее совершенствование созданного раннее продукта, а так же осуществление технической поддержки пользователей информационной системы SIKE.ERP на ОАО «Белон» и ОАО «ММК-Метиз».

В таблице 1 приведены значения основных бухгалтерских показателей деятельности отдела программирования (данные изменены) за 3 прошедших года. На рисунке 2 показано изменение данных показателей в динамике.

Таблица 1 – Основные бухгалтерские показатели

	2011	2012	2013
Выручка от продаж, руб	5 609 488,99	8 980 729,70	16 601 839,80
Себестоимость продаж, руб	2 602 234,09	3 895 930,30	3 952 212,70
Прибыль, руб	3 915 005,58	4 115 859,30	5 311 348,70

Рисунок 2 – Изменение бухгалтерских показателей в динамике

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

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

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

Таблица 2 – Расчет абсолютного прироста и цепного темпа роста выручки от продаж ПО

Период	2011	2012	2013
Выручка от продаж, руб	5 609 488,99	8 980 729,70	16 601 839,80

Продолжение таблицы 2

Период	2011	2012	2013
Абс, руб	-	3 371 240,71	7 621 110,10
Отн, %	-	60,10	84,86

Таблица 3 – Расчет абсолютного прироста и цепного темпа роста себестоимости продаж

Период	2011	2012	2013
Себестоимость продаж, руб	2 602 234,09	3 895 930,30	3 952 212,70
Абс, руб	-	1 293 696,21	56 282,40
Отн, %	-	49,71	1,44

Таблица 4 – Расчет абсолютного прироста и цепного темпа роста прибыли

Период	2011	2012	2013
Прибыль, руб	3 915 005,58	4 115 859,30	5 311 348,70
Абс, руб	-	200 853,72	1 195 489,40
Отн, %	-	5,13	29,05

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

Показатели рентабельности, рассчитанные в таблице 5 показали, что в 2011 году на каждый рубль затрат на продукцию, произведенную отделом программирования, компания получила 1,50 руб. прибыли, в 2012 году – 1,06 руб., а в 2013 г. – 1,34 руб. С каждого рубля реализованной продукции, произведенной отделом программирования, компания получила 0,70 руб. прибыли, в 2012 г. – 0,46, в 2013 г. – 0,32 руб. На рисунке 3 показано изменение данных показателей в динамике.

Таблица 5 – Расчет показателей рентабельности

Показатели	Анализируемые периоды
Показатели	2011	2012	2013
Рентабельность затрат	1,50	1,06	1,34
Рентабельность продаж	0,70	0,46	0,32

Рисунок 3 – Изменение показателей рентабельности в динамике

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

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

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

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

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

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

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

Расчет описанных показателей представлен в таблице 6.

Таблица 6 – Расчет коэффициентов финансовой устойчивости

Показатели	2011	2012	2013
Коэффициент автономии	0,69	0,63	0,52
Коэффициент финансирования	1,02	1,36	1,78
Коэффициент мобильности собственного капитала	0,49	0,46	0,31
Коэффициент обеспеченности собственными средствами	0,13	0,17	0,18
Коэффициент финансовой устойчивости	0,36	0,58	0,76

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

Для анализа платежеспособности рассчитывают коэффициенты ликвидности или платежеспособности.

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

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

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

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

Расчет данных коэффициентов представлен в таблице 7.

Таблица 7 – Расчет коэффициентов ликвидности и платежеспособности

Показатели	2011	2012	2013
Коэффициент текущей ликвидности	1,52	1,58	1,50
Коэффициент критической ликвидности	0,81	0,94	0,78
Коэффициент абсолютной ликвидности	0,73	0,23	0,31
Коэффициент общей платежеспособности	1,52	1,64	1,58

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

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

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

Сотрудники и руководители ООО «Корпоративные системы Плюс» используют такие ИТ-сервисы, как:

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

Аудит ИТ-инфраструктуры

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

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

Таблица 8 – Используемое сетевое оборудование

Оборудование	Назначение оборудования
Маршрутизатор Cisco 1800	Подключение к Интернет
Коммутатор Compex SAS 2224	Подключение рабочих мест пользователей
Коммутатор D-Link DES-1024D	Подключение рабочих мест пользователей

В основном состояние пассивных компонентов локальной сети хорошее. У компании нет претензий по работоспособности кабельной системы.

Центральная точка расположена в комнате, которая представляет собой запираемое помещение размером 2 на 2,5 метра. Система вентиляции и кондиционирования есть. Все оборудование размещено на коммуникационной стойке. В состав центральной точки входит следующее оборудование:

маршрутизатор Cisco 1800, подключено 1 порт WAN и 1 порт LAN;
коммутатор Compex SAS2224 на 24 порта, из них занято 19 портов;
коммутатор D-Link DES-1024D на 24 порта, все порты заняты;
сервер PS1;
сервер PS2;
3 источника бесперебойного питания PowerCOM мощностью 1300 VA каждый.

Сервер PS1 играет роль файлового сервера. На сервере установлена серверная операционная система Windows 2003 Server Enterprise. Сервер представляет собой обычный компьютер, собранный самостоятельно. Характеристики сервера представлены в таблице 9.

На сервере установлено антивирусное программное обеспечение Symantec версии 10 и консоль управления. Резервное копирование данных выполняется с помощью программы Acronis True Image с понедельника по пятницу. Образы создаются на дисках F: и D:. Помимо этого, создается бэкап System State также с понедельника по пятницу.

Таблица 9 – Характеристика сервера PS1

Процессор	Память	Оптический привод	Жесткие диски (все диски IDE, RAID массивы или зеркалирование не используется)
Pentium 4 1,8 GHz	256 Мб	DVD-RW	Диск 0 – 40 Гб, разбит на: С: (7Гб, 1,8 свободно) - Система D: (33 Гб, 6,4 свободно) – Архив
			Диск 1 – 40 Гб, G: - Резервный, 221 Мб свободно
			Диск 2 – 120 Гб, разбит на: F: (60 Гб, 20 свободно) – Резервное копирование E: (60 Гб, 60 свободно). На диске E хранятся файлы пользователей

Сервер PS2 играет роль почтового сервера и сервера службы обновлений WSUS. Установлена серверная операционная система Windows 2003 Server Enterprise. Почтовый сервер работает под управлением программы Microsoft Exchange 2003. Сервер представляет собой обычный компьютер, собранный самостоятельно. Характеристики сервера представлены в таблице 10.

На сервере также установлено антивирусное программное обеспечение Symantec версии 10 и консоль управления. Резервное копирование выполняется с помощью Acronis True Image по воскресеньям на диск E:. Резервное копирование почтового хранилища Exchange отдельно не делается.

Таблица 10 - Характеристика сервера PS2

Процессор

Память

Оптический привод

Жесткие диски (все диски IDE, RAID массивы или зеркалирование не используется)

AMD Sempron 2400 + 1,6 GHz

512 Мб

DVD-RW

Диск 0 – 150 Гб, разбит на:

С: (113 Гб, 83 свободно) Система

D: (36 Гб, 20 свободно) Рабочий

Диск 1 – 40 Гб,

E: - Backup, 12Гб свободно

Характеристики почтового хранилища MS Exchange:

количество почтовых ящиков – 48;
размер самого большого ящика – 184 Мб;
размер базы почтовых ящиков – 8 Гб;
размер базы общих папок – 42 Мб;

Размер хранилища службы обновлений – 6, 26 Гб.

Все рабочие места оснащены источниками бесперебойного питания APC Back UPS мощностью 500VA или 350VA.

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

Мониторы на 100% рабочих мест удовлетворяют требованиям офисной работы.

На большинстве рабочих мест используется операционная система – Windows 7 и пакет офисных программ OpenOffice, но единого стандарта на основные продукты нет. Все программное обеспечение на рабочих местах подкреплено лицензиями. Обновление программного обеспечения происходит централизованно.

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

Таблица 11 – Перечень периферийного оборудования

Устройство	Тип подключения
Принтер HP LaserJet 1200	Сетевое через принт-сервер D-Link
Принтер Canon LBP – 800	Локальное на рабочем месте 3 через LPT1

Сетевые принтеры даны в общий доступ на сервере PS1.

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

1.2. Моделирование бизнес-процессов отдела программирования

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

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

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

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

Одними из самых распространенных методологий моделирования бизнес-процессов являются методологии SADT и ARIS.

В соответствии с методологией ARIS, организация рассматривается как совокупность организационных, функциональных, информационных систем и систем целей, средств производства и человеческих ресурсов. Одной из самых популярных нотаций данной методологии является нотация eEPC (extended Event Driven Process Chain) – описание цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Prof. Scheer GmbH.

Нотация eEPC относится к классу нотаций Work Flow (описания потоков работ), которые предназначены для описания деятельности в динамике (так же, как и нотация IDEF 3).

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

Основные объекты модели:

функция (Function). Отображает выполняемые работы;
событие (Event). Отображает состояния системы, влияющих и управляющих выполнением работ;
организационная единица (Organizational Unit). Отображает организационные звенья компании;
документ (Document). Отображает носители информации;
прикладная система. Отображает прикладную систему, используемую в рамках технологии выполнения функции;
кластер информации (Cluster). Отображает данные как набор сущностей и связей между ними;
стрелка (Arrow). Отображает тип отношений между другими объектами;
логические операторы. Определяют связи между событиями и функциями в рамках процесса.

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

Наиболее распространенными в данной методологии являются нотации семейства IDEF. Данное семейство включает в себя нотации IDEF0, IDEF1x, IDEF3. Аналогом для нотации eEPC здесь является нотация IDEF3, т.к. она тоже предназначена для описания деятельности в динамике.

IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) – методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов представляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие.

Основные объекты нотации:

работа (Activity). Отображает функции (процессы, работы);
стрелки (Arrows). Отображают взаимоотношения работ;
перекрестки (Junction). Отображают логику взаимодействия стрелок. В перекрестках используются логические операторы «И», «ИЛИ», исключающее «ИЛИ»;
объект ссылки (Referent). Отображает идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой.

В таблице 12 приводится сравнение нотаций IDEF3 и еЕРС. Нотация еЕРС является более новой с точки зрения времени ее появления, но, фактически, она – расширение IDEF3 за счет использования объекта «Событие».

Таблица 12 – Сравнение нотаций IDEF3 и ARIS еЕРС

Критерии сравнения	Нотация
Критерии сравнения	ARIS еЕРС	IDEF3
Принцип построения диаграммы	Временная последовательность выполнения процедур	Временная последовательность выполнения процедур
Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме
Входящий документ	Используется отдельный объект для описания типа Document. Могут быть использованы другие объекты	Используется отдельный объект для описания. (Объект ссылки типа Object или стрелка Object flow)
Входящая информация	Используется отдельный объект для описания типа Cluster и Technical term	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Исходящий документ	Используется отдельный объект для описания типа Document Могут использоваться другие объекты	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Исходящая информация	Используется отдельный объект для описания типа Cluster и Technical term	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Исполнитель процедуры	Используется отдельный объект для описания типа Position, Organizational unit и др	Нет (Может быть отражен в модели только привязкой объекта ссылки)

Продолжение таблицы 12

Критерии сравнения	Нотация
Критерии сравнения	ARIS еЕРС	IDEF3
Используемое оборудование	Используется отдельный объект для описания	Нет (может быть отражен в модели только привязкой объекта ссылки)
Связь диаграмм при декомпозиции	Для привязки к другим диаграммам используется объект Process interface	Для привязки к другим диаграммам используется объект ссылки
Связь диаграмм при декомпозиции	Для привязки к другим диаграммам используется объект Process interface	Для привязки к другим диаграммам используется объект ссылки
Стандартная форма представления диаграммы процесса при документировании	Не регламентирована. Нет рекомендаций по форматированию моделей ARIS еЕРС при документировании	Регламентирована. Рамка IDEF0 Развитая система обозначений на диаграмме
Ограничения по количеству объектов на диаграмме процесса	Количество объектов не ограничено	Рекомендовано не более шести. Общее количество не ограничено

Строго говоря, формально нотации ARIS еЕРС и IDEF3 не отличаются друг от друга, так как базируются на одних и тех же принципах моделирования потоков работ, предполагающих использование символов логики («перекрестков» в IDEF3). При помощи этих символов отображаются ветвления и слияния потоков работ в рамках бизнес-процесса.

Возможность моделирования событий в ARIS еЕРС позволяет создавать более корректные и подробные описания процессов. При этом, однако, существенно повышается сложность и трудоемкость описания.

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

На рисунке 4 представлена модель AS-IS («как есть»), процесс оказания услуг технической поддержки пользователей SIKE.ERP. Модель была разработана с помощью программного продукта Microsoft Office Visio 2007.

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

Рисунок 4 – Модель AS-IS

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

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

1.3. Service Desk. Возможности, схема и структура работы службы

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

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

Схема и структура работы Service Desk

В общем случае работа Service Desk может быть представлена из пяти основных этапов.

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

Структура Service Desk напоминает луковицу (рисунок 5). Ее сердцевина – программно-аппаратный комплекс, называемый центром обработки вызовов, который обеспечивает грамотное распределение заявок. Вокруг него строится Help Desk, который регистрирует заявку и передает ее на более высокий уровень для дальнейшего исполнения. Service Desk, как структурное подразделение, решает эту проблему и оказывает дополнительные услуги бизнесу.

Рисунок 5 – Структура службы Service Desk

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

Варианты организации

Существует несколько вариантов организации служб Service Desk. Наиболее распространенными являются следующие:

централизованная служба Service Desk как единая точка контакта для всех пользователей, возможно с отдельной службой Service Desk, расположенной ближе к пользователям бизнес-приложений (Service Desk с разделением функций);
локальные (распределенные) службы Service Desk, расположенные на нескольких объектах. Обычно такое деление службы Service Desk усложняет управление;
Виртуальная служба Service Desk, когда ее географическое расположение не имеет значения в связи с использованием коммуникационных и Интернет-технологий.

Централизованная служба Service Desk

На рисунке 6 показана структура централизованной службы Service Desk с разделением функций. Если ИТ-организация несет ответственность и за предоставление услуг, и за поддержку информационных систем, то лучше всего, чтобы служба Service Desk была для пользователей единой точкой контактов. В этом случае Service Desk отвечает за прием, регистрацию, мониторинг хода обработки и эскалацию звонков. Функция поддержки бизнес-операций может являться частью функций службы Service Desk или же за это может отвечать отдельная группа поддержки, контролируемая службой Service Desk. Для такой организации работы требуется общая система регистрации инцидентов. Если ИТ-организация не несет ответственности за поддержку бизнес-операций, тогда служба поддержки бизнес-операций будет действовать от лица пользователей в тех случаях, когда требуется поддержка со стороны поставщика ИТ-услуг.

Рисунок 6 – Служба Service Desk с разделением функций

Такой подход может сочетаться с организацией «моста» с операционной средой (т.е. точкой концентрации руководства операционной деятельностью, которой может выступать, например, служба Service Desk в сочетании с отделом эксплуатации). Это может быть целесообразно для обеспечения взаимодействия между службой Service Desk и руководством операционной деятельностью, включая Управление Сетями, Серверами и т.д.

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

Распределенная служба Service Desk

Распределенная служба размещается в разных зданиях или даже в разных городах и регионах. На рисунке 7 представлен пример распределенной службы Service Desk. При использовании такой структуры целесообразно выбрать один из предлагаемых ниже вариантов:

центральная точка контактов, где звонки принимаются и далее маршрутизируются в локальные службы поддержки. Центральная Служба Service Desk является для пользователей начальной точкой контактов, где регистрируются инциденты. Современное программное обеспечение маршрутизации звонков способствует повышению эффективности работы службы Service Desk в разрешении инцидентов;
локальные точки контактов с центральной службой Service Desk предназначены для отслеживания и мониторинга инцидентов. Данный подход часто используется в тех случаях, когда у локальной организации свой язык и корпоративная культура, а также когда у организации достаточно много специфических приложений собственной разработки для каждого направления бизнеса. В такой ситуации единственным практическим решением является распределение функции службы Service Desk различными направлениями бизнеса, т.к. для решения инцидентов требуются специфические знания в конкретной области. Локальная ответственность за затраты на поддержку может служить дополнительным мотивирующим фактором в такой структуре;
центр обработки звонков (Call Center). Этот вариант становится все более популярным, и его часто используют провайдеры и поставщики услуг. По центральному номер телефона, обычно бесплатному, можно получить доступ к главному меню, из которого пользователь выбирает пункт, по которому требуется помощь, например, электронная почта или офисные приложения. Звонок затем направляется к специалисту соответствующей группы поддержки. Эти группы могут находиться в разных местах, но пользователь об этом может даже не подозревать.

Рисунок 7 - Распределенная служба Service Desk с централизованным управлением

Виртуальная служба Service Desk

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

В последнее время, пользователи могут сами получить помощь в решении проблемы (самообслуживания, self-help). Это можно рассматривать как форму «автоматизированной» функциональности службы Service Desk. Например, возможность самообслуживания посредством веб-доступа к базе знаний (поиск известных ошибок) способствует сокращению расходов и созданию сообщества пользователей.

Основные процессы службы ServiceDesk

Согласно методологии ITSM основными процессами для службы Service Desk являются Процесс Управления Инцидентами (Incident Management) и Процесс Управления Проблемами (Problem Management).

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

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

В книге «Поддержка услуг» библиотеки ITIL дается следующее определение:

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

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

Для объективной оценки приоритета в диалоге с пользователем употребляются следующие критерии:

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

2) срочность инцидента: приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.

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

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

Различают функциональную и иерархическую эскалацию:

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

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

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

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

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

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

ВЫВОДЫ ПО ГЛАВЕ 1

Отдел программирования является структурным подразделением ООО «Корпоративные системы Плюс». В своей деятельности отдел руководствуется действующим законодательством Российской Федерации и Челябинской области, Трудовым Кодексом РФ, уставом ООО «Корпоративные системы Плюс», правилами внутреннего распорядка.

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

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

ГЛАВА 2. ПРОЕКТ ВНЕДРЕНИЯ СИСТЕМЫ Redmine В ДЕЯТЕЛЬНОСТЬ ОТДЕЛА ПРОГРАММИРОВАНИЯ 2.1. Анализ существующих систем Service Desk

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

возможность добавления не менее 30 исполнителей в системе;
возможность ведения базы знаний;
импорт задач из электронного письма;
наличие e-mail и sms-уведомлений;
конструктор отчетов;
открытость кода;
техподдержка от производителя системы;
учет трудозатрат исполнителей.

Ориентировочно до 2004 г. на российском рынке было представлено всего две достойных системы Service Desk – HP Service Desk и продукты семейства Remedy. На данный момент, рынок систем Service Desk разнообразен. Существует более 20 видов различных отечественных систем и десятки зарубежных систем, которые удовлетворяют различные потребности всех пользователей. Поэтому выбор системы для предприятия должен осуществляться на основе характеристик и параметров, необходимых для полноценного функционирования компании.

По данным портала Real ITSM, на январь 2014 года наиболее популярными среди бесплатных Service Desk-систем являются системы Redmine, Gemini и OTRS [34].

Redmine

Redmine – открытое серверное веб-приложение. Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby-on-Rails. Распространяется согласно GNU General Public License.

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

ведение нескольких проектов;
гибкая система доступа, основанная на ролях;
система отслеживания ошибок;
диаграммы Ганта и календарь;
ведение новостей проекта, документов и управление файлами;
оповещение об изменениях с помощью RSS-потоков и электронной почты;
форумы для каждого проекта;
учёт временных затрат;
настраиваемые произвольные поля для инцидентов, временных затрат, проектов и пользователей;
лёгкая интеграция с системами управления;
создание записей об ошибках на основе полученных писем;
поддержка множественной аутентификации LDAP;
возможность самостоятельной регистрации новых пользователей;
многоязычный интерфейс (в том числе русский);
поддержка СУБД MySQL, PostgreSQL, SQLite, Oracle.

Основные понятия:

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

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

Пользователям назначается роль в каждом проекте, в котором он участвует. Пользователь может иметь несколько ролей. Назначение роли для отдельной задачи (issue) в данный момент невозможно.

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

Трекеры. Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учёта ошибок (англ. Bug tracking tool), представлявшим каждая в отдельности один проект. Примерами трекеров в Redmine являются «Улучшение», «Ошибка», «Документирование», «Поддержка».

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

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

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

Отслеживание изменения статуса задач. За отслеживание изменений параметров задач пользователями в системе отвечают две сущности: «Запись журнала изменений» и «Измененный параметр». Запись журнала отображает одно действие пользователя по редактированию параметров задачи и/или добавление комментария к ней. То есть служит одновременно инструментом ведения истории задачи и инструментом ведения диалога.

Сущность «Измененный параметр» привязана к отдельной записи журнала и предназначена для хранения старого и нового значения измененного пользователем параметра.

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

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

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

«Редакция» является отображением редакции репозитория, и, кроме информационных полей, может быть привязана к конкретной задаче (для этого требуется указать в описании изменений «refs #NUM», где NUM — номер задачи), и к пользователю-автору редакции. Сущность «Изменение» предназначена для хранения списка измененных (добавленных, удаленных, перемещенных, модифицированных) файлов в каждой редакции.

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

Недостатки Redmine

1. 1. 1. Управление файлами и документами в Redmine сводится к их добавлению, удалению и редактированию. Правами доступа ни к файлам, ни к отдельным документам управлять нельзя.
    2. Отсутствуют оповещения об изменении документов.
    3. Нельзя управлять правами доступа на уровне отдельных полей задачи. Например, от клиентов нельзя скрыть оценки времени работы над задачей.
    4. Все дополнительные поля доступны всем пользователям, все участники проекта смогут их видеть и изменять. Это ограничение может привести к сложностям при наличии неоднородной команды, когда доступ к проекту имеют и менеджеры, и разработчики, и клиенты.
    5. В список задач не выводится общая трудоемкость задач.

Gemini

Gemini – программное приложение, написанное на .NET. Разработано компанией CounterSoft, Великобритания.

Первая версия Gemini была создана в 2003 году. После создания на сайте разработчика была доступна бесплатная версия программы для внутреннего использования с возможностью установки на одном сайте и ограничением на 10 пользователей.

Официальные уведомления о выходе новых версий программы стали появляться на форумах компании начиная с 2006 года (версия 2.0.2), а в 2008 году новости стали доступны на официальном сайте компании.

30 апреля 2006 года наряду с веб-приложением было выпущено приложение для Windows – Gemini Desktop. 8 апреля 2007 года была выпущена новая версия Gemini 2.1.1 с поддержкой русского языка. 2 февраля 2009 года в Gemini была добавлена поддержка TechSmith SnagIt и MSN Messenger. 22 декабря 2009 года вышла новая версия Gemini 3.6 с улучшенным интерфейсом, динамическими фильтрами задач, улучшенными отчётами, возможностью создавать задачи по почте и прочими улучшениями.

Основными функциональными возможностями Gemini являются:

интеграция с сервером баз данных SQL Server;
отслеживание рабочего времени;
интеграция с системами контроля версий;
настраиваемые шаблоны уведомлений, отправляемых по электронной почте и с помощью RSS;
автоматическое создание задач на основе полученных писем (интеграция с POP3);
персональные фильтры задач;
интеграция с Microsoft Visual Studio;
интеграция с календарём и задачами Microsoft Outlook;
настраиваемые типы и приоритеты задач;
управление правами доступа для незарегистрированных пользователей;
гибкая система отчётов;
связь между задачами в рамках проекта.

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

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

OTRS Help Desk

OTRS HELP Desk – бесплатная helpdesk-система, написанная на Perl. В 2010 году новая версия система была официально сертифицирована экспертной компанией PinkVERIFY на соответствие ITIL v3. В системе реализовано управление инцидентами, проблемами, конфигурациями, уровнем услуг и управление знаниями, а также управление изменениями. Работает под Linux и Windows. В начале апреля 2014 года была выпущена новая версия OTRS Help Desk 3.3.6.

Основные возможности:

импорт задач с почты, e-mail-уведомления;
поддержка СУБД MySQL, SQLite, Oracle;
гибкая система отчетов,
большие возможности поиска по задачам и FAQ;
управление пользователями: добавление, редактирование, удаление;
возможна интеграция с уже имеющимися БД клиентов и сотрудников;
система легко раcширяема через дополнительные модули: база знаний/FAQ, календарь, файловый менеджер;
есть русская локализация.

Выбранные системы будут сравниваться по требованиям, которые предъявили руководители ООО «Корпоративные системы Плюс», а именно:

возможность добавления не менее 30 исполнителей в системе;
возможность ведения базы знаний;
импорт задач из электронного письма;
наличие e-mail и sms-уведомлений;
конструктор отчетов;
открытость кода;
техподдержка от производителя системы;
учет трудозатрат исполнителей.

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

Количество исполнителей (W₁ =0,1).
База знаний (W₂ =0,1).
Создание заявок по письму (W₃ =0,1).
E-mail, sms – уведомления (W₄ =0,2).
Конструктор отчетов (W₅ =0,1).
Возможность доработки «под себя» (W₆=0,2).
Техподдержка (W₇ =0,05).
Учет трудозатрат (W₈ =0,15).

Также руководством были выставлены оценки (P_i) заданным системам. Минимальный балл – 0, если система не поддерживает данное требование, максимальный – 5 баллов.

Итоговый балл подсчитан в таблице 13.

Итоговой балл будет рассчитываться по формуле (1):

, (1)

где W_i – вес функции;

P_i – балл, поставленный системе.

Таблица 13 – Применение метода экспертных оценок для выбора системы

Характеристика	Вес	Redmine	Gemini	OTRS Help Desk
Количество исполнителей	0,1	5	2	4
База знаний	0,1	5	0	5
Создание заявок по письму	0,1	5	5	5
e-mail, sms -уведомления	0,2	5	5	0
Конструктор отчетов	0,1	5	5	5
Возможность доработки «под себя»	0,2	5	0	5
Техподдержка	0,05	0	0	0
Учет трудозатрат	0,15	5	5	0
Итого:		4,75	2,95	2,9

Анализ вышеуказанных продуктов показал, что системой, способной косвенно или частично решать поставленные задачи является Service Desk-система Redmine.

2.2. Проект внедрения системы Redmine

Для разработки проекта внедрения системы Service Desk Redmine в деятельность отдела программирования был составлен план-график работ (рисунок 8) с использованием Microsoft Office Project 2007.

Рисунок 8 – План-график работ по внедрению Redmine

Первый этап проекта – разработка технического задания на проведение работ по внедрению Redmine. Техническое задание представлено в приложении А. Согласно ГОСТ 34.602 – 89, техническое задание (далее – ТЗ) включает в себя общие сведения о системе, назначение и цели внедрения системы. Также прописывается состав и содержание работ по внедрению Redmine и порядок контроля и приемки системы. ТЗ утверждается руководством ООО «Корпоративные системы Плюс».

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

Следующий этап – установка системы и интеграция с почтовой службой. Для установки будет использоваться Redmine версии 2.5.1-1. Установка серверного веб-приложения Redmine будет происходить с помощью BitNami.

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

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

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

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

На следующем этапе разрабатываются должностные инструкции менеджера службы поддержки и аналитика (инженера).

У менеджера Service Desk, большинство задач связаны с координацией работы специалистов технической поддержки. Роль аналитика Service Desk ответственна за выполнение ежедневных задач и процессов Службы. Эта роль, прежде всего, связана с выполнением процесса Управления Инцидентами. Аналитики Service Desk ответственны за корректную регистрацию и классификацию инцидента, оказание начальной поддержки. На стадии начальной поддержки, они ответственны за разрешение максимального количества Инцидентов, насколько это возможно в пределах определенных временных рамок. Эта роль также включает начальную обработку всех типов запросов, поступающих в Redmine.

Для оценки продолжительности работ был использован метод Pert (Program Evaluation And Review Technique – метод оценки и обзора программы). Для использования данного метода были определены:

оптимистическое время (время выполнения работы в наиболее благоприятных условиях);
наиболее вероятное время (время выполнения работы в нормальных условиях);
пессимистическое время (время выполнения работы в неблагоприятных условиях).

Учитывая, что время выполнения работы описывается бета-распределением, среднее или ожидаемое время выполнения работы будет определяться по формуле (2):

, (2)

где A_i– оптимистическое время выполнения работы;

S_i – наиболее вероятное время выполнения работы;

D_i – пессимистическое время выполнения работы.

Применив метод Pert (рисунок 9), мы рассчитали, что наиболее вероятная длительность проекта составит 31 день.

Рисунок 9 – Применение метода Pert для оценки продолжительности выполнения проекта

Для выполнения проекта назначены ресурсы: программист Иванов К. И., начальник отдела программирования Осипов Я. В., Якшимбаева С. А. Ресурсам назначена зарплатная ставка и определен график их работы: с понедельника по пятницу, с 9:00 до 13:00 и с 14:00 до 18:00. Лист ресурсов представлен на рисунке 10.

Рисунок 10 – Лист трудовых ресурсов

На каждый из этапов проекта внедрения были назначены ресурсы и подсчитаны их общие трудозатраты. Трудозатраты представлены на рисунке 11. На основе полученных трудозатрат и зарплатной ставки сотрудников были подсчитаны общие затраты на заработную плату специалистам, участвующим во внедрении Redmine. Затраты на оплату труда сотрудников представлены на рисунке 12.

Рисунок 11 – Общие трудозатраты сотрудников

Рисунок 12 – Общие затраты на заработную плату

На основе проекта внедрения системы Redmine была разработана модель TO-BE («как будет»). Модель была разработана с помощью программного продукта Microsoft Office Visio 2007. Модель представлена на рисунке 13.

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

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

Рисунок 13 – Модель TO-BE

2.3. Экономическая эффективность внедрения системы Redmine

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

К основным обобщающим показателям экономической эффективности относятся:

годовой экономический эффект внедрения программного средства;
срок окупаемости программного средства.

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

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

, (3)

где Э – годовой экономический эффект, руб.;

П – годовая экономия (годовой прирост), руб.;

К – единовременные затраты, руб;

Е_н – нормативный коэффициент эффективности капитальных вложений. Е_н – представляет собой минимальную норму эффективности капитальных вложений, ниже которой они не целесообразны. Значение Е_н принимается равным 0,2 [10].

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

Срок окупаемости затрат на внедрение программного средства представляет собой отношение капитальных затрат на внедрение средства к годовой экономии (годовому приросту прибыли) и рассчитывается по формуле (4).

, (4)

где Т – срок окупаемости капитальных затрат на внедрение программного средства;

П – годовая экономия (годовой прирост), руб.;

К – единовременные затраты, руб.

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

Общая ожидаемая трудоемкость внедрения Redmine составляет 36 дней. В смету затрат на внедрение ПО включаются:

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

Материальные затраты.

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

В процессе работы использовались материалы и принадлежности, представленные в таблице 14.

Таблица 14 – Материалы и принадлежности, использованные в процессе разработки.

Наименование	Количество, шт.	Цена, руб.	Стоимость, руб.
Бумага	400	0,4	160
Ручка	5	5	25
Картридж	1	150	150
Итого, руб.:	335

Основная и дополнительная заработные платы.

Основная заработная плата при выполнении проекта внедрения включает зарплату всех сотрудников, принимающих непосредственное участие во внедрении ПО. В данном случае необходимо учитывать основные зарплаты программиста и начальника отдела программирования. Таким образом, основная заработная плата З_осн при внедрении рассчитывается по формуле (5).

, (5)

где З_{срдн j} – зарплата j-го сотрудника, руб.;

n – количество сотрудников, принимающих непосредственное участие во внедрении программного продукта.

Основная заработная плата при выполнении проекта внедрения равна сумме заработных плат программиста и начальника отдела программирования и рассчитывается по формуле (5). Для расчета заработной платы программиста З_пр необходимо указать, что работы по настройке и адаптации Redmine производились в течение 46 часов. 1 час работы программиста стоит 150 рублей. Заработная плата начальника отдела программирования З_начсоставляет 250 рублей в час.

, (6)

где З_пр – заработная плата программиста, руб.;

З_нач – заработная плата начальника отдела программирования, руб.

К дополнительной заработной плате относятся: оплата отпусков, выплата вознаграждения за выслугу лет и т.д. Дополнительная заработная плата составляет 10 % от основной и рассчитывается по формуле (7).

(7)

где З_осн – основная заработная плата сотрудников, участвующих во внедрении, руб.

Исходя из формулы (7) рассчитаем сумму дополнительной заработной платы:

, (8)

Общая заработная плата равна сумме основной и дополнительной заработной платы сотрудников, участвующих во внедрении Redmine и рассчитывается по формуле (9).

(9)

где З_осн – основная заработная плата сотрудников, участвующих во внедрении, руб.;

З_доп – дополнительная заработная плата сотрудников, руб.

Общая заработная плата составит:

, (10)

Отчисления на социальные нужды

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

(11)

где З_общ – общая заработная плата сотрудников, участвующих во внедрении, руб.

Сумма отчислений составит:

, (12)

Стоимость инструментальных средств

Стоимость инструментальных средств включает стоимость системного программного обеспечения, использованного при внедрении программного продукта в размере износа за этот период. Стоимость продуктов представлена в таблице 15. Норма амортизации для системного программного обеспечения – 30%, а время использования программного обеспечения 31 день.

Таблица 15 – Стоимость системного программного обеспечения

Наименование продукта	Первоначальная стоимость, руб.
Операционная система Windows 7	5750
Пакет программ Microsoft Office 2007	3200
Итого, руб.:	8950

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

, (13)

где О_ф – первоначальная стоимость инструментальных средств, руб.;

Н_ам – норма амортизации, % (принято 30%);

Т_эвм – время использования оборудования, дней.

Стоимость системного программного обеспечения, использованного при внедрении системы Redmine, составит:

, (14)

Накладные расходы

Накладные расходы – это дополнительные к основным затратам расходы, необходимые для обеспечения процессов производства, связанные с управлением, обслуживанием, содержанием и эксплуатацией оборудования плюс ненормированные расходы Накладные расходы составляют 30% от суммы основной заработной платы и рассчитываются по формуле (15).

(15)

где З_осн – основная заработная плата сотрудников, участвующих во внедрении, руб.

Сумма накладных расходов, согласно формуле (15) составит:

, (16)

В таблицу 16 заносится смета затрат на внедрение Redmine.

Таблица 16 – Смета затрат

Элемент затрат	Сметная стоимость, руб.
Материальные затраты	335
Основная и доп. з/п	27755,53
Отчисления на соц. нужды	7216,44
Амортизация стоимости инструментальных средств	228,04
Накладные расходы	7569,7
Итого, руб.:	43104,7

Итого единовременные затраты на внедрение системы Redmine (К) составляют 43104,7рублей.

Рассчитаем показатели экономической эффективности.

По данным ЧТУП «КомплИТ», после внедрения систем Service Desk затраты на заработную плату сотрудников технической поддержки снижаются на 5% за счет того, что большая доля инцидентов решается аналитиками на первом уровне поддержки [5].

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

(17)

где З_тп – годовой фонд заработной платы специалистов технической поддержки, руб.

Согласно формуле (17) рассчитаем годовую экономию:

(18)

Тогда экономический эффект от внедрения системы Redmine, согласно формуле (3) составит:

(19)

Экономический эффект от внедрения Redmine положителен. Это означает, что расходы на внедрение системы не превышают доходов, полученных компанией.

Вычисляем срок окупаемости вложений во внедрение системы Redmine (отношение затрат на внедрение системы к годовому экономическому эффекту) по формуле (4):

(20)

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

ВЫВОДЫ ПО ГЛАВЕ 2

В рамках написания данной работы был исследован рынок систем Service Desk. По данным портала Real ITSM, на январь 2014 года наиболее популярными среди бесплатных Service Desk систем являются системы Redmine, Gemini и OTRS.

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

1) возможность добавления не менее 30 исполнителей в системе;

2) возможность ведения базы знаний;

3) импорт задач из электронного письма;

4) наличие e-mail и sms-уведомлений;

5) конструктор отчетов;

6) открытость кода;

7) техподдержка от производителя системы;

8) учет трудозатрат исполнителей.

Для оценки систем по указанным характеристикам был применен метод экспертных оценок. Анализ продуктов показал, что системой, способной косвенно или частично решать поставленные задачи является Service Desk система Redmine.

Для разработки проекта внедрения Redmine был составлен план-график работ, также была оценена длительность проекта с помощью метода PERT. Примерная длительность составит 31 день.

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

ЗАКЛЮЧЕНИЕ

В рамках написания бакалаврской работы был исследован рынок систем Service Desk. По данным портала Real ITSM, на январь 2014 года наиболее популярными среди бесплатных систем Service Desk являются системы Redmine, Gemini и OTRS.

1) возможность добавления не менее 30 исполнителей в системе;

2) возможность ведения базы знаний;

3) импорт задач из электронного письма;

4) наличие e-mail и sms-уведомлений;

5) конструктор отчетов;

6) открытость кода;

7) техподдержка от производителя системы;

8) учет трудозатрат исполнителей.

Для оценки систем по указанным характеристикам был применен метод экспертных оценок. Руководством ООО «Корпоративные системы Плюс» были выставлены оценки, а так же предложены веса заданным требованиям. Анализ продуктов показал, что системой, способной косвенно или частично решать поставленные задачи является система Redmine.

Далее был разработан план-график работ по внедрению данной системы. Для установки серверного веб-приложения Redmine использовался интегрированный пакет программного обеспечения BitNami Stack, которое включает в себя веб-приложение и все его необходимые компоненты. На каждый из этапов были назначены трудовые ресурсы, общие трудозатраты проекта составляют 285 часов. С помощью метода PERT мы оценили примерную длительность проекта, она составила 31 дней.

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

Для оценки экономической эффективности внедрения системы были рассчитаны коэффициенты эффективности. Расчеты показали, что благодаря невысокой стоимости внедрения системы, она окупается за 2,3 месяца (71 день), а годовая экономия в первый год функционирования системы составляет 226573,2 рублей. Организация может сэкономить за счет уменьшения затрат на заработную плату сотрудникам технической поддержки, поскольку после внедрения Redmine большая часть заявок пользователей будет решаться аналитиками на первом уровне поддержки.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Gemini tracke | Countersoft [Электронный ресурс] – Режим доступа: http://www.countersoft.com
IntraService. Service desk система. Управление задачами [Электронный ресурс] – Режим доступа: http://www.intraservice.ru/default.ivp
NAUMEN – информационные системы управления растущим бизнесом [Электронный ресурс] – Режим доступа: http://www.naumen.ru/
Release Notes: Help Desk @ru Archives [Электронный ресурс] – Режим доступа: http://www.otrs.com/category/release-notes-help-desk-ru/?lang=ru
SERVICE DESK [Электронный ресурс] – Режим доступа: http://www.komplit.by/products/63/
Аксенов Е. В, Альтшулер И. А. Аутсорсинг: 10 заповедей и 21 инструмент. — СПб.: Питер, 2009. — 464 с.
Алехин З.А. ITIL — основа концепции управления ИТ-сервисами.// Открытые системы, март 2001. — с. 32-36.
Алехин З.А. О возможностях и путях построения управляемой ИТ-инфраструктуры.// Нефтяное хозяйство, №5, 2001 г. — с. 92-94.
Баранчеев В.П. и др. Управление инновациями. Учебник для бакалавров / В. П. Баранчеев, Н. П. Масленникова, В. М. Мишин. — 2-е изд., перераб. и доп. — М.: Юрайт; 2012. — 711 с.
Барташев Л. В. Технико-экономические расчеты при проектировании и производстве машин. – М.: Высшая школа, 1973. - 384 c.
Бон Ян Ван, Кеммерлинг Георгес, Пондман Дик. Введение в ИТ Сервис-менеджмент. - М.: IT Expert, 2003. — 215 с.
Брукс Питер. Метрики для управления ИТ-услугами. – М.: Альпина Бизнес Букс, 2008. – 283 с.
Внедрение ПО: оценка окупаемости | Внедрение и эффективность | Информационные технологии [Электронный ресурс] – Режим доступа: http://www.iteam.ru/publications/it/section_53/article_2183/
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы [Текст]. - Взамен ГОСТ 24.201-85; введ. 1990 – 01 – 01. - Москва: Межгос. Совет по стандартизации, метрологии и сертификации; Москва: Изд-во стандартов, 2002. – 7 с.
Джейсон Фрайд, Дэвид Хейнмейер Ханссон. Rework. Бизнес без предрассудков. – М.: Манн, Иванов и Фербер, 2010. – 208 с.
Дополнительная зарплата [Электронный ресурс] – Режим доступа: http://www.ngpedia.ru/id032944p1.html
Дунаев Г. Е. Для чего и как приобретать решение по ITSM?// Нефтяное хозяйство, № 10, 2002 г. – с. 109-113.
Дунаев Г. Е. Как оценить результаты внедрения ITSM?// Директор ИС, № 4, 2004 г.
Дунаев Г. Е., Михалев В.А. Особенности внедрения методологии ITSM.// Открытые системы, № 1, 2004 г.
Журавлев Роман. Иллюстрированный ITSM. Наблюдения тренера-консультанта. – М.: Лайвбук, 2013. - 126 c.
Ингланд Р. Овладевая ITIL. Скептическое руководство для ответственных лиц. - М.: Лайвбук, 2011. — 65 с.
Ингланд Роб. Введение в реальный ITSM. – М.: Гаятри/Livebook, 2010. - 132 c.
Итилиум. Service desk, helpdesk, управление IT-helpdesk [Электронный ресурс] – Режим доступа: http://www.itilium.ru/
Каталог: отечественные ITSM-системы [Электронный ресурс] – Режим доступа: http://www.itsmonline.ru/software/for.php
Компания БИТЕК (Бизнес-инжиниринговые технологии). ARIS eEPC [Электронный ресурс] – Режим доступа: http://www.betec.ru
Корпоративный сайт ООО «Корпоративные системы Плюс» [Электронный ресурс] – Режим доступа: http://www.sike.ru
Крылов Е.С. Как получить превосходство в бизнесе? [Электронный ресурс] – Режим доступа http://itsmf.ru/main.phtml
Кудричевский Б.Ю. Введение в ITIL: Основные понятия (The ITIL Story) Version 3.0: Учебное пособие. – Санкт-Петербург: Pink Elephant, 2002. – 12 с.
Лучшие практики ITIL/ITSM [Электронный ресурс] – Режим доступа: http://www.terrasoft.ru/products/service_desk/definition
Начальный или первичный сбор исходных данных [Электронный ресурс] – Режим доступа: http://www.sudru.com/
Нормативный коэффициент - эффективность. [Электронный ресурс] – Режим доступа: http://www.ngpedia.ru/id115890p1.html
Подходы к внедрению ITSM-проектов [Электронный ресурс] – Режим доступа: http://www.naumen.ru/products/service_desk/pages /itsm_implemen-tation/
Портал Real ITSM: все об ITIL, COBIT, ISO 20000 [Электронный ресурс] – Режим доступа: http://www.realitsm.ru
Рейтинг Service Desk – обзор на Real ITSM [Электронный ресурс] – Режим доступа: http://www.realitsm.ru/rejting_SERVICE_DESK/
Сетевой анализ проектов. Метод PERT [Электронный ресурс] – Режим доступа: http://matica.org.ua/issledovanie-operatsiy-v-ekonomike-modeli-zadachi-resheniya-afanasev-m-u-suvorov-b-p/09-setevoy-analiz-proektov-metod-pert
Служба Service Desk. ИТ-сервис менеджмент. Введение [Электронный ресурс] – Режим доступа: http://www.redov.ru/kompyutery_i_internet/ it_servis_menedzhment_vvedenie/p11.php
Сравнительный анализ нотаций ARIS/IDEF | Моделирование | Информационные технологии [Электронный ресурс] – Режим доступа: http://www.iteam.ru/publications/it/section_51/article_2518/
Теория и практика мотивации персонала Service Desk [Электронный ресурс] – Режим доступа: http://www.osp.ru/cio/ 2005/06/174035/
Управление задачами и проектами [Электронный ресурс] – Режим доступа: http://web.bitacs.ru/solution/tm.html#2
Управление потоком задач [Электронный ресурс] – Режим доступа: http://potokzadach.ru/
Установка и настройка Service Desk на примере OTRS проектов [Электронный ресурс] – Режим доступа: http://www.itsmportal.com/news/ general-public-can-download-open-source-itsm-solution-otrsitsm-20

ПРИЛОЖЕНИЕ А

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ«МАГНИТОГОРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ИМ. Г.И. НОСОВА»

Институт энергетики и автоматизированных систем,

факультет информатики

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

Техническое задание

НА ПРОВЕДЕНИЕ РАБОТ ПО ВНЕДРЕНИЮ

системы автоматизированного управления

службой технической поддержки Redmine

на 11 листах

УТВЕРЖДАЮ

Начальник отдела программирования

ООО «Корпоративные системы Плюс»

____________________ Я. В. Осипов

«_4__» __июня__ 2014 года

Магнитогорск, 2014

Аннотация

Настоящий документ представляет собой техническое задание к проведению работ по внедрению Service Desk-системы Redmine в ООО «Корпоративные системы Плюс» (далее по тексту – Объект внедрения).

Содержание

ОТЗЫВ РУКОВОДИТЕЛЯ 5

Содержание 7

ВВЕДЕНИЕ 9

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ИСПОЛЬЗОВАНИЯ СИСТЕМ SERVICE DESK 12

1.1. Анализ деятельности отдела программирования ООО «Корпоративные системы Плюс» 12

1.2. Моделирование бизнес-процессов отдела программирования 29

1.3. Service Desk. Возможности, схема и структура работы службы 37

ВЫВОДЫ ПО ГЛАВЕ 1 46

ГЛАВА 2. ПРОЕКТ ВНЕДРЕНИЯ СИСТЕМЫ Redmine В ДЕЯТЕЛЬНОСТЬ ОТДЕЛА ПРОГРАММИРОВАНИЯ 47

2.1. Анализ существующих систем Service Desk 47

2.2. Проект внедрения системы Redmine 56

2.3. Экономическая эффективность внедрения системы Redmine 62

ВЫВОДЫ ПО ГЛАВЕ 2 70

ЗАКЛЮЧЕНИЕ 71

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 74

ПРИЛОЖЕНИЕ А 78

Цель проекта 83

Задачи проекта 83

Общие сведения 84

1.1 Наименование темы 84

1.2 Наименования Исполнителя и Заказчика работ 84

1.3 Этапы работ по внедрению программного обеспечения 84

1.4 Методика проведения обучения 85

Требования к техническому и программному обеспечению 87

2.1 Требования к техническим средствам серверов 87

2.2 Требования к техническим средствам рабочих станций 87

2.3 Требования к программному обеспечению 88

Внедрение Redmine 89

3.1 Общие требования 89

3.2 Обследование Объекта внедрения 89

3.3 Подготовка Объекта внедрения к началу внедрения 89

3.4 Организация процесса внедрения Redmine 90

3.5 Обучение пользователей работе с Redmine 90

3.6 Ввод в действие Redmine на Объекте внедрения 91

3.7 Сопровождение Redmine 92

Перечень условных обозначений, сокращений и терминов 93

Цель проекта

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

Задачи проекта

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

Общие сведения 1.1 Наименование темы

Полное наименование темы:

Внедрение Service Desk-системы Redmine в ООО «Корпоративные системы Плюс».

Условное обозначение темы:

Внедрение Redmine.

1.2 Наименования Исполнителя и Заказчика работ

Исполнитель:

ФГБОУ ВПО «Магнитогорский Государственный Технический Университет ИМ. Г.И. Носова»

Адрес: 455000, Магнитогорск, пр. Ленина, д. 114.

Заказчик:

Общество с ограниченной ответственностью «Корпоративные системы Плюс»

Адрес: 455000, Магнитогорск, пр. Металлургов, д. 7.

1.3 Этапы работ по внедрению программного обеспечения

Для каждого Объекта внедрения работы по внедрению должны включать в себя следующие этапы:

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

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

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

1.4 Методика проведения обучения

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

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

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

Фамилия, имя, отчество обучаемого лица
Дата проведения обучения;
Подпись обучаемого лица

Ответственный за проведение обучения со стороны Исполнителя должен подготовить план-график обучения, который согласуется и утверждается представителем Заказчика на Объекте внедрения (далее по тексту Получателем).

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

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

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

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

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

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

Обучение технических специалистов должно проводиться в несколько этапов:

Теоретическая часть (лекции);
Тестирование пользователей - проверка приобретенных знаний и навыков.

Обучение производится сотрудником со стороны Объекта внедрения.

Требования к техническому и программному обеспечению 2.1 Требования к техническим средствам серверов

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

процессор: Pentium 4;
тактовая частота: 1.2 ГГц;
оперативная память: 256 Мбайт;
дополнительная дисковая память (на системные компоненты):10 Гбайт;
CD-ROM устройство;
сетевой адаптер;
терминал;
устройство резервного копирования;
источник бесперебойного питания.

Серверы должны обладать возможностями расширения вычислительной мощности (дисковое пространство, вычислительная мощность) и обладать полным набором средств защиты от сбоев внутренних компонентов.

2.2 Требования к техническим средствам рабочих станций

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

процессор: Celeron;
тактовая частота: 500 МГц;
оперативная память: 128 Мбайт;
дополнительная дисковая память (на системные компоненты): 1 Гбайт;
сетевой адаптер;
видеоадаптер: не менее SuperVGA;
разрешающая способность: не менее 800x600 точек.

2.3 Требования к программному обеспечению

ПО рабочих мест пользователей (рабочих станций) должно быть оснащено операционными системами (ОС) Windows XP/7, офисными средствами MS Office версии не ниже 2000 (Word, Excel) или OpenOffice, средствами Internet Explorer не ниже версии 6.0.

ПО сервера должно быть оснащено ОС SUSE Linux Enterprise Server 8.0 или Windows 2000 Server SP4 (MSXML 4.0, MDAC 2.7), СУБД MySQL 4.0 (или более поздними версиями). В ОС Windows должна быть установлена поддержка русского языка.

Внедрение Redmine 3.1 Общие требования

Обучение сотрудников судов должно быть проведено Исполнителем в помещении Объекта внедрения. Дальнейшее сопровождение системы Исполнителем не проводится.

Для Объекта внедрения Исполнителем должен быть разработан, а Получателем должен быть утвержден план обучения.

3.2 Обследование Объекта внедрения

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

Обследование объектов внедрения Исполнителем непосредственно на территории Объекта внедрения и с помощью анкетирования и интервьюирования руководства Объекта внедрения.

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

3.3 Подготовка Объекта внедрения к началу внедрения

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

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

По итогам установки и настройки Redmine производится проверка его функционирования в полном объеме.

3.4 Организация процесса внедрения Redmine

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

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

В распорядительных документах должно быть отражено:

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

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

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

3.5 Обучение пользователей работе с Redmine

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

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

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

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

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

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

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

3.6 Ввод в действие Redmine на Объекте внедрения

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

На этапе ввода в действие Получатель должен обеспечить организованную работу пользователей и структурных подразделений Объекта внедрения. Ввод в действие Redmine должен осуществляться последовательно.

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

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

По результатам ввода в действие Redmine на Объектах внедрения подписывается Технический акт сдачи-приемки выполненных работ.

3.7 Сопровождение Redmine

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

Перечень условных обозначений, сокращений и терминов

Обозначение	Описание
Объект внедрения	Общество с ограниченной ответственностью «Корпоративные системы Плюс»
ОС	Операционная система
Redmine	Система автоматизированного управления службой технической поддержки.
ПО	Программное обеспечение
РФ	Российская Федерация
СУБД	Система управления базами данных
ТЗ	Техническое задание

Просмотров работы: 8151

Код для цитирования:

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

РАЗРАБОТКА ПРОЕКТА ПО ВНЕДРЕНИЮ СИСТЕМЫ REDMINE В ДЕЯТЕЛЬНОСТЬ ОТДЕЛА ПРОГРАММИРОВАНИЯ ООО «КОРПОРАТИВНЫЕ СИСТЕМЫ ПЛЮС»

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