Портал самообслуживания для сотрудников

cartТретью неделю размышляем с коллегами о том, какой бы могла быть идеальная система заявок на ИТ-услуги и другие общие сервисы (управление персоналом, административные заявки и пр.). Скорее всего, такой системы никогда не будет. Однако, полезно иметь в голове некоторый спектр возможных решений в котором с правой стороны расположена вот такая неосуществимая система-мечта, а слева – проект замены старого итилиума на новый. В общем, проделываем  такое, достаточно теоретическое упражнение. Процесс заключается в последовательном отбрасывании тех или иных стереотипов мышления и постепенно получается некоторый набор тезисов о том, как может выглядеть такой портал. Как говорится, здесь пока оставлю, пусть повесит.

1. Идея первая. Это должно быть похоже на интернет-магазин. Подразделения публикуют товары-услуги, а сотрудники заходят на сайт, набирают себе услуги в корзину и проходят на кассу. То же самое происходит через мобильные приложения (у нас их любят). Это основная идея. У услуги не должно быть никаких непонятных и потому многочисленных параметров (срочность заявки, важность и пр.), в общем, всего того, чем изобилуют сейчас корпоративные системы

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

3. Раз уж мы делаем интернет-магазин, то подходы к поиску услуг перенимаем у такого рода решений. Пусть будет возможность группировать услуги в множество разных каталогов(таксономия), полнотекстовый поиск, возможность искать по тегам и поиск с ограничениями. Часть ограничений определяется профилем сотрудника (не всем видна заявка на служебный автомобиль). Вообще, кому показывать заявку, а кому не показывать должны решать менеджеры услуг, как впрочем, и определять иерархию, в которой эти услуги показывать. Т.е. как таковой каталог есть  и причем не один. Можно сделать столько каталогов сколько нужно. Некоторые из них будут использоваться для навигации, а некоторые для построения отчетов и просмотра статистики. Ведь как потом группировать заявки для построения отчетности это тоже большой и интересный вопрос. В любом случае, каталоги – это не самое главное. Основные механизмы навигации: поиск и ссылка на услугу, присланная коллегой по e-mail

4. Теперь, мы выбрали услугу и надо оформить заявку. В этой операции не должно быть полей ввода. Заказываем, например, мы рабочее место и система предлагает нам ответить на ряд вопросов в wizard(последовательное меню). Серия задаваемых вопросов может быть следующая: ноутбук или стационарный компьютер, маленький ноут или большой, а руки вы сегодня мыли, а правила пользования информационными технологиями подписали… В общем, заявка – это тоже некоторое меню. Здесь возникает один философский вопрос: предоставление настольного компьютера и ноутбука – это одна услуга или это разные  услуги. Ответа на него, как вы понимаете, не существует. А если ноутбуки разные, например один красный, а другой lenovo? Если вы организуете работу с каталогом, как прохождение по серии вопросов и ответов, то этот вопрос вас не должен сильно интересовать. Вы просто пишете дерево меню, в листьях которого висят заявки, возможно, с набором параметров. Если вы организуете это меню правильно (см. HATEOAS), то сможете в отдельных его узлах временно вывешивать надпись: “красных ноутбуков сейчас нет, берите lenovo”

5. Следующая интересная тема – workflow обработки заявок. Так вот в системе его нет. Мы же делаем портал самообслуживания сотрудников, а не BPMs. Поэтому, все рабочие процессы выносим во вне системы в стиле архитектур BPEL4People и WfMC. В системе есть только статусы, об изменении которых нас нотифицирует внешние процессные движки (дополнительные статусы наследуются из основных – создан, в работе, завершен и пр., но это отдельная тема). В простейшем случае внешних движков нет и все делает исполнитель заявки в аскетичном пользовательском интерфейсе с внутренней стороны системы. Вообще, все дополнительные данные, история изменений статусов, комментарии и т.п. просто подклеиваются к заявке как комментарии к сообщению в блоге. У заявки есть неизменный идентификатор, ссылка на услугу, инициатор, получатель услуги и статус. Все остальные реквизиты заявки – слабо структурированный комок данных в json. По завершению обработки заявки можете бросить в этот поток сообщение с опросом удовлетворенности пользователя или рекомендацию о подключении какой-нибудь другой услуги(те, кто заказывает у нас этот принтер, обычно следом оформляют заявку номер 876 на замену катриджа).

В общем, такая вот простая концепция идеального внутреннего портала самообслуживания. Поняв, что это должно быть так, можно с чистой совестью приступить к внедрению очередной версии итилиума или еще какой-нибудь ерунды

