Поиск по форуму даёт только элементы решения, а в целом собрать схему что-то не получается.

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

Непонятно, как наиболее элегантно разрешить нестыковку: всем кладовщикам дать одну либо минимально возможное число видов профессий, по возможности воспользовавшись картой решений (в идеале - опереться на ОКДПР, но имена штатным должностям пользователи хотят придумывать сами), при этом в разных подразделениях устанавливать разные тарифы, чтобы они а) подхватывались соответствующими мероприятиями приёма/перевода и б) чтобы в Т-3 они тоже попадали бы.
И ещё желательно нормативную оплату цеплять к должности, а не к штатной должности, чтобы в нужный момент можно было легко изменить ставку оплаты сразу группе штаток в пределах одного подразделения.

При этом очень желательно, чтобы пользователи могли в дальнейшем максимально самостоятельно всё это вести, без изменений настроек системы.

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

А чем вас "вилки" (тарифная структура, ИТ1005) не устраивает?
Сделайте её один раз нормальную и дальше пользователи будут использовать ей как вы и пишите...
А Должностями и Штатными должностями лучше не играть, первое это ОКПДТР, второе это то, что печатается в Штатном расписании (Т-3). И кстати в Т-2, приказы и т.д. должность должна выводиться "в соответствии со штатным расписанием".

Наверное, нужно провести декомпозицию задачи на подзадачи по важности.

Вилка - это ТарифГруппа с ... по ... в закладке Тариф ИТ 1005? Если так, то такой вариант, к сожалению, усложнит жизнь кадровикам: например, по одним разновидностям кладовщиков в разных подразделениях имеем не менее 4 видов тарифов, а с учётом старших кладовщиков - не менее 6. И такой зоопарк видов тарифов разбросан не менее чем по 16 подразделениям. А ещё аналогичная проблема имеется и по другим видам должностей. Текучесть и переводы высокие, и кадровики будут ещё больше ошибаться, чем сейчас, когда нужно в мероприятии просто сохранить предложенное значение. Вот это сейчас первичная проблема.

У нас в Т-3 сейчас печатается должность, но это всегда можно исправить на нужное поле из ОМ. Будем считать, что это вторичная проблема.

В Т-2 должность печатается как есть - возможно, это и неправильно, но наши кадровики не выставляют претензии, и мы не на настаиваем - они и без этого нас без работы не оставляют. Слегка беспокоит поле профессия, которое приходит из должности - вот это действительно выглядит диковато. Но всё равно, можно считать это вторичной проблемой.


По первичной проблеме (тарифы) возникла такая мысль. По прежнему вести для набора сходных должностей все разновидности с похожими, но индивидуальными названиями (Кладовщик1, Кладовщик2, ...) с присвоенной каждой должности своей нормативной оплатой, а справочник названий должностей (профессий) из ОКПДТР, которые будут привязываться к должностям и печататься в каких-то формах (Т-2, Т-3), хранить во внешнем по отношению к должности ИТ (1222, 9xxxx, или ещё каком-то). Конечно, отступление от стандарта, но другого пути разрешить логическое противоречие первичной проблемы я пока не вижу.

Да.

Зоопарк в любом случае есть, в не зависимости от проблемы. А почему кадровики путаются? В средстве поиска выпадает 20 Кладовщиков и не понятно какого выбрать? Так вы добавьте колонку в средство поиска ТраифГруппа и путаницы не будет...
Даже если вы будете где-то хранить "правильную должность", вам в любом случае нужно будет разбираться с зоопарке в тарифной структуре. Кроме того создавая новое место хранения должности вам придется докручивать все отчеты, в которых нужно выводить информацию об это должности... это ИМХО большее зло чем использовать стандартные (пусть и не удобные) объекты.