Администрация как оператор внутрифирменной организационной платформы
Мы тут просто следуем за последними трендами системной инженерии design for manufacturing и строительство более-менее универсальных заводов/фабрик/plants, которая вслед за программной инженерией и вместе с идеями переходит к линии развития DevOps/SRE к идеям инженерии внутренней платформы разработки/internal development platform engineering или коротко platform engineering. Мы избегаем говорить просто «инженерия платформы», потому как слишком много разных значений у слова платформа. Впрочем, у нас «разработчик» — это «организатор», поэтому «внутренняя платформа организации», занимается ей обычно администрация. Но тут есть некоторый общий тренд: раньше администраторами были люди, а сейчас это всё больше и больше переходит к софту, IT-инфраструктуре и другому безлюдному (даже такому «оборудованию» в кавычках, как здания и сооружения). Администрация тем самым становится «инженерами организационной платформы». То есть у нас появляется ещё одна система, которую надо делать внутри организации, это «организационная платформа», которая должна выполнять для организации примерно те же функции, что и любая другая производственная система, с учётом последних трендов разделения труда[1]:
Пользователями этой платформы являются организаторы прежде всего. Отличия от предыдущего понимания — это то, что администраторы сами что-то «производят». Сегодняшнее понимание — всё делают организаторы сами, но администраторы им предоставляют работающую организационную**/административную** платформу как «станочный парк» для изготовления организации, при этом администраторы по факту занимаются только «разработкой» организационной платформы и поддержанием её работоспособности. А вот пользователями тут будут организаторы. Грубо говоря, организаторы раньше бы передавали бы оргпроект администраторам для «изготовления» и далее «эксплуатации», но сейчас нет — они сами проектируют (оргпроектировщики), сами воплощают (лидеры), сами «эксплуатируют» (операционные менеджеры). А администрация даёт для этого все необходимые технические системы «конвейера», которые обслуживают организаторов в их самых разных командах:
- Поставку материала: людей с рынка труда, постановку их на кадровый учёт, выплаты зарплаты, учёт труда, поддержание кадрового резерва (HR).
- Мониторинг характеристик, которые требуются внешними проектными ролями организации (регуляторы рынка труда, финансовые регуляторы, технадзоры/безопасность, экология, санитария), но могут быть и инициативные требования, они отслеживаются тоже администрацией.
- Помещения для работы (цеха, офисные площади)
- Официальный документооборот и делопроизводство, а также поддержку управления работами. Вообще, отслеживание корпоративных учётных систем (официальные архивы, стратегии и оргпроекты, операционные модели организации, репозитории целеполагания, всё что кому-то может понадобиться — управление информацией) как раз тут.
- Компьютерный парк, поддержка со стороны общих информационных систем предприятия (но не специфических информационных систем, направленных на решение каких-то задач в инженерии целевой системы, или продвижения, или бизнеса).
- Отслеживание орг-архитектурных решений (перед тем, как лидер начинает проводить в жизнь решения оргпроектировщика, орг-проект проверяется на то, насколько она соответствует орг-архитектурным решениям. Если орг-проект не соответствует — об этом сообщается орг-архитектору. Это похоже на реализацию fit functions в архитектурной работе программных инженеров, это обсуждалось в курсе «Системная инженерия»).
- Юридический сервис (включая учёт договорных обязательств), учёт финансов и казначейские функции (проплаты по договорам).
- Защита бизнеса (security, ибо безопасность/safety чаще идёт по линии учёта требований надзоров)
- … всё остальное, что требуется организации для её деятельности (включая заказ внешних административных сервисов при недостаточности собственных трудовых ресурсов и оборудования, например, заказ офисных или производственных площадей на условиях аренды, если нет помещений во владении фирмы).
Все эти деятельности носят весьма прикладной характер (по каждой из них написаны какие-то учебники, где рассматриваются довольно узкие вопросы по поводу лучших практик ведения этих деятельностей). Формально эти все деятельности относятся к менеджменту, но по факту рассматриваются как его «бюрократическая» часть, мало связанная с принятием решений по поводу организации. Но любые нарушения в этом «организационном конвейере», на котором и изготавливается современная организация будут вести сразу к огромным проблемам.
Скажем, у вас вдруг произошёл сбой в казначействе: платёжки не уходят в банк, абсолютно при этом неважно, по какой причине: не работает оформляющий платёжки компьютер, сбоит оформляющая платёжки программа, поломалась доставка платёжек в информационную систему банка, невозможно проверить необходимые визы на платеже, невозможно провести учёт платежа, нет денег на счету фирмы, данные договора вдруг разошлись с данными на платёжке, ответственный за проведение платежей сотрудник ушёл в отпуск, причин «почему не работает» обычно много больше, чем причин «почему всё-таки работает».
Такой сбой немедленно отразится на всей фирме. Администрация как здоровье: его не замечаешь, пока здоровье есть, но сразу о нём вспоминаешь, когда со здоровьем что-то не так. И чинить тогда здоровье обычно долго и дорого. Администрация так же: пока она работает качественно, быстро и дёшево — её не замечаешь (и так и должно быть!). Но если она работает плохо, медленно и дорого, то проблемы будут у всей фирмы: вся фирма неожиданно окажется работающей плохо, медленно и дорого.
Администраторы следят, чтобы для всех организаторов использовалась одна и та же орг-платформа, ибо на выходе должна быть целокупная организация, а организаторы могут работать независимо друг от друга отдельными «инкрементами» для разных частей организации, и именно администрация обеспечивает инфраструктуру взаимодействия для разных оргзвеньев, которые организовывали разные организаторы. Это не означает, что все регистры/реестры ведутся в организации централизованно, ибо на вопрос о степени автономности работы оргзвеньев отвечают даже не их проектировщики, а орг-архитекторы. Конечно, орг-архитекторы должны учитывать и те оргзвенья в составе организации, которые занимаются администрированием. Особенность организации в том, что оргзвенья из разных орг-систем в цепочках создания работают все в одной организации и нужно принимать решения по поводу их орг-автономности, орг-интерфейсов и взаимодействия через эти орг-интерфейсы. Этим занимаются орг-архитекторы, но администраторы затем поддерживают эти решения архитекторов.
В любом случае, администраторы держат если не тесты (трудно представить себе работу организации в тестовом режиме), то мониторят информаци****ю о****б организационных сбоях**—** и предоставляют её организаторам как можно скорее**, чтобы те исправили ошибки (заново спроектировали и «изготовили», или только исправили ошибки «изготовления»)****.**