Так сложилось, что чаще всего на Инфостарте я пишу про управление проектами внедрения. Это и не удивительно, ибо я в-основном занимаюсь как раз управлением проектами. Кстати, в конце августа стартует мой курс по Управлению проектами по 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С? О чем стоит написать подробнее? Какими способами решения проблем можете поделиться?
