Роб Ингланд продолжает нас радовать своим скептическим отношением к управлению ИТ услугами. На этот раз темой стал Social ITSM – a skeptical view, и я просто не смог удержаться от комментариев.
Вообще говоря, мне не сильно нравится скептический взгляд на вещи. Не нравится просто потому, что если ты чем-то занимаешься, то следует в это верить. Это не значит, что сомнения не нужны. Наоборот, перед тем как принять то или иное решение, полезно как следует посомневаться. Посомневаться, но решение все же принять, и от сомнений перейти к действиям.
Так вот, что же говорит скептик про Social ITSM: « Social media is a communication channel, and not a very good one. Get over it». Если считать корпоративную социальную сеть просто еще одним каналом поступления запросов в IT Service Desk, то пользу извлечь из этого, действительно, трудно. Далее наш ИТ скептик цитирует Jim Finister-а:
«there is a lot of talk about social media and ITSM, but not many ideas for how it can be used in reality, either now or in the future»
и от себя добавляет: «Мне нравится Джим. Это тот самый британец, который в дискуссиях продолжает одной ногой твердо стоять на земле. На него можно положиться»
Хорошо, раз уважаемые эксперты не сумели найти достойного применения социальному программному обеспечению в управлении сервисами, то это попробую сделать я.
Традиционно, ITSM уделяет недостаточное внимание пользователями своих услуг. Полистайте книжки ITIL. Сервисные каталоги там есть, конфигурационные единицы – есть, релизы, изменения, KPIs – много умных слов. А вот пользователи всех этих услуг описаны крайне абстрактно. Кто все эти люди, которые пишут заявки на ИТ-услуги, формулируют SLA и создают запросы на изменения? Как они организованы, чего хотят, зачем им вообще нужны наши ИТ-услуги, в каких процессах они задействованы, какие у них (не у нас, ИТ) показатели эффективности? Ответы на все эти вопросы айтшники представляют себе очень смутно. Согласуй со своим начальником заявку на предоставление ИТ-услуги, и мы её выполним (если сможем) – вот типичный ход их рассуждений. Очевидно, что пользователи потребляют ИТ-услуги для того, чтоб делать свою работу. Индивидуумы объединены в отделы и функции, участвуют в проектах, бизнес-процессах, рабочих группах. Доступ к тому или иному приложению нужен им для выполнения своих служебных обязанностей. Для большинства приложений нет смысла создавать отдельные персонифицированные заявки на предоставление доступа. Добавление сотрудника в ту или иную группу с определенной ролью – уже достаточное основание для предоставления ему набора ИТ-услуг.
Социальное ПО привнесло в организацию идею объединения сотрудников в группы (сообщества). Группы в Интернет образуются по интересам. Группы в Интранет создаются по проектам, процессам, функциям. В социальном программном обеспечении сделано все необходимое, чтоб максимально упростить включение и исключение людей из группы(сообщества), чтоб освободить ИТ-администраторов от функции предоставления доступа (это функция модераторов группы). Остается только использовать этот функционал для организации доступа ко всем остальных приложениям организации. Интегрировать корпоративную социальную сеть с Active Directory, если говорить языком айтишников. Но интегрировать в обратную сторону, т.е. добавлять в группы AD пользователей из групп социальной сети. Корпоративная социальная сеть – это не просто еще одна информационная система, а наиболее эффективный на сегодняшний день способ думать об организационной структуре, проектах и процессах вашей компании. Даже если вы не планируете разворачивать полноценный Интранет, то присмотритесь к этим технологиям при разработке HR-системы вашей организации (Подробнее см. В. Ананьин “Интранет как инструмент корпоративного управления”).
Другой невероятно популярный инструмент социальных сетей – это потоки событий (activity streams). Я всегда считал, что обращения в Service Desk, сообщения систем мониторинга, инциденты – это и есть те самые потоки событий. У традиционных приложений ITSM об этом иное мнение. Устаревшие ITSM системы считают, что всё это записи в базах данных, а потому практически не предоставляют сколь-либо развитых средств для управления потоком обращений или анализа корреляции сообщений об авариях. Люди, которые заняты реальной работой по решению инцидентов, в отличие от поставщиков ITSM решений, давно придумали и реализовали такой функционал. Научились выделять из общего потока инцидентов последствия конкретных аварий, коррелировать события между собой, скоординированно решать проблемы и информировать об этом клиента. Разве что до хэш-тегов и кнопки “Like” пока не дошло. Хотя мне как пользователю было бы намного удобней не дозваниваться до службы Service Desk каждый раз, когда какая-то из ИТ систем недоступна, а увидеть затрагивающую меня глобальную проблему в потоке сообщений о плановых работах и прерываниях сервиса и нажатием одной кнопки на мобильнике подтвердить, что проблема влияет и на меня.
И еще два сценария, о которых я не раз писал в этом блоге. Первый – регистрация обращений, заявок, запросов на изменение, проблем и последующая их обработка. Совершенно неразумно, имея развитые средства issue tracking, приближающиеся к реализации концепции adaptive case management, не представить их в Интранет. Выстраивание деятельности подразделений (не только ИТ) вокруг заявок на оказание тех или иных услуг является на сегодняшний день наиболее простым с точки зрения реализации, но при этом крайне эффективным способом выстраивания бизнес-процессов. По сути своей, заявка на: подключение ИТ услуги, подбор персонала, получение копии трудовой книжки для посольства, доставку корреспонденции в другой офис и т.п. – является тем самым сервисом, о котором сказано столько слов в контексте сервис-ориентированной архитектуры. Если не зацикливаться на задаче прорисовки бизнес-процессов в виде блок-схемы, а уделить внимание регистрации обращений, классификации, анализу результатов исполнения, статистике, то большинство обещаний BPM будет реализовано малыми силами и в короткие сроки. Потом можно моделировать, анализировать и улучшать. Подробнее по теме см. adaptive case management
И, пожалуй, самый очевидный сценарий использования корпоративной социальной сети в ITSM – управление знаниями. Мы в какой-то момент перевели документирование архитектуры компании и ряда приложений (интеграционных сред) на MediaWiki. Не скажу, что все нас устраивает, но задача того стоила. Первое время количество пользователей на ресурсе увеличивалось ежемесячно на сотню. Причем речь идет не о пользовательской документации, а о технических описаниях и руководствах. Никогда не мог подумать, что в компании столько людей интересуется архитектурой ИТ. Другой пример. В 2000 году мы запустили систему для взаимодействия с дилерами, и документацию по системе сделали в виде сайта. Заодно к каждой статье “прицепили” возможность задать вопрос или оставить комментарий. Посадили человека отвечать на эти вопросы. Проект запустили, внимание системе уделять перестали. Через несколько лет человек уволился. Основную систему пару раз переписали, но сайт с документацией и форумом остался жить. Каково же было мое удивление, когда сегодня, зайдя на этот ресурс, я обнаружил новые сегодняшние сообщения.
ИТ-скептик заканчивает свою статью следующими словами:
“Back in the real ITSM world the impact of social media is like rain on the window.
Ho hum.”
Конечно, к новым возможностям можно отнестись именно так. Но можно и приоткрыть окно. Хотя бы для того, чтоб просто узнать, что же там происходит
Разделяю вашу позицию и хотелось бы добавить, что АСМ приятно дополняется социальными сервисами (wiki, activity stream, bookmarks, blogs, tags/tag cloud, ratings, following), которые способствуют самоорганизации участников таких процессов и, как следствие, даже может упрощаться задача контроля результативности/эффективности, т.к. именно социальные свойства: внимание участников к потокам активности, рейтинги, общение в группе и т.п. (“массовый интеллект”) оптимизируют сам процесс. Однако, мне кажется, что всеравно подобная система (АСМ+социальность) должна быть дополнена инструментом для анализа происходящего: затраты времени участников, кол-во подключенных участников к одной теме и др. – чтобы возможно было оценивать финансовые затраты связанные с такой деятельностью, выявлять KPI участников (связывать их с рейтингами и др.) и др…, а если организация большая (>1k сотрудников вовлеченных в такие процессы) – это уже могут быть отдельные, большие темы математического моделирования сообществ, обработки социальных данных и т.п. с неочевидной математикой (типа кластерного анализа, коллоборативной фильтрацией) – похожие аналитические задачи сейчас решают социальные сервисы с целью оптимизации выгоды, а в нашем случае целью будет оптимизация затрат. Хотя, может быть, я усложняю…
Слава, спасибо за комментарий. Я думаю, что на сегодня главная проблема в том, что люди, отвечающие в организациях за ITSM не понимают что такое социальное ПО. Их не стоит обвинять в этом, ведь люди отвечающие за социальное ПО в организациях(HR, внутренние коммуникации) тоже не понимают что такое социальное ПО. Аналогия с временами внедрения Интранетов – полная.
Конечно, анализ деятельности людей крайне нужен. Без него – не полетит
Мне видится несколько причин неиспользования социальных технологий.
1) Социальные сети ассоциируются со всеми известными проектами одноклассников, фейсбуков, контактов и пр. И воспринемаются как средства развлечения, скорее мешающие работе, нежели помогающие им. Нужен ребрендинг технологии.
2) ИТ не очень-то стремятся быть открытыми, чтобы все видели и знали какие у них проблемы и что там вообще внутри происходит. Часто сталкиваешься с тем, что ИТ-руководители как огня боятся отчётности, а вдруг оан что-то покажет не то… Это навернео не только от них зависит, но и от восприятия этой отчётности вышестоящим руководством, но вот есть такой факт.
3) Флуд и некомпетентные рекомендации. Большая проблема многих форумов по теме поддержки это флудеры, которые считают необходимым отписаться по любому поводу, раздавать советы по любому поводу, разводить базар на тему “нафиг вам это надо” вместо конкретных советов. В итоге поиск зёрен в куче этих плевел занимает очень многовремени. С другой стороны “больные могут начать заниматься самолечением”, типа “не работает сеть? пойди там выдерни проводок, потом туда воткни, я видел так ребята на прошлом месте работы делали…”, кто будет лечить весь этот бардак не понятно. Поэтому я к таким средствам управления знаниями отношусь скептически. Я считаю, что управлять знаниями должны специальные люди а не народные массы.
4) эффект масштаба. Социальные сети – как инструмент управления знаниями может быть эффективна в большом коллективе, навернео не менее 500 человек. В меньших коллективах не достаточна масса “активистов”. Ну или для территориально расперделённых коллективов.
А вообще ITSM инструментарий достаточно приметивные продукты в своей массе. Это всё больше просто БД с разными интерфейсами. Мне не приходилось встречать проудктов, которые предлагали бы какие-то оптимизационные функции, например.
Но на самом деле возможно это связано с тем. что в ИТ всё не так сложно, как принято думать.
1. Социальные сети неявно уже существуют в большинстве организаций, где практически всегда кроме организационной, формальной структуры существуют неформальные лидеры, вокруг которых и образуются те самые сети строящиеся на доверии, авторитете и т.п. А те самые конкретные соц-инструменты вроде блогов (который вы сами ведете), тегов и т.п. – результат эволюции управления неформальными отношениями и организации знаний на соответствующем технологическом уровне.
2. Если рассматривать организацию внутри (ее бизнес-процессы), то именно попытки скрывания итшниками вопросов и проблем от их потребителей (бизнеса) – не дальновидны не способствует оптимизации общей выгоды организации, т.к. итшники либо не хотят погружаться в предметную область, либо бизнес не хочет понимать то, на чем он сиждется – развивая инструменты управления рисками и т.п. костыли. С другой стороны, так сказать, связь с общественностью уж лучше была бы более открытой, чем закрытой, чтобы меньше было кривотолков и больше доверия, которое зарабатывается во многом именно открытостью (как пример, оверсан воткрытую постит в твиттер о проблемах в своем облаке – лично наблюдал как это позитивно подстегивало их потенциальных клиентов).
3. Ну вроде как инструменты рейтингов и др. Соц-модерации – не плохо позволяют ставить людей на место и фильтровать лишнее: см. хабр, яндекс-маркет – это уже достаточно известные шаблоны. Другое дело, что владельцы многих форумов (cms) не заботятся о своих пользователях и не поддерживают такие возможности (и не понимая, как они сами же сокращают свой траффик) – не дают минусовать саппорта:)
4. Мне кажется, что в коллективе уже из 10-20 человек при средней текучке , соц-фичи могут быть довольно полезны, когда важно сохранять и развивать знания.
Само по себе ITSM на моей практике, всетаки, больше это управление людьми, экспертами, характерами:) и т.п., чем работа с БД и т.п. Да, без разных мониторов, sla, отчетов, управления инцидентами и т.п. – ничего не получится, но проблематичнее становится построить нужных людей, их взаимодействие и организовать доступность их знаний. Интересна ваша точка зрения на развитие Lotus Notes от IBM, которое позиционируется как колоборативная/соц платформа – в том числе для поддержки ИТ.
К сожалению, мне не приходилось плотно сталкиваться с Lotus Notes, поэтому не могу высказать своего мнения по её поводу. Могу сказать лишь однно. У меня нет ощущуения, что они активно продвигают его на рынке ITSM (или поддержки ИТ). Практически ничего о них в этмо ключе не слышал и не читал.
Я тоже думал об описании CMDB & инструкций на базе MediaWiKi, но в итоге остановился на WordPress + Google Sites.
В первом удобно упорядочивать хаос, во втором выстраивать понятную и упорядоченную модель инструкций по бизнес-процедурам.
В обоих вариантах есть комментарии, в которых удобно фиксировать историю изменения инструкций или объектов ИТ. Например сменили хостинг сайта или перевели ERP на новую версию или сменили пароль администратора системы и т д
А какую тему WP используете?
А можете поделиться деталями реализации? Или это пока на уровне идеи?
Если уже ерализовали было бы интересно посмотерть на это в живую или хотя бы на скриншотах.
А я вот всегда уважал мнение The Скептика и сейчас с ним полностью согласен (как, честно говоря и с большинством его тезисов).
Желание “социализировать” взаимодействие со стороны ИТ-шников это скорее попытка действовать по аналогии – “как мы саморганизовались” (GitHub, stackoverflow, Facebook в конце-концов, как мерило успеха процесса), так пусть они (пользователи) сделают то же. А вот не сделают.
Прежде всего, надо выиграть конкуренцию у “реальных” соц. сетей, чтобы получить свой ресурс времени пользователя.
Далее, надо воспитать слой “писателей”, которые будут видеть (или получать заменители) цели такой работы и удовлетворяться своим вкладом, ибо чаще всего в компаниях сидят чукчи-читатели.
Третье – инструмент должен быть простым удобным и понятным всем – и писателям и потребителям.
Управление знаниями говорите? Да как только появится принцип need to know – тут же все это обрастет ролями, правами, администрированием, DLP и всеми “очарованиями”, например PCI DSS, Sox. и защиты персональных данных. И оно перестанет быть фонтаном знаний и местом отдыха и станет очередным толстым процессом.
Да, в принципе, это может работать. Но, на мой взгляд, кластер работоспособности этих идей лежит среди не особо крупных и не сильно старых компаний или отдельных функциональных команд, прекрасно мотивированных прежде всего свой работой, использующих инструмент, который содержит в себе все необходимые средства для социализации и управления знаниями (как артефакты рабочих процессов или кейсов, например).
Отклонение от этого кластера по одной или нескольким осям существнно снижает вероятность успешной и, что самое важное – эффективной реализации.
Посмотрите, сколько компаний имеют Интранетовский портал(ы) и у скольких из них там не просто новости, а хоть сколько-нибудь живое общение? И какой процент пользователей вовлечен в это общение? Я сильно сомневаюсь, что цифры значимы.
Идеи выглядят правильно и обещают пользу и профит, но лично я весьма скептичен (солидарен с Робом) по поводу массового успеха подхода.
Точечно, в определенных условиях – да. Так же “просто” как request/incident management/SDM – совсем нет.
Спасибо за комментарий