Третью неделю размышляем с коллегами о том, какой бы могла быть идеальная система заявок на ИТ-услуги и другие общие сервисы (управление персоналом, административные заявки и пр.). Скорее всего, такой системы никогда не будет. Однако, полезно иметь в голове некоторый спектр возможных решений в котором с правой стороны расположена вот такая неосуществимая система-мечта, а слева – проект замены старого итилиума на новый. В общем, проделываем такое, достаточно теоретическое упражнение. Процесс заключается в последовательном отбрасывании тех или иных стереотипов мышления и постепенно получается некоторый набор тезисов о том, как может выглядеть такой портал. Как говорится, здесь пока оставлю, пусть повесит.
1. Идея первая. Это должно быть похоже на интернет-магазин. Подразделения публикуют товары-услуги, а сотрудники заходят на сайт, набирают себе услуги в корзину и проходят на кассу. То же самое происходит через мобильные приложения (у нас их любят). Это основная идея. У услуги не должно быть никаких непонятных и потому многочисленных параметров (срочность заявки, важность и пр.), в общем, всего того, чем изобилуют сейчас корпоративные системы
2. Для реализации первой идеи мы отказываемся от понятия каталог услуг в его традиционном виде. Мы его все равно уже пару месяцев написать не можем. Получается что-то страшное и непонятное – странная иерархия типов услуг, групп услуг и пр. В общем, если у вас в компании есть каталог ИТ-услуг, то почитайте его и задумайтесь о способностях автора к структурному мышлению. Мы не верим в то, что можно раз и навсегда сделать один хорошо структурированный каталог внутренних услуг и потому от этой идеи отказываемся. Пусть будет некое неструктурированное множество, в которое добавляются, и из которого исчезают услуги. Причем, услуги могут быть не только внутренние, но и внешние (абонементы в соседний фитнес со скидкой, билеты в командировку и пр.).
3. Раз уж мы делаем интернет-магазин, то подходы к поиску услуг перенимаем у такого рода решений. Пусть будет возможность группировать услуги в множество разных каталогов(таксономия), полнотекстовый поиск, возможность искать по тегам и поиск с ограничениями. Часть ограничений определяется профилем сотрудника (не всем видна заявка на служебный автомобиль). Вообще, кому показывать заявку, а кому не показывать должны решать менеджеры услуг, как впрочем, и определять иерархию, в которой эти услуги показывать. Т.е. как таковой каталог есть и причем не один. Можно сделать столько каталогов сколько нужно. Некоторые из них будут использоваться для навигации, а некоторые для построения отчетов и просмотра статистики. Ведь как потом группировать заявки для построения отчетности это тоже большой и интересный вопрос. В любом случае, каталоги – это не самое главное. Основные механизмы навигации: поиск и ссылка на услугу, присланная коллегой по e-mail
4. Теперь, мы выбрали услугу и надо оформить заявку. В этой операции не должно быть полей ввода. Заказываем, например, мы рабочее место и система предлагает нам ответить на ряд вопросов в wizard(последовательное меню). Серия задаваемых вопросов может быть следующая: ноутбук или стационарный компьютер, маленький ноут или большой, а руки вы сегодня мыли, а правила пользования информационными технологиями подписали… В общем, заявка – это тоже некоторое меню. Здесь возникает один философский вопрос: предоставление настольного компьютера и ноутбука – это одна услуга или это разные услуги. Ответа на него, как вы понимаете, не существует. А если ноутбуки разные, например один красный, а другой lenovo? Если вы организуете работу с каталогом, как прохождение по серии вопросов и ответов, то этот вопрос вас не должен сильно интересовать. Вы просто пишете дерево меню, в листьях которого висят заявки, возможно, с набором параметров. Если вы организуете это меню правильно (см. HATEOAS), то сможете в отдельных его узлах временно вывешивать надпись: “красных ноутбуков сейчас нет, берите lenovo”
5. Следующая интересная тема – workflow обработки заявок. Так вот в системе его нет. Мы же делаем портал самообслуживания сотрудников, а не BPMs. Поэтому, все рабочие процессы выносим во вне системы в стиле архитектур BPEL4People и WfMC. В системе есть только статусы, об изменении которых нас нотифицирует внешние процессные движки (дополнительные статусы наследуются из основных – создан, в работе, завершен и пр., но это отдельная тема). В простейшем случае внешних движков нет и все делает исполнитель заявки в аскетичном пользовательском интерфейсе с внутренней стороны системы. Вообще, все дополнительные данные, история изменений статусов, комментарии и т.п. просто подклеиваются к заявке как комментарии к сообщению в блоге. У заявки есть неизменный идентификатор, ссылка на услугу, инициатор, получатель услуги и статус. Все остальные реквизиты заявки – слабо структурированный комок данных в json. По завершению обработки заявки можете бросить в этот поток сообщение с опросом удовлетворенности пользователя или рекомендацию о подключении какой-нибудь другой услуги(те, кто заказывает у нас этот принтер, обычно следом оформляют заявку номер 876 на замену катриджа).
В общем, такая вот простая концепция идеального внутреннего портала самообслуживания. Поняв, что это должно быть так, можно с чистой совестью приступить к внедрению очередной версии итилиума или еще какой-нибудь ерунды