Модель органиграммы

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

• Руководитель — один из сотрудников, но «сотрудниками» у него могут быть и другие оргзвенья
• Если нет явного подначального подразделения «оргзвена», то используйте слово «направление» или «служба» и тем самым создайте его!

Вот пример для «конкретной организации» (КонкОрг):

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

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

Вот примерная «логическая» (в реальности это «непрерывная разработка», и все действия итеративны) последовательность работ оргдизайнера:

• Начинаем с основных изменяемых объектов работы (прежде всего — целевой системы!). Определяем список кейсов, готовим шаблоны этих кейсов (с экспертами предметной области смотрим на SoTA практики, учитываем ресурсы, прописываем чеклисты для определения моментов перехода предмета кейса по графу его состояний и т.д.). Делаем подкейсы (разбиения) на столько уровней, сколько представляется удобным — понимая, что на самом верхнем уровне принимать решения по кейсам нижнего уровня нельзя, там будут свои оргдизайнеры. Как-то раскладываем эти кейсы по оргролям. Это всё будет функциональная декомпозиция организации.
• Прописываем органиграмму: определяем оргзвенья, которые будут выполнять прописанные роли — учитываем при этом решения орг-архитектора.
• Прописываем, какие информационные системы поддерживают какие кейсы и как организована маршрутизация предметов кейса по оргзвеньям (проектирование IT-решения, при этом учитывается и IT-архитектура). В простых случаях это будет LowCode моделирование, в сложных — придётся разрабатывать или дорабатывать какой-то корпоративный софт.
• Определяем, что ещё будет надо (помещения, оборудование, разделы бюджета и т.д.), доводим концепцию предприятия до полноценного орг-проекта/design, готового к воплощению.

Итого в практике оргдизайна помните:

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