Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

20.08.20

Управление ИТ - Help desk: Служба поддержки

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

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

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

По моему опыту наиболее частые проблемы следующие:

  • Продукт передан в эксплуатацию “сырой” и не до конца готовый
  • Запросы попадают в службу поддержки как в черную дыру - и невозможно предсказать, когда они будут выполнены
  • При этом ответственные за поддержку продукта плохо представляют его архитектуру, и изменяют что-то методом тыка.
  • Служба поддержки “ужасно занята”, а чем именно - установить невозможно, поэтому разгрузить и оптимизировать ее работу затруднительно
  • Доработки в-основном выполняются по принципу “изобретаем велосипед, а сверху костыли”, в том числе потому, что всё нужно еще вчера, а ресурсов нет 
  • Все запросы, попадающие в службу поддержки имеют “наивысший” приоритет, исполняются в первую очередь те, чьи авторы наиболее назойливы
  • Разработчики воют, что из-за постоянных задач по поддержке не успевают заниматься разработкой, в результате срываются важные проекты.
  • Непрозрачность процесса. В каком статусе моя заявка? Сколько будет стоить моя задача? Когда будет результат? Кого и как пинать, чтоб было?
  • Разделение труда, процессы, технология. Все делают всё, очередь по принципу “свободная касса”, тестирует пользователь, плачет по результатам он же.
  • KPI назначаемые по принципу “пол-палец-потолок”. Мерило загруженности = насколько вспотевшие или веселые спецы. Оценка удовлетворенности =  количество матов в адрес техподдержки. Мерило эффективности = количество успешно потушенных пожаров. Премия = Удовлетворенность начальника х Мерило эффективности (см.выше) Коллеги, ваши предложения по дополнению списка? Пишите в комментариях!

 

Итак, проблема знакома, теперь вопрос - как ее можно решать? 

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

А именно - старое доброе управление информационными технологиями как услугой, то бишь ITSM (IT Service Management).  То есть систематизированное управление ИТ, с фокусом внимания на том, чтобы пользователям ИТ-услуг было максимально хорошо. 

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

В чем суть: 

Мысль номер раз. 

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

Ибо, как это ни обидно осознавать некоторым ИТ-специалистам, мы с вами в первую очередь - обслуживающий персонал. Который не приносит денег компании (не рассматриваем ситуацию реализации внешних проектов), а исключительно является Центром расходов, деньги компании тратящим. Также как и другие вспомогательные службы - бухгалтерия, HR и т. д. и т. п.  В этом нет, на самом деле, ничего обидного - это просто факт, который нужно принять. Главная цель работы ИТ - чтобы бизнесу было хорошо и удобно. А еще - стабильно. И выбирая приложения и “железо”, которое мы используем, мы ориентируемся в первую очередь на ценность для бизнеса. Например, что CRM-система обеспечивает оперативное и качественное обслуживание клиентов, управление складами - возможность своевременно проверять наличие продукции и поддерживать остатки, а электронный документооборот - доступ к документам для заключения сделок и поддержи контрактов. И так далее.  Ценность состоит из двух компонентов: это полезность - то есть, та польза, которую ИТ-услуга приносит пользователю, и гарантия - то есть уверенность в том, что эта услуга будет оказана, невзирая на внешние обстоятельства.  Сами по себе программные продукты и компьютеры ценности не содержат, ценность в том, что мы с их помощью делаем. 

Мысль номер два. 

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

Управлении каталогом и уровнем услуг. И Управлении уровнем сервиса (Service level management). 

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

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

Мысль номер три. 

Ключевой инструмент управления уровнем сервиса - это договоренности об уровне сервиса - Service Level Agreements (SLA).

Мы можем говорить о том, что система управления ИТ у нас четко выстроена, когда у нас есть понимание о том, какие услуги каким образом оказываются. Допустим, что критичные сервисы работают 95% времени, и устранение возникших проблем происходит в течение 3 часов. А основные сервисы работают 90% времени, и устранение возникших проблем происходит в течение рабочего дня и т. п. 

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

Кстати, образцы SLA можно скачать в том числе на Инфостарте, см. каталог. 

Мысль номер четыре.

Нам важно выстроить взаимодействие бизнеса с ИТ-подразделениями. Его можно разделить на три процесса:

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

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

Что здесь важно? Важно не смешивать управление инцидентами и управление проблемами - управление инцидентами призвано максимально быстро вернуть системе работоспособность, а управление проблемами - решить проблему системно. И крайне не рекомендуется, чтобы эти две задачи решал один и тот же человек - ибо это токсичные роли, для работы с инцидентами и проблемами используются прямо противоположные подходы. Для инцидента - “давайте быстро приделаем какие-нибудь костыли, чтобы пользователь смог пока работать”. А для проблемы - “давайте мы найдем первоисточник/напишем обработку/переставим систему/реорганизуем процесс и т. п.”. И KPI у тех, кто отвечает за устранение инцидентов и устранение проблем будут разные - первым нужно решить вопрос быстро, а вторым - надежно.

Рассказывают, что на заводе Генри Форда бригада, ответственная за устранение неполадок, получала зарплаты только за время простоя. Поэтому они были заинтересованы устранить проблему как следует, чтобы она не возобновлялась как можно дольше - вот, мне кажется, прекрасный пример KPI на решение проблем ))). 

Мысль номер пять. 

Разумеется, всем тем, о чем я рассказала, ITSM не исчерпывается.  

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

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

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

Канбан в условиях российской действительности

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

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

Мысль номер шесть. 

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

 

