Выбор оргмоделера
Нормы (правила, которые надо соблюдать) проектирования организации/оргдизайна (то есть нормы описания будущей организации, моделирование будущей организации) не отличаются от норм любого другого проектирования. Проектирование своим результатом имеет модели будущей системы, причём эти модели должны быть документированы, иначе и обсуждать нечего.
Для документирования используются моделеры. Вы можете сделать моделер даже из воздуха (указав на места в пространстве, где ваши собеседники будут помнить, какие объекты каких типов вы ассоциируете с этими местами в пространстве — полностью эквивалентно «пусть S — это путь, а V — это скорость», только запись не буквами на бумаге, а указанием на место в пространстве), вы можете сделать моделер из своей руки (указывая место на руке, где ваши собеседники будут помнить, какие объекты каких типов вы ассоциируете с этими «именами»), и это много лучше, чем когда вы держите модель только «в чертогах разума». Это может пригодиться в разговоре «на бегу». Но для нормальной работы у вас должно быть управление конфигурацией, а вот этого таким моделированием не добьёшься: нужно использовать компьютерное моделирование (даже не бумажное!):
- Вам нужно уменьшить число ошибок моделирования. Если у вас в модели больше пяти объектов, то человеческая память будет крайне ненадёжна. Если пройдёт всего день с момента моделирования, вы уже можете вспомнить очень немного (кривые забывания[1] работают даже в случае работ по проектированию, не только при обучении).
- вам нужно управлять информацией проекта (нашем случае проекта оргизменений, то есть надо управлять информацией оргпроекта, включая стратегические модели и концепцию системы, а также всё остальное, что нужно для реализации запроектированных оргизменений). Это означает, что модели проекта должны быть доступны всем, кто имеет к этому проекту отношение, так что вам придётся часто пересылать документацию моделей (или давать доступ к моделеру с этой моделью, что то же самое). В этом плане ящик с мокрым песком и веточкой, в отличие от воздуха и руки хотя бы могут быть сфотографированы.
- Вам нужно легко вносить изменения, «непрерывное всё»: оргпроект будет непрерывно меняться. Компьютерные модели легко менять, модели на мокром песке и на бумаге менять трудно. В том числе вам нужно будет менять модели дистантно, поэтому стена со стикерами тоже не подойдёт, придётся всё равно сдублировать результаты моделирования стикерами на стене в компьютер, чтобы иметь возможность корректировать модель удалённо. Так что должен быть моделер, доступный через интернет.
- Вам нужно управлять конфигурацией: какая из многочисленных версий проекта/design (это набор самых разных моделей, которые тоже имеют версии!) будет воплощаться, должно быть точно известно в любой момент. Исправления, внесённые не в ту версию — не исправления. Оргизменения, сделанные по «не той версии, извините» — это будет вред, а не развитие. Это означает, что должен быть репозиторий моделей, в котором поддерживается версионирование (и тут проблема даже с моделями в отличных универсальных моделерах типа coda.io или notion.so).
Почему делается такой упор на табличное моделирование? Моделирование текстом получается совсем не наглядным, ибо очень трудно указывать типы и очень трудно показывать много похожих (например, одного типа) сущностей. Таблички тут представляют вариант много лучше, хотя у них есть определённые недостатки — но эти недостатки с лихвой перекрываются удобным визуальным представлением и доступными моделерами (редакторы таблиц повсеместны, к тому же большинство современных баз данных реляционные, то есть по факту «табличные»). Многочисленные попытки наладить редактирование в диаграммных представлениях («квадратики и стрелочки»/box and arrows) успешны только там, где удаётся выделить огромные (как выяснилось позже) совершенно ненужные ресурсы: это моделирование особо плохо в части непрерывных изменений. Ещё как-то удаётся один раз отмоделировать оргмодели диаграммами, но вот потом не удаётся постоянно корректировать эти модели и удерживать управление конфигурацией. По факту все эти «диаграммные моделеры» (иногда их называют «архитектурные моделеры», иногда «моделеры архитектуры предприятия») имеют альтернативное текстовое представление (например, XML или JSON документы, которые могут редактировать профессионалы-программисты) или табличное представление (которое могут редактировать «продвинутые пользователи»), и оказывается, что основное время модельеры-оргдизайнеры проводят в этих представлениях, а не в визуальном редакторе диаграмм. Поэтому проще оказалось сразу использовать табличные представления.
Но и тут есть несколько вариантов: электронные таблицы (например, MS Excel, Airtable) и базы данных (например, PostrgeSQL, MySQL), а также лет пять назад появившиеся универсальные редакторы, сочетающие в себе свойства редакторов текста с возможностью вёрстки, электронных таблиц и баз данных (coda.io, notion.so). И тут надо указать, что в рамках практики lean в большинстве случаев оказалось не нужным разрабатывать отдельные корпоративные приложения для поддержки новых практик работы, достаточно было использовать LowCode средства этих моделеров, если речь не идёт о сотнях и тысячах однотипных работ, для которых этих средств LowCode универсальных моделеров не хватает (обычно там проблемы масштабирования для большого числа операций: 1. лицензионная политика, делающая цену использования запредельно высокой, и своё приложение написать оказывается дешевле, 2. Отсутствие управления конфигурацией и версионирования, что заставляет прибегать к сложным ухищрениям для репликации данных где-то ещё, и своё приложение оказывается в конечном итоге проще, 3. Низкая производительность, ибо речь идёт об универсальном моделере, который платит за универсальность низкой скоростью, 4. Проблемы с безопасностью и защитой, ибо в собственных приложениях проще прописать доступ разных ролей к разной информации. Все эти проблемы, впрочем, можно в существенной мере убрать, если за универсальными моделерами оставить роль «пользовательского интерфейса», а информацию хранить в корпоративных базах данных, обеспечив какую-то интеграцию между моделером и хранилищем информации).
Оргдизайнеры помогают экспертам (владеющим метаУ-моделями и метаС-моделями) разработать таблички в универсальных моделерах, разъяснения к этим табличкам писать текстом, а дальше «автоматизацию» обеспечивать или простейшим LowCode программированием «на кнопках» (вроде как послать кому-нибудь письмо, что «Сегодня вы появились в табличке «Проект мытья полов» в колонке «Исполнитель»»), или же путём такой же необременительной в части программирования связи с другими корпоративными информационными системами. То есть оргпроекты в ходе моделирования становятся исполняемыми/actionable, в табличках могут быть кнопки. Это общий ход: редактор Lists (редактор списков, которые выражаются в табличной форме) в MS Teams прежде всего задействуется как issue tracker.
Что надо добавить в issue tracker, чтобы он отражал оргмодель? Не так много, ибо отслеживание самой работы (issue, потом task, потом notice) в issue tracker уже есть: указание на «собственника кейса/issue», обычно это сотрудник, который открыл кейс, и он же проверит, можно ли кейс закрыть. Как всегда с людьми, тут нужно знать и исполнителя роли, и роль, и должность, а часто ещё и понимать, где именно в организации находится эта должность, в каком оргзвене её искать, к какому начальнику обращаться, если встретится неожиданное «внеролевое» поведение и нужно будет его корректировать.
Если речь идёт о новом шаблоне кейса, то это и есть описание новой практики. Вот это и есть работа оргразвития: оргдизайнер сделает шаблон кейса, а лидер потом наладит работу по практике, описанной в шаблоне кейса. Так что оргдизайнер в качестве моделера часто использует сразу issuetrackerкак систему моделирования. Не надо одну и ту же модель отражать в issuetracker, в специальной системе моделирования оргдизайнера, в слайдах презентации для начальства красивыми картинками, в виде регламентов для сотрудников (которые никто не будет читать) и т.д. Меньше дублирования**—** меньше вероятности развала конфигурации.
Если речь идёт о чём-то непонятном, что встретилось в организации первый раз и никакого шаблона ещё нет («глухие стуки в моторе — что это? Надо ли что-то делать?»), то и там встречается работа оргдизайнера и лидера «по их роли»: вы по факту должны создать организацию, которая разберётся с непонятным в вашем кейсе — вам придётся собрать совещание, как-то уговорить людей в нём поучаствовать, принять решение о выполнении или невыполнении каких-то работ, выделить на решение ваших проблем ресурсы. То есть оргдизайн и лидерство происходят в организациях на бытовом уровне — и либо этим занимаются исполнители «технических ролей» (ролей, занятых практиками в предметной области организации) сами, либо этим приходится заниматься начальникам технических ролей (ибо у исполнителей технических ролей «лапки», они беспомощны как оргдизайнеры и как лидеры, поэтому их удел — проекты размером не больше, чем для одного человека).
Подробно обсуждаются в BORO Book, https://disk.yandex.ru/i/2SgjvILB3PqJEZ ↩︎