Конструкция организации и координация работ
Если кто угодно в организации обращается к кому угодно и просит выполнить какую-то работу по какой-то практике, то организация тут же остановится: все окажутся перегруженными ненужными работами, или наоборот, будут с удовольствием бездельничать — право попросить ведь всегда сопровождается правом отказать. Попробуйте в пиццерии заказать вместо пиццы женские босоножки 37 размера, у вас вряд ли получится. Попросить программиста заварить вам кофе можно, но это не будет воспринято как рабочее задание — даже если кофе вам нужно, чтобы напоить людей перед важным совещанием, это ведь сильно поднимает продуктивность совещания[1]. Конструкция организации (кто кого о чём может попросить, и от кого не ожидается отказа в выполнении просьбы) крайне важна. Если у вас отличный оргпроект в части описания функциональных ролей, выполняемых ими практик, перечислены очень удачно выбранные альфы и их состояния и даже всё запрограммировано, то это только половина дела:
- Надо определить, какие оргзвенья будут назначены на исполнение этих ролей, и дать этим оргзвеньям полномочия выполнять практику и тратить свои ресурсы на выполнение работ по новым практикам. Это работа оргпроектировщика, но дальше нужно как-то разобраться с полномочиями (скажем, подписать оргпроект как приложение к приказу какого-то начальника).
- Обучить людей в этих оргзвеньях и запрограммировать компьютеры (хотя на предыдущем такте это уже может быть сделано — «описать практику в моделере» и «запрограммировать компьютер» может оказаться одним и тем же делом, которое может сделать оргпроектировщик, оргмодель сегодня обычно actionable orgmodel), снабдить их необходимым инструментарием (и настроить или адаптировать эти инструменты), материалами. Это работа лидера, который пользуется административными службами для «изготовления» запроектированного оргпроектировщиком (помним, что администратор — это аналог инженера внутренней платформы разработки, DevOps в варианте организации).
Дальше будет много удивительных моментов, связанных с проектированием взаимодействий в конкретных операциях. Это, конечно, не дело архитектора, архитектора будут заботить вопросы другого порядка, относящиеся к организации в целом. Например, если кто-то кого-то просит о чём-то из другого департамента, он обращается прямо к нему, или пишет начальнику, тот пересылает начальнику другого департамента, а уже тот своему подчинённому, причём тот, кто пишет уже договорился с тем самым подчинённым и тот ожидает, пока письмо дойдёт длинным маршрутом через начальников? Это обычная немецкая и российская практика, но есть и американская: писать непосредственно тому, кто выполняет нужную роль. Есть «за» и «против» обоих решений. Например, если внутрь оргзвена проникнет большое количество неучтённой работы извне, как раз через такие письма-просьбы, то ситуация станет непредсказуемой, что очень плохо. Но если пересылать все просьбы о работе через начальников, то всё будет долго и есть шанс принятия решения некомпетентными в обсуждаемом вопросе начальниками, а не их компетентными подчинёнными. Но оставим пока вопрос о документообороте (это всё-таки вопрос администрирования, и часто там решается другое: «вам надо как быстрее, или чтобы чётко был юридический ответ на вопрос «кто сидеть будет, если что пошло не так»?»).
Обсуждение конструкции (структуры оргзвеньев и их полномочий) предприятия, абстрагированное от обсуждения функциональной специфики, наиболее подробно даётся в книге Ian Dietz и Hans Mulder «Enterprise Ontology», 2021:
«Онтология предприятия» — это важные в предприятии объекты, о которых легко договориться. Авторы книги справедливо утверждают, что проще всего в предприятии обнаружить оргзвенья, которые они называют «акторами» (actors), и эти акторы заказывают работы (оказание сервисов) друг у друга. Если какое-то оргзвено считает, что работу у него запрашивают неправомерно, происходит «выход в дискурс», работа прекращается, начинается обсуждение того, кто прав, кто виноват (если в пиццерии заказать женские босоножки, то работа прекратится и начнётся разговор о том, кто пришёл, кого попросил, почему это нельзя сделать — тот самый «дискурс»). Главное, что книга предлагает кроме традиционного для операционного менеджмента деления на время паузы (wait time) и время обработки (touch time) вводить другое различение, тоже влияющее на скорость работы: это coordination time (время договаривания о работах, связанных с полномочиями) и production time (собственно время обработки).
«Договаривание» или по обсуждаемой книге Dietz и Mulder (общее название представленной там методологии — DEMO) «координация» относится к таким речевым актам/действиям, как **просьбы, обещания, предъявлени**я выполненной работы, акцепт****ы **результатов, отказы.**Речевые акты тут упомянуты не случайно, ибо DEMO основывается на теории речевых актов. Речевые акты — это такие высказывания, которые порождают действия в реальном мире (то есть как раз просьбы, обещания, предъявления выполненной работы, акцепты результатов, отказы). В частности, делается утверждение, что надо специально договариваться о моментах, когда считаем работу выполненной (то есть кейс закрытым), и основные события в мире координации должны происходить по явным речевым актам, то есть «не сказал/не написал — не считаем, что что-нибудь произошло в обработке». При этом можно договариваться, что «если положил результат вот сюда, это означает, что я закончил работать и выдал результат по цепочке дальше», но если договорённости не было — окончание работы считаем не произошедшим, пока об этом исполнитель не скажет явно, а заказчик не получит это сообщение. Основная ошибка оргдизайнера — это пропуск стадий координации и пропуск того, что будет происходить, если на любой из стадий будет отказано в продолжении (например, что будет происходить, если поручение будет выдано, но работа не будет взята, то есть обещание выполнить работу не будет получено):
- Осознание нужности инициатором трансакции/заказчиком/поручителем какой-то работы/кейса
- Поручение/заказ/просьба выполнения работы/кейса (предъявление потенциальному исполнителю). Работа тут поручена, но не взята!
- Обещание исполнителя выполнить работу (явный приём к исполнению)
- Выполнение работы (это собственно обработка/производство/работа/труд)
- Объявление о том, что работа выполнена. Работа тут выполнена, но не принята!
- Объявление о принятии работы
Операционный менеджер затем может думать о том, как уменьшить время на координационные акты (скажем, если у вас цикл бюджетирования 1 год, то в начале года у вас могут возникнуть координационные проблемы на простейшие работы — они попросту не смогут быть профинансированы, никаких работ не будет происходить год, пока финансирование этих работ не попадёт в бюджет. Это типичная координационная проблема, ибо «ничего не происходит, работы нет, полномочий что-то делать нет, ждём каких-то разрешений»).
Конечно, дальше можно усложнять и усложнять ситуацию, например потребовать 12 виз при подписании договора (договор тут — это поручение на работу и обещание выполнения оплаты при условии выполнения работ, совмещённое с обещанием выполнить работу и выражением требования при условии выполнения работы получить деньги). Понятно, что договора просто прекратят подписываться. Это вопрос оргдизайнера сделать так, чтобы координационные акты занимали минимум времени.
Кажется, что вопрос о том, кто заказчик работ, всегда ясный. Нет. Например, кто является заказчиком работ по созданию корпоративного софта оформления командировок (кейсы создания «деловых поездок»)? У подразделения/оргзвена программистов возникает ложное впечатление, что заказчик тут бухгалтерия — это оформление нужно вроде как бухгалтерии. После чего подразделение программистов защищает интересы бухгалтерии, воюя с тысячами «пользователей системы» (людьми, которым нужны деловые поездки). Заставляем программистов точнее определить свою целевую систему: оказывается, деловые поездки нужны инженерной службе предприятия, и помогать нужно командированным, а не бухгалтерии! После этого оргзвено программистов воюет на стороне нескольких тысяч человек с несколькими сотрудниками бухгалтерии и без труда выигрывает, сотрудники получают отличный сервис оформления деловых поездок, удобный им, хотя и не такой удобный для бухгалтерии (а бухгалтерии пришлось изобретать схему, мы об этой работе юристов, финансистов и прочих администраторов уже говорили — их задача быть на стороне организации, а не на стороне разных надзоров). Так что оргдизайнеры определяют, какие именно типовые кейсы должны быть поддержаны корпоративными информационными системами (а в современной ситуации оргдизайнеры часто будут сотрудниками айтишных подразделений, хотя их можно найти практически везде — от отделов «аналитиков», до «служб обеспечения качества»).