Что-то много вокруг меня собралось членов нашего клуба выпускников, которые состоялись как директора по развитию, но которым пришлось развивать не только продуктовую разработку, но и back-office aka административные службы предприятия.
Как говорится в курсе "Системный менеджмент" -- администрация создаёт и развивает аналог internal development platform (DevOps), только речь идёт о выпуске не продукта, а самой организации-создателя продукта. OrgOps, те самые "сисадмины", только они "оргадмины", ибо их "система" -- сама организация, а современные OrgOps создают "организационную платформу", "завод-автомат", который в идеале "тёмный холодный завод", ибо заводу без людей свет и отопление не нужны, но пока там между айтишными системами поддержки финансов, проверки договоров и т.д. затёсаны люди из службы администрирования. OrgOps создают эти службы и развивают их.
Это самые разные службы, обеспечивающие существования "формы предприятия": финансовые/бухгалтерские службы в их ассортименте, кадровики, юристы, офис-менеджмент, эникейщики, безопасники и так далее. В самом учебнике "Системного менеджмента" рассказано о работе администраторов не слишком много, примерно 15 страниц:
- Практика администрирования
-- Администрация как оператор внутрифирменной организационной платформы
-- Опасность: администрация для организаторов или организаторы для администрации?
Зато приведено много примеров того, что редко встречается в книжках курсов MBA: как легко все эти финансисты, юристы, безопасники начинают работать не в помощь продуктным бригадам, а ровно наборот -- вставляют им палки в колёса. И ещё в курсе предупреждение: платформа разработки сама по себе сложная система, которая осуществляет сервис производства, это ж конвейер с кучей "станков", и его надо разработать, надо его администрировать. Хотя работают на нём какие-то другие люди, для которых всё и делается. Финансовая служба работает для менеджеров, принимающих решение, тратящих и зарабатывающих деньги, юристы работают для них, кадровики работают для них -- а не наоборот! Так что есть какие-то "организаторы администрации", которые строят эту "администрацию", этот конвейер, который обслуживает своими сервисами ежедневную работу предприятия. И эти организаторы, конечно, прислеживают, кто для кого: бухгалтерия для работников, или работники для бухгалтерии, безопасники для работников, или работники для безопасников (даже если безопасники и бухгалтерия прикрываются тем, что это не они враги -- а они лишь "перчатки на руке господней" в лице надзоров, самых-самых топ-менеджеров и т.д.).
Каждый раз, когда мы внятно объясняли, кто там настоящий клиент, жизнь в этом месте существенно менялась к лучшему. Скажем, пример (из реальной жизни!) из курса про командировки: если клиент у айтишной службы бухгалтерия, то у неё 2000 работников предприятия врагов и 2 сотрудника бухгалтерии в друзьях, когда она делает айтишную систему оформления поездок. А если клиентом является те, кому нужны поездки, то у неё 2000 драгоценных клиентов, а 2 сотрудника бухгалтерии не клиенты, а просто коллеги, у которых тоже 2000 клиентов. И тогда не командировочные обслуживают бухгалтерию с её требованиями, а наоборот.
И вот как это всё делать, и какие там службы вообще должны быть -- это отдельный курс "Системное оргадминистрирование" или "Инженерия администрации/бэк-офиса", который должен быть сделан по образу и подобию (примерно те же роли, примерно те же практики, хотя названия там будут другие) курсов системной инженерии и системного менеджмента как инженерии организации.
А как сделать курс? Делаем лабораторию, поднимаем там теорию, оформляем в виде курса. А технологии? А технологии уж какие будут обнаружены на месте. Вопрос больной.
Так, сегодня встречались техпреды МФТИ, пили чай и обсуждали, что трое в разных фирмах занимаются одной задачей -- onboarding (раньше говорили placement, onboarding вроде как чуть шире -- включает не только знакомство с конкретной позицией, но и погружение в культуру организации), ибо когда свежий сотрудник в сегодняшней текучке заходит на предприятие, его надо как-то познакомить с метаС-моделью, а заходит он с метаУ-моделью в голове. Кто проходил наши курсы -- тот поймёт. Это то, чем "предметная область из учебника" отличается от "предметной области в нашем предприятии", там ни одного слова может не совпадать. Понятно, что это тоже часть конвейера работы с персоналом: сначала надо сотрудника где-то взять (причём взять точно: понимая не столько должность, сколько роль и практику, а также требуемый уровень компетенции), потом тот самый onboarding. Как это сделать быстро, дёшево, надёжно? Какая там есть теория, которая может помочь в создании технологии?! Понятно, что это технология обучения, и первый же вопрос -- это содержание образования. И чему учить нового сотрудника, в каком объёме, как это делать? Это только один пример.
В качестве другого примера давайте возьмём организацию финансовой службы. Там тоже есть теория, "дебит должен сойтись с кредитом", двойная запись. Выкинем многочисленные попытки сделать систему с "тройной записью" (в блокчейн, по способу Ф.Езерского столетней давности, по способу Юджи Иджири конца 20 века, и т.д.) и поглядим, что происходит с теорией учёта сегодня. А происходит что-то малопонятное при попытках вести учёт финансовых трансакций нескольких организаций, непреодолимые онтологические трудности.
Есть много попыток что-то сделать с этой малопонятностью, создать новые объекты для бухучёта с новыми отношениями, то есть онтологию бухучёта. Главная из этих попыток -- онтология REA (ресурсы, события, агенты), поддержанная многочисленными стандартами. Вот моя запись 2010 года про REA -- https://ailev.livejournal.com/871585.html, и ещё одна запись 2010, https://ailev.livejournal.com/871933.html, и дальше постановка задачи в https://ailev.livejournal.com/876070.html: 1. Онтология REA2: как от понятия "ресурс" перешли к понятию "право" и 2. Квантовая теория прав и онтология REA2.
Но жизнь не стоит на месте, и в 2018 году Chris Partridge публикует свой вариант исправления недостатков бухучёта для нескольких организаций, опирающийся на методологию BORO -- и находит, что онтологически важно, что финансовые операции часто записываются как приходы и расходы, и при этом в "записях" теряется референтный индекс, кто там вторая сторона ("выдали Васе", "пришло от Пети" -- а кто вторая сторона? Если это "я", а организаций участвует в учёте три -- как быть?). Вот эти работы: https://disk.yandex.ru/i/x1XhWKjt1Iad4A и https://disk.yandex.ru/i/inRcf3iC91vbCw. REA там тоже учитывается, но она не снимает главного вопроса про "позицию восприятия" -- от чьего имени ведётся этот СебеУчёт, где там "я", которое не очень очевидно в случае описаний взаимодействия, которые все стороны считают своим?! Это как переход от "соматики" в описаниях тела к внешним описаниям, https://en.wikipedia.org/wiki/Somatics или попыток описать active inference не "изнутри агента", а "снаружи группы агентов" (и там онтология тоже потихоньку разрабатывается, https://coda.io/@active-inference-institute/active-inference-ontology-website/actinf-ontology-definitons-3), или это близко идеям "теории ума" (theory of mind), которая подразумевает возможность построить описание моделей, которые разделяет внешний агент, как внутренних моделей его самого (грубо говоря, "кредит" для вашего котрагента по сделке -- это ваш "дебет", способны ли вы это понять? GPT-4, например, понимает такие штуки лучше, чем средний человек, хотя надо уметь её заставить над этим подумать, https://arxiv.org/abs/2304.11490). Ещё один близкий пример на эту тему различия позиций описаний "от моего лица" и "что там в мире": "-- сколько будет 2*2? -- а мы покупаем, или продаём?".
Дальше возникает хитрый момент про СебеУчёт, который очень плохо воспринимается классически образованными финдиректорами и их ведущими сотрудниками -- все эти Throughput accounting, Constraints accounting сразу уменьшают возможность "рисовать показатели", а ведь это их главное мастерство! И тут вдруг от них требуют не "нарисовать прибыль", а "показать, сколько у нас денег". И не "провести бюджетирование", а работать по методикам вроде beyond budgeting (то есть напрягаться не раз в год с бюджетом, а в идеале раз в день! Хотя и раз в квартал как шаг к идеалу -- это ж явно не такая спокойная жизнь, как при разе в год!). Как строить организацию, чтобы финансисты помогали менеджерам, а не связывали им руки? Когда-то Либерзон ответил мне на вопрос, зачем он в Spider Project вставил полноценную учётную систему: "мне нужны честные финансы, ибо если нет на счету денег заплатить за какой-нибудь бетон, то на стройке беда. А в бухгалтерии финансы всегда удобные для всяких других целей -- налоги, чьи-то KPI и т.д. Но сначала бухгалтерия с нами воюет как конкурентами, а потом начинает бегать за точными цифрами -- ибо им точный учёт тоже иногда нужен, а у самих них этого учёта нет, бегают к нам". И вот этот учёт и как пользоваться его цифрами даётся вроде как в курсе операционного менеджмента, а вот вести этот учёт должна финансовая служба предприятия -- администрация, бэк-офис. У организаторов бэк-офиса при этом сложнейшая задача, ибо они набирают финансистов, заказывают систему СебеУчёта и поддержки нескольких ТебеУчётов у айтишников, потому как хотят "как лучше", а получают очень часто "как всегда", поддержку "мира себестоимости" и KPI вместо каких-то связанных с финансами OKR (кстати, вот эти OKR -- это ж тоже "для всего предприятия", тоже инфраструктура! Их тоже надо администрировать! Там вся администрация довольно тесно перевязана своими функциями). И все эти Себе и Тебе -- это как раз вопросы про референтный индекс, точку отсчёта описания. Chris Partridge для этого предложил различать ontology и agentology -- "онтологию с точки зрения агента".
Это всё теория, а на выходе -- ответ на вопрос про лучшие практики создания и развития административной службы, занимающейся финансами. И этот длинный ответ на вопрос должен быть оформлен в виде прикладного курса. Ибо директора по развитию иногда выносит в развитие продуктовой части предприятия, а иногда -- развитие административной части. И тут неожиданно оказывается, что никакие учебники по agile (он их все хорошо знает! и сам много работал разработчиком! и даже архитектором!) почему-то не помогают, а имеющиеся учебники и курсы типа "как нам построить финансовую службу" транслируют идеи столетней давности, не лучшие, а "наиболее распространённые практики". И они про отдельные службы, а нам-то нужно сделать весь конвейер по производству самой организации, все службы в их переплетении!
Так что стартуем лабораторию администрирования и ждём прикладной курс инженерии администрации/бэк-офиса (спор о том, что бэк-офис имеет множество значений, как и администрация -- это уже внутри работы лаборатории, название можно и поменять, если найдётся более удачное). Сегодня договорились с Александром Писаренко, что он займётся этой лабораторией.
Disclaimer: я понимаю, что "внутренний онтолог" должен подскакивать, когда рассматривается отношение "внутри" в заголовке. Но я с одной стороны признаю, что это "публицистический приём, риторика, не принимайте заголовок всерьёз", а с другой стороны напоминаю, что мереология на описаниях вполне возможна в constructive ontology (в курсе "Моделирование и собранность" это уже упоминается, отсылки к работам Kit Fine даются в курсе "Системное мышление", а для самых въедливых вот вам свеженькая работа Chris Partridge по constructive BORO, где вместо отношений -- операции с объектами, https://disk.yandex.ru/i/EEGiVnCAkIzEng. И вот ещё один заход на конструктивные определения от Андрея Родина, в 2010 году я писал про интересные вопросы типа "Предположим, что мы пытаемся каким-то образом эксплицировать общее понятие человека. Классическая стратегия состоит в том, чтобы из всех человеческих свойств выделить все те, которые одинаково присущи всем людям и при отсутствии которых мы не будем считать данную вещь человеком. Затем такой набор общих свойств можно отождествить с содержанием общего понятия человека. Категорная стратегия состоит в другом. В этом случае вместо свойств мы будем пользоваться преобразованиями и поставим вопрос о том, насколько может измениться данный человек, оставаясь при этом человеком", это в https://ailev.livejournal.com/858667.html. То есть ход на конструктивные определения имеет интересные мыслительные следствия. Так что дразниться мереологией описаний я буду и впредь, хотя и очень осторожно -- и каждый раз предупреждая об этом).