Портал самообслуживания для сотрудников: 19 комментариев

  1. Пункт 2 всё-равно придётся реализовать потихоньку 🙂
    А в целом – всё красиво, всё “в соответствии с трендом”.
    Ещё “геймификацию” добавить – и будет ещё ближе к идеалу.

    1. Да. Тема геймификации возникает. Особенно при обсуждении того, как мотивировать пользователей заполнять опрос об уровне удовлетворенности 🙂

  2. Ну да, и диспетчера услуг пед таким сайтом посадить, и пользователь как всегда будет звонить диспетчеру, а он оформлять “покупку услуги”.
    А все потому, что корень проблемы в непонимании пользователями сути проблемы. Как правило пользователь не знает что у него случилось, и соответственно весь каталог сведется к 3 кнопкам “проблема с ПК”, “нет доступа к ресурсам” и самое главное “сделайте чтоб _все_ работало”.

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

  3. У IT Sceptic по этому поводу (2) есть прекрасный подход – каталогов много, и в них технический – включает в себя всё, что только есть, а остальные – есть сабсеты от технического – некий view на общий плацдарм сервисов с разных точек зрения. Красивый буклет – верхнепользовательский каталог – тот самый магазин, в который смотрят пользователи и видят в нем отмеченными те услуги, которые они сейчас получают, добавляют новые или постят на уже существующие запрос или инцидент.

    1. Ну да, Алексей, на это я и намекал Максиму 🙂
      На эти 4 вида каталога. Действительно, более внятной модели, чем у Скептика, мне пока не попадалось (напр. http://www.itsmforum.ru/reference/publication/article-76).

      Кстати, там есть и описание цели “Автоматизированного каталога” (этот как раз в тему поста).

      P.S. /Мнение из практики/ Большой соблазн, действительно, втолкнуть всё в технический каталог, но нет особого смысла – каждый из каталогов всего лишь одно из измерений этого “объекта” (услуги).

      P.S.S. Так же, надо отдать должное прошлогодней попытке НП “Астра” стандартизировать этот подход (http://library.croc.ru/document/20701/).

      1. На мой взгляд – АСТРА сделала попытку для людей, говорящих на одном языке и понимающие не только значение, но и назначение используемых терминов.

        Для пользовательского/бизнес каталога должна быть совершенно другой дискурс – “подземный стук” и все такое – все на уровне магии, с которой пользователь воспринимает все ИТшное. imho

  4. А чего там думать? 🙂 http://casepress.org/projects/portal-vnutrennih-uslug/

    Все уже давно придумано. Обычный каталог услуг. Оформляется как обычный каталог чего либо.
    Каждая услуга может быть как просто ссылка на форму заявки. Так и как полноценный landing page. В том проекте внутренние отделы работали как полноценные предприниматели. Они боролись за своих клиентов. За рост показателей по заявкам.
    Каждый отдел был предприятием со своими продуктами и был обязан продать свой продукт. И отвечать за его спрос. А это требовало фокусировки на том чтобы делать продукт лучше. Полноценный капитализм внутр организации 🙂

    1. Прекрасный подход вебдизайнерской студии. “Вам каталоги? – их есть у нас”. Да и самое интересное – не группировка по функциям типов обращений, а само обращение – как, на каком языке, кому адресовано и все такое..

  5. И да, если у вас нормальная ACM система то думать о том куда выносить процессы не нужно.
    Все это есть единая информационная система. Которая содержит в себе информацию как о продукте, так и о процессах, так и каждой операции по процессу.

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

    Это сложно назвать как WorkFlow, описывали мы это перед разработкой в MindMaps, но работало лучше чем любой Workflow, схема процессов оказалась очень ветвистой и сложной, но при этом работала стабильно и быстро запустилась.

    После этого проекта я окончательно потерял веру в WorkFlow и стал больше верить в ACM 🙂

  6. Кстати ИТ-услуги или любые другие услуги легко структурируются если достаточно хорошо вникнуть в определения слов Процесс и Продукт в ИСО 9000.
    После этого становится понятно что многие сущности которые именуются услугами или процессами на самом деле таковыми не являются и это ошибка определения а также стереотипы. Можете привести примеры ваших сущностей и я смогу аргументированно сказать где есть услуга, а где не услуга, сославшись на определения ИСО 9000, а также ряд других методологий.
    У меня эта ломка шла где то пол года, в ходе которых я усердно штудировал стандарты и методики, анализируя то что совпадает, находя стереотипы и отсекая их.
    После этого каталог услуг причесался и стал стабильным 🙂
    Ну и конечно же этого нельзя сделать без методики ВИСИ.
    Где то через год приходит осознание что в этой структуре не хватает очень важной сущности. Найдя которую понимаешь что это подразделение. И становятся ясны две вещи: хороший каталог услуг без орг структуры не построить. и все это было известно 60 лет назад. современные технологии лишь запутали людей. но основа этих идеологий была известна задолго до появления компьютеров в мире ИТ.

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

  8. Красивая идея, а мне в голову пришла другая. Еще проще для пользователя. Виджет или кнопка на портале ‘заказать звонок’. Специалист дозванивается до сотрудника, производит компетентный опрос и тд..

Добавить комментарий для Alex Iliynsky Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *