Первая часть поста будет теоретической — о подготовке к вводу в эксплуатацию, вторая часть о настройке системы.
1. Анализ текущей деятельности отдела
Пару слов о компании:
Основное направление — строительство, постоянный штат >150 человек, >5 удаленных объектов.
О самом отделе:
В отделе работает 6 человек:
- 1С программист — решает вопросы по внедрению полезного софта для нужд компании;
- Специалист технической поддержки — ваш покорный слуга, основное направление — поддержка пользователей, второстепенно — разработка документации отдела и т.д.;
- Сетевой администратор — администрирование серверов компании, телефонии и т.д.;
- Веб-разработчик — отвечает за сайт компании;
- Специалист по инфраструктуре — внутренняя инфраструктура компании;
- Руководитель службы ИТ.
Вывод:
В результате знакомства с обязанностями сотрудников было выведено четыре основных направления для настройки и использования системы:
- Поддержка — сюда входят запросы на изменения, инциденты, критичные инциденты. Крайний срок для такого типа обращений устанавливается согласно каталогу сервисов (о нем ниже);
- Сопровождение — внесение изменений в используемые системы, ресурсы, настройки оборудования. Крайний срок устанавливается ответственным за решения заявки специалистом;
- Проекты (отдельный модуль GLPI) — работа над новыми проектами. Заданные критерии для определения проекта: есть время начала и время окончания, есть четкие задачи (вехи проекта), есть группа участников, есть цель. Крайний срок устанавливается проектной группой;
- Задачи руководителя отдела своим сотрудникам.
Также было принято решение оказания многоуровневой поддержки. Изначально рассматривался вопрос одноуровневой поддержки, но в таком случае обращения дублировались.
2. Подготовка к внутренней настройке системы GLPI (теория, документация)
Первый этап ввода системы в эксплуатацию — это описание теоретической части работы системы и работы с системой. Не буду кривить душой, многое вещи документировались уже в процессе настройки системы (как раз из-за отсутствия туториала по данной системе).
Каталог сервисов:
В лучших традициях itil было принято решение составить каталог сервисов компании и описать оказываемые услуги. После чего прописать метрики, SLA для заявок, ответственных за решение задач. Каталог сервисов имеет следующую структуру:
- Вкладка «Сервис» — наименование сервиса, например, почта, 1С, телефония и т.д.;
- Вкладка «Услуги» — услуги, оказываемые в рамках сервиса, например, настройка учетной записи, предоставление доступа и т.д.;
- Вкладка «Пользователи» — описание групп пользователей, использующих сервис, например, топ-менеджмент, администрация, канцелярия и т.д.;
- Вкладка «Доступность» — описание уровня доступности сервиса, например, 24х7, 5х40 и т.д.;
- Вкладка «Влияние» — описание уровня критичности сервиса, влияния на другие сервисы, влияние на бизнес-процессы компании;
- Вкладка «Ответственные» — ответственные за оказание услуг специалисты;
- Вкладка «Метрики» — описание измеримых метрик, например, время реакции на обращение, максимальное время решения обращения, допустимое количество обращений в конкретный срок и т.д.
Типы заявок:
Далее был процесс разделения заявок/обращений на типы:
- Запрос — все заявки на изменение чего-либо, например, предоставление/изменение прав доступа, установку программного обеспечения и т.д., решение таких обращений в режиме 5х40;
- Инцидент — временная приостановка доступа или работы сервиса для 1-3х человек единовременно, решение таких обращений в режиме 5х40;
- Критичный инцидент — недоступность сервиса для 4х и более человек единовременно, решение таких обращений происходит в режиме 24х7.
Группы:
Разделение отдела на группы (с заделом на расширение штата) и назначение ответственных:
Так как было принято решение использовать модель многоуровневой поддержки с разным направлением работы и взаимодействия с системой glpi, было выделено несколько групп:
- Инфраструктура — сюда вошли: сетевая инфраструктура, разработка стандартов, поддержка шлюзов, поддержка сетевого оборудования. Ответственный — сетевой администратор;
- Телефония — обслуживание АТС, администрирование абонентов, стыки с call — центром. Ответственный сетевой администратор;
- Пользователи и пользовательское оборудование — здесь собраны установка и поддержка рабочих мест, подключение периферии, ремонт техники, замена расходных материалов и т.д;
- Серверная инфраструктура — ответственный специалист по инфраструктуре;
- Веб ресурсы — создание, поддержка и сопровождение. Ответственный веб-разработчик;
- Корпоративные информационные системы. Разработка и релизы, администрирование прав пользователей, работа с подрядными организациями. Ответственные — 1С разработчик.
- Сторонние ИТ-услуги. Мобильная связь, КПД, Интернет — это то, что находится на аутосорсе.
Данное разделение позволило разграничить зоны ответственности и снять с повестки дня вопрос — почему сотрудников контролирует их коллега.
SLA:
Дальше наступило время проработки SLA (крайнего срока обращений). Ниже я привожу факторы, которые повлияли на установку SLA конкретно в нашем случае.
- Местоположение заказчика. Некоторые вопросы требуют выезда к заказчику на площадку, соответственно крайний срок для таких обращений закладывался с учетом времени в пути +20% времени от обычного SLA;
- Критичность/влияние — SLA для обращений, оказывающих заметное влияние на бизнес-процессы компании устанавливался минимально возможный срок решения (в рамках разумного);
- Ответственность за сервис. Здесь имеется ввиду чей сервис недоступен — наш или провайдера. В случае недоступности сервиса со стороны провайдера, например, интернет, SLA брался из договора оказания услуг.
Вот эти три показателя изменяли SLA в большую или меньшую сторону. Разумеется, SLA в каждой компании будет свой, здесь я просто обозначил те позиции, на которые, на мой взгляд, стоит обратить внимание.
После проработки данной теоретической части я приступил к внутренней настройке системы. Об этом во второй части.
Комментарии (33)
Sergey-S-Kovalev
12.10.2016 19:51Я сходу обозначу все грабли внедрения сервисдеска, которые я увидел в вашей статье:
1. Отсутствие ожиданий от реализации внедрения. Вы сами не понимаете зачем оно вам нужно. Поэтому у вас в статье описывается внедрение сервисдеска ради сервисдеска. Нет четкой цели — «Для чего?». Что это даст бизнесу и тем 150 пользователям? Что это даст отделу ИТ?
2. Реанимация. В вашем же случае некромантия. Если первый раз был при текущем начальнике, то и в этот раз вы просто будете вливать свои силы в мертвую тушку. Возможно она даже будет шевелиться.
3. «Внедрением» занимается самый малоопытный и молодой член команды. При нормальном подходе к проекту внедрения сервисдеска привлекают тех кто ооочень хорошо знает, что и как в компании работает. Именно привлекают для внедрения, а не опрашивают или смотрят должностные обязанности.
4. ITIL/SLA/KPI и прочие страшные слова без первоначальной аналитики того как реально работает helpdesk в организации бесполезны от слова совсем. Если все это пишется и регламентируется до внедрения самого продукта и прописывается в его настройках до начала использования, то это еще один гвоздь в крышку гроба реализации проекта.
5. Многоуровневая поддержка в ИТ отделе из шести человек у которых строго определенные роли. Я не увидел у вас в статье наличие каллцентра, а в списке сотрудников отдела ИТ — диспетчеров. Т.е. опять ложное целеполагание.
6. «ITIL-факап» — это когда бизнес натягивают на ITIL, а не ITIL на бизнес как в общем то рекомендует эта методология. Т.е. нет понимания как работает методология в принципе. Но все себя мнят эффективными же менеджерами. Эффект будет закономерен.
7. «Бесплатнейший, опенсорс, фри-фор-алл». Их всех объединяет ровно одна вещь. Ужасный, не логичный UI. Нет, серьезно. Если конечно слаще морковки в жизни ничего не жрать, то даже очень ничего.
8. GLPI. Зашел на glpi-project.org, а мне провайдер сказал, что роскомнадзор заблочил данный сайт, хотя в реестре РКН поиск его не нашел. Я даже добрался до демо и повтыкал его. Да, действительно, что бы им пользоваться нужны мануалы, даже для специалистов.
Резюмирую, несмотря на то что вы там внедрите, но использовать это опять никто не будет, то вы хотя бы нормальный продукт используйте: ManageEngine ServiceDesk Plus Вдруг, дело было в UI :))))
Есть бесплатная версия этого вылизанного годами коммерческого продукта, которым пользуются такие неизвестные компании как Xerox / Honda / Scania / Dell / Siemens / Vodafone. И в отличие от OTRS, который пользуют не менее именитые компании он не требует напильника. Все инсталляции OTRS которые я видел всегда пилились внутренними разработчиками, потому что стоком пользоваться невозможно.
Бесплатная версия без регистрации — до 5 специалистов, если зарегаться и получить годовой ключ (продлевается без проблем сколько угодно раз в год на год) то будет ограничение в 100 одновременно работающих специалистов. Количество активов и авторов заявок не ограничено.
Fanta
12.10.2016 21:42Вот в комментах каждый 2й умнее 1го :)…
А как "правильно готовить" сабж в СМБ-секторе? У вас есть чек-лист и "роадмап" или мастхев шаги по внедрению?
Поделитесь.
Думаю многим это спасет время/нервы!Sergey-S-Kovalev
13.10.2016 06:07При внедрении сервисдеска все очень просто:
— Определиться зачем оно вам? Я непосредственно про начальника ИТ.
— Развернуть портал. (минимум: подключить почту, настроить шаблоны ответов/подтверждений/уведомлений, подключить к AD, создать группы, наполнить их специалистами, требование заполнять поле Решение при закрытии заявки)
— Провести обучение специалистов (причем на использование продукта полчаса, и еще полтора вообще на логику работы и хождения заявок) (если продукт требует обучения всему функционалу специалиста более получаса — замените продукт)
— Приказ по организации о использования системы подачи заявок через почту, портал и если все это не доступно, по телефону.
— Воля начальника ИТ что бы задачи не ставились в обход сервисдеска. Специалисты должны работать только по задачам зарегистрированным в сервисдеске. Особенно если это задача внутри отдела ИТ.
— Подождать пару месяцев.
Теперь вы МОЖЕТЕ начать ВНЕДРЯТЬ сервисдеск.
Потому что за пару месяцев у вас появится:
1. История заявок, информация по работам по каждому специалисту, информация о хронической проблематике на рабочих местах пользователей, объем нагрузки на специалистов, понимание прозрачности работы ИТ отдела. Информация о узких местах в ИТ инфраструктуре.
Все это в виде понятного, реального отчета/графиков/аналитики.
2. Понимание у начальника ИТ чего ему еще не хватает (фильтры автоназначения на группы и сотрудников, категории/подкатегории/позиции при описании заявки что бы заполнялись, авторассылка отчетов, контроль выполнения задач от VIP, мониторинг определенных проблем критичных для его отдела)
3. Понимание, где процесс подачи заявок факапится (например, главбух категорически отказывается подавать заявки через СД, и в случае чего сразу реализует телефонное право через звонок ген/зам или просто директору)
4. Понимание кто из своих будет допиливать продукт на регулярной основе и требует ли это отдельного обучения.
— Все, теперь можно по честному внедрять, с проектной инциативой, паспортом проекта, описанием рисков и бизнес процессов. И я вам скажу что пока отдел ИТ часть организации и бизнеса, никаких SLA и KPI внедрено не будет. Они могут быть расписаны, описаны, настроены, но всем будет нас целая рать, пока их заявки будут выполняться в приемлемое время. На ITIL кстати тоже всем пофиг.
А для начальника ИТ должно быть понимание, что сервисдеск это полная прозрачность работы его отдела. Скажем так, не все хотят этой прозрачности.
Повторюсь, это смб, примерно до 2500-3000 пользователей.Sergey-S-Kovalev
13.10.2016 06:14Описал очень грубо. Хоть статью пиши.
Потому что раздел про риски проекта легко переваливает за десяток-другой пунктов.
pan_KOST
13.10.2016 10:29Если попробовать сократить описание рисков ( отправив читать соответсвующие книги или хотя бы ИТ-скептика), думаю — многим будет интересна статья, особенно с тем учётом, что подобных я как то на хабре и не упомню.
Особенно в разрезе «для малых компаний»
Quattro805
13.10.2016 12:41Спасибо, я попробую во второй части описать непосредственно внутреннюю настройку системы, т.е. мануал — что, где находится и как это сделать, после опишу те проблемы с которыми я столкнулся уже внутри отдела.
Aleksei_Mikhailov
13.10.2016 12:01Сергей, замечательные рекомендации.
По-моему, автор достаточно просто и базисно описал старт внедрения. Где именно его описание противоречит вашим добавлениям?
Почему вы думаете, что у автора нет или не будет поддержки руководителя?
Все описанное вами можно счесть вторым, организационным этапом внедрения, верно?
Quattro805
13.10.2016 12:00Я понял ваш вопрос, попробую сформировать что-нибудь похожее в конце второй части (может дополнением)
Quattro805
13.10.2016 12:001. Что касается ожиданий. Цели внедрения прозрачны — улучшение качества услуг, упрощение взаимодействия с пользователями и т.д. На данный момент при опытной эксплуатации есть результаты. Нет больше обращений с неограниченным сроком решения, нет задач на которые сотрудники ИТ отдела забивают/забывают.
2.Реанимация. Здесь не столько реанимация, сколько настройка системы после её развертывание, приведение к стандартам и потребностям компании. Как я написал выше, у руководителя в определенный момент появилась более приоритетная задача.
3.Внедрение. Тут не очень согласен про малоопытность. Каких-то конкретных особенностей отличающих работу данного отдела от отдела в других компаниях не так много. Есть большой опыт и работы с сервисдеск системой (правда HPSM) и частичный опыт внедрения. Здесь же я пробую (есть возможность) в том числе свои силы.
4.Как я писал — многие документы доделываются уже непосредственно во время работы системы. В том числе и SLA. Но есть те показатели которые были известны заранее, например по услугам провайдеров.
5. Есть план развития отдела, согласованный и проработанный с руководством. Поэтому система внедряется немного с заделом на будущее. Но без фанатизма.
6. Не пытаюсь натянуть бизнес на ITIL ни в коем случае.
7,8 — GLPI достаточно не плохой продукт в своей категории, конечно есть вещи которых в нем не хватает, но на данном этапе это не критичные вещи. Что касается использования сотрудниками — используют. Есть большое количество плагинов позволяющих доделать систему, добавить функционал (напишу отдельно), а что касается мануала — после того как я настраивал систему и не нашел нормальных мануалов — решил все таки расписать что и как делал, для тех кто столкнется с данной системой.
В любом случае спасибо за содержательный комментарий, я обязательно также посмотрю рекомендованную вами систему.Aleksei_Mikhailov
13.10.2016 13:55К тому же, именно по данным статистики теперь уже систематизированных обращений можно предоставлять отчет работы ИТ. Вот в этом и есть опосредованная необходимость «бизнесу».
workoff
12.10.2016 22:59Чего делает ваш 1С Программист?
berlevdv
13.10.2016 12:01Лично меня больше интересует что делает их руководитель в столь разностороннем отделе.
Quattro805
13.10.2016 12:02У него есть отдельный проект, но в силу определенных запретов не смогу его описать) может быть позже)
asolokha
13.10.2016 12:01Spiceworks и никаких гвоздей…
Кстати, OCS+GLPI на 200 раб. мест с десятком филиалов была внедрена успешно, но все ныряли в Spiceworks
alexkuzko
Напишите еще, а есть ли у вас Jira? Я очень часто вижу что ее используют в фирмах для трекинга проектов и она фактически является точкой входа. Не будет ли дублирования функционала? Как вы решали этот вопрос?
Я тоже хочу попробовать внедрить OCS+GLPI в существующей компании, где учета нормального нет, есть только централизованная джира, и несколько важных для работы сервисов. Даже AD нет :) (работники сидят на всех основных платформах: Windows 7-8-10, Mac, Linux всех мастей, по убыванию).
pan_KOST
А сколько всего у Вас в компании работает человек и сколько ИТ-сервисов уровня инфраструктуры и приложений?
Кстати, AD *nix и Mac вполне себе умеют через LDAP-коннекторы. А современные версии, по моим данным, это умеют «почти» из коробки без излишних «танцев с бубном»
alexkuzko
Как минимум гит, гипервизоры, та же джира с вики и прочие.
Я знаю что AD можно и на самбе поднять (и именно в эту сторону смотрю), но не получится ли в итоге какой-то скрытый головняк?
Еще хочется использовать RADIUS для авторизации по портам (802.1x) и wifi (EAP), он как раз будет прослойкой между AD.
Т.е. уже есть ощущение что контроль начинает теряться (сотрудников около 50, машин столько же, еще около сотни разных устройств вроде телефонов), но еще нет понимания с какой стороны лучше зайти. Робко поглядываю в сторону тонких клиентов…
Моя стезя системное администрирование, тут вроде как и мое, но не совсем (у меня никсы всюду, веб-сервисы, базы данных, деплой и т.п. — т.е. я с точки зрения пользователя смотрю редко). Сейчас изучаю разные вещи чтобы попытаться вникнуть в тему, но не хочется просто взять и поставить AD чтобы было «как у всех» — хочу понять что именно я смогу получить, и какие минусы будут.
pan_KOST
Как уже описано Sergey-S-Kovalev немного ниже — первые шаги надо смотреть по его плану, с которым я целиком и полностью согласен.
От себя добавлю — самое главное — п.1 — ЗАЧЕМ это всё бизнесу. Даже не ИТ-отделу.
PS. Если бизнесу не нужно от слова «совсем», то можно на всё забить.
Без настоящей, деятельной поддержки уровня гендиректора небольшой компании — ничего не взлетит.
Sergey-S-Kovalev
Я все таки поправлю по п.1. Бизнесу сервисдеск не нужен. Он им денег не приносит. Сервисдеск нужен директору/начальнику по ИТ.
Для эффективного внедрения сервисдеска нужно ровно две причины: Что бы запросы от пользователей не терялись, и что бы жопа каждого первого ИТ специалиста была железобетонно прикрыта от необоснованных наездов от тех, чъе слово весит больше стоимости ИТшника в организации.
В первом случае — забытые задачи от руководства и начальства грозят наказаниями и портят карму.
Во втором случае — это ситуации связанные с тем, что начальник другого отдела может на совещаниях перед гендиром из раза в раз кидать фразу, что мол задачу ИТшнику поставил, а он подлец не сделал. Чем ставит начальника ИТ в уязвимое положение в коллективе. А при разборах выяснится, что задачу никто не ставил, либо ставилось в форме типа иди туда не знаю куда, почини то, не знаю что. Починить починили, но не то и не так ему хотелось. Про то как юзают сотрудники бухгалтерии 1Сника я вообще молчу. И бухгалтер, и расчетчик часто в одном лице, а зарплату за одного получает.
Итого. Бизнесу сервисдеск не нужен, он нужен ИТ подразделению, что бы наглядно показать на что бизнес тратит деньги и какова эффективность. Исключение: там где ИТ это профильное направление организации.
pan_KOST
Тут всё зависит от бизнеса, на самом деле.
Если ИТ-отдел — это чисто техническая вспомогательная служба во главе с главным сисадмином, то да, бизнесу на этот отдел как то по барабану, а если в сферу ответственности ИТ входят бизнес-процессы и в той или иной степени менеджмент качества, то в этом случае ИТ — это бизнес-партнёр.
Лично для меня -сервис-деск — это всего лишь один из «интерфейсов», пускай и один из ключевых, для взаимодействия пользователей и ИТ-отдела.
Quattro805
Полностью согласен с комментарием. ИТ отдел в компании в данном случае очень тесно завязан на бизнес-процесс.
И одна и целей внедрения — как раз упорядочивание и упрощение процесса взаимодействия с пользователями.
Надо отметить, что как ни странно, сотрудники компании очень лояльно отнеслись к подобной системе, и сейчас уже на этапе «опытной эксплуатации» активно её используют.
pan_KOST
В этом случае, в штате компании необходим сотрудник, отвечающий за бизнес-процессы как таковые и понимающий, обе стороны — и бизнес и ИТ. Будь то специалист по бизнес-процессам или бизнес-аналитик, но его не должны пугать такие слова как BPMN,ARIS, IDEF и одновременно для него должно быть родными слова AD, XML, .NET/Java, SOAP, REST, SLA, инцидент, проблема, управление конфигурацией и т.п.
PS. Я бы сначала определился со списком процессов взаимодействия бизнеса и ИТ и о том, как они должны быть реализованы. Т.е., ЧТО ИМЕННО хочет контролировать бизнес, в каком виде, как часто. Взаимодействие с пользователями — это лишь 50% работы ИТ-отдела, а
остальное — это уже взаимодействие с бизнесом и собственные внутренние процессы.
Кстати, очень рекомендую достаточно простую для понимания книгу — Роб Ингланд (ИТ-Скептик), «Овладевая ITIL». Найти, где её скачать несложно ( распространяется в pdf ).
По итогам прочтения и ответа самому себе и ИТ-директором на вопросы из неё можно уже делать детальный план и выбирать способы достижения целей проекта упорядочивания деятельности
pan_KOST
В этом случае, если он не является его непосредственным начальником, то руководитель ИТ просто ставит его задачу ( проект? ) в очередь, правильно расставив приоритеты.
Единственное — это реалистично только для достаточно большой компании со зрелым управлением бизнесом. В ином случае — это всего лишь мечта об идеальном мире
Sergey-S-Kovalev
Вы не поняли моей фразы. Суть в том, что есть проблема, но ИТ отделу ее не озвучивают. А на совещании говорят что ИТ касячит. Слово рядового специалиста против слова начальника другого отдела. Результат, кому поверит гендир — предсказуем. Что потом будет делать начальник ИТ уже не важно. Негатив в карму вброшен, и метода защиты от такого без сервисдеска нет.
Неоднократное повторение ситуации формирует мнение, что ИТ начальник не контролирует процессы, и вполне может пойти под замену.
pan_KOST
Мы оба друг друга не до конца поняли.
Основной мой посыл — начальник ИТ в нормальной компании — это топ-менеджер и выше его только генеральный/исполнительный директоры, совет директоров и т.п.
Т.е. любой другой руководитель/директор — по факту, это один уровень и в этом случае споры решаются уже в несколько ином ключе.
Из своего опыта для меня логичным и нормальным является тот вариант, когда ИТ-менеджер выступает посредником между бизнесом и ИТ и решает проблемы бизнеса с помощью ИТ.
НО, я категорически не принимаю вариант, когда ИТ-руководитель находится в оппозиции бизнес-руководителям и всеми руками держится за свою власть и место даже в ущерб бизнесу.
Sergey-S-Kovalev
Я бы тоже хотел, что бы в каждой первой окружающей меня компании наравне с замами по экономике, финансам и безопасности существовали еще и замы по ИТ, но все как то больше начальники департаментов и управлений, и в подавляющем большинстве начальники отделов ИТ. Тогда бы и разговор был на равных. Но увы, работаем с тем что есть.
Aleksei_Mikhailov
Сергей, но с другой стороны именно к бизнесу придет ИТ с запросом по бюджету на устранения проблемы, выявленной на основании повторяющихся инцидентов на одном и том же блоке устройств. И именно статистика Сервисдеска сможет показать экономическую эффективность трат: например, когда несколько раз чинить уже дороже чем купить новое.
Sergey-S-Kovalev
Не вижу противоречия. ИТ там себе что то поставило, регистрирует и контролирует. Подтверждает свои запросы документами — еще лучше.
Quattro805
По п.1 — что касается зачем это бизнесу — бизнес очень хочет видеть чем занимается отдел + планирует внедрять показатели эффективности. Также само качество услуг оказываемых отделом ИТ стало падать, появились бессрочные задачи, игнорирования задач и т.д.
По большому счету задачу контроля и улучшения работы отдела поставил исполнительный директор компании, соответственно и основная поддержка с его стороны. Что касается руководителя — на момент первоначального развертывания системы у него появилась более важная и более интересная задача, поэтому проект был «заморожен».
Sergey-S-Kovalev
Вы как то обозначили эти нюансы в статье. :)
Quattro805
Как я и писал, в компании 150 человек, штат расширяется, критичных сервисов около 40, есть также не критичные.
Quattro805
Jira не используется, что касается OSC — используется модуль fusion inventory, единственная проблема которая возникла с плагином — каждое обновление системы как новая лицензия.