10. Практика администрирования

Администрация как оператор внутрифирменной организационной платформы

Мы тут просто следуем за последними трендами системной инженерии design for manufacturing и строительство более-менее универсальных заводов/фабрик/plants, которая вслед за программной инженерией и вместе с идеями переходит к линии развития DevOps/SRE к идеям инженерии внутренней платформы разработки/internal development platform engineering или коротко platform engineering. Мы избегаем говорить просто «инженерия платформы», потому как слишком много разных значений у слова платформа. Впрочем, у нас «разработчик» — это «организатор», поэтому «внутренняя платформа организации», занимается ей обычно администрация. Но тут есть некоторый общий тренд: раньше администраторами были люди, а сейчас это всё больше и больше переходит к софту, IT-инфраструктуре и другому безлюдному (даже такому «оборудованию» в кавычках, как здания и сооружения). Администрация тем самым становится «инженерами организационной платформы». То есть у нас появляется ещё одна система, которую надо делать внутри организации, это «организационная платформа», которая должна выполнять для организации примерно те же функции, что и любая другая производственная система, с учётом последних трендов разделения труда¹:

Пользователями этой платформы являются организаторы прежде всего. Отличия от предыдущего понимания — это то, что администраторы сами что-то «производят». Сегодняшнее понимание — всё делают организаторы сами, но администраторы им предоставляют работающую организационную/административную платформу как «станочный парк» для изготовления организации, при этом администраторы по факту занимаются только «разработкой» организационной платформы и поддержанием её работоспособности. А вот пользователями тут будут организаторы. Грубо говоря, организаторы раньше бы передавали бы оргпроект администраторам для «изготовления» и далее «эксплуатации», но сейчас нет — они сами проектируют (оргпроектировщики), сами воплощают (лидеры), сами «эксплуатируют» (операционные менеджеры). А администрация даёт для этого все необходимые технические системы «конвейера», которые обслуживают организаторов в их самых разных командах:

• Поставку материала: людей с рынка труда, постановку их на кадровый учёт, выплаты зарплаты, учёт труда, поддержание кадрового резерва (HR).

• Мониторинг характеристик, которые требуются внешними проектными ролями организации (регуляторы рынка труда, финансовые регуляторы, технадзоры/безопасность, экология, санитария), но могут быть и инициативные требования, они отслеживаются тоже администрацией.

• Помещения для работы (цеха, офисные площади)

• Официальный документооборот и делопроизводство, а также поддержку управления работами. Вообще, отслеживание корпоративных учётных систем (официальные архивы, стратегии и оргпроекты, операционные модели организации, репозитории целеполагания, всё что кому-то может понадобиться — управление информацией) как раз тут.

• Компьютерный парк, поддержка со стороны общих информационных систем предприятия (но не специфических информационных систем, направленных на решение каких-то задач в инженерии целевой системы, или продвижения, или бизнеса).

• Отслеживание орг-архитектурных решений (перед тем, как лидер начинает проводить в жизнь решения оргпроектировщика, орг-проект проверяется на то, насколько она соответствует орг-архитектурным решениям. Если орг-проект не соответствует — об этом сообщается орг-архитектору. Это похоже на реализацию fit functions в архитектурной работе программных инженеров, это обсуждалось в курсе «Системная инженерия»).

• Юридический сервис (включая учёт договорных обязательств), учёт финансов и казначейские функции (проплаты по договорам).

• Защита бизнеса (security, ибо безопасность/safety чаще идёт по линии учёта требований надзоров)

• … всё остальное, что требуется организации для её деятельности (включая заказ внешних административных сервисов при недостаточности собственных трудовых ресурсов и оборудования, например, заказ офисных или производственных площадей на условиях аренды, если нет помещений во владении фирмы).

Все эти деятельности носят весьма прикладной характер (по каждой из них написаны какие-то учебники, где рассматриваются довольно узкие вопросы по поводу лучших практик ведения этих деятельностей). Формально эти все деятельности относятся к менеджменту, но по факту рассматриваются как его «бюрократическая» часть, мало связанная с принятием решений по поводу организации. Но любые нарушения в этом «организационном конвейере», на котором и изготавливается современная организация будут вести сразу к огромным проблемам.

