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

Компания, в которой трудится наш доблестный ИТ департамент, — дочка Корпорации, входящей в Fortune 500. В родной стране Корпорации, за тридевять земель от нас, есть решительно все: ИТ стратегия, ИТ политики-стандарты-процедуры, своя ИТ компания полного профиля, свой Tier 3 ЦОД, прямые контакты и ценовые соглашения с основными производителями ИТ оборудования и ПО, быстрые и дешевые поставщики оборудования и услуг, ловкие интеграторы, толковые консультанты по внедрению, и т.д. и т.п. — в общем, там рай. От нас ждут и требуют того же уровня, но повторюсь, мы работаем в Центральной Азии и у нас тут пока сплошная стройка.

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

К чему я все это рассказываю и причем тут GLPI? Я просто люблю рассказывать истории с подробностями. Можете спокойно пропустить пару абзацев.

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

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

Все очень старались. Работы было много: пока временщики отбивались от рутины, мы, то есть немногочисленный собственный ИТ персонал компании, координировали работы по обустройству нового офиса (4 этажа, около 2 тыс кв.м., около 400 рабочих мест) и с минимальным даунтаймом для основного бизнеса переехали и продолжили работу на новом месте. На самом деле, было не до хелпдеска, так что я даже не помню что у них там стояло и как оно работало. Особых проблем с техподдержкой тоже не припоминаю. А про глобальные проблемы мы и так не забывали…

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

Контракт предстоял длинный — на 5 лет — так что новые ребята были полны решимости все делать правильно и основательно. И, конечно же, лучше предшественников. Хотя они тоже были, что называется, first-timer'ы. Но хелпдеск они заявили особо еще на этапе тендера и хотели даже развивать его как коммерческую услугу. Благодаря им, кстати, хелпдеск при промышленном объекте у нас стал стал работать в режиме 24х7.

Среди прочего, завязалась дискуссия о выборе платформы хелпдеска. Британцы свой хелпдеск забрали. Хелпдеск временщиков даже не рассматривался. Естественно, я запросил у головного офиса информацию по поводу их хелпдеска. Выяснилось, что они используют CA Service Desk Manager от CA Technologies, их лицензия на нас никак не транслируется, внедрять хелпдеск у нас в обозримом будущем никто не собирается. И вообще, у них масштабная реорганизация. Но по крайней мере, мы теперь знаем чего хотим! Так что совершаем звонок монопольному продавцу софта в стране. Тут начинается, как обычно: что именно вам нужно, где техзадание, почему именно это… Ну, почитали описания продуктов на сайте CA, составили wish list. Через какое-то время получаем коммерческое предложение — там было столько нулей, что продавцы несколько раз перепроверяли их количество со своим поставщиком. И это только за лицензию, сказали они, а что будет стоить внедрение и кто будет внедрять — неизвестно. Обычно, сказали они, лицензия составляет 1/4 часть от общей стоимости проекта — но тут вообще сложно что-то обещать. Ну, стало быть, не судьба… А время-то ушло. А операторы-то пишут тикеты в Экселе.

Лезу в Гугл. Узнаю про GLPI. Ставлю на свободную машину — работает, ну нифига себе! Показываю новым контракторам… Вот за что я не люблю инженеров, так это за то, что они во всем видят проблемы и не способны разделить радость коллеги. Конечно же, мой GLPI какой-то левый, а вот они нашли систему — так это система. Правда, платная, но мы ж по-любому готовы были купить CA? Зато она может то, се, пятое и десятое. А мне-то уже обидно, это что же я, зря ставил GLPI? К тому же было не столько жалко денег, сколько не хотелось связываться с нудной системой согласований и закупки через тендер. А GLPI уже стоит и работает. Почитал, поковырялся в настройках — оказывается, GLPI может это все + прикрутил инвентаризацию, которая мне тоже была очень нужна. Инженеры пошли читать про свой софт и, конечно же, обнаружилось, что легко можно докупить инвентарный модуль. В общем, я выиграл. Пока они искали дополнительные контр-аргументы, я научил операторов пользоваться GLPI и со временем они перестали даже (по крайней мере, при мне) параллельно записывать заявки в Эксель. Но все равно, сначала все заявки аккуратно записывали на бумагу.