Минутка саморекламы. Совместно с одним учебным центром я в свое время разработала учебный курс “Разработка ИТ-стратегии”. Когда-нибудь презентую его на Инфостарте (пробные занятия уже обкатывала на нескольких наиболее везучих ИТ-руководителях). Кстати, кому будет интересно участие в курсе - оставляйте заявки!  А пока могу только предложить желающим принять участие в курсах по “Управлению ИТ-проектами”. Про поддержку там, честно скажу, будет несколько основных моментов: во-первых, говорим вообще про границы между проектами и эксплуатацией. Во-вторых, подробно разбираем канбан-систему, снижение объема незавершенных задач и прочие вопросы службы поддержки. В-третьих, говорим про общие принципы, которые помогут организовать ИТ-подразделения: оценка и повышение уровня организационной зрелости, внедрение регулярного менеджмента и т. п.  В-четвертых, разбираемся как создать и развивать команду.

 

Коллеги, поделитесь в комментариях вашим опытом: какие еще проблемы больные при поддержке продуктов 1С? О чем стоит написать подробнее? Какими способами решения проблем можете поделиться?

 

См. также

Внедрение единого центра обслуживания бизнеса в авторитейле

Help desk: Служба поддержки Бесплатно (free)

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

29.01.2024    390    0    user1063453    0    

2

Сколько нужно сотрудников IT на телефоне для компании 4500+ сотрудников

Help desk: Служба поддержки Бесплатно (free)

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

29.01.2024    499    0    user1063453    1    

2

Как выглядит ITSM-портал в XXI веке

Help desk: Служба поддержки ITIL Бесплатно (free)

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

29.01.2024    547    0    user1063453    0    

1

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

Сопровождение Help desk: Служба поддержки Бесплатно (free)

Исполнительный директор компании «Гильдия консультантов» Николай Елатонцев на конференции Infostart Event 2021 Post-Apocalypse рассказал, как организовать процессы техподдержки, чтобы это направление бизнеса стало прибыльным и прогнозируемым. Он поделился опытом, как правильно составить договор на техподдержку, зачем фиксировать каждую транзакцию по задаче, и как уведомления помогают в исполнении SLA.

13.03.2023    1971    0    nelatontsev@webgk.ru    8    

13

Service desk in ITIL 4: что изменилось?

Help desk: Служба поддержки Бесплатно (free)

ITIL – одно из популярных руководств по управлению ИТ-услугами и выстраиванию эффективного менеджмента. Появилась уже четвертая версия этой библиотеки, и по сравнению с прошлыми в ней много нового, в том числе для Service desk. О том, что изменилось, рассказал автор учебных курсов по управлению ИТ-услугами и тематических публикаций в периодических изданиях, автор и переводчик книг по управлению ИТ, архитектор ITIL 4 Роман Журавлев.

29.10.2021    6261    0    user1455784    0    

10

Что такое качество разработки и качество поддержки? Статья 2

Help desk: Служба поддержки Бесплатно (free)

Это вторая из 8 статей про разработку в сфере 1С. В данной статье будут раскрыты следующие вопросы: 1. Ошибки в решениях в пользовательском режиме и их причины. 2. Технические ошибки при разработке решений в 1С. 3. Мы закрыли 100 заявок за 1 день. Есть ли польза от такой поддержки? Польза или вред от SLA.

30.06.2020    3406    0    biimmap    5    

17

История создания службы поддержки, или "Почему лучшие практики не работают?"

Help desk: Служба поддержки Бесплатно (free)

Чем больше услуг для внешних и внутренних клиентов предлагает бизнес, тем сложнее их обслуживать. Правильный выход в такой ситуации – создать сервисную техническую службу, благо, примеров создания такой структуры очень много. Но даже если вы возьмете лучшие практики и внедрите их у себя, это не значит, что проект «Служба технической поддержки» взлетит. Почему лучшие практики не работают, участникам конференции INFOSTART EVENT 2019 Inception объяснил руководитель службы технической поддержки в группе компаний «Доброфлот» Арсен Сазандрашвили.

03.04.2020    7297    0    Arsen1986    3    

10

Как создать идеальную службу поддержки бизнеса

Help desk: Служба поддержки Бесплатно (free)

О том, насколько хорошо работают бизнес-процессы, можно понять по реакции пользователей: если они довольны - значит, все хорошо. А что является главным связывающим звеном между бизнесом и пользователями? Конечно, служба поддержки, и чем лучше вы организуете ее работу, тем удовлетворенность пользователей будет выше. О том, что как создать идеальную службу поддержки, на конференции INFOSTART EVENT 2018 Education рассказал Сергей Харитонов из ГК «Агат».

26.07.2019    6030    0    user1063453    0    

8
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. duke-81 21.08.20 12:08 Сейчас в теме
Актуальна проблема удаленной работы сотрудника и его прокрастинация. Решение = Все врут! Поэтому => Никому не верь. Становиcь их блогером, на которого они подписаны, и жёстко мотивируй! =)))
2. Yashazz 4709 21.08.20 18:07 Сейчас в теме
Очередное теоретическое философствование. Ну, на словах-то оно всегда красиво да правильно. А на практике начинаются такие приключения, которые всю эту заумь сводят к нулю, а то и выворачивают ситуацию так, что от подобных советов делается ещё хуже.

На самом деле реально работающий рецепт всего один, и он очень давно известен.
3. Brawler 454 22.08.20 19:57 Сейчас в теме
Ну помечтали, можно и дальше пойти тянуть всю контору на плечах ИТ отдела и исполнять функцию справочного бюро для всей фирмы (ну реально грубо говоря прутся со всеми вопросами, только уборщицы не приходя и не спрашивают, где половые тряпки брать чтобы туалеты отдраить)
user1011767; AnnaSmailova; user635667; muskul; katrice; +5 Ответить
4. Somebody1 68 24.08.20 07:04 Сейчас в теме
Это что было? Краткое изложение ITIL или реклама курса по управлению IT-проектами?
Оставьте свое сообщение