Скажем, у вас вдруг произошёл сбой в казначействе: платёжки не уходят в банк, абсолютно при этом неважно, по какой причине: не работает оформляющий платёжки компьютер, сбоит оформляющая платёжки программа, поломалась доставка платёжек в информационную систему банка, невозможно проверить необходимые визы на платеже, невозможно провести учёт платежа, нет денег на счету фирмы, данные договора вдруг разошлись с данными на платёжке, ответственный за проведение платежей сотрудник ушёл в отпуск, причин «почему не работает» обычно много больше, чем причин «почему всё-таки работает».

Такой сбой немедленно отразится на всей фирме. Администрация как здоровье: его не замечаешь, пока здоровье есть, но сразу о нём вспоминаешь, когда со здоровьем что-то не так. И чинить тогда здоровье обычно долго и дорого. Администрация так же: пока она работает качественно, быстро и дёшево — её не замечаешь (и так и должно быть!). Но если она работает плохо, медленно и дорого, то проблемы будут у всей фирмы: вся фирма неожиданно окажется работающей плохо, медленно и дорого.

Администраторы следят, чтобы для всех организаторов использовалась одна и та же орг-платформа, ибо на выходе должна быть целокупная организация, а организаторы могут работать независимо друг от друга отдельными «инкрементами» для разных частей организации, и именно администрация обеспечивает инфраструктуру взаимодействия для разных оргзвеньев, которые организовывали разные организаторы. Это не означает, что все регистры/реестры ведутся в организации централизованно, ибо на вопрос о степени автономности работы оргзвеньев отвечают даже не их проектировщики, а орг-архитекторы. Конечно, орг-архитекторы должны учитывать и те оргзвенья в составе организации, которые занимаются администрированием. Особенность организации в том, что оргзвенья из разных орг-систем в цепочках создания работают все в одной организации и нужно принимать решения по поводу их орг-автономности, орг-интерфейсов и взаимодействия через эти орг-интерфейсы. Этим занимаются орг-архитекторы, но администраторы затем поддерживают эти решения архитекторов.

В любом случае, администраторы держат если не тесты (трудно представить себе работу организации в тестовом режиме), то мониторят информацию об организационных сбоях — и предоставляют её организаторам как можно скорее, чтобы те исправили ошибки (заново спроектировали и «изготовили», или только исправили ошибки «изготовления»).

Опасность: администрация для организаторов или организаторы для администрации?

Типовая проблема — это определение того, кто клиенты/пользователи оргплатформы, которую делает администрация. Поскольку «внутренняя платформа разработки» это как раз то место, которое реализует самые разные функции мониторинга, а также «прогоняет тесты» и делает другие испытания для разработчиков, то туда вставляются в том числе тесты и архитектора (а мы помним, что разработчики и архитектор в продуктивном конфликте), и «безопасников» (с которыми трудно поддерживать содержательные беседы, ибо аппетит их ненасытный), и ещё внешних надзоров, самых разных. И вот тут может оказаться, что в продуктивном конфликте инженеры платформы делают платформу не удобной для своих клиентов-разработчиков, а делают удобной её для самых разных «проверяющих», которые им представляются главней разработчиков. Это редко случается в инженерии каких-то систем, но в случае администрации как инженерии организационной системы это случается более чем часто. И тогда мы имеем вместо администрации по факту представительство госнадзоров, госрегуляторов, налоговой инспекции, которое строго надзирает за организаторами, но не помогает им. Это огромная проблема. Организационная платформа должна помогать организаторам выполнять их работу: развивать фирму. А всё остальное (включая проверки всевозможных мониторингов), по определению дорогие и медленные, как и любое тестирование, должно реализовываться в той мере, в которой риски получения проблем будут достаточно низкими, но главное — организаторы не будут вынуждены работать хуже, медленней, дороже. Это и есть основной конфликт, который лежит в основе работы организационной платформы. Стимулов, которые заставляют администраторов преследовать интересы не предприятия, а всевозможных внешних регуляторов и надзоров, а часто и внутренних регуляторов и надзоров, действующих в ущерб бизнесу — их более чем достаточно. Но нужно помнить: главный клиент администрации — организаторы, и администраторы должны строить оргплатформу так, чтобы защищать скорость и качество их работы, а не скорость и качество работы внешних надзоров.

