Метка: HRMS

HR Self Service

Тема digital workplace постепенно овладевает умами. Сегодня в блоге Human Resource на хабре появилось сообщение: Битва за трудочасы. Как надо считать зарплату? Автор статьи предложил:

делайте личный кабинет сотрудника с детальной информацией о зарплате. Это должно быть интегрировано с модулем, где он отчитывается по работам, и где руководитель проекта управляет проектом. И это не должны быть разные системы! … Схема такая: есть некий виртуальный счет сотрудника, куда ежедневно или еженедельно «капают денюжки» по итогам его работы, с расшифровкой. И он этот счет видит…. В этом заключается основная «магия» мотивации: ты предпринял некие усилия, и сразу увидел, как, и в каком размере они вознаградились.

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

Таксономия и фолксономия

Прошедшие выходные я провел за «увлекательным» занятием классификации информационных систем нашей компании. Выгруженные из Configuration management database (CMDB) приложения и из Human Resource management system (HRMS) сотрудники были подвергнуты различным inner, outer и cross join-ам . Естественно, делал это я не в трудовом порыве, а по служебной необходимости. Чтоб время, эмоции и силы были потрачены не совсем зря, изложу своё понимание терминов таксономия, фолксономия, агрегация и композиция в применении к современным информационным системам, в частности к CMDB.

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

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

Категории, подкатегории, классы, типы, группы, разделы, виды, рода и пр. делаются обязательными свойствами тех или иных классов. Это все равно, что в первой строке текстового файла писать имя компьютера на котором он лежит и полный путь к файлу. Но это все делается, причем в качестве обоснования приводится идея наведения порядка и классификации объектов, т.е. таксономия.

На самом деле, разница между таксономией и фолксономией следующая. В случае таксономии, решение о включении или не включении определенного объекта в группу(отнесении к категории) принимает владелец этой группы. Т.е. если компания считает необходимым категорировать документы атрибутом «важно!», то в случае таксономии должен быть назначен сотрудник, отвечающий за присвоение документам данного атрибута. Категорий, подкатегорий и видов классификации, и ответственных за них, может быть произвольное количество. Одни отвечают за иерархию категорий «важно!» , другие за иерархию категорий «срочно!» и т.д. Если же категорирование отдается на откуп авторам документов, то это фолксономия (что, впрочем, не исключает возможности  учета принадлежности объектов  категориям). Возвращаясь к корпоративным справочникам. Если классифицирующие объект поля вносятся в структуру данных объекта, то это – плохая архитектура данных. Никакого отношения ни к таксономии ни к фолксономии такая архитектура не имеет.

Сервисная архитектура и Digital Workplace

Продолжаю тему цифрового рабочего места, затронутую в сообщении Что такое Digital Workplace. Сегодня я хотел бы дистанцироваться от технологий и уделить большее внимание методологии DW. Однако немного затронуть технологии все же придется.

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

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

Digital Workplace, в свою очередь, предлагает объединить эти службы единым веб-порталом, через который сотрудник может задействовать любые внутренние сервисы, не заботясь о том, какое именно подразделение их предоставляет. В телекоммуникациях давно и успешно абоненты используют такой инструмент как личный кабинет (web self-service). Это приложение позволяет включать, выключать и настраивать услуги, отслеживать историю звонков и платежей, отправлять оператору связи разнообразные запросы, получать таргетированные предложения и т.д. При этом сложная «внутренняя кухня» оператора скрыта от абонента. Он не должен заботиться о том, в каких системах предоставляется та или иная услуга, как организовано взаимодействие с контрагентами и партнерами, кто и когда строит сеть или устраняет неисправности.

DW предлагает реализовать «личный кабинет» для сотрудников. Эта идея очень похожа на концепцию адаптивного кейс-менеджмента (ACM). На самом деле, АСМ приложение и является тем порталом, через который сотрудник инициирует запуск экземпляров бизнес-процессов. Безусловно, делает он это не просто так, а для решения некоторой конкретной задачи, порученного ему кейса.

В общем, разные эксперты, разными словами говорят об одном и том же