В общем, в течение примерно 2 лет у нас работала связка GLPI+OCS. Все это время системой пользовались только операторы хелпдеска — регистрировали заявки в режиме 24х7, эпизодически — главный инженер контракторов, потому что тоже считал такой подход правильным, ну и я. За это время я успел перенести сервера OCS+GLPI на виртуальную машину с переходом на новую версию и Ubuntu и OCS и GLPI. OCS постепенно расставлял агентов через GPO, а я использовал административный ресурс, заставляя техников вносить бухгалтерские инвентарные номера в OCS и GLPI. Помимо этого, я настоял на том, чтобы содержимое складов было внесено в базу GLPI. Таким образом, мы получили связку пользователь/местоположение-серийный номер-бухгалтерский инвентарный список.

Пользуясь плагином Data Injection я списком добавил в GLPI рации, радиостанции и остальное барахло строгой отчетности. Прямо в радиостанции добавил сканы разрешений, лицензии, анкеты и письма. Я принципиально не стал вносить изменений в структуры данных и просто сунул все в категорию Devices (Устройства(?)). Лицензии и разрешения со сроками действия я оформил как контракты — и получил готовые плановые уведомления об истечении сроков действия таких документов. Удобно, но никому кроме меня это было не нужно. У них всегда можно спросить и они ответят. Вот только надо помнить кого о чем спрашивать.

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

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

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

Ввели ротацию персонала внутри команды. Решались 2 задачи: 1) взаимозаменяемость внутри команды, 2) нехватка специалистов на удаленных объектах. Тут бы очень помог общий календарь или расписание дежурств, но ничего такого в GLPI или для GLPI я не нашел.

Внутри команды расписали обязанности. Список обязанностей у нас складывался постепенно. Я уже упомянул ротацию, так вот, мы постарались чтобы каждая роль (или обязанность) исполнялась по крайней мере двумя людьми в разных сменах, так чтобы они меняли друг друга. Обязанности можно отразить в системе либо через группы техников, либо через entities (мы пользуемся английским интерфесом, я не знаю как это слово переведено в русской версии) — это что-то типа OU, организационной единицы в активной директории.

Наша работа состоит из неизбежной рутины и интересных проектов. Рутины должно быть как можно меньше, а проектов — чем больше, тем лучше. Часть проектов предложил я исходя из потребностей конторы, часть народ выдвинул сам. Договорились, что проекты и необходимые ресурсы (время, люди, материалы, деньги, ...) будут согласовываться со мной заранее. Не хочешь заниматься рутиной — бери нужные мне проекты. Нет проектов — занимайся рутиной. Для разделения времени между занятием рутиной и выполнением проектов или планового тех обслуживания задействовали планирование GLPI. Теперь в календаре видно, кто в данное время занят. Для контроля исполнения проектов в GLPI нашелся простой, но симпатичный плагин управления проектами с отрисовкой диаграм Ганта. На проект можно навесить массу системных объектов. Мы только начинаем вписывать проекты в GLPI — и, опять-таки, это пока нужно только мне, потому что народу много, проектов много, а склероз прогрессирует.

Чтобы добиться справедливого распределения заявок, собрали команду в одном месте: до этого техники были распределены по разным офисным блокам. При этом слегка потеряли во времени реагирования на заявки, но добились-таки своего. Договорились, что все заявки и задания раздаются через хелпдеск — так никому не было обидно. Установили простую очередь при назначении заявок свободным техникам. Проанализировали данные по количеству отработанных заявок за единицу времени — появились аргументы для серьезного разговора с некоторыми техниками. И, наконец-то, удалось заставить техников регистрировать все заявки. Не удалось пока заставить их закрывать заявки самостоятельно: это продолжает делать хелпдеск. В свою очередь, хелпдеску объяснили, что теперь не получится записывать заявки на листочек и вносить их в систему в конце смены — иначе совпадет время открытия и закрытия заявки. Хелпдеск вообще у нас — молодцы. Стоило только показать им как можно использовать шаблоны для автоматизации и стандартизации наиболее частых заявок — и они стали самыми благодарными адептами GLPI и лучшими помощниками в дальнейшем развитии системы. Как мне кажется, с минимальными подсказками системы операторы стали чувствовать себя гораздо уверенней. Я планирую использовать высвободившееся у хелпдеска время на присмотр за NMS, на удаленную поддержку, да на что угодно: мне нужно вывести их из-под риска сокращения персонала в кризис, чтоб даже мысли такой у начальства не возникало…