Оргплатформа эта сегодня строится главным образом из компьютеров и по возможности в небольшой степени из другого оборудования, а иногда ещё и помещений и как можно реже из живых людей (в административной/организационной платформе выполнение операций автоматизируется проще, чем в инженерии, там более-менее однотипные действия!).

Документооборот и делопроизводство так называются в современном менеджменте только тогда, когда речь идёт о чётких ответах на вопрос «кто виноват»: у каждой возможной ошибки должны быть юридически достоверные имя, фамилия, отчества. И отчества тут не случайны. Например, на предприятиях ВПК до сих пор жива традиция называть людей по имени-отчеству, и там же вы убедитесь, что в угоду правильному документообороту и делопроизводству будут делать любые абсолютно бесполезные и даже вредные действия по конструированию самой системы. И тут два тренда:

• Госчиновники пытаются из любого предприятия сделать военное предприятие с госприёмкой. Это неважно, что речь идёт о продовольствии, или детских игрушках, или транспортных средствах, или производстве электроники — вам легко объяснят, что вы не имеете права делать, что угодно, поэтому вам нужно делать только то, что можно, а для этого нужно хорошо документировать ваше производство.

• Менеджеры и инженеры разных частей предприятия из любого предприятия пытаются сделать гибкое/шустрое/agile (и ещё в agile манифесте сказано о том, что польза для клиентов ценится выше, чем документирование — это как раз про те самые документы, по которым точно можно найти «кто виноват», но которые не помогают что-то сделать лучше и быстрее), а ещё элегантное/lean — то есть не делать того, что можно не делать и оно бесполезно, документирование на предмет юридически значимых (правильно оформленных и зарегистрированных) документов с ответами на вопросы «кто виноват» чаще всего относится именно к такому классу. Вы или чекаете ответ на вопрос чек-листа в длинном списке, или оформляете целый документ на этот ответ «да/нет»: что, кому, когда, зачем, подпись, подпись того, кто удостоверяет вашу подпись, выполнение правил архивирования ответа, способ осуществления выписки для официального предъявления и т.д.

Что делать в этих случаях? В очередной раз скажем, что надо изобретать схему: делать СебеДокументооборот и ТебеДокументооборот. Это «тебе» обычно включает обслуживание запросов ролей:

• связанных с требованиями госчиновников по самым разным линиям: бухгалтерия, кадры, технические стандарты, экологические стандарты, стандарты безопасности и всё самое неожиданное, что может выдать бешеный принтер под напором лоббистов из самых разных сфер бизнеса. Скажем, двадцать лет назад подписываемая директором пачка бухгалтерской отчётности была тоненькой, а сейчас она много толще — и хотя компьютеры существенно помогают производить эту бухгалтерскую отчётность быстрее, но и требования по её сдаче становятся жёстче и жёстче, и так во всех сферах жизни: чем больше возможностей выполнить требования регулятора, тем жёстче начинает требовать регулятор.

• связанных с требованиями сотрудников службы защиты (по традиции на русском языке — это будет называться требованиями сотрудников службы безопасности, но не safety/безопасности, а защиты/security). При этом что из этого идёт по линии требований законодательства (часто лоббируемого как раз бизнесом организаций защиты), а что по линии инициативы сотрудников службы защиты — это обычно трудно разобраться. Службы защиты обычно вполне себе силовые подразделения, а преимущество в силе часто реализуется в непроизводительные траты на неэффективные мероприятия. Конечно, специалисты по защите выполняют для агента функции иммунной системы, но аутоиммунные заболевания не так уж редки, поэтому полиция вполне может разрастаться до уровня полицейского государства (помним об исследованиях John Doyle²).

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

