Первая встреча лаборатории администрирования пройдёт уже 27 мая 2023, будем там обсуждать планы и онтологические предложения Chris Partridge 2018 года по финансовому учёту (я писал об этой лаборатории и там давал ссылки на эти онтологические предложения неделю назад в "Администрация, а внутри неё финансовая служба, а внутри практика учёта, а внутри теория учёта", https://ailev.livejournal.com/1686561.html).
К этому событию публикую подраздел из курса "Системный менеджмент". Это фактически последний подраздел курса, поэтому при его чтении ожидается, что вы хорошо понимаете, какие там подроли у организатора и в чём суть практики администрирования по отношению к практикам оргархитектуры, организовывания (со всеми тремя подролями) и бизнеса. Подраздел задаёт вопрос: сотрудники существуют, чтобы выполнить все требования финансистов, или всё-таки финансисты должны выполнять требования сотрудников? Юристы ставят задачи приходящим к ним за согласованием договоров сотрудникам (всё ради безопасности!), или сотрудники ставят им задачи (самое безопасное -- это не работать вообще)? Ответы на эти вопросы вроде как ожидаются одни "административные службы нужны для того, чтобы сотрудники могли продуктивно трудиться", а в жизни с практически всеми службами администрации неожиданно получается наоборот, вся фирма работает на администраторов, уж как-то так получается.
Типовая проблема — это определение того, кто клиенты/пользователи оргплатформы, которую делает администрация. Поскольку «внутренняя платформа разработки» это как раз то место, которое реализует самые разные функции мониторинга, а также «прогоняет тесты» и делает другие испытания для разработчиков, то туда вставляются в том числе тесты и архитектора (а мы помним, что разработчики и архитектор в продуктивном конфликте), и «безопасников» (с которыми трудно поддерживать содержательные беседы, ибо аппетит их ненасытный), и ещё внешних надзоров, самых разных. И вот тут может оказаться, что в продуктивном конфликте инженеры платформы делают платформу не удобной для своих клиентов-разработчиков, а делают удобной её для самых разных «проверяющих», которые им представляются главней разработчиков. Это редко случается в инженерии каких-то систем, но в случае администрации как инженерии организационной системы это случается более чем часто. И тогда мы имеем вместо администрации по факту представительство госнадзоров, госрегуляторов, налоговой инспекции, которое строго надзирает за организаторами, но не помогает им. Это огромная проблема. Организационная платформа должна помогать организаторам выполнять их работу: развивать фирму. А всё остальное (включая проверки всевозможных мониторингов), по определению дорогие и медленные, как и любое тестирование, должно реализовываться в той мере, в которой риски получения проблем будут достаточно низкими, но главное — организаторы не будут вынуждены работать хуже, медленней, дороже. Это и есть основной конфликт, который лежит в основе работы организационной платформы. Стимулов, которые заставляют администраторов преследовать интересы не предприятия, а всевозможных внешних регуляторов и надзоров, а часто и внутренних регуляторов и надзоров, действующих в ущерб бизнесу — их более чем достаточно. Но нужно помнить: главный клиент администрации — организаторы, и администраторы должны строить оргплатформу так, чтобы защищать скорость и качество их работы, а не скорость и качество работы внешних надзоров.
Оргплатформа эта сегодня строится главным образом из компьютеров и по возможности в небольшой степени из другого оборудования, а иногда ещё и помещений и как можно реже из живых людей (в административной/организационной платформе выполнение операций автоматизируется проще, чем в инженерии, там более-менее однотипные действия!).
Документооборот и делопроизводство так называются в современном менеджменте только тогда, когда речь идёт о чётких ответах на вопрос «кто виноват»: у каждой возможной ошибки должны быть юридически достоверные имя, фамилия, отчества. И отчества тут не случайны. Например, на предприятиях ВПК до сих пор жива традиция называть людей по имени-отчеству, и там же вы убедитесь, что в угоду правильному документообороту и делопроизводству будут делать любые абсолютно бесполезные и даже вредные действия по конструированию самой системы. И тут два тренда:
-- Госчиновники пытаются из любого предприятия сделать военное предприятие с госприёмкой. Это неважно, что речь идёт о продовольствии, или детских игрушках, или транспортных средствах, или производстве электроники — вам легко объяснят, что вы не имеете права делать, что угодно, поэтому вам нужно делать только то, что можно, а для этого нужно хорошо документировать ваше производство.
-- Менеджеры и инженеры разных частей предприятия из любого предприятия пытаются сделать гибкое/шустрое/agile (и ещё в agile манифесте сказано о том, что польза для клиентов ценится выше, чем документирование — это как раз про те самые документы, по которым точно можно найти «кто виноват», но которые не помогают что-то сделать лучше и быстрее), а ещё элегантное/lean — то есть не делать того, что можно не делать и оно бесполезно, документирование на предмет юридически значимых (правильно оформленных и зарегистрированных) документов с ответами на вопросы «кто виноват» чаще всего относится именно к такому классу. Вы или чекаете ответ на вопрос чек-листа в длинном списке, или оформляете целый документ на этот ответ «да/нет»: что, кому, когда, зачем, подпись, подпись того, кто удостоверяет вашу подпись, выполнение правил архивирования ответа, способ осуществления выписки для официального предъявления и т.д.
Что делать в этих случаях? В очередной раз скажем, что надо изобретать схему: делать СебеДокументооборот и ТебеДокументооборот. Это «тебе» обычно включает обслуживание запросов ролей:
Системы документооборота и делопроизводства дают чёткий ответ на вопрос «кто виноват», в их состав, например, входят системы управления поручениями и прочие системы поддержки официального документооборота, главный по должности за развитие таких систем — начальник канцелярии.
- связанных с требованиями госчиновников по самым разным линиям: бухгалтерия, кадры, технические стандарты, экологические стандарты, стандарты безопасности и всё самое неожиданное, что может выдать бешеный принтер под напором лоббистов из самых разных сфер бизнеса. Скажем, двадцать лет назад подписываемая директором пачка бухгалтерской отчётности была тоненькой, а сейчас она много толще — и хотя компьютеры существенно помогают производить эту бухгалтерскую отчётность быстрее, но и требования по её сдаче становятся жёстче и жёстче, и так во всех сферах жизни: чем больше возможностей выполнить требования регулятора, тем жёстче начинает требовать регулятор.
- связанных с требованиями сотрудников службы защиты (по традиции на русском языке — это будет называться требованиями сотрудников службы безопасности, но не safety/безопасности, а защиты/security). При этом что из этого идёт по линии требований законодательства (часто лоббируемого как раз бизнесом организаций защиты), а что по линии инициативы сотрудников службы защиты — это обычно трудно разобраться. Службы защиты обычно вполне себе силовые подразделения, а преимущество в силе часто реализуется в непроизводительные траты на неэффективные мероприятия. Конечно, специалисты по защите выполняют для агента функции иммунной системы, но аутоиммунные заболевания не так уж редки, поэтому полиция вполне может разрастаться до уровня полицейского государства (помним об исследованиях John Doyle ).
Системам документооборота и делопроизводства противопоставляются системы не слишком формального, то есть юридически не слишком значимого управления информацией, где важны скорость и удобство работы, возможность получить информацию для всех, кто в ней заинтересован, а официальный статус этой информации волнует мало. Главный тут будет какой-то организатор (например, технический директор, которого интересует issue tracker, чтобы учитывать все дефекты, но меньше заботит, чтобы были в любой момент готовы юридически обоснованные документы для передачи в суд материалов, говорящих, кто в этих дефектах виноват. Скажем, какой-нибудь low code modeler (типа coda.io, notion.so) полностью устроит менеджера и инженера, но служба безопасности будет запрещать такую работу (и трудно будет сразу сказать, осмысленный этот запрет, или неосмысленный). Большинство производств выбирают не борьбу со службой безопасности (они силовики, с ними бороться трудно: у них оружие есть, а у вас нет — они ваши аргументы обычно просто игнорируют и отвечают какими-нибудь фразами из каких-нибудь произвольно подобранных документов), а выбирают сразу оба способа ведения дел (схема):
- Учётная система «для работы» на базе универсальных моделеров, корпоративных информационных систем и т.д., причём не все из них показывают «безопасникам» и тем более чиновникам.
- Часть информации оформляют в каких-то «официальных системах», передавая туда (если повезёт) через электронный интерфейс, а иногда и (если не повезёт) вбивая эту часть информации руками.
Скажем, «флешками пользоваться нельзя, ибо это требования службы безопасности, проносить ноутбуки нельзя, ибо это требования службы безопасности» — повторим, что проход по этой линии ведёт к тому, что «работать нельзя». Но морские суда безопасней всего чувствуют себя в порту, в гавани, а строят их отнюдь не для этого, поэтому основное время эти суда проводят в море, где риски в разы и разы выше. К организациям это относится в полной мере.
Поэтому юристов, безопасников, бухгалтеров и прочих «представителей государства, начальства и т.д.» (тех, кому вы не очень доверяете в плане осмысленности принимаемых ими обязательных для вас решений) вы отбираете по простому критерию: они придумывают схемы, которые позволяют вам работать с каким-то осмысленным риском, их работа в этом. Если не придумывают, то их увольняете, это просто вы платите лишний налог на работу представителей чиновничьего госаппарата — вы и так платите все налоги, на которые вам придумывают всё больше и больше ограничений в работе и держат всё больше и больше проверяющих органов (армия чиновников растёт во всём мире!), не надо платить больше, платить зарплату своим сотрудникам за препятствия вашему же бизнесу. Ваши сотрудники должны быть в продуктивном конфликте и находить баланс между выполнением требований и свободой организации бизнеса.
Поэтому имейте у себя управление информацией (репо для версионирования, issue trackers), а официальный документооборот (архивы, системы управления документами) — по минимуму. Бойтесь, когда поставщики средств документооборота, бухгалтерских систем, систем обеспечения информационной защиты пытаются вам выдать их за средства повышения производительности труда. Нет, смотрите внимательно на практики, которые они поддерживают. Например, это информационная система не для поддержки работы, а для ответа на вопрос «кто виноват», если там проще отвечать на вопросы «в какой момент меняется юридический статус», «не имеет ли юридический статус в какой-то момент сразу два противоречащих значения». Для производственных систем это обычно не так важно, а важно совсем другое. Вряд ли вы будете задаваться этими вопросами в ходе работы с issue tracker [1]. Но если ваше предприятие само по себе занимается поддержкой формального документооборота, то тогда наоборот — ровно эти вопросы будут для ваших информационных систем главными.
Основные функции бухгалтерии:
- Вести первичный учёт так, чтобы были возможны все виды ТебеУчёта (государству, и часто даже не одному государству, иногда раскрытие части учёта клиентам, иногда раскрытие части учёта владельцам в порядке раскрытия информации), а также СебеУчёта (прежде всего для throughput accounting). Сюда же можно отнести учёт операций по корпоративным финансам (инвестиции, займы, траты на слияния-поглощения).
- Это надзорный орган выполнения требований законодательства, но оплачивается он из денег предприятия. Важно не забывать это и чётко контролировать, в чьих интересах работает бухгалтерия: она защищает вас от внешнего произвола, или наоборот, это чужие люди, работающие против ваших интересов.
- Проведение биллинга (сбора платежей с клиентов) и учёт договоров (хотя учёт договоров может быть и отделён куда-нибудь в делопроизводство)
- Проведение казначейских операций, то есть выплаты контрагентам и учёт соответствующих договоров (хотя учёт договоров может быть и отделён куда-нибудь в делопроизводство)
Напомним типичный сюжет про бухгалтерию, его всё время надо держать в голове как типовой. Информационная система оформления деловых поездок (командировок) делается по заказу бухгалтерии. Программисты из айти-службы защищают интересы бухгалтерии перед работниками предприятия, которым куда-то надо в деловые поездки, воюют со всеми работниками предприятия, отстаивая требования заказчика. После того, как программисты сообразили, что их целевая система — это деловая поездка, заказчики на деловые поездки — сотрудники, которым надо в командировки по производственной необходимости, бухгалтерия оказалась не заказчиком, а одной из внешних ролей, интересы которой надо как-то учесть, на минимально возможном уровне. Но при этой постановке вопроса на стороне программистов оказались не пара сотрудников бухгалтерии, которые занимались командировками «как это удобно бухгалтерии», а практически все сотрудники завода. «Весь завод и программисты против пары сотрудников бухгалтерии» — программисты разобрались, в чём там минимальные требования и выполнили только их, много тысяч человек вздохнуло с облегчением. Это основной паттерн отношения к бухгалтерии: разбираться и снижать требования до минимально необходимых, включая ведение первичного учёта для целей управленческого учёта прежде всего, а уж налоговый учёт только в той мере, в которой это требуется, не больше.
Про юристов мы говорили уже много раз, не будем повторяться: или они работают, чтобы вы ничего не делали, и у вас не будет никаких рисков и никакой прибыли, или они пытаются сделать так, чтобы хоть какая-то прибыль у вас была, и при этом минимизируют риски, не останавливая проекты.
Ещё одна служба администрации, для которой нужно быть внимательным в перехвате инициативы — это управление человеческими ресурсами/human resource management (HR). Типичный тут сюжет — это спросить на каком-нибудь совещании перед начальниками самых разных оргзвеньев у начальника HR про то, что делает его служба. После обычных утверждений о том, что служба заботится о наличии в организации запаса людей, которые могут быть использованы для развития организации (иногда это называют «управление талантами»/talent management [2]), обслуживает «кадры» (то есть формальный найм, увольнение, администрирование выплаты зарплаты), удивлённые начальники узнают, что HR-менеджеры занимаются планированием карьерного роста сотрудников, обучением этих сотрудников, назначают вознаграждение за успехи в работе и общий уровень зарплаты, оценивают качество работы сотрудников в различных опросах — и у начальников оргзвеньев появляется общий для них вопрос: они-то тут зачем? Дальше события развиваются по двум сценариям:
- HR-менеджер почему-то увольняется через пару недель (ибо хором все менеджеры понимают, что или они руководят сотрудниками, или все кнуты и пряники в руках у HR-службы — и вопрос ставится «или мы, или они»).
- HR-менеджер оказывается опытным психологом и/или социологом (что часто профильное образование) и как-то удерживается на своей позиции, для него эта ситуация лишь «политическая борьба, групповая динамика», никаких проблем с разделением труда HR-менеджер не усматривает, корпоративную культуру и лидерство оставляет за собой, равно как вопросы оценки сотрудников и принципы выплаты зарплат и вознаграждений за какое-то поведение (incentives — то, что меняет поведение людей).
Уйти из этого конфликта можно только одним способом: HR-менеджер может выступать как архитектор в части персонала, принимая некоторые общие решения для всех сотрудников. А всё, что связано с конкретными сотрудниками и их поведением — это предмет ведения их начальников, как «разработчиков» личностей своих «талантов». Если это не удаётся как-то наладить, то вокруг фигуры HR-менеджера будет всегда война: профессионализм HR-менеджера позволяет установить личные (за пределами рабочих) отношения с первыми несколькими лицами (CEO/ген.директор и несколько ключевых замов) — после этого все остальные оказываются бессильными, этому HR-менеджеру будет прощаться всё. Ну, или эти HR-менеджеры будут меняться как перчатки, ибо начальники хором всё квалифицированней будут возражать вмешательству в их работу с подчинёнными.
Есть и другие опасности. Например, HR-менеджер даже не сам, а через своих сотрудников фильтрует образовательные программы «для развития» так, чтобы они были понятны этим сотрудникам (помним: базовое образование там чаще всего психологическое и социологическое). Это означает, что более-менее нормальные программы уровня сложности третьего курса инженерного или менеджерского вуза никогда не прорвутся в предприятие, будут сочтены как «слишком сложные и заумные, это не для наших сотрудников». Мало кто понимает, какой жёсткий этот фильтр. Поэтому единственный шанс получить нормальное развитие сотрудников — это заказ таких курсов по развитию непосредственно от начальников тех, кому это развитие или дообучение нужно, а затем прислеживание за тем, чтобы всякие «конкурсы на закупки» не попали в HR-службу, иначе лучшие курсы будут объявлены «заумными», а закуплен будет броский «инфобизнес» в худшем значении этого слова.
Примерно то же самое происходит со службой айтишников, которых надо чётко делить на «электронщиков» и «программистов». У них там между собой тоже продуктивный конфликт: программисты всегда хотят поставить новый софт, на который никогда не хватает аппаратуры или проблемы с закупками мощностей датацентра, с другой стороны, «электронщики» всегда хотят закупить аппаратуру впрок — но вот только почему-то всегда оказывается, что закупленная впрок аппаратура не подходит для того софта, который на этой аппаратуре должен быть запущен. Обращение к облачным сервисам вроде как должно решать все проблемы, но по факту не решает: тут и сразу ограничения со стороны софта, и ограничения со стороны службы информационной защиты («информационная безопасность», но это security, а не safety), и ограничения по финансам (облако оказывается не таким уж дешёвым), и ограничения по устройствам, с которых сотрудники намерены работать с облаком, и архитектурные ограничения корпоративной информационной системы.
Ещё одно различение — это программисты разных служб, которые помогают инженерам самых разных целевых систем и работающего над этими системами оборудования и софта против программистов, которые разворачивают корпоративные информационные системы, поддерживающие администрирование и взаимодействие между оргзвеньями по координации работ. Их часто путают и объединяют в общий пул «программистов». Не надо этого делать, программисты отличаются одни от других больше, чем врачи друг от друга: объединение кардиохирургов с венерологами ещё выглядит осмысленно, но вот программисты встроенных/embedded систем (прошивок аппаратуры) и программисты языков запросов корпоративных баз данных — между ними не так много общего, чтобы объединять их в рамках одного оргзвена просто по принципу «у них общее образование». И образование у них может быть совсем даже не одинаковым.
Больше всего надо бояться ситуации, когда программисты корпоративных информационных систем (систем, помогающих работать менеджерам) путают, кто у них клиент: другие службы администрирования (нет, это неверно, они тут «братья по роли администратора»), или организаторы (оргпроектировщики и лидеры, занимающиеся развитием своих оргзвеньев, операционные менеджеры этих оргзвеньев, программисты должны выполнять прежде всего их запросы). И, конечно, помним про наличие не только разработчиков софта, но и архитекторов, и инженеров платформы разработки софта. Это полноценная инженерия, «программисты» оказываются набором самых разных ролей, которые тоже имеют разные интересы и находятся в продуктивном конфликте, то есть это не просто «каста с общими интересами», совсем нет.
Про то, как самые разные административные службы и подслужбы могут злоупотреблять своим положением разработчиков оргплатформы, можно писать тома и тома (собственно, когда говорится о «бюрократическом беспределе» — это как раз ведь типовые проблемы практики администрирования). Поэтому раздел тут будет коротким: обычно довольно просто найти специалистов, которые развернут оргплатформу, учебников по всем практикам администрирования много, а вот как обо всём этом думать — это уже должно быть понятно из содержания текущего короткого раздела.
[1] https://ailev.livejournal.com/213182.html
[2] https://en.wikipedia.org/wiki/Talent_management
И опять не удержался, киберпанк-иллюстрация от Kandinsky 2.1, промпт "администратор строго выговаривает пришедшим ему на поклон сотрудникам предприятия".