Заявок, кстати, стало больше. И оформлены они стали гораздо лучше. Если раньше раньше заявка выглядела примерно так: что-то случилось у пользователя такого-то — заявка открыта/заявка закрыта, то теперь для доброй половины заявок достаточно выбрать категорию заявки и из шаблона заполняются нужные поля, заявка назначается определенному технику либо группе техников в соответствии с их специализацией, в описании появляется подсказка для оператора. Это может быть типовое описание проблемы, ссылка на документ в базе знаний, список информации, которую необходимо уточнить у пользователя, порядок действий оператора — все, что угодно. Я даже не знаю, стоит ли выдавать все наши блестящие идеи безвозмездно. С одной стороны очень хочется похвастаться, а с другой закрадываются мысли о монетизации… Впрочем, как выясняется, рынок услуг еще уже, чем нам представлялось совсем недавно, ниже расскажу почему.

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

Business rules мы пока не осилили — смысл ясен, функционал нужен, но пока не проходят критерии так, как мы хотим. Не страшно, разберемся.

Нарисовали карту сети в плагине Network architecture. Красиво. Центру иногда хочется зачем-то знать с точностью до порта что куда подключено. Мне однозначно нужно, чтоб такая карта была, чтоб она лежала в определенном месте и была доступна отовсюду (доступ мы, естественно, контролируем). Для Центра, для презентаций, для взаимодействия команд, для полноты охвата системы, и просто на всякий случай. А так у наших сетевиков есть карты в Visio, в Cisco Prime — но это надо у кого-то запрашивать, ждать пока ответят, а вы же знаете этих инженеров — от них сплошной негатив.

Бюджет — можно расписать бюджет вплоть до стоимости отдельных единиц оборудования или материалов или услуг. С привязкой финансовой информации к оборудованию и контрактам. Как по мне, так у нас очень сложный бюджетный цикл. Примерно каждые 2 месяца разные инстанции требуют отчетов с разной степенью детализации. Я обязательно распишу в деталях свой бюджет на следующий год в GLPI. Пока там только 2 статьи: CAPEX и OPEX.

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

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

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

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

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

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

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

Система управления нужна руководителю в том случае, когда свалить ответственность не на кого. В корпоративной среде очень важно на любой «вызов» отреагировать оперативно и аргументированно, а «вызов» могут «бросить» самым неожиданным образом. Это может быть просто требование очередного отчета из центра, а может быть и приглашение в прокуратуру. То есть лучше быть готовым. И коллеги это понимают. Но когда я попытался во время подходящего по теме обсуждения «продать» свое решение своим аналогам в других странах, мне сказали, типа: «Да, прикольно… у нас есть что-то вроде… Но это же freeware или opensource? Его же нельзя использовать в среде enterprise? Все должно быть строго enterprise-grade. Ты на всякий случай GLPI аудиторам не показывай.» А я так на него рассчитывал при прохождении аудита! Главное, это прозвучало из уст «бирманца», который только с месяц назад сам отправил длинное открытое письмо про то, что в условиях мирового кризиса надо переосмыслить корпоративные стандарты, искать новые пути и вообще «think outside the box»…

То есть, казалось бы, вот оно — нашел я GLPI целевую аудиторию, своим уже сказал, что в Бруней поедем GLPI ставить, но и тут засада — если, конечно, мне не подскажут чем ответить на это «вызов»… Поэтому я и сказал, что рынок для GLPI уже, чем мы ожидали. Хотя я лично не вижу никаких нарушений GPL2/GNU, мы даже ничего не меняем в коде — это если озабоченность вызвана типом лицензии.

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

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

И вам спасибо за внимание.