Системам документооборота и делопроизводства противопоставляются системы не слишком формального, то есть юридически не слишком значимого управления информацией, где важны скорость и удобство работы, возможность получить информацию для всех, кто в ней заинтересован, а официальный статус этой информации волнует мало. Главный тут будет какой-то организатор (например, технический директор, которого интересует issue tracker, чтобы учитывать все дефекты, но меньше заботит, чтобы были в любой момент готовы юридически обоснованные документы для передачи в суд материалов, говорящих, кто в этих дефектах виноват. Скажем, какой-нибудь low code modeler (типа coda.io, notion.so) полностью устроит менеджера и инженера, но служба безопасности будет запрещать такую работу (и трудно будет сразу сказать, осмысленный этот запрет, или неосмысленный). Большинство производств выбирают не борьбу со службой безопасности (они силовики, с ними бороться трудно: у них оружие есть, а у вас нет — они ваши аргументы обычно просто игнорируют и отвечают какими-нибудь фразами из каких-нибудь произвольно подобранных документов), а выбирают сразу оба способа ведения дел (схема):

• Учётная система «для работы» на базе универсальных моделеров, корпоративных информационных систем и т.д., причём не все из них показывают «безопасникам» и тем более чиновникам.

• Часть информации оформляют в каких-то «официальных системах», передавая туда (если повезёт) через электронный интерфейс, а иногда и (если не повезёт) вбивая эту часть информации руками.

Скажем, «флешками пользоваться нельзя, ибо это требования службы безопасности, проносить ноутбуки нельзя, ибо это требования службы безопасности» — повторим, что проход по этой линии ведёт к тому, что «работать нельзя». Но морские суда безопасней всего чувствуют себя в порту, в гавани, а строят их отнюдь не для этого, поэтому основное время эти суда проводят в море, где риски в разы и разы выше. К организациям это относится в полной мере.

Поэтому юристов, безопасников, бухгалтеров и прочих «представителей государства, начальства и т.д.» (тех, кому вы не очень доверяете в плане осмысленности принимаемых ими обязательных для вас решений) вы отбираете по простому критерию: они придумывают схемы, которые позволяют вам работать с каким-то осмысленным риском, их работа в этом. Если не придумывают, то их увольняете, это просто вы платите лишний налог на работу представителей чиновничьего госаппарата — вы и так платите все налоги, на которые вам придумывают всё больше и больше ограничений в работе и держат всё больше и больше проверяющих органов (армия чиновников растёт во всём мире!), не надо платить больше, платить зарплату своим сотрудникам за препятствия вашему же бизнесу. Ваши сотрудники должны быть в продуктивном конфликте и находить баланс между выполнением требований и свободой организации бизнеса.

Поэтому имейте у себя управление информацией (репо для версионирования, issue trackers), а официальный документооборот (архивы, системы управления документами) — по минимуму. Бойтесь, когда поставщики средств документооборота, бухгалтерских систем, систем обеспечения информационной защиты пытаются вам выдать их за средства повышения производительности труда. Нет, смотрите внимательно на практики, которые они поддерживают. Например, это информационная система не для поддержки работы, а для ответа на вопрос «кто виноват», если там проще отвечать на вопросы «в какой момент меняется юридический статус», «не имеет ли юридический статус в какой-то момент сразу два противоречащих значения». Для производственных систем это обычно не так важно, а важно совсем другое. Вряд ли вы будете задаваться этими вопросами в ходе работы с issue tracker³. Но если ваше предприятие само по себе занимается поддержкой формального документооборота, то тогда наоборот — ровно эти вопросы будут для ваших информационных систем главными.

Основные функции бухгалтерии:

• Вести первичный учёт так, чтобы были возможны все виды ТебеУчёта (государству, и часто даже не одному государству, иногда раскрытие части учёта клиентам, иногда раскрытие части учёта владельцам в порядке раскрытия информации), а также СебеУчёта (прежде всего для throughput accounting). Сюда же можно отнести учёт операций по корпоративным финансам (инвестиции, займы, траты на слияния-поглощения).

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

• Проведение биллинга (сбора платежей с клиентов) и учёт договоров (хотя учёт договоров может быть и отделён куда-нибудь в делопроизводство)

• Проведение казначейских операций, то есть выплаты контрагентам и учёт соответствующих договоров (хотя учёт договоров может быть и отделён куда-нибудь в делопроизводство)

Напомним типичный сюжет про бухгалтерию, его всё время надо держать в голове как типовой. Информационная система оформления деловых поездок (командировок) делается по заказу бухгалтерии. Программисты из айти-службы защищают интересы бухгалтерии перед работниками предприятия, которым куда-то надо в деловые поездки, воюют со всеми работниками предприятия, отстаивая требования заказчика. После того, как программисты сообразили, что их целевая система — это деловая поездка, заказчики на деловые поездки — сотрудники, которым надо в командировки по производственной необходимости, бухгалтерия оказалась не заказчиком, а одной из внешних ролей, интересы которой надо как-то учесть, на минимально возможном уровне. Но при этой постановке вопроса на стороне программистов оказались не пара сотрудников бухгалтерии, которые занимались командировками «как это удобно бухгалтерии», а практически все сотрудники завода. «Весь завод и программисты против пары сотрудников бухгалтерии» — программисты разобрались, в чём там минимальные требования и выполнили только их, много тысяч человек вздохнуло с облегчением. Это основной паттерн отношения к бухгалтерии: разбираться и снижать требования до минимально необходимых, включая ведение первичного учёта для целей управленческого учёта прежде всего, а уж налоговый учёт только в той мере, в которой это требуется, не больше.

Про юристов мы говорили уже много раз, не будем повторяться: или они работают, чтобы вы ничего не делали, и у вас не будет никаких рисков и никакой прибыли, или они пытаются сделать так, чтобы хоть какая-то прибыль у вас была, и при этом минимизируют риски, не останавливая проекты.

Ещё одна служба администрации, для которой нужно быть внимательным в перехвате инициативы — это управление человеческими ресурсами/human resource management (HR). Типичный тут сюжет — это спросить на каком-нибудь совещании перед начальниками самых разных оргзвеньев у начальника HR про то, что делает его служба. После обычных утверждений о том, что служба заботится о наличии в организации запаса людей, которые могут быть использованы для развития организации (иногда это называют «управление талантами»/talent management⁴), обслуживает «кадры» (то есть формальный найм, увольнение, администрирование выплаты зарплаты), удивлённые начальники узнают, что HR-менеджеры занимаются планированием карьерного роста сотрудников, обучением этих сотрудников, назначают вознаграждение за успехи в работе и общий уровень зарплаты, оценивают качество работы сотрудников в различных опросах — и у начальников оргзвеньев появляется общий для них вопрос: они-то тут зачем? Дальше события развиваются по двум сценариям:

• HR-менеджер почему-то увольняется через пару недель (ибо хором все менеджеры понимают, что или они руководят сотрудниками, или все кнуты и пряники в руках у HR-службы — и вопрос ставится «или мы, или они»).

• HR-менеджер оказывается опытным психологом и/или социологом (что часто профильное образование) и как-то удерживается на своей позиции, для него эта ситуация лишь «политическая борьба, групповая динамика», никаких проблем с разделением труда HR-менеджер не усматривает, корпоративную культуру и лидерство оставляет за собой, равно как вопросы оценки сотрудников и принципы выплаты зарплат и вознаграждений за какое-то поведение (incentives⁵ — то, что меняет поведение людей).

Уйти из этого конфликта можно только одним способом: HR-менеджер может выступать как архитектор в части персонала, принимая некоторые общие решения для всех сотрудников. А всё, что связано с конкретными сотрудниками и их поведением — это предмет ведения их начальников, как «разработчиков» личностей своих «талантов». Если это не удаётся как-то наладить, то вокруг фигуры HR-менеджера будет всегда война: профессионализм HR-менеджера позволяет установить личные (за пределами рабочих) отношения с первыми несколькими лицами (CEO/ген.директор и несколько ключевых замов) — после этого все остальные оказываются бессильными, этому HR-менеджеру будет прощаться всё. Ну, или эти HR-менеджеры будут меняться как перчатки, ибо начальники хором всё квалифицированней будут возражать вмешательству в их работу с подчинёнными.

Есть и другие опасности. Например, HR-менеджер даже не сам, а через своих сотрудников фильтрует образовательные программы «для развития» так, чтобы они были понятны этим сотрудникам (помним: базовое образование там чаще всего психологическое и социологическое). Это означает, что более-менее нормальные программы уровня сложности третьего курса инженерного или менеджерского вуза никогда не прорвутся в предприятие, будут сочтены как «слишком сложные и заумные, это не для наших сотрудников». Мало кто понимает, какой жёсткий этот фильтр. Поэтому единственный шанс получить нормальное развитие сотрудников — это заказ таких курсов по развитию непосредственно от начальников тех, кому это развитие или дообучение нужно, а затем прислеживание за тем, чтобы всякие «конкурсы на закупки» не попали в HR-службу, иначе лучшие курсы будут объявлены «заумными», а закуплен будет броский «инфобизнес» в худшем значении этого слова.

Примерно то же самое происходит со службой айтишников, которых надо чётко делить на «электронщиков» и «программистов». У них там между собой тоже продуктивный конфликт: программисты всегда хотят поставить новый софт, на который никогда не хватает аппаратуры или проблемы с закупками мощностей датацентра, с другой стороны, «электронщики» всегда хотят закупить аппаратуру впрок — но вот только почему-то всегда оказывается, что закупленная впрок аппаратура не подходит для того софта, который на этой аппаратуре должен быть запущен. Обращение к облачным сервисам вроде как должно решать все проблемы, но по факту не решает: тут и сразу ограничения со стороны софта, и ограничения со стороны службы информационной защиты («информационная безопасность», но это security, а не safety), и ограничения по финансам (облако оказывается не таким уж дешёвым), и ограничения по устройствам, с которых сотрудники намерены работать с облаком, и архитектурные ограничения корпоративной информационной системы.

Ещё одно различение — это программисты разных служб, которые помогают инженерам самых разных целевых систем и работающего над этими системами оборудования и софта против программистов, которые разворачивают корпоративные информационные системы, поддерживающие администрирование и взаимодействие между оргзвеньями по координации работ. Их часто путают и объединяют в общий пул «программистов». Не надо этого делать, программисты отличаются одни от других больше, чем врачи друг от друга: объединение кардиохирургов с венерологами ещё выглядит осмысленно, но вот программисты встроенных/embedded систем (прошивок аппаратуры) и программисты языков запросов корпоративных баз данных — между ними не так много общего, чтобы объединять их в рамках одного оргзвена просто по принципу «у них общее образование». И образование у них может быть совсем даже не одинаковым.

Больше всего надо бояться ситуации, когда программисты корпоративных информационных систем (систем, помогающих работать менеджерам) путают, кто у них клиент: другие службы администрирования (нет, это неверно, они тут «братья по роли администратора»), или организаторы (оргпроектировщики и лидеры, занимающиеся развитием своих оргзвеньев, операционные менеджеры этих оргзвеньев, программисты должны выполнять прежде всего их запросы). И, конечно, помним про наличие не только разработчиков софта, но и архитекторов, и инженеров платформы разработки софта. Это полноценная инженерия, «программисты» оказываются набором самых разных ролей, которые тоже имеют разные интересы и находятся в продуктивном конфликте, то есть это не просто «каста с общими интересами», совсем нет.

Про то, как самые разные административные службы и подслужбы могут злоупотреблять своим положением разработчиков оргплатформы, можно писать тома и тома (собственно, когда говорится о «бюрократическом беспределе» — это как раз ведь типовые проблемы практики администрирования). Поэтому раздел тут будет коротким: обычно довольно просто найти специалистов, которые развернут оргплатформу, учебников по всем практикам администрирования много, а вот как обо всём этом думать — это уже должно быть понятно из содержания текущего короткого раздела.

Задания

Поставьте отметку о выполнении.

1. Опубликовано эссе, в котором вы рассказываете, что в пройденном курсе системного менеджмента было самым непонятным, что было самым контринтуитивным, что было очень неприятно обнаружить в части собственных ошибок, что оказалось немедленно полезным, что вы не смогли себя заставить одолеть сразу и отложили на потом. Изложите общие впечатления от курса.

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

3. Намечены планы по личному развитию в части каких-то менеджерских практик.

4. В чат поддержки курса «Системный менеджмент» (https://t.me/sys_mngmt_course) сделана запись, в которой вы делитесь опытом прохождения курса и даёте советы новым студентам, которые только-только начинают изучать курс. На что им обратить особое внимание? Что им поможет пройти курс легче и быстрее? На чём им нельзя экономить?

Что потом?

На этом курс системного менеджмента вами закончен. Курс очень короткий (несколько сотен книжных страниц, несколько десятков упражнений), поэтому не может заменить полноценного вузовского курса MBA, где вас просто заставят проштудировать множество толстых книг и выполнить множество упражнений. Но выпускники MBA отзывались о материале нашего курса как о крайне важном: наш курс позволяет разложить по полочкам в голове те знания, которые обычно даются в курсе MBA, а также наш курс даёт инструкцию по тому, как и когда использовать эти знания. Удивительно, но в самом курсе MBA такого не предусмотрено!

В нашем курсе даются отсылки к литературе по отдельным темам (книги и просто сноски на первоисточники — таких отсылок больше двухсот в курсе), и если вы пройдёте тщательно материал литературы к курсу, то это будет по объёму примерно равным курсу MBA. Каждый может взять от нашего курса столько, сколько может взять — и ограничителем тут прежде всего является время, потраченное на курс.

Основное, что вы должны при этом понять — это даже не то, как и что происходит в ходе практикования менеджмента. Вы должны прежде всего понять, что менеджмент — это просто приложение идей системной инженерии к инженерии организаций самых разных форм — предприятий, фирм, подразделений фирм, хоббийных кружков, партийных ячеек. Формы организаций, для которых приложим материал нашего курса могут быть какими угодно, отнюдь не только вариантами классического «юридического лица». В тексте мы старались реже использовать термин «предприятие» (или его синонимы: компания/фирма и даже бизнес), а использовали главным образом термин «организация», включающий и самые разные другие формы оргзвеньев — как подразделения компаний, так и объединения компаний для выполнения каких-то проектов, но также и всяческие не-подразделения типа советов и комиссий, рабочих групп проектов, и множество самых разных других оргформ. Важно лишь, чтобы в этих организациях создавались какие-то системы, даже если эти создаваемые системы — личности самих участников организаций (например, такое можно найти в учебных группах/study group). Конечно, в организации должны быть понятны полномочия по распоряжению трудом и имуществом организации, прежде всего средствами производства и сырьём.

А ещё идеи менеджмента в существенной мере приложимы и к личности (можно говорить и об инженерии личности, и о менеджменте личности, и о личной организованности), и отчасти даже к сообществам (организовывание сообществ тоже вполне можно обсуждать).

Что делать дальше?

• продолжать участвовать в неформальном чате обсуждений курса https://t.me/sys_mngmt_course, где общаются студенты и выпускники. Там ответят на оставшиеся вопросы по курсу и составят вам компанию практикующих системный менеджмент.

• просто применять материал курса в своей работе. Договорить всех вокруг («договориться со всеми вокруг» — это более слабая формулировка!), скорректировать свой способ управления работами, отмоделировать происходящее вокруг вас (или даже на предприятии в целом), используя простые таблички, выполнить «распожаризацию», дальше развивать и совершенствовать свою организацию.

• Есть и вариант «ничего не делать»! Но понимание того, что происходит в головах у менеджеров, останется с вами на всю жизнь. Ну, не на всю жизнь — но только до тех пор, пока значительную часть менеджерской работы не возьмёт на себя машинный интеллект. А ещё прохождение курса добавило вам практики в системном мышлении, методологии и системной инженерии. Это более сильное и точное мышление останется с вами на всю жизнь, оно меняется не так быстро, как менеджмент.