Вступление: утверждение командировок происходит через сообщения в группе, а поиск ответственного за рассмотрение — посредством вопросов.
В производственной компании численностью около 200 человек первая после нового года заявка на командировку была оформлена следующим образом: сотрудник упомянул в чате своего руководителя, тот, увидев сообщение, ответил «OK», после чего сотрудник сделал скриншот и сохранил его; в конце месяца бухгалтер, готовя отчёт по командировочным расходам, по каждому скриншоту сверял данные с бюджетом; а кадровик, подводя итоги по «количеству дней командировок сотрудников» в конце года, обнаружил, что скриншоты неполные и данные между отделами не согласованы.
Это не единичный случай. В большинстве отечественных компаний процедура утверждения проходит следующим образом:
- Найти человека — это вопрос общения.: В первую неделю работы новички чаще всего спрашивают: «Кому подавать заявку на отпуск? Кто будет утверждать мои расходы?»
- Сообщение группы в качестве подтверждения: В группах WeChat или DingTalk отметка «@Босс одобрено» считается подтверждением утверждения, что впоследствии невозможно провести аудит.
- Межотраслевые данные не совпадают: Отдел продаж считает, что визиты клиентов уже одобрены, отдел маркетинга — что нет, а финансовый отдел произвёл оплату на основании скриншота отдела продаж.
- Права передаются устно: Один из менеджеров уволился, а его права не были отозваны; новый сотрудник пришёл и не знает, в чьих руках находится договор, одобренный прежним менеджером.
Корень этих проблем кроется не в том, насколько сложна процедура утверждения, а вУтверждённый поток не попал в систему. Групповые сообщения, устные обращения и скриншоты — всё это временные средства; им не хватает структурированного, фиксирующего и отслеживаемого носителя. Система OA (система офисной автоматизации) как раз позволяет структурировать этот процесс: все ключевые моменты — «кто, по какому вопросу, когда, к кому обращался, по каким правилам производилось согласование и как после этого формируются данные» — сводятся в единую процедуру утверждения.
01 Как разбить бизнес: трёхуровневая структура процесса утверждения
Если разложить процесс утверждения на составляющие, то получится три уровня:
- Уровень задач: Сотрудник инициирует конкретные операции, такие как «командировка, отпуск, возмещение расходов, договор, печать документов, закупка», при этом каждая операция сопровождается суммой, количеством дней, приложениями и связанными бизнес‑объектами (например, заявка на командировку привязывается к заказу на продажу, а возмещение — к счету‑фактуре).
- Уровень процессов: Задачи перемещаются от одного узла к другому, при этом утверждение на каждом узле определяется динамически (с учётом отдела, уровня, суммы и категории), а не задаётся жёстко.
- Уровень данных: После утверждения или отклонения данные должны быть записаны обратно в бизнес‑системы (HR, финансы, продажи, база договоров), а не оставаться лишь в потоке утверждений.
Трёхуровневая связь выглядит следующим образом:События — это вход, процессы — это основная структура, а данные — это выход.. Если при создании системы OA реализовать только бизнес‑процессы, но не обеспечить вывод данных, то потоки утверждений превратятся в изолированные островки; если же сосредоточиться лишь на задачах, не выстроив процессов, система сведётся к «системе заполнения форм».
02 Как это спроектировать: три составляющие — динамические узлы, матрица прав и ведение журнала изменений
Дизайн узла: утверждение не задаётся жёстко
Многие системы OA сразу же жёстко задают порядок утверждения: «Заявка на командировку → менеджер отдела → HR → генеральный директор». В результате, когда менеджер отдела меняется, HR переводится в административный отдел или генеральный директор уезжает в командировку, вся система оказывается полностью нарушена.
Правильный подход:Утверждение осуществляется динамически на основе правил.. Правила обычно имеют четыре измерения:
- Разделение по отделам: Отдел, к которому относится заявитель, соответствует текущему руководителю этого отдела (поиска в реальном времени по организационному дереву).
- Уровень измерения: Сумма, количество дней и сумма контракта соответствуют различным диапазонам и требуют разных уровней утверждения.
- Размерность ролей: Если сумма контракта превышает 500 тысяч, в процесс обязательно вовлекается юридический отдел; при командировках сотрудников за рубеж необходимо обязательное согласование по вопросам безопасности и соответствия нормативным требованиям.
- Размер агента: Если утверждающий находится в отпуске или в командировке, заявка автоматически передаётся его заместителю; заместитель назначается на основе организационной структуры или HR‑отдела.
Соединив эти четыре измерения в «регулярное выражение», движок процессов в режиме реального времени вычисляет узлы согласно правилам,Не указывать фиксированное имя утверждающего. При смене должности или организационных изменениях не требуется вносить изменения в шаблон процесса.
Дизайн прав доступа: три уровня — меню, данные и поля
Права — это не «можно ли войти в систему», а три уровня:
- Меню‑уровень: Можно ли увидеть этот модуль (обычные сотрудники не видят «Управление организационной структурой»)?
- Уровень данных: Можно ли просмотреть эти данные (отдел продажи №1 может видеть только отчёты о командировочных расходах сотрудников своего отдела, но не видит отдела продажи №2)?
- Уровень поля: Можно ли просматривать некоторые поля этой записи (обычные утверждающие не видят поле зарплаты заявителя, но HR может его видеть).
После разбиения на три уровня прав доступа система OA способна поддерживать сложную организационную структуру: группа — филиал — отдел — группа; при работе с данными, охватывающими несколько уровней, применяется параллельное управление по двум правилам: «я могу видеть только свою собственную ветвь» и «я являюсь руководителем этой ветви».
Дизайн отслеживания: семь ключевых элементов журнала утверждений
Каждая операция утверждения должна фиксировать семь ключевых элементов:
- Оператор: Кто нажал.
- Время операции: с точностью до секунды.
- Операционные действия: Одобрить, отклонить, передать, добавить подпись, отозвать.
- Рекомендации по операции: Отказ в отзыве обязателен к заполнению, согласие можно оставить пустым.
- Позиция узла: На каком этапе находится текущий процесс.
- Снимок связанных данных: При утверждении значения полей объекта бизнес‑процесса (сумма, вложения) сохраняются без изменений; не допускается последующее изменение объекта бизнес‑процесса при том, что запись об утверждении остаётся неизменной.
- Оборудование и IP‑следы: От какого устройства и с какого IP‑адреса отправлено (для соблюдения нормативных требований).
Если отсутствует хотя бы один из этих семи элементов, при аудите неизбежно возникают разногласия. Распространённая ошибка — поле «оперативные замечания» может быть пустым; в результате запрос отклоняется без объяснения причин, сотрудники снова и снова поднимают этот вопрос, а процесс утверждения затягивается.
03 Как разрабатывать: три составляющие — движок процессов, движок форм и шина сообщений
Ключевыми компонентами разработки OA являются три движка, а не N страниц:
Движок процессов
Движок процессов позволяет запускать бизнес‑процессы без написания кода — достаточно лишь выполнить настройку. Требуемые функции:
- Последовательное, параллельное, совместное согласование, последующее согласование: Четыре типа базовых потоков — заявка на приём в штат обрабатывается последовательно (HR → руководитель → генеральный директор), а согласование закупок осуществляется параллельно (одновременно проверяют финансовый отдел и руководитель закупок).
- Условная ветвь: Разделение по сумме, категории и уровню заявителя — до 5 000 юаней — упрощённый процесс; от 5 000 до 50 000 — двойная проверка отделом и финансовым подразделением; свыше 50 000 — с участием генерального директора.
- Откат и отклонение: Возврат к заявителю, возврат к любому узлу, возврат к предыдущему узлу — все три типа возврата должны быть поддержаны.
- Добавление подписи и перенаправление подписи: Утверждающий может передать задачу коллеге (перевести на рассмотрение) и также привлечь коллегу к совместному рассмотрению (добавить для подписи).
- Отмена и аннулирование: Заявитель может отозвать нерассмотренные заявки; администратор может аннулировать нештатные операции.
После того как был создан процессный движок,Добавлена новая категория утверждений, для которой не требуется написание кода., достаточно нарисовать диаграмму и оформить форму — и система уже готова к запуску. Именно в этом заключается ключевое отличие OA от «аутсорсинга разработки функций утверждения».
Формулярный движок
Формы должны быть созданы «без кода»: типы полей (текст, число, дата, вложение, связанный бизнес‑объект), правила проверки, обязательность и необязательность, условия отображения и скрытия — всё настраивается визуально путём перетаскивания. Таким образом, HR может корректировать поля для оформления расходов, а отдел продаж — добавлять поля для договоров,Не нужно согласовывать с IT。
Формовый движок должен поддерживать:
- Права на уровне полей: В одной и той же форме разные утверждающие видят разные поля (обычный утверждающий не видит номер телефона заявителя).
- Связь полей : при выборе «Тип контракта = Сервисный контракт» автоматически раскрываются специфические для сервисных контрактов поля.
- Запись данных обратно : после одобрения автоматически записывается в бизнес‑систему (статус контракта, табель учёта рабочего времени HR, бухгалтерские проводки).
Шина сообщений
При одобрении или отклонении заявитель и соответствующие бизнес‑системы (HR, финансы, продажи) немедленно получают уведомление. Единая рассылка через шину сообщений:
- Внутрисистемные уведомления : внутренние сообщения плюс задачи в обработке.
- Уведомления через IM : webhook в WeChat Work, DingTalk, Feishu — отправка в соответствующие группы или личные сообщения.
- Электронная почта и SMS : резервные уведомления по ключевым этапам (утверждение контракта, командировка за рубеж).
- Сообщения в бизнес‑системах : после одобрения создаётся запись в системе о задаче в обработке (финансы получают задачу по возмещению, HR — задачу по приёму на работу).
Шина сообщений — это не «украшение», а «замкнутый цикл» процесса утверждения: без уведомлений заявитель не знает, к кому обращаться дальше, и весь процесс застывает.
Завершение: порядок внедрения, риски и показатели
Запуск OA‑системы проходит в три этапа:
- Первый этап (1 месяц) : внедрение трёх наиболее частых операций — отпуск, командировка, возмещение расходов — охват всех сотрудников. Сначала перенести утверждения из групп WeChat в систему , даже если только эти три операции, данные между подразделениями сразу выровняются.
- Второй этап (2–3 месяца) : добавить четыре среднечастотных операции — заключение контрактов, печать документов, закупки, оплаты — интеграция с финансовой системой. На этом этапе необходимо наладить обратную запись данных (после одобрения контракта он автоматически архивируется в базе контрактов).
- Третий этап (по мере необходимости) : внедрение полного HR‑процесса — оценка эффективности, повышение, переход на постоянную работу, найм, увольнение и т. д. Этот этап возглавляет HR; требуется интеграция основных данных HR.
Распространённые риски:
- Слишком гибкие правила : слишком свободная настройка потока утверждения, в результате никто не знает, кто будет следующим. Принцип: шаблонов процессов не должно быть больше 30 , иначе контроль теряется.
- Неправильное назначение представителя : если утверждатель в командировке и не назначен заместитель, процесс зависает на 3 дня без проверки. Система автоматически сигнализирует, если «процесс висит более 24 часов».
- Отсутствие обратной записи данных : утверждение пройдено, но в системе HR не обновлена информация по табелю учёта, а в финансовой системе нет соответствующих проводок. Обратная запись требует «двойной проверки»: после записи в OA система активно вызывает интерфейс бизнес‑системы, чтобы подтвердить получение.
Показатели успешности проекта:
- Среднее время завершения утверждения : до запуска — 3 дня в группе, после запуска — замкнутый цикл в системе за 1 день.
- Согласованность данных между подразделениями : уровень ошибок при сверке данных HR, финансов и продаж снизился более чем на 80%.
- Возможность аудита и отслеживания : случайная выборка 20 исторических утверждений — 100% полнота заполнения семи обязательных элементов.
Перенос утверждений из групп WeChat в систему — это не просто «переход на систему», а преобразование самого процесса «поиска человека» из зависимости от конкретного лица в зависимость от правил . Как только правила зафиксированы, независимо от того, кто уходит или как меняется организация, утверждение остаётся чётким и предсказуемым.