Подрядчики сказали: «невозможно». Но мы рискнули

В продолжение моего поста об оргструктуре — сегодня про подход к управлению ФОТ.

Оба проекта — оргструктура и ФОТ — стартовали практически одновременно. Одним из первых и самых важных шагов на этапе планирования была оценка готовых решений. Я сразу рассматривала именно комплексные продукты. Хотелось найти систему, которая закроет всё: и структуры, и изменения, и ФОТ, и визуализацию. Решений много, но ни одно не закрывало все наши потребности и не учитывало наши особенности.

Тогда мы приняли решение — идти в собственную разработку

Два ключевых фактора: 1. Стоимость — покупка и доработка готового продукта требовала больших первоначальных инвестиций. 2. Создание инструмента «как надо» — без компромиссов и подгонки под чужие логики и доп затраты.

Реакция подрядчиков была предсказуемой: «Это невозможно» «Вы не справитесь» «Такие проекты не делают внутри»

Но я знала одну вещь: Большинство решений, которые сейчас продаются на рынке, были созданы внутри сильных компаний под собственные запросы, а потом уже потом вышли на рынок как готовые продукты. А чем мы хуже? Возможно всё.

Архитектура решения Вот как мы выстроили систему: 🔹 ЗУП — база по юридической и финансовой структуре. Но мы даже не рассматривали вариант пускать туда руководителей. 🔹 MDM по управленческой структуре в системе СЭД (уже существовала в компании) — хранение всех структур, синхронизированных между собой. Процессы управления изменениями, которые начинаются именно с управленческой структуры. 🔹 Фронт структуры (CMS) — собственная разработка с учётом всех наших типов подчинения. Доступна всем сотрудникам для просмотра общедоступной информации. 🔹 MDM по ФОТ — отдельная база на SQL. 🔹 Фронт для работы с ФОТ — та же CMS, но уже технологичный сайт для работы всех заинтересованных сторон через личные кабинеты.

UseCase: как это работало на практике

Ситуация: необходимо перевести сотрудника на новую позицию более высокого грейда.

Что делает руководитель: 1. Заходит в систему СЭД в блок «Управление изменениями». 2. Выбирает тип изменения — в нашем случае «Перевод сотрудника». 3. Выбирает нужного сотрудника — система показывает текущую информацию по нему. 4. Вносит изменения: — должность (если новая — автоматически запускается подпроцесс ввода новой штатной единицы); — ФОТ (и окладная, и переменная часть). 5. Процесс проходит цепочку согласования: кадры → C&B → ФЭО → вышестоящее руководство.

Что происходит после утверждения: — изменения вносятся автоматически; — информация обновляется по всем трём структурам (юридическая, финансовая, управленческая); — обновляется база по ФОТ.

И всё это — по выстроенному маршруту. Никаких почт. Никакого риска потери информации. Никаких «а где согласование?».

Мой вывод: Если у вас уникальные процессы и ни один вендор не закрывает потребности — собственная разработка имеет право на жизнь. Но нужно быть готовым к: — долгосрочным инвестициям; — сильной команде; — постоянной синхронизации с бизнесом; — и главное — вере в то, что вы делаете.

Это только один этап проекта, в следующих постах расскажу подробнее: 🔹 Полный цикл управления ФОТ, который мы заложили в проект. 🔹 Какие были сложности и чему мы научились.

А вы используете подобные решения? Или всё ещё на почтах и экселях? Если да — выбрали подрядчика или создали под себя? 👇