Введение

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

В этой статье мы продемонстрируем подход к дизайну Структуры компании в Employee Central, который позволяет сохранить организационные структуры SAP HCM от излишних изменений.

Статья адресована опытным консультантам по SuccessFactors Employee Central, SAP HCM и Core Hybrid.

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

Структура компании

Структура компании в SAP HCM выстраивается при помощи Организационных единиц, которые, в свою очередь, хранят все прочие атрибуты данной структуры, включая Юридические лица (они же Балансовые единицы), Разделы персонала, Подразделы персонала, Места возникновения затрат и др.

В модуле Employee Central существует много подходов по выстраиванию Структуру компании, что детально описано в следующем документе с Принципами проекта по внедрению Employee Central Core Hybrid: Organization Structure Design Consideration. Из всех подходов, описанных в данном документе, мы покажем наименее болезненный, а также дадим несколько ценных рекомендаций, которые делают данный подход универсальным.

Первый уровень Структуры компании

Для первого уровня структуры компании должен быть выделен отдельный MDF-объект, предназначенный только для этой роли и не используемый в качестве основы для других уровней данной структуры. Начиная с этого объекта, все нижестоящие уровни выбираются на Позициях и отображаются в Обзоре структуры компании. Объект первого уровня также используется в качестве отправной точки для различных бизнес-правил, которые наследуют данные на Позиции и нижестоящие уровни структуры.

Коды объекта первого уровня должны быть связаны с корневыми Организационными единицами в SAP HCM, т.е. мигрированы из SAP HCM и реплицированы обратно в SAP HCM. Например, если в SAP HCM только одна корневая Организационная единица, то в Employee Central должен быть только один код объекта первого уровня; и если в SAP HCM несколько корневых Организационных единиц, то в Employee Central должны быть точно такие же коды объекта первого уровня.

В зависимости от дизайна SAP HCM и SuccessFactors «Управление талантами», внедренных у клиента, первым уровнем Структуры компании будет либо Подразделение, либо Структурная единица, либо нестандартный объект:

• Подразделения часто используются в SuccessFactors «Управление талантами» как список Юридических лиц. Также Юридическое лицо (т.е. Балансовая единица) часто является основным атрибутом корневых Организационных единиц в SAP HCM.

• Структурные единицы используются в качестве объекта первого уровня в том случае, если клиент ведет одинаковые типы бизнеса через разные юридические лица или в разных странах.

• Нестандартный MDF-объект используется в качестве объекта первого уровня в целях группировки, например, для групп компаний или качестве единственного корневого объекта.

Несмотря на рекомендации вышеупомянутого документа с Принципами проекта по внедрению, мы советуем не использовать ни Юридическое лицо, ни Отдел в качестве объекта первого уровня по следующим причинам:

1. В систему SuccessFactors Юридические лица переносятся из SAP HCM,^[1] где они являются атрибутом Организационных единиц, а следовательно, также должны быть атрибутом соответствующего MDF-объекта в Employee Central.

2. Отделы используются в качестве нижестоящих уровней Структуры компании, поэтому их неудобно использовать в роли корневого объекта.

Второй и более нижние уровни Структуры компании

Второй и более нижние уровни Структуры компании должны быть основаны на Отделе, как описано в документе с Принципами проекта по внедрению (см. § 6.3 Option 1, стр. 10). Прочие MDF-объекты, в т.ч. Юридическое лицо, Матричные позиции, Область шкалы оплаты, Тип шкалы оплаты, Страна, Расположение, Раздел персонала, Структурная единица и Подразделение,^[2] должны быть атрибутами Отделов.

Хорошей практикой является закрепление верхних уровней Отделов за конкретным атрибутом (например, Страна, Юридическое лицо, Расположение, Структурная единица или Подразделение), что значительно расширяет возможности бизнес-правил, документооборота и полномочий.

Объект дочернего уровня должен быть связан с объектом родительского уровня через поле (не через ассоциацию), поскольку поле имеет событие «По изменению» и по мере ввода данных может вызывать бизнес-правило с назначением «Оценить», чтобы определить уровень данного Отдела в Структуре компании. Уровень Отдела используется для наследования значений с верхних уровней и для контроля видимости полей в настраиваемом пользовательском интерфейсе.

Как показано на Рисунке 1, Отделы самого высокого уровня (второго уровня в Структуре компании) связывают с объектом первого уровня при помощи нестандартного поля. Нижестоящие Отделы связывают с родительским Отделом при помощи стандартного поля parentDepartment. Подробности см. в документе с Принципами проекта по внедрению Employee Central Core Hybrid: Organization Structure Design Consideration, § 6.3.1 Org Unit Department Object Structure and Configuration, стр. 11.

Настройка Позиции

Дайте представим, что имеются следующие ожидания от «Управления позициями»:

• Нанимающие руководители^[3] могут создавать Позиции в Employee Central с нуля;

• Позиции могут принадлежать Отделу любого уровня в Структуре компании, как показано на Рисунке 1;

• Позиции наследуют данные из Структуры компании, когда прикрепляются к соответствующему Отделу, чтобы использовать наследованные данные в бизнес-правилах, документообороте и полномочиях Позиций;

• Сотрудники также наследуют данные из Структуры компании, когда принимаются на конкретную Позицию, а наследованные данные также используются в бизнес-правилах, документообороте и полномочиях Сотрудников.

Чтобы приблизить «Управление позициями» к перечисленным ожиданиям, вам нужно сделать следующие настройки для Позиции:

1. Набор нестандартных полей с соответствующими критериями для ввода всех уровней Структуры компании, как показано в Таблице 1;

2. Бизнес-правило с назначением «Оценить», которое вызывается событиями «По изменению» полей для Структуры компании, чтобы заполнять стандартное поле department, как показано в Программном коде 1;

3. Для поля department – видимость «Только для чтения» и синхронизацию в jobInfo.

Таблица 1 Настройка набора полей для ввода Структуры компании в Позицию

_{¹ В данном примере Подразделение используется как объект первого уровня Структуры компании, а нестандартное поле cust_Division используется для связи Отделов самого высокого уровня с Подразделениями. ² Пример правила см. в Программном коде 1. ³ Поле department должно быть открыто на изменение в период миграции данных по Позициям из SAP HCM в Employee Central, так как хранит соединение A-003 от Позиций к Организационной единице}

Программный код 1 демонстрирует пример бизнес-правила с назначением «Оценить», которое выполняется событиями «По изменению» полей для Структуры компании, чтобы рассчитать значение для поля department данной Позиции.

Программный код 1. Тело бизнес-правила для оценки стандартного поля department объекта Position

rule() {
  if(literal(Position.cust_Department_L7) != null) {
    Position.department = Position.cust_Department_L7;
  }
  else if(literal(Position.cust_Department_L6) != null) {
    Position.department = Position.cust_Department_L6;
  }
  else if(literal(Position.cust_Department_L5) != null) {
    Position.department = Position.cust_Department_L5;
  }
  else if(literal(Position.cust_Department_L4) != null) {
    Position.department = Position.cust_Department_L4;
  }
  else if(literal(Position.cust_Department_L3) != null) {
    Position.department = Position.cust_Department_L3;
  }
  else if(literal(Position.cust_Department_L2) != null) {
    Position.department = Position.cust_Department_L2;
  }
  else {
    Position.department = null;
  }
}

Настраиваемый пользовательский интерфейс для Позиции

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

Если требуется скрывать/отображать поля пользовательского интерфейса Позиций при определенных обстоятельствах (например когда данный пользовательский интерфейс открыт Нанимающим руководителем или если определенное поле Структуры компании пусто), то вам нужно включить Настраиваемый пользовательский интерфейс.

Программный код 2 демонстрирует пример UI-правила, которое контролирует видимость полей для Структуры компании: правило отображает поле дочернего уровня только при условии, если заполнено соответствующее поле родительского уровня. Данное правило предназначено для следующих событий пользовательского интерфейса:

• UI-события onInitUI, которое контролирует видимость полей, когда открывается пользовательский интерфейс, что также включает добавление новой записи;

• UI-событий полей родительского уровня, которые контролируют видимость поля дочернего уровня в том момент, когда изменяется соответствующее поле родительского уровня.

Программный код 2. UI-правило, которое контролирует видимость полей для Структуры компании

rule() {
  if(literal(Position.cust_Department_L6) != null) {
    Position.cust_Department_L2.visibility == "yes";
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "yes";
    Position.cust_Department_L6.visibility == "yes";
    Position.cust_Department_L7.visibility == "yes";
  }
  else if(literal(Position.cust_Department_L5) != null) {
    Position.cust_Department_L2.visibility == "yes";
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "yes";
    Position.cust_Department_L6.visibility == "yes";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(literal(Position.cust_Department_L4) != null) {
    Position.cust_Department_L2.visibility == "yes";
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "yes";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(literal(Position.cust_Department_L3) != null) {
    Position.cust_Department_L2.visibility == "yes";
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(literal(Position.cust_Department_L2) != null) {
    Position.cust_Department_L2.visibility == "yes";
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "no";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(literal(Position.division) != null) {
    Position.cust_Department_L2.visibility == "yes";
    Position.cust_Department_L3.visibility == "no";
    Position.cust_Department_L4.visibility == "no";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else {
    Position.cust_Department_L2.visibility == "no";
    Position.cust_Department_L3.visibility == "no";
    Position.cust_Department_L4.visibility == "no";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
}

Вывод

С технической точки зрения, Employee Central способен полностью воспроизвести организационную структуру SAP HCM, поэтому существенные изменения в организационной структуре могут быть продиктованы только требованиями бизнеса, а не техническими ограничениями.

Список литературы

1. Латышенко В. В. The Core Hybrid integration model on the example of Cost Centers [Электронный ресурс] // SAPinsider. 2020. URL: https://www.sapinsideronline.com/wp-content/uploads/2020/12/The-Core-Hybrid-Integration-Model-on-the-Example-of-Cost-Centers.pdf (Дата обращения: 23.03.2022).

2. Employee Central Core Hybrid: Organization Structure Design Consideration. Document Version 1.2 [Электронный ресурс]. URL: https://d.dam.sap.com/a/Hf6JH6M/IDP%20Employee%20Central%20Core%20Hybrid%20-%20Organization%20Structure%20Design%20Consideration%20V1.2.pdf (Дата обращения: 23.03.2022).

3. Migrating Data from SAP ERP HCM to Employee Central Using Infoporter. Document Version 2H 2021 – 2022-03-15 [Электронный ресурс]. URL: https://help.sap.com/doc/1cb0fa7722f44260b5ab7e6b8d7ab33c/latest/en-US/SF_ERP_EC_Data_Migration_en-US.pdf (Дата обращения: 23.03.2022).

4. What is Hiring Manager? [Электронный ресурс] // TalentLyft URL: https://www.talentlyft.com/en/resources/what-is-hiring-manager (Дата обращения: 23.03.2022).

^{[1] Балансовые единицы ведутся в настроечной таблице T001 и переносятся из SAP HCM в Employee Central c помощью транзакции ECPAO_TRANS_FO_OBJ «Перенести основные объекты в EC». Если есть выбор переноса Балансовых единиц либо из SAP ERP, либо из SAP HCM, то выбор SAP HCM является более предпочтительным.}

^{[2] Если MDF-объект, например Структурная единица или Подразделение, используется как основа для первого уровня Структуры компании, то рекомендуется иметь два поля для данного MDF-объекта на каждом Отделе. Одно поле заполняется только для Отделов второго уровня (т.е. самого высокого уровня Отделов) и используется для ведения данных Отделов/Позиций и Обзора структуры компании. Второе поле заполняется для Отделов всех уровней и используется в бизнес-правилах и полномочиях.}

^{[3] Нанимающий руководитель – это лицо в компании, ответственное за наём сотрудников для заполнения открытой позиции.}