*фреймворк Projects IN Chaotic Environment, версия 4.0
У меня есть знакомая, которую зовут, допустим, Анна. Она работает за пятерых - за руководителя направления, руководителя проекта, тимлида, системного архитектора и наполовину за закупщика и сисадмина. И как-то она выдала фразу: "Программа, которую я пишу, спокойно может отказаться делать свою работу, если ей поставить задачу неправильно или если она перегружена, а я все беру и беру на себя, все тащу и тащу". И действительно, софт или "железка" спокойно откажутся работать там, где люди возьмут на себя непосильные обязательства. Из-за этих непосильных обязательств, которые не выполняются или выполняются только частично, получается так, что машины намного надежнее, чем люди. В результате куда больше людей верят своим смартфонам, чем другим людям.
Рисунок 1. Данные по технооптимизму в России, исследование Евробарометра
Машины надежнее людей потому что их работа описывается достаточно точными моделями. Без четкого понимания того, как машина работает, ее просто нельзя создать и отладить. Чтобы машина или программа работала, надо четко описывать то, какие задачи и как она получает и какие результаты, как и куда выдает.
Чтобы поставить задачу системе, надо выдать ей корректное задание в правильном месте - на интерфейсе, API или в экранной форме, с использованием протоколов обмена информацией, плюс она еще и уровень доступа у вас проверит, а можете ли вы вообще ей задачи ставить. Выполнение задачи забирает ограниченные ресурсы системы, нельзя навалить сто задач и требовать, чтобы все это было сделано сию же минуту. Если системе не выдать абсолютно понятного ей задания, или у нее ресурсов не хватает, она просто ничего не сделает и ей даже стыдно не будет. Человеку же дать задание намного проще - достаточно остановить в коридоре на 15 секунд и что-то быстро надиктовать, зачастую даже проверки прав на доступ не происходит, на чем живут многочисленные продавцы по телефону и мошенники. А дальше человек сам справляется с потоком непонятно каких задач непонятно от кого, как Анна. До какого-то момента справляется, пока ресурсы не кончатся. У кого-то их много, и он тянет долго, у кого-то их меньше, и они выгорают раньше. Если только не перепоручать выполнение другим. Но тут есть ряд проблем.
Проблема Анны в том, что она не может дальше перепоручить ничего из своих дел, потому что все задачи слишком слабо формализованы и только она знает, что, как и когда делать. На передачу дела уйдет уйма времени, больше, чем на то, чтобы сделать самой.
Но необязательно так страдать от чрезмерной нагрузки, достаточно правильно построить орг.дизайн в своих проектах. И один из ключевых шагов в построении правильного орг.дизайна заключается в том, что надо перенести понятие системного интерфейса на взаимодействие людей. Достаточно начать правильно рассуждать о бизнес-процессах, организационных ролях, организационных единицах и организационных интерфейсах. И тогда не будет ситуации, которую описал Виктор Вахштайн, исследователь, который формирует результаты Евробарометра в России. На вопрос «Как вы считаете, люди действительно такие откровенные сволочи, какими кажутся?», подавляющее большинство россиян отвечает «И еще хуже!». (https://www.dv.kp.ru/daily/26739/3767213/)
Аннотация
Понятие интерфейса в культуре значительно уже и конкретнее понятия системного или организационного интерфейса в системном подходе 2.0. В этой статье я разбираю основные ошибки в мыслительных ходах по поводу системных интерфейсов, которые допускают люди, изучающие системный подход. Кроме того, я привожу примеры, когда более абстрактное понимание интерфейса приводит к переосмыслению подхода к цифровизации и внедрению ИТ-систем, в особенности про создании киберличностей и киберорганизаций.
Статья описывает часть фреймворка PRINCE 4.0 - Projects in Chaos Environment.
3. А вот с точки зрения системного инженера ситуация выглядит немного по другому. Системный инженер (СИ) всегда задает себе вопросы - а откуда пришло это требование, почему оно именно такое, можно ли его ослабить или наоборот, оно слишком мягкое и даже если его выполнить, то система будет работать неустойчиво? Чтобы ответить на эти вопросы, СИ делает особый мыслительный ход, который называется метасистемным переходом. Он видит в этой ситуации не одну систему, а три - программу, которая работает на компьютере (1), пользователя, который взаимодействует с интерфейсом программы (2), и надсистему, которая их объединяет - пользователя, чьи способности усилены компьютером и программой (3).
4. Такой мыслительный ход может большинству разработчиков и аналитиков показаться пустым умствованием и переусложнением, но на практике этот взгляд бывает крайне продуктивен. В частности, если речь идет о построении сложных систем или организации бизнес-процессов в хаотичных средах. Отступление для тех, кто погружен только в софт
Даже в блестящем докладе Филиппа Дельгядо "Методология как конструктор: инструкция по сборке" орг.интерфейсы не выделены как объекты первого рода, хотя у меня есть гипотеза, что при анализе матрицы плотности методологии А. Коуберна формальность описаний процессов касается в первую очередь имплементаций интерфейсов, но не самих практик преобразования одних артефактов в другие.
Интерфейс как абстрагирование от деталей реализации и проблема дырявых границ системы
10. Интерфейс не только сопрягает, но и изолирует подробности реализации, позволяет абстрагироваться от деталей, ограничить распространение ошибки. Применительно к орг.интерфейсу это означает, что нам необязательно знать исполнителей, нам должны быть известны только роли, которые исполняются практики бизнес-процесса, и которые отвечают за интерфейс. И здесь всплывает интересный момент, связанный с ассистентами и SPOC, single point of contact. Фактически, и те и другие - это роли, которые занимаются только имплементацией интерфейсов. Другими словами, есть организационные единицы - предприятия, организации, бизнес-подразделения, дивизионы, отделы, интегрированные продуктовые команды, комитеты, рабочие группы, цеха и другие формальные и неформальные объединения ролей, и процессы с их имплементацией интерфейсов помещаются в контейнер организации. А ассистенты, SPOC и менеджеры по работе с клиентами выполняют все процессы имплементации
11. Поэтому так важно прописывать меморандумы о взаимопонимании, соглашения о взаимодействии или уровне сервиса - это, фактически, определяет требования к роли, которая будет обеспечивать имплементацию интерфейса. Что часто пропускают в SLA так это указания на то, орг.интерфейсы каких процессов реализуются исполнителем роли SPOC, ассистента или менеджера клиента. Куда, в какие процессы он обязан выдавать информацию? Опять мы видим подход - у Анны голова большая, пусть думает. В результате абстрагированная до задерганного, ничего не понимающего менеджера, компания выглядит не самым лучшим образом.
12. Со стороны клиента ваш процесс хорош ровно настолько, насколько хорош его орг.интерфейс. Возьмите пример МФЦ - практически без изменения практик добились качественного улучшения обслуживания, поменяв орг.интерфейсы.
Но при назначении исполнителей на роль SPOC зачастую игнорируют ключевое требование к интерфейсу. Интерфейс должен ограничивать распространение ошибки, не пропускать внутрь и не передавать наружу некорректную информацию. Это требует особых навыков у исполнителя, которые отдельно редко обсуждаются и поэтому исполнители роли SPOC не полностью реализуют возложенный на них объем интерфейсной работы. А если еще вспомнить про проблему потери интерфейсом функциональности из-за переноса в другой контекст, то ситуация осложнится и дальше. Ведь для переноса знаний в новый контекст необходимо понятийное мышление, которое есть у очень немногих людей. Словом, для таких позиций нужен особый набор мыслительных практик и навыков, который, как мне кажется, сейчас слабо осмыслен, координатор или ассистент считается проходной позицией с низкими требованиями, хотя эта роль является архитектурным элементом организационно-технической системы предприятия.
13. Нефункциональность орг. интерфейсов приводит к проблеме слабых границ системы, неконтролируемым распространениям ошибок и ослаблению информационной безопасности. Если нет удобных и быстрых способов коммуникации и работы с системой, те, кто находятся снаружи ее контура, будут постоянно пытаться искать более подходящие способы работы, и создавать свои орг. интерфейсы (договоренности с командой). Эти орг. интерфейсы не будут увязаны с системной архитектурой, и неизбежно вызовут неправильные режимы работы. Особенно актуальным это стало сейчас, когда люди даже после пересечения физического периметра предприятия по-прежнему имеют доступ к ИТ-ресурсам организации. И в таком случае начинает играть крайне коварная для орг. дизайна особенность орг. интерфейсов - в отличие от спроектированных систем, в которых для несанкционированного доступа к ресурсам системы вначале надо создать возможную лазейку, имплементацию интерфейса, которой воспользуется злоумышленник, у социальных систем - людей и особенно киберличностей, имплементация орг. интерфейса есть всегда. Анна всегда готова поговорить по задаче, даже дома. Даже если это обсуждение слабо формализовано, его правила не отслеживаются, а протоколы безопасности в лучшем случае опираются на определение номера и распознавание голоса. Это слабый, плохой интерфейс, его можно намного улучшить.
В каком мире существует интерфейс?
14. Итак, интерфейсы с одной стороны существуют, раз они являются частью причинно-следственных связей составных частей системы, а с другой, ни в одной спецификации вы не увидите таблицу с составом и строчку "Интерфейсы USB 2 шт." Так что они вроде как и нематериальны, их нельзя купить, заказать, установить, они появляются в момент функционального сопряжения нескольких действующих объектов, составных частей системы или системы систем.
15. Как такое может быть? неплохое объяснение сути интерфейсов дает акторно-сетевая теория.
Дальше цитата по:
Ло Дж. Объекты и пространства // Социология вещей / Под ред. В. Вахштайна. М.: Территория будущего, 2006. C. 30–42.
Вахштайн В., Три «поворота к материальному»
«Корабль, — пишет Ло, — может быть представлен в виде сети — сети остовов, рангоутов, парусов, канатов, пушек, складов про довольствия, кают и самой команды. С другой стороны, при более обобщенном рассмотрении, навигационная система, со всеми ее эфемеридами, астролябиями и квадрантами, таблицами расчетов, картами, штурманами и звездами, также может быть рассмотрена как сеть. Далее, при еще более отстраненном анализе, вся португальская имперская система в целом, с ее портами и пакгаузами, кораблями, военными диспозициями, рынками и купцами может быть описана в тех же категориях» [Ло 2006: 224].
В данном описании все предметы исследования рассматриваются как «объекты» — корабль, навигационная система, португальская империя. Объектами их делают устойчивые связи и отношения друг с другом. Особый акцент на устойчивости: «Штурманы, противники-арабы, ветра и течения, команда, складские помещения, орудия: если эта сеть сохраняет устойчивость, корабль остается кораблем, он не тонет, не превращается в щепки, напоровшись на тропический риф, не оказывается захваченным пиратами и уведенным в Аравийское море.
Он не пропадает, не теряется, до тех пор пока команда не сломлена болезнями или голодом. Корабль определяется своими отношениями с другими объектами, и акторно-сетевой анализ направлен на исследование стратегий, которые производят (и, в свою очередь, произведены) этой объектностью, синтаксисом или дискурсом, определяющими место корабля в сети отношений» [Ло 2006: 227]. Разрыв сети отношений кладет конец дискретной объектности.
Как объект, корабль пространственно или топологически множественен: «Он занимает — а также преобразует — два типа пространства. Географическое и семиотическое (сетевое)». Он неизменен в каждой из форм пространства и сохраняется в обоих: физически — в географическом пространстве, функционально или синтаксически — в семиотическом (сетевом) пространстве. Двигается он только в географическом пространстве. Напротив, в пространстве сетей он неподвижен, никакого изменения отношений между компонентами не происходит. (А если происходит, значит, что-то не так, значит, это уже другой объект.) Именно неподвижность в сетевом пространстве делает возможным его перемещение в пространстве географическом, позволяя переплывать из Калькутты в Лиссабон с грузом специй. Перемещение из точки А в точку В некоторого объекта происходит благодаря устойчивости отношений между различными элементами сети, в которой этот объект находится. Если произойдет смещение в пространстве сетей (т.е. если изменятся конституирующие объект отношения), корабль просто перестанет быть «кораблем Х с грузом Y, следующим курсом Z», а станет чем-то иным: обломками корабля, Летучим Голландцем или просто деревом для костра.
16. С точки зрения системной инженерии семиотическое пространство (пространство знаков, описаний) - это и есть пространство, где существуют интерфейсы. Скажем, если пользователь только-только купил телефон и начал им пользоваться, еще не создал для себя интерфейсов к нему. Есть только имплементация интерфейса со стороны телефона. Это очень четко видно на сложных автоматизированных системах, которые сдаются вначале в опытную эксплуатацию (transition stage), и только потом в промышленную. Сложная автоматизированная система изначально не вписана в пространство смыслов ее оператора, она не функциональна без обучения, тренингов, сопровождения, у нее нет интерфейсов. Пока сопрягаемая система не сможет запустить на своей стороне процессы, которые реализуют вторую половину интерфейса, он сам не появляется. Чем лучше освоены системные интерфейсы, чем ближе к архитектурному замыслу они работают, тем больше функциональных возможностей у системы. В англоязычной литературе это называется 'capabilities acquisition', на русском "освоение", "использование по назначению".
17. Итак, интерфейс имеет двойственную природу - с одной стороны он материален и существует одновременно как часть двух или более искусственных или естественных систем. Никакой другой объект системной инженерии не обладает больше таким свойством, любой материальный объект является составной частью только одного другого, более высокого системного уровня, это основной принцип управления составом системы. А с другой стороны, несмотря на материальность, он не изготавливается и не приобретается.
18. Название статьи "Дырка от бублика" намекает именно на то, что мы не изготавливаем дырку от бублика отдельно, она появляется как результат изготовления бублика. И чтобы сделать хороший бублик, надо четко указать какая именно дырка должна в нем быть. Аналогично, мы не изготавливаем интерфейсы, но зато пишем на них подробную документацию, потому что дырка от бублика очень важная часть бублика. В системной инженерии идейная проработка системных интерфейсов идет со старта проекта и на ранних этапах фиксируется в документе "Операционная концепция", Concept of Operations.
19. Из этого свойства дуальности интерфейса следует два вывода:
Вывод первый - интерфейс позволяет рассматривать всю систему или ее составную часть как черный ящик, скрывать детали реализации за фасадом интерфейса. И, значит, предъявлять требования к системе и проверять исполнение этих требований следует именно на интерфейсах, оставляя реализацию требований за разработчиком. А таблички трассировки требований должны быть иметь столбец "Интерфейс".
Вывод второй - если нам надо автоматизировать интерфейсные объекты, у нас большие проблемы, так как существующие подходы к построению автоматизированных систем подразумевают материальность проектируемых и создаваемых систем, наличие целевой системы и ее жизненного цикла. Но есть целый класс ИТ-систем, которые не моделируют целевые системы, так называемые трансдоменные объекты, boundary objects. И попытки создать трансдоменные объекты с помощью методов разработки автоматизированных систем на мой взгляд обречены на неудачу. Поэтому критически важно на старте проекта понимать, к какому классу относится система и не использовать методы системной инженерии, пусть хоть и в варианте ГОСТ 19 и ГОСТ 34, для создания трансдоменных объектов на базе ИТ-систем.
20. Подводя промежуточный итог, как проверить, является ли штука интерфейсом:
- Не изготавливается
- Является частью минимум двух искусственных или естественных систем
- Позволяет сформулировать и проверить на нем предъявляемые к системе или ее составной части требования для любой, частью которой он является.
Проверьте по этому чек-листу то, что вы сейчас называете интерфейсом, и вас ждет много открытий. Подумайте, где же у вас на самом деле интерфейсы.
Трансдоменные объекты
21. Проблему информационной безопасности, дырявых границ социально-технических систем и перегрузки ресурсов исполнителей можно начинать решать, если коммуникация будет организована через трансдоменные объекты. Но прежде чем перейти к рецептам, надо ввести это понятие в область обсуждения.
22. Ключевым понятием системного подхода является целевая система. Она является точкой отсчета всех системных построений.
У меня есть знакомая, которую зовут, допустим, Анна. Она работает за пятерых - за руководителя направления, руководителя проекта, тимлида, системного архитектора и наполовину за закупщика и сисадмина. И как-то она выдала фразу: "Программа, которую я пишу, спокойно может отказаться делать свою работу, если ей поставить задачу неправильно или если она перегружена, а я все беру и беру на себя, все тащу и тащу". И действительно, софт или "железка" спокойно откажутся работать там, где люди возьмут на себя непосильные обязательства. Из-за этих непосильных обязательств, которые не выполняются или выполняются только частично, получается так, что машины намного надежнее, чем люди. В результате куда больше людей верят своим смартфонам, чем другим людям.
Рисунок 1. Данные по технооптимизму в России, исследование Евробарометра
Машины надежнее людей потому что их работа описывается достаточно точными моделями. Без четкого понимания того, как машина работает, ее просто нельзя создать и отладить. Чтобы машина или программа работала, надо четко описывать то, какие задачи и как она получает и какие результаты, как и куда выдает.
Чтобы поставить задачу системе, надо выдать ей корректное задание в правильном месте - на интерфейсе, API или в экранной форме, с использованием протоколов обмена информацией, плюс она еще и уровень доступа у вас проверит, а можете ли вы вообще ей задачи ставить. Выполнение задачи забирает ограниченные ресурсы системы, нельзя навалить сто задач и требовать, чтобы все это было сделано сию же минуту. Если системе не выдать абсолютно понятного ей задания, или у нее ресурсов не хватает, она просто ничего не сделает и ей даже стыдно не будет. Человеку же дать задание намного проще - достаточно остановить в коридоре на 15 секунд и что-то быстро надиктовать, зачастую даже проверки прав на доступ не происходит, на чем живут многочисленные продавцы по телефону и мошенники. А дальше человек сам справляется с потоком непонятно каких задач непонятно от кого, как Анна. До какого-то момента справляется, пока ресурсы не кончатся. У кого-то их много, и он тянет долго, у кого-то их меньше, и они выгорают раньше. Если только не перепоручать выполнение другим. Но тут есть ряд проблем.
Проблема Анны в том, что она не может дальше перепоручить ничего из своих дел, потому что все задачи слишком слабо формализованы и только она знает, что, как и когда делать. На передачу дела уйдет уйма времени, больше, чем на то, чтобы сделать самой.
Но необязательно так страдать от чрезмерной нагрузки, достаточно правильно построить орг.дизайн в своих проектах. И один из ключевых шагов в построении правильного орг.дизайна заключается в том, что надо перенести понятие системного интерфейса на взаимодействие людей. Достаточно начать правильно рассуждать о бизнес-процессах, организационных ролях, организационных единицах и организационных интерфейсах. И тогда не будет ситуации, которую описал Виктор Вахштайн, исследователь, который формирует результаты Евробарометра в России. На вопрос «Как вы считаете, люди действительно такие откровенные сволочи, какими кажутся?», подавляющее большинство россиян отвечает «И еще хуже!». (https://www.dv.kp.ru/daily/26739/3767213/)
Аннотация
Понятие интерфейса в культуре значительно уже и конкретнее понятия системного или организационного интерфейса в системном подходе 2.0. В этой статье я разбираю основные ошибки в мыслительных ходах по поводу системных интерфейсов, которые допускают люди, изучающие системный подход. Кроме того, я привожу примеры, когда более абстрактное понимание интерфейса приводит к переосмыслению подхода к цифровизации и внедрению ИТ-систем, в особенности про создании киберличностей и киберорганизаций.
Статья описывает часть фреймворка PRINCE 4.0 - Projects in Chaos Environment.
Ключевые слова: ограничения системной инженерии, трансдоменные объекты, организационные интерфейсы, архитектура предприятия
Интерфейс или его имплементация?
1. Если попросить разработчика ПО сделать пользовательский интерфейс, то он нарисует форму, настроит вывод данных в эти формы, проверит, что все работает и сдаст работу. Для него все просто - интерфейс отображается на экране.
Интерфейс или его имплементация?
1. Если попросить разработчика ПО сделать пользовательский интерфейс, то он нарисует форму, настроит вывод данных в эти формы, проверит, что все работает и сдаст работу. Для него все просто - интерфейс отображается на экране.
Рисунок 2. Обычное представление об интерфейсе
Качество интерфейса - это его понятность, простота использования, в целом способность работать с системой. Другими словами, интерфейс является основной причиной взаимодействия программы и пользователя. Есть интерфейс - взаимодействие происходит, нет интерфейса - взаимодействия не происходит. Причина (интерфейс) есть - есть следствие (работа пользователя с программой), нет причины (интерфейса) - нет следствия (работы).
2. А теперь проведем мысленный эксперимент. Есть экран, на котором показан пользовательский интерфейс. И представим, что на него смотрит человек со слабым зрением, которые не понимает язык интерфейса и логики работы программы. Реализация интерфейса на стороне программы не изменилась, пользовательский интерфейс программы точно такой же, но взаимодействия между программой и пользователем не происходит. Интерфейс не выполняет свою задачу, не обеспечивает взаимодействие. Если спросить разработчика в чем дело, он скажет, что к программе предъявлены неправильные требования. Другими словами, требования к системе предъявляются на интерфейсе.
2. А теперь проведем мысленный эксперимент. Есть экран, на котором показан пользовательский интерфейс. И представим, что на него смотрит человек со слабым зрением, которые не понимает язык интерфейса и логики работы программы. Реализация интерфейса на стороне программы не изменилась, пользовательский интерфейс программы точно такой же, но взаимодействия между программой и пользователем не происходит. Интерфейс не выполняет свою задачу, не обеспечивает взаимодействие. Если спросить разработчика в чем дело, он скажет, что к программе предъявлены неправильные требования. Другими словами, требования к системе предъявляются на интерфейсе.
Рисунок 3. Требования и интерфейсы
3. А вот с точки зрения системного инженера ситуация выглядит немного по другому. Системный инженер (СИ) всегда задает себе вопросы - а откуда пришло это требование, почему оно именно такое, можно ли его ослабить или наоборот, оно слишком мягкое и даже если его выполнить, то система будет работать неустойчиво? Чтобы ответить на эти вопросы, СИ делает особый мыслительный ход, который называется метасистемным переходом. Он видит в этой ситуации не одну систему, а три - программу, которая работает на компьютере (1), пользователя, который взаимодействует с интерфейсом программы (2), и надсистему, которая их объединяет - пользователя, чьи способности усилены компьютером и программой (3).
Рисунок 4. Взгляд системного инженера на интерфейс
В разработке софта интерфейсный модуль, то есть какой-то компонент, который обеспечивает взаимодействие составных частей программной системы, можно создать один раз и потом вставить во все программные модули, которые этот интерфейс используют. Поэтому классический перекос мышления у разработчиков ПО в том, что они часто воспринимают все интерфейсы через призму такой однократной реализации. Но на примере пользователя, который работает с пользовательским интерфейсом программы, видно, то интерфейс появляется как результат взаимодействия двух процессов сопрягаемых систем. Процесса отображения интерфейса на экране со стороны программы и процесса восприятия изображения со стороны пользователя. Если любой из процессов исчезает, останавливается, то и интерфейс исчезает.
Проведем другой мыслительный эксперимент. Пользователь сидит и работает с программой, у него все хорошо. Но тут он начинает уменьшать яркость монитора, уменьшает ее до минимума, перестает видеть экранные формы и не может работать дальше. С программной реализацией интерфейса ничего не случилось, она все та же, но интерфейс исчез, взаимодействие процессов отображения и восприятия остановилось. Аналогично мы можем не менять яркость монитора, а просто раскрыть плотные шторы или жалюзи в яркий солнечный день и вытащить монитор на прямой солнечный свет. Пользователь опять ничего не увидит и работающий интерфейс исчезнет.
5. Интерфейсы реализуются (имплементируются) несколькими составными частями системы, не существуют вне взаимодействия этих составных частей и зависят от контекста.
6. Отсюда вытекает важнейший вывод для орг.дизайна - не надо думать, что процессная модель должна покрывать всю деятельность подразделения от получения задания на вход до поставки готового результата. Куда важнее описать четкую реализацию, имплементацию орг.интерфейсов, интерфейсных частей процессов. Регламентировать в первую очередь надо не исполнение функции, а сервисы, которые бизнес-процессы оказывают друг-другу, обеспечивают их взаимодействие.
Рисунок 5. Схема имплементации орг. интерфейса
7. Мысленный эксперимент: представим, что наша компания заключила договор на оказание консультационных услуг. Договор - это описание, спецификация организационного интерфейса. Чтобы договор заработал, чтобы образовался орг.интерфейс, с нашей стороны должен появиться процесс формулирования и доведения задачи до исполнителя и изменения постановки и приемки результата. А со стороны консультанта должен появиться процесс приемки задачи, отчета о ходе исполнения и предоставления готовых результатов. Сам орг.интерфейс как дырка от бублика, существует между этими процессами, в тот момент, когда они взаимодействуют. Еще раз подчеркну, что интерфейс существует только тогда, когда взаимодействуют процессы на стороне заказчика и исполнителя. Если человек заболел или уволился, а замены ему нет, то интерфейс исчезает, контракт перестает работать.
8. Другой момент, который постоянно пропускают в процессных моделях, заключается в описании тех контекстов, в которых интерфейсные части процессов остаются функциональными. Вообще, формальное описание процессов, бюрократизация, позволяет масштабировать организационные системы. Но с масштабированием неизбежно происходит смена контекста и работающие орг.интерфейсы, возможно, теряют свою функциональность. Этот эффект часто наблюдается внутри больших корпораций - процесс, эффективно работающий в одной части организации перестает работать в другой даже если люди обучены, ИТ-системы внедрены, регламенты написаны.
Академическое замечание "Интерфейс как причина"
Подчеркну то, что интерфейс входит в каузальную цепочку взаимодействия составных частей системы. На практике это означает, что если интерфейс сопрягает две функции, два процесса работы двух составных частей системы, то какое-то изменение параметров одной сопрягаемой функции должно приводить к изменению параметров другой сопрягаемой функции.
Например, хотя все телефоны, планшеты и компьютеры в доме подключены к одной Wi-Fi сети и получают постоянно один и тот же физический сигнал, сопрягаются они только в тот момент, когда передаваемые данные предназначены для них, имеют четкий синтаксис и соответствуют спецификации. И тогда поведение роутера и сетевой карты связаны алгоритмом, логикой, причинно-следственными связями.
9. Процессные менеджеры зададут вопрос - а что же тогда находится в оставшейся части бизнес-процесса? Что происходит после того, как задача, материалы, рабочие продукты прошли через имплементацию интерфейса? Мой ответ близок к пониманию бизнес-процессов в варианте Rummler and Brache, Managing the white space и Jan Dietz, Enterprise ontology - внутри бизнес-процессов, ограниченные орг.интерфейсами, находятся практики. И одна из основных ошибок при проектировании процессной модели заключается в том, что в моделях процессов одними и теми же методами описания прописывают как интерфейсы так и практики.
Рисунок 6. Процессные имплементации орг. интерфейсов и практики
Интерфейс как абстрагирование от деталей реализации и проблема дырявых границ системы
10. Интерфейс не только сопрягает, но и изолирует подробности реализации, позволяет абстрагироваться от деталей, ограничить распространение ошибки. Применительно к орг.интерфейсу это означает, что нам необязательно знать исполнителей, нам должны быть известны только роли, которые исполняются практики бизнес-процесса, и которые отвечают за интерфейс. И здесь всплывает интересный момент, связанный с ассистентами и SPOC, single point of contact. Фактически, и те и другие - это роли, которые занимаются только имплементацией интерфейсов. Другими словами, есть организационные единицы - предприятия, организации, бизнес-подразделения, дивизионы, отделы, интегрированные продуктовые команды, комитеты, рабочие группы, цеха и другие формальные и неформальные объединения ролей, и процессы с их имплементацией интерфейсов помещаются в контейнер организации. А ассистенты, SPOC и менеджеры по работе с клиентами выполняют все процессы имплементации
11. Поэтому так важно прописывать меморандумы о взаимопонимании, соглашения о взаимодействии или уровне сервиса - это, фактически, определяет требования к роли, которая будет обеспечивать имплементацию интерфейса. Что часто пропускают в SLA так это указания на то, орг.интерфейсы каких процессов реализуются исполнителем роли SPOC, ассистента или менеджера клиента. Куда, в какие процессы он обязан выдавать информацию? Опять мы видим подход - у Анны голова большая, пусть думает. В результате абстрагированная до задерганного, ничего не понимающего менеджера, компания выглядит не самым лучшим образом.
12. Со стороны клиента ваш процесс хорош ровно настолько, насколько хорош его орг.интерфейс. Возьмите пример МФЦ - практически без изменения практик добились качественного улучшения обслуживания, поменяв орг.интерфейсы.
Но при назначении исполнителей на роль SPOC зачастую игнорируют ключевое требование к интерфейсу. Интерфейс должен ограничивать распространение ошибки, не пропускать внутрь и не передавать наружу некорректную информацию. Это требует особых навыков у исполнителя, которые отдельно редко обсуждаются и поэтому исполнители роли SPOC не полностью реализуют возложенный на них объем интерфейсной работы. А если еще вспомнить про проблему потери интерфейсом функциональности из-за переноса в другой контекст, то ситуация осложнится и дальше. Ведь для переноса знаний в новый контекст необходимо понятийное мышление, которое есть у очень немногих людей. Словом, для таких позиций нужен особый набор мыслительных практик и навыков, который, как мне кажется, сейчас слабо осмыслен, координатор или ассистент считается проходной позицией с низкими требованиями, хотя эта роль является архитектурным элементом организационно-технической системы предприятия.
13. Нефункциональность орг. интерфейсов приводит к проблеме слабых границ системы, неконтролируемым распространениям ошибок и ослаблению информационной безопасности. Если нет удобных и быстрых способов коммуникации и работы с системой, те, кто находятся снаружи ее контура, будут постоянно пытаться искать более подходящие способы работы, и создавать свои орг. интерфейсы (договоренности с командой). Эти орг. интерфейсы не будут увязаны с системной архитектурой, и неизбежно вызовут неправильные режимы работы. Особенно актуальным это стало сейчас, когда люди даже после пересечения физического периметра предприятия по-прежнему имеют доступ к ИТ-ресурсам организации. И в таком случае начинает играть крайне коварная для орг. дизайна особенность орг. интерфейсов - в отличие от спроектированных систем, в которых для несанкционированного доступа к ресурсам системы вначале надо создать возможную лазейку, имплементацию интерфейса, которой воспользуется злоумышленник, у социальных систем - людей и особенно киберличностей, имплементация орг. интерфейса есть всегда. Анна всегда готова поговорить по задаче, даже дома. Даже если это обсуждение слабо формализовано, его правила не отслеживаются, а протоколы безопасности в лучшем случае опираются на определение номера и распознавание голоса. Это слабый, плохой интерфейс, его можно намного улучшить.
В каком мире существует интерфейс?
14. Итак, интерфейсы с одной стороны существуют, раз они являются частью причинно-следственных связей составных частей системы, а с другой, ни в одной спецификации вы не увидите таблицу с составом и строчку "Интерфейсы USB 2 шт." Так что они вроде как и нематериальны, их нельзя купить, заказать, установить, они появляются в момент функционального сопряжения нескольких действующих объектов, составных частей системы или системы систем.
15. Как такое может быть? неплохое объяснение сути интерфейсов дает акторно-сетевая теория.
Дальше цитата по:
Ло Дж. Объекты и пространства // Социология вещей / Под ред. В. Вахштайна. М.: Территория будущего, 2006. C. 30–42.
Вахштайн В., Три «поворота к материальному»
«Корабль, — пишет Ло, — может быть представлен в виде сети — сети остовов, рангоутов, парусов, канатов, пушек, складов про довольствия, кают и самой команды. С другой стороны, при более обобщенном рассмотрении, навигационная система, со всеми ее эфемеридами, астролябиями и квадрантами, таблицами расчетов, картами, штурманами и звездами, также может быть рассмотрена как сеть. Далее, при еще более отстраненном анализе, вся португальская имперская система в целом, с ее портами и пакгаузами, кораблями, военными диспозициями, рынками и купцами может быть описана в тех же категориях» [Ло 2006: 224].
В данном описании все предметы исследования рассматриваются как «объекты» — корабль, навигационная система, португальская империя. Объектами их делают устойчивые связи и отношения друг с другом. Особый акцент на устойчивости: «Штурманы, противники-арабы, ветра и течения, команда, складские помещения, орудия: если эта сеть сохраняет устойчивость, корабль остается кораблем, он не тонет, не превращается в щепки, напоровшись на тропический риф, не оказывается захваченным пиратами и уведенным в Аравийское море.
Он не пропадает, не теряется, до тех пор пока команда не сломлена болезнями или голодом. Корабль определяется своими отношениями с другими объектами, и акторно-сетевой анализ направлен на исследование стратегий, которые производят (и, в свою очередь, произведены) этой объектностью, синтаксисом или дискурсом, определяющими место корабля в сети отношений» [Ло 2006: 227]. Разрыв сети отношений кладет конец дискретной объектности.
Как объект, корабль пространственно или топологически множественен: «Он занимает — а также преобразует — два типа пространства. Географическое и семиотическое (сетевое)». Он неизменен в каждой из форм пространства и сохраняется в обоих: физически — в географическом пространстве, функционально или синтаксически — в семиотическом (сетевом) пространстве. Двигается он только в географическом пространстве. Напротив, в пространстве сетей он неподвижен, никакого изменения отношений между компонентами не происходит. (А если происходит, значит, что-то не так, значит, это уже другой объект.) Именно неподвижность в сетевом пространстве делает возможным его перемещение в пространстве географическом, позволяя переплывать из Калькутты в Лиссабон с грузом специй. Перемещение из точки А в точку В некоторого объекта происходит благодаря устойчивости отношений между различными элементами сети, в которой этот объект находится. Если произойдет смещение в пространстве сетей (т.е. если изменятся конституирующие объект отношения), корабль просто перестанет быть «кораблем Х с грузом Y, следующим курсом Z», а станет чем-то иным: обломками корабля, Летучим Голландцем или просто деревом для костра.
16. С точки зрения системной инженерии семиотическое пространство (пространство знаков, описаний) - это и есть пространство, где существуют интерфейсы. Скажем, если пользователь только-только купил телефон и начал им пользоваться, еще не создал для себя интерфейсов к нему. Есть только имплементация интерфейса со стороны телефона. Это очень четко видно на сложных автоматизированных системах, которые сдаются вначале в опытную эксплуатацию (transition stage), и только потом в промышленную. Сложная автоматизированная система изначально не вписана в пространство смыслов ее оператора, она не функциональна без обучения, тренингов, сопровождения, у нее нет интерфейсов. Пока сопрягаемая система не сможет запустить на своей стороне процессы, которые реализуют вторую половину интерфейса, он сам не появляется. Чем лучше освоены системные интерфейсы, чем ближе к архитектурному замыслу они работают, тем больше функциональных возможностей у системы. В англоязычной литературе это называется 'capabilities acquisition', на русском "освоение", "использование по назначению".
17. Итак, интерфейс имеет двойственную природу - с одной стороны он материален и существует одновременно как часть двух или более искусственных или естественных систем. Никакой другой объект системной инженерии не обладает больше таким свойством, любой материальный объект является составной частью только одного другого, более высокого системного уровня, это основной принцип управления составом системы. А с другой стороны, несмотря на материальность, он не изготавливается и не приобретается.
18. Название статьи "Дырка от бублика" намекает именно на то, что мы не изготавливаем дырку от бублика отдельно, она появляется как результат изготовления бублика. И чтобы сделать хороший бублик, надо четко указать какая именно дырка должна в нем быть. Аналогично, мы не изготавливаем интерфейсы, но зато пишем на них подробную документацию, потому что дырка от бублика очень важная часть бублика. В системной инженерии идейная проработка системных интерфейсов идет со старта проекта и на ранних этапах фиксируется в документе "Операционная концепция", Concept of Operations.
19. Из этого свойства дуальности интерфейса следует два вывода:
Вывод первый - интерфейс позволяет рассматривать всю систему или ее составную часть как черный ящик, скрывать детали реализации за фасадом интерфейса. И, значит, предъявлять требования к системе и проверять исполнение этих требований следует именно на интерфейсах, оставляя реализацию требований за разработчиком. А таблички трассировки требований должны быть иметь столбец "Интерфейс".
Вывод второй - если нам надо автоматизировать интерфейсные объекты, у нас большие проблемы, так как существующие подходы к построению автоматизированных систем подразумевают материальность проектируемых и создаваемых систем, наличие целевой системы и ее жизненного цикла. Но есть целый класс ИТ-систем, которые не моделируют целевые системы, так называемые трансдоменные объекты, boundary objects. И попытки создать трансдоменные объекты с помощью методов разработки автоматизированных систем на мой взгляд обречены на неудачу. Поэтому критически важно на старте проекта понимать, к какому классу относится система и не использовать методы системной инженерии, пусть хоть и в варианте ГОСТ 19 и ГОСТ 34, для создания трансдоменных объектов на базе ИТ-систем.
20. Подводя промежуточный итог, как проверить, является ли штука интерфейсом:
- Не изготавливается
- Является частью минимум двух искусственных или естественных систем
- Позволяет сформулировать и проверить на нем предъявляемые к системе или ее составной части требования для любой, частью которой он является.
Проверьте по этому чек-листу то, что вы сейчас называете интерфейсом, и вас ждет много открытий. Подумайте, где же у вас на самом деле интерфейсы.
Трансдоменные объекты
21. Проблему информационной безопасности, дырявых границ социально-технических систем и перегрузки ресурсов исполнителей можно начинать решать, если коммуникация будет организована через трансдоменные объекты. Но прежде чем перейти к рецептам, надо ввести это понятие в область обсуждения.
22. Ключевым понятием системного подхода является целевая система. Она является точкой отсчета всех системных построений.