Пособие для санитаров по выявлению неожиданных изменений реальности

Подкаст с Марком Акоевым. Заведующий лабораторией Наукометрии Уральского федерального университета имени первого Президента России Б.Н.Ельцина; член ACM, IEEE Computer Society и EuroCRIS. Стаж научно-педагогической работы – 19 лет. Область интересов: информационные технологии для поддержки решений в организации и управление научными и образовательными процессами. Эксперт в области наукометрии. Автор и редактор монографии "Руководство по наукометрии: индикаторы развития науки и технологии" http://info.clarivate.com/rcis_scientometrics С презентациями выступлений можно ознакомиться по адресу: https://www.slideshare.net/Marcus.Akoev

1:00 Про практики образования детей с задержками развития и конфликт исполнения желаний и реальности.
2:30 Кто побеждает - человек, который говорит "да" или "нет". Конфликт между переговорными стратегиями.
3:40 Культурные паттерны переговорных практик.
4:30 Культура обсуждений в российских университетах, этика последствий в переговорах.
5:30 Ловушка переговоров, которые начинаются с "да". Базовые паттерны предсказаний в голове российского руководителя.
7:00 Логика "бла-бла-бла" или "баба-яга против"? Какую тактику выбрать?
8:00 Чем работа в команде хороша для "бабы-яги"?
9:00 Опасность веры в свою правоту.
10:03 Пример ложной позиции - зелот менеджмента качества.
11:30 Разбор неверности концептов в голове, корпоративное донкихотство.
12:10 Адекватность мышления, привязка концептов к реальности.
12:45 А так ли уж ошибается Черный Властелин?
13:10 3 совета корпоративному мастеру переговоров.
14:45 Перефраз 3 советов.
15:00 Пузырь информационной реальности и что с ним делать.
16:00 Сборка-разборка сложных ситуаций и применение системного мышления в переговорах. Требование к адекватности мышления.
16:30 Отделение критики решения от личной критики, запрет перехода на личности.
17:20 Бойль и появление научного метода как противоположности личных нападок. 18:10 Рекомендации для руководства по рациональности.
18:40 Бэкон, рациональность и познание мира.
19:20 Как появился научный метод?
20:10 А существуют ли ангелы? Как схоласты ставили эксперименты по измерению количества ангелов на кончике иглы?
22:05 Рациональность и прагматизм как основа переговоров.
23:20 Есть ли у вас интерес в этих переговорах или вы отстаиваете правду?
24:10 Правление миром должно давать хлеб, масло и джем. Есть ли последствия в реальности от твоих рекомендаций?
25:10 Подведение итогов обсуждения. "Баба-яга" долгосрочно побеждает обещальщиков. Компромиссы или осознанность и прагматизм?
26:50 Рецепт. Зачем ты это делаешь? Продавливание своих проектов.
28:20 Аспект самомотивации. Наличие неправильных определений как оскорбление реальности.
30:20 Чья расстановка квадратиков соответствует реальности? Что делать "бабе-яге"?
31:00 Как отловить тех сумасшедших, которые правят реальностью?
31:45 Почему таких сумасшедших (почти) никогда не наймут?
32:30 Если только он сам не Тони Старк.
33:10 Концепция человека, стоящего в двух мирах.
33:45 Элон Маск не рулит, Эдисон тоже.
34:00 Пример Уатта как человека, который стоит в двух мирах и изменяет реальность.
37:30 Команды, которые меняют мир.
38:20 Как стать таким человеком или создать такую команду?
39:30 Провал идеи с распространением системного подхода - Форрестер с идеей распространения этики последствий.
41:05 Условия выживания сообщества системного подхода в современных корпорациях.
42:10 Стратегия компании как необходимое условие распространения системного подхода на предприятии.

Экономика "шабашки" - фрилансеры, консультанты и контракторы

Во время пресейла часто сталкиваюсь с тем, что даже HR и наниматели не до конца понимают разницу между этими терминами и их смыслом. Этот текст отражает мое текущее понимание этих слов.
Итак, у вас есть какая-то работа, которую нерационально делать внутренними ресурсами, и вам ее надо кому-то поручить.

Фрилансер
Когда? - Когда объем работ ясен, есть рыночные ставки, можно объективно сравнивать предложения и отслеживать качество выполнения работ.
Тип контракта. - Обычно фикс по деньгам и времени (FTM), качество проработки зависит от квалификации, но не хуже, чем спецификация. Контракт типовой, желательно заключать его в терминах "хочу, чтобы работало вот так", и не предписывать методы исполнения работ.
Зачем? - Разовые типовые работы либо для того, чтобы вразумить распустившихся штатных сотрудников. Поясню - иногда люди начинают лениться, ты нанимаешь фрилансера на ту же работу, которую поручаешь работнику. И когда фрилансер сделал работу, а сотрудник еще тянет резину, ты показываешь ему раскладку по работе, ее стоимости для работодателя и задаешь риторический вопрос: "Что бы ты сделал на моем месте?" Обычно вразумляет либо с человеком надо прощаться.

Консультанты
Когда? - Когда объем работ не ясен, нужна профильная экспертиза или сторонний взгляд. Еще один вариант - показать "зазвездившимся" работникам, что есть люди куда круче них и надо закрыть рот и работать, а не воображать себя незаменимым специалистом.
Тип контракта. - Почасовка (FTM, T&M), качество проработки зависит от работ, но не хуже, чем спецификация. Впрочем, здесь больше поле для торговли как с той так и с другой стороны, т.к. задачи сложные и неоднозначные. Контракт должен сопровождаться SLA. Консультант, который не оговаривает четко SLA, должен вызывать подозрение. SLA может меняться по ходу работ.
Зачем? - Разовые нетиповые работы, "пробная поездка" на специалисте либо вообще оценка необходимости новой должности на предприятии. Лучше заплатить нормальных денег один раз и понять надо-не надо, чем нанять кого-то по рекомендации и потом мучиться с увольнением. Сторонний взгляд из-вне отрасли. Часто бывает так, что единственная работа консультанта - это рассказать начальству секрет Полишинеля или дать очевидную рекомендацию. Да, нет пророка в родном отечестве.

Контракторы, они же внештатные сотрудники
Когда? - Когда понятен фронт работ и необходимые компетенции, но нельзя составить план работ, спецификацию и составить договор. При этом нанимать в штат бессмысленно, т.к. работа временная. Либо сам человек не хочет (ставка контрактора обычно выше, чем штатного сотрудника).
Тип контракта. - Обычный временный трудовой договор по совместительству либо абонентский договор, почасовка. SLA лучше бы иметь, но не критично. Отличие от консультанта - нужен конкретный результат, сделанная работа, измененный бизнес-процесс, работающая система и т.п. Консультанты больше про поговорить и дать рекомендации, контрактор несет ответственность за то, что штука заработает.
Зачем? - Работы с непонятным объемом, "пробная поездка" на специалисте, оценка необходимости новой должности на предприятии и уточнение требований к вакансии. Частый случай - получить классный результат за фиксированные деньги. Вы берете эксперта, который за три месяца точно проведет исследование, сформирует методологию и проведет обучение лучше, чем любая рабочая группа за полгода.

Dislike, unshare, unsubscribe.

Связь стратегии, архитектуры предприятия и управления проектами

Распространено такое мнение, что архитектура предприятия - это такая оторванная от жизни практика. Она становится оторванной от жизни из-за того, что руководители не берут на себя ответственность за формирование качественной стратегии, которая фокусирует ресурсы, усилия на переломном моменте. Дело в том, что архитектура предприятия находится между стратегическим и проектным управлением. Она берет стратегию и преобразует ее в вводные для проектов - уставы, бизнес-требования, орг.структуру и ИТ-ландшафт. Если у вас на входе будет миссия и видение, сформированное с помощью https://strategy-madlibs.herokuapp.com/ то нечего сваливать на архитектора предприятия вину за то, что архитектура предприятия невнятная, расплывчатая и абстрактная. Это как обвинять руководителя проекта в том, что он не может представить точный бюджет и график проекта, пока инженеры не разработали даже концептуальное решение, а заказчик не решил, в какой конфигурации и для чего он хочет это решение использовать. Вначале четкая стратегия, потом ясная архитектура, затем точное и своевременное исполнение, так это задумывалось и так это работает там, где оно работает. Если эта логика где-то рвется, то не работает все целиком.
Цепочка "стратегия предприятия - архитектура предприятия - стратегические проекты" на каждом уровне принятия решений заставляет делать однозначный выбор и нести за него ответственность. И, к сожалению, цепочка рвется в самом начале. Очень мало кто из руководителей готов взять на себя ответственность за однозначную стратегию, которая проверит его рыночную гипотезу. От менеджеров продуктов требуют однозначных гипотез по рынку и их проверки, от руководителей проектов требуют однозначных гипотез по работам и их проверки, и только стратегия намеренно мутна и неясна, чтобы размазать ответственность.
И в заключение я напомню оригинальное высказывание генерала Паттона:
A good solution applied with vigor now is better than a perfect solution applied ten minutes later.
As quoted in The Unknown Patton (1983) by Charles M. Province, p. 165
В русском переводе эта фраза нам известна как: "Хороший план сегодня лучше безупречного плана завтра". Но Паттон говорил не про планы, он говорил про решения, которые воплощаются сейчас или потом. Цену планам Паттон знал - она равна нулю сама по себе. Важно действие и принятие ответственности, важно четкое мышление и понимание последствий, выбор между развилками последствий и корректировка мыслительной модели мира.
Лидер в ответе за все.

Инженерия трансграничных объектов в проектах цифровой трансформации предприятия

История 1. Как люди 500 лет умирали от цинги, при этом владея знаниями, как лечить эту болезнь.
В 1500 году до н.э. египтяне знали, что если будешь есть печень, то будешь лучше видеть в темноте. Они не подозревали про существование витамина А, но уже понимали как он действует. Точно также европейцы в 1400-х годах не подозревали про существование витамина С, но знали, что свежая еда и цитрусовые предотвращают появление цинги.
Но дальше произошло то, что можно было бы назвать комедией ошибок, над которой не особо посмеешься. Европейцы, которые вообще-то считают себя довольно умным народом, по меньшей мере семь раз забыли и переоткрыли этот секрет борьбы со страшной болезнью, которая унесла жизни более миллиона моряков, больше, чем погибло во всех морских сражениях за тот же самый период. А ведь цинга бушевала и на суше, в осажденных крепостях, тюрьмах, удаленных поселках. Васко де Гама, первооткрыватель Индии, а затем Губернатор Португальской Индии и вице-король Индии, из-за цинги потерял 100 человек из 160 в своей экспедиции.
Почему же европейцы, которые знали как лечить цингу в 1400-х, переоткрывали это знание в 1593, 1614, 1707, 1734, 1747, 1794, пока, наконец, в 1904 году не выяснили все окончательно? Ответ простой - плохая коммуникация и неважное состояние науки.
Люди - это одни из немногих животных, организм которых не вырабатывает витамин С. Но при нормальном питании мы получаем его в достатке с пищей, и его запаса в организме хватает на 4 недели. Если мы будем только тратить запасы, например, питаться только консервами и макаронами, то через 4 недели может начаться цинга. Тонкость здесь заключается в том, что витамин С разрушается при высокой температуре, например, при готовке и на открытом воздухе, так что в обработанной еде или в еде, которая долго хранилась, вы его не обнаружите. В 1400-х годах итальянские моряки знали, что цитрусовые фрукты предотвращают появление цинги, а португальские моряки даже выращивали апельсиновые деревья на островах, которые лежали вдоль морских путей, но это знание было впоследствие утрачено.
Но что же случилось с повторными открытиями этого знания в 1593, 1614, 1707 и далее? Ведь цинга уносила жизни еще сотни лет подряд? Почему великие державы потеряли 1,000,000 подготовленных моряков от этой болезни, все время владея простым и доступным секретом ее лечения? Открытия 1593-1794 были просто проигнорированы, потому что шли вразрез с общепринятым тогда представлением, что цинга вызывалась “внутренним гнилостным разложением, вызванным плохим пищеварением”. Да, я думаю, мало у кого хорошо пахло изо рта в то время, в эту идею было легко поверить. Британский флот в начале 19 века использовал лимоны для профилактики и лечения цинги, но это знание было утрачено в 1867 году, когда лимоны заменили соком лаймов. Сок - это обработанный фрукт, а если его еще подержать в тепле и на свету, и хранить в медных трубках, то витамина С в нем почти не останется. Но утрата соком лаймов лечебных свойств прошла незамеченной потому что корабли стали быстрее, плавания стали короче, питание на суше получше, и моряки просто не успевали потерять накопленные в организме запасы. Кто-то в снабжении, наверное, получил премию и звездочку за оптимизацию, а флот приобрел скрытую проблему. В длительных морских походах моряки продолжали умирали от цинги, и сок лаймов не спасал. И тогда выдвинули новую теорию, которая говорила, что цинга вызывается пищевым отравлением из-за некачественной пайки консервных банок, а некоторые даже говорили что причиной цинги был упадок боевого духа или плохая гигиена.
В 1907 году провели эксперименты на морских свинках. Это был удачный выбор подопытного животного, они точно также как и люди не вырабатывают витамин С в организме и поэтому у них может развиться цинга. И когда обнаружился факт, что свежая еда спасет от цинги, идея, наконец, прилипла и овладела общественностью. Мы все теперь знаем, что надо есть свежую пищу и пить витамин С. Цинга причинила огромное количество страданий, унесла множество жизней, и привела к огромным последствиям для человечества, потому что трудно ожидать милосердия к туземцам от команды моряков, у которых половина товарищей умерла на их глазах в страшных мучениях. И что печально, все это время люди владели знаниями по тому, как легко и просто лечить эту болезнь.
Что интересно, Петр 1 при создании морского флота организовал поставку лимонов и апельсинов с юга Европы, хотя обеспечение флота клюквой по американскому примеру или квашенной капустой по немецкому могло решить проблему гораздо проще. В 1932 году за окончательное доказательство того, что цинга вызывается недостатком витамина С, дали Нобелевскую премию.

Обобщение 1. Трансграничные объекты позволяют знаниям пересекать смысловые и терминологические барьеры.
Ситуация с цингой четко показывает, что если есть непонятная ситуация, для описания которой у нас не хватает общепринятых понятий, то мы можем долгое время не делать никакого прогресса в решении проблемы, а там, где прогресс есть, мы его не видим, не ценим и в конце концов утрачиваем. Люди не владели концепцией витаминов и не могли рассуждать в логике их недостатка, поэтому не могли планомерно решать проблему цинги. И эта ситуация в меньшем масштабе повторяется сейчас, когда команды не знают, что делать с сайтом, который не генерирует лиды, с отделом продаж, который не дает объемы и прибыль, с системой CRM, которую уже целый год не могут интегрировать с базами данных и не могут объяснить в чем проблема, с учебными курсами, через которые проходят тысячи людей и выходят ровно с тем же уровнем знаний, с каким приходили на курсы, с предприятиями, которые проходят через 12 реорганизацию-реинжиниринг и перестройку бизнес-процессов без видимого финансового результата. Во всех этих ситуациях у людей не хватает знаний о “витамине С”, и у них нет механизмов и инструментов для целенаправленного поиска этого “витамина С”. Там, где есть прогресс, он не замечается, скрытые знания уходят вместе с носителями, открытий, которые меняют реальность предприятия, все меньше. Хотя внутри организаций наверняка хранятся знания, которые бы много что изменили, если бы их распространили по всему предприятию.
И тут на помощь могут прийти трансграничные объекты, т.н. boundary objects. Это достаточно известное на английском языке понятие, Google выдает 245,000 результатов по запросу "boundary objects", а сама тема была на пике популярности 15 лет назад:
https://trends.google.com/trends/explore?q=%2Fm%2F03hmq0g&date=all
Русское языковое сообщество переводит этот термин как “граничный объект” или “интерфейсный объект” https://www.multitran.com/m.exe?l1=1&l2=2&s=boundary%20object
Для слепых мудрецов, которые ощупывают слона, трансграничным объектом будет маленькая фигурка слона, которую один мудрец может ощупать целиком и понять о чем говорят другие мудрецы.
Если проиллюстрировать что такое трансграничный объект с помощью простенькой диаграммы, то получится что-то такое.

Есть система S, у которой есть пользователи A и B. У этих пользователей в голове есть представления, модели системы S, Sa и Sb соответственно. У них есть некие представления о том, какая система должна быть, это Sa’ и Sb’ соответственно. И они хотят изменить систему S на S’, для этого им нужны процессы изменения Pa и Pb. Эти пользователи могут говорить на разных языках, использовать разные термины, приписывать одним и тем же словам разные значения, работать в разных предметных областях и делать с системой разные вещи, выполнять разные процессы преобразования системы S в S’.

Чтобы эффективно договариваться о совместных действиях, им нужны трансграничные объекты Sx, Sx' и Px.

Примеры таких трансграничных объектов: план управления проектом, устав и паспорт проекта, канбан доска, wardley map, цепочка создания ценности и TLSC диаграмма, рабочий прототип в Эджайл разработке, модель жизненного цикла, архитектурная модель, CJM и т.п.

Литература дает следующий список: 
- физические объекты, такие как прототипы (Carlile, P. R. (2004). Transferring, translating, and transforming: An integrative framework for managing knowledge across boundaries. Organization Science, 15(5), 555–568.), 
- разделяемые ИТ-приложения (Pawlowski, S. D., & Robey, D. (2004). Bridging user organizations: Knowledge brokering and the work of information technology professionals. MIS Quarterly, 28(4), 645–672.), 
- карты и модели (Star, S. L., & Griesemer, J. R. (1989). Institutional ecology, ‘Translations’ and boundary objects: Amateurs and professionals in Berkeley’s Museum of Vertebrate Zoology 1907-39. Social Studies of Science, 19(4), 387–420.), 
- стандартизованные формы и хранилища (те же источники).

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

Но из опыта все знают, что те же сводные планы проекта (integrated master schedule) и канбан-доски бывают качественные и пригодные для координации нескольких сотен или тысяч участников, а бывают просто отписками. Поэтому характеристики таких трансграничных объектов не ограничиваются формой, хотя она и важна, и ценность этого текста в том, что в нем дается обзор и разбор характеристик трансграничных объектов применительно к моделям сквозных процессов и процессной архитектуре в целом.

Чтобы глубже разобраться в этих характеристиках, я расскажу куда более сложную, но менее интересную историю про внедрение одной разделяемой ИТ-системы в госорганах и мэрии. Оригинал этой истории находится по адресу https://www.cc.gatech.edu/~keith/pubs/chi2010-scale.pdf конспект изложен в истории 2, см. ниже.

История 2. Система управления бизнес-процессами в госсекторе и местном самоуправлении - что помешало наладить взаимодействие

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

Ключевые слова: совместная работа, госсектор, границы организации, полевые исследования, экосистема.

Вводная часть
Наиболее часто в отчетах по изучению опыта внедрения ИС изучаются внедрения в условиях, когда есть четкая организационная граница, очерчивающая контур организации и контур автоматизации процессов. В таких условиях ясно как организуется совместная работа, кто кому и что поручает. Это не говорит о том, что ограниченное таким образом внедрение будет простым, но даже для очень крупных предприятий со сложной органиграммой, контур автоматизации, полномочий и ответственности всегда достаточно четко ясен и понятен. В этом смысле все, что находится в границах одного предприятия, находится в рамках того, что мы в этой работе назвали масштабом (scale). И отличие этой работы в том, что мы разбираем внедрение ИС не в рамках одного масштаба, пусть даже сложного, а многомасштабное внедрение, на уровне поставщиков и операторов отдельных услуг, их объединений, городских комитетов, которые курируют работу поставщиков услуг на муниципальном уровне, и на федеральном уровне. И в этом плане внедрение ИС осложняется не только длительным циклом использования технологии, но и различными потребностями в функциональности ИС с точки зрения федеральных органов, муниципальных образований и собственно поставщиков услуг. Мы рассматриваем ИС как средство, которое способно навести мосты между различными участниками такой экосистемы, и рассказываем про то, как в таких условиях распространяется знание предметных областей, практики работы и распределяются полномочия и влияние между различными организациями, которые работают в рамках этой экосистемы.

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

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

Контекст исследования
Исследование шло 1 год, проводилось множество интервью на всех уровнях - от исполнителей в некоммерческих организациях до служащих правительства штата Джорджия. Также был подробно опрошен поставщик ИС.

Если обобщить заданные вопросы, то их можно объединить в три больших вопроса:
1. Как каждая конкретная организация, на своем уровне, видит и использует ИС?
2. Как конкретно ИС пересекает границы между отдельными поставщиками и операторами услуг, региональными властями, правительством штата и государством и как поддерживает повестку этих организаций на каждом организационном уровне?
3. В чем состоят ключевые различие в том, как предполагалось будет использоваться ИС и как по факту она используется?


Происхождение ИС по управлению бизнес-процессами по обеспечению бездомных
До 2003 года не было никакой систематической отчетности в этой области, поэтому нельзя было оценить эффективность действующих программ по помощи бездомным. С 2003 года закон обязал штаты, муниципалитеты и некоммерческие организации собирать и предоставлять обязательную отчетность по программам помощи. В штате Джорджия сложилась особая ситуация, т.к. распространение получила одна ИС, в других штатах было закуплено множество различных ИС. Изучаемая ИС работала с середины 90-х, и некоммерческие организации, которые занимались помощью бездомным, согласовывали свои действия через эту ИС. Это наложило свой отпечаток на логику работу ИС, в частности, она была ориентирована на конкретные ситуации оказания помощи, а не на людей, которым оказывалась помощь, не на семьи и не на предотвращение бездомности. Автоматизация была оптимизирована на управление ночлежками.
После вступления законодательства в силу назначение ИС было изменено и она теперь должна была генерировать обязательную отчетность по оказанию помощи бездомным. Такое изменение назначения привело к задержке в реализации проекта 2 года, потому что пришлось перестраивать философию управления процессами.
Вторая проблема, которая возникла в ходе внедрения, заключалась в том, что логика обеспечения услуг сменилась логикой обеспечения исполнения требований  законодательства, в результате организации стали меньше сотрудничать и стали более бюрократическими, стали защищать свои потребности в финансировании за счет бюджета, скрывать и утаивать информацию об имеющихся ресурсах.
Отдельные случаи оказания услуг стали намного менее важными, потому что отчетность требовала данных по демографии, а самих услуг стало куда больше. А сама структура данных, которая была построена от логики отдельных случаев оказания услуг, не позволяла построить качественную систему консолидации отчетности, тем более что сами организации за это время создали множество различных способов ведения записей о своей оперативной деятельности. Все это создавало множество случаев непонимания, несправедливости в распределении бюджетных средств и привело к разочарованиям в среде некоммерческих организаций.

Местный уровень
Некоторые некоммерческие организации принимали активное участие в разработке ИС. Для ряда организаций это был единственный инструмент управления данными, другие использовали бумажный документооборот, а в ИС вели только обязательную отчетность. Для большинства организаций использование ИС в основном было продиктовано необходимостью предоставлять обязательную отчетность, вести учетные данные по клиентам для того, чтобы отчитываться перед надзорными органами, обычно сразу на нескольких уровнях от муниципального до федерального. Трансформация из системы управления бизнес-процессами и кейсами в систему подачи отчетности не прошла для этих организаций бесследно, они были вынуждены создавать формы Excel и базы данных Access для составления этих отчетов. Понятно, что на такой шаг организации пошли от нужды, но само существование ручных процессов обработки данных поставило под вопрос  целостность и доступность этих данных в самой ИС. Кроме того, при таком подходе именно сама форма отчетности, но никак не содержание стало приоритетом при работе с ИС.
Как нам объяснил директор компании, создавшей ИС, структура баз данных, которая лежала в ее основе, основывалась на информации вокруг оказания услуги, потому что именно так ранее координировались некоммерческие организации. Но даже и этот функционал использовался не всеми работники, которые были задействованы в работе над кейсами. Бывало такое, что в организации сидели работники на полную ставку или волонтеры, которые забивали в ИС данные из бумажных документов. Именно с организацией взаимодействия в ИС возникли наибольшие проблемы и для этого были две причины. Причина 1 - в целях защиты персональных данных информация была поделена на куски и данные по клиенту (например, его персональные данные и история обращений) хранились раздельно с разным уровнем доступа. Это усложнило получение полной информации по клиентам, что было важно при обработке повторных обращений. Вторая проблема была в некотором роде противоположностью первой, и она касалась отражения ресурсов некоммерческих организаций в общем доступе. В результате публикации активов всех организаций в общий доступ каждый стал видеть ресурсы каждого и некоторые организации получили потоки заявок на некоторые ресурсы, что нарушило их регулярную работу, и им пришлось перебрасывать клиентов из одного кабинета в другой.

Региональный уровень: планирование развития региона
На региональном уровне озабочены не столько эффективной работой на уровне отдельных некоммерческих организаций, сколько оказанием услуг особым сегментам крайне бедных и бездомных граждан. Кроме того, задачей регионального уровня было собрать вместе наиболее активных представителей местного уровня и заставить их говорить друг с другом.
На региональном уровне и выше не интересны операционные подробности, но нужна статистика по людям, которым оказали помощь. На региональном уровне наибольший интерес у пользователей ИС был к организации взаимодействия между операторами услуг и правительственными агентствами. Это взаимодействие диктовалось двухлетними планами развития. Офис мэра создавал рабочие группы и комитеты, целью которых являлось достижение заявленных уровней показателей региона. Это все накладывало отпечаток на то, какую информацию надо было вводить в ИС.
Этот баланс между реальной заботой о нуждающихся гражданах и стратегической работой лучше всего характеризует потребности пользователей регионального уровня в функционале ИС. Для поставщика ИС это означает, что надо увязывать требования 200 с лишним операторов услуг, а потом из введенных этими операторами данных генерировать отчетность, которая будет полезна на региональном и федеральном уровне.

Федеральный уровень: законодательство и измерение эффективности проводимой политики
На уровне штата ИС используется как агрегатор данных и потребность заключается в получении точных, полных и своевременных данных. Поэтому основная озабоченность пользователей на федеральном уровне заключалась в том, чтобы операторы услуг на местах на самом деле использовали ИС для работы и вводили данные. Иначе объем выделяемых бюджетных средств не соответствовал бы реальным потребностям в финансировании на местах и создало бы кризис ресурсного обеспечения в уже напряженной текущей ситуации. Кроме этого, пользователи на федеральном уровне были крайне обеспокоены соблюдением законодательства о защите персональных данных. Эта потребность в статистических данных и озабоченность в защите персональных данных граждан привела к перекосу в восприятии пользователями федерального уровня необходимого функционала системы. Им было практически все равно насколько она удобна и приемлема для обеспечения работы на местах, ключевым для них являлся объем и точность собираемой статистики.

Обсуждение
Наш разбор ситуации вокруг разделяемой ИС по управлению бизнес-процессами обеспечения бездомных показывает как вокруг нее появляются различные ожидания и интересы. И такая ситуация встречается все чаще по мере того, как все чаще ИС привлекаются для организации взаимодействия между различными операторами и госорганами.

Трансграничные объекты и классификации
Можно рассмотреть изучаемую ИС как трансграничный объект между гражданами, правительством, а также некоммерческими и муниципальными организациями, которые действуют как от лица правительства, так и от лица граждан.
В принципе, так изучаемая ИС и должна была работать - с одной стороны она должна была поддерживать ежедневную работу операторов услуг, при этом обеспечивать информацией региональный уровень об уровне этих услуг и обеспечивать информацией контур принятия законодательных решений.
Другим способом можно рассматривать изучаемую ИС в виде трансграничного объекта между масштабами. Но для этого ИС должна была обладать способностью порождать множественные представления хранимых данных и обеспечивать обсуждение и переговоры как вверх так и вниз по иерархическим уровням организаций.
Карлайл так характеризует трансграничные объекты: “Цена работы с новым для каждой группы не только в том, что им приходится изучать новое, но включает в себя и цену адаптации своих практик работы, приведение их в соответствие с полученными от другой группы знаниями на границе взаимодействия этих групп”. Другими словами, настоящая межфункциональная группа заставляет участников постоянно изменять свои практики работы по мере получения новой информации от других участников. Мало понять, что тебе пытаются сказать, надо еще и подумать, каких изменений это от тебя потребует, а потом еще и измениться. Это большой труд и трансграничный объект как раз уменьшает размер проблемы при такой сложной коммуникации.
Возвращаясь к рассматриваемой ИС, которая пересекает несколько организационных границ и является многомасштабной, то в данном примере ИС теряет основную функциональность и перестает качественно поддерживать ежедневную работу, а операторы услуг стараются только угадать чего хочет региональное и федеральное руководство. То есть низовые уровни изменяют свои практики, причем так, что гражданам становится хуже, но вот обратного процесса не происходит.
Продолжая цитировать Карлайла: “Не только сама коммуникация сложна, но также сложно улучшить качество обслуживания людей, потому что для того, чтобы достичь этого, надо как-то повлиять на другие функции и организационные уровни, которые и порождают отрицательные последствия для других из-за своего нежелания менять свои знания, а для этого если и есть, то лишь небольшое количество каналов”. Другими словами, чтобы качественно изменить услуги гражданам, в приведенном примере надо было менять способы работы на всех уровнях, чтобы низовые уровни не получали только ухудшение условий работы, рост бюрократии, неудобную для работы ИС, потому что это ухудшение в итоге привело к тому на верхнем уровне появилась недостоверная информация о том, что происходит “на земле”. Информация должна идти и сверху вниз и снизу вверх, а все организационные уровни должны изменять свои практики работы исходя из полученных новых знаний о работе всей системы.
В итоге все это приводит к тому, что ожидания между организационными уровнями расходятся, а ИС перестает быть трансграничным объектом, и становится инструментом надзора.

Перечитывая Ривердейла
Использование ИС действительно снизило повторный ввод персональных данных и упростило процесс получения услуги для обращающихся за помощью граждан, но вот польза от внедрения ИС для работников, которые занимаются делопроизводством, замылена размытой ответственностью и некорректным использованием системы в рамках экосистемы оказываемых услуг. В результате эффект внедрения сложно измерить, а выгоды сложно реализовать. После внедрения ИС экосистема операторов услуг во многом утратила дух низового взаимодействия из-за того, что ИС принуждала исполнителей к регуляторному соответствию, а не обеспечивала коллаборацию.
Кроме того, ИС не заменила существующие социальные каналы взаимодействия и поэтому поставщики и операторы услуг не воспринимали ее полезной в этом плане. Для них это был еще один набор отчетов, которые надо заполнить для начальства.

Полученные знания и опыт
Чтобы ИС подобного класса приносили ожидаемые выгоды, мы думаем, надо иметь куда более настраиваемые под конкретные нужды решения. В таком случае сценарии использования ИС могут сместиться от обеспечения регуляторного соответствия к подходу система-как-средство-коммуникации. Но к сожалению, у подобного подхода мало шансов на реализацию в такой зарегулированной среде и к тому же где найти технических специалистов, которые бы смогли обеспечить настройку этой системы под конкретные нужды “на земле”?
Кроме того, стало понятно, что у разных заинтересованных сторон принципиально разные представления о том, какие данные нужно хранить в системе, какая степень формализации процессов необходима, и в общем как найти тот баланс между локальным знанием, которое быстро меняется, и достаточно стабильными категориями данных, которые нужны для построения отчетности и направления развития разнообразной экосистемы.
И, наконец, есть соображения о том, как мы классифицируем работу, которая происходит на разных организационных уровнях, в разных масштабах. Примером может быть выбор что отслеживать - людей или случаи оказания помощи, федералам важно первое, а “на земле” важно второе. И такие выборы приводят к кардинальным последствиям, когда речь заходит о передаче данных из ИС от одного организационного уровня к другому. Например, в изучаемом случае установленная на старте внедрения жесткая таксономия услуг привела к тому, что по мере развития экосистемы и увеличения количества предоставляемых услуг, стало непонятно куда их вписывать. Метаданные перестали описывать данные и отчетность на разных уровнях попросту разошлась и потеряла смысл. В результате некоторые операторы перестали поддерживать каталоги услуг и попросту вели в ИС обязательную отчетность.

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

Основы планирования от морских котиков

Из книги "Лидер в ответе за все" (Extreme Ownership)

Через год я вернулся назад в центр подготовки в Сан-Диего служить инструктором по основам боевой работы SEAL. И я использовал этот сценарий для урока по принятию решений. В классе сидели только что назначенные на должности командиров взводов и их заместители, и я сказал им: иракские войска захватили заложников, вы спланировали спасательную операцию и готовы ее начать. "Но перед самым выдвижением, - говорю я им, - разведка донесла, что во дворе дома, где находятся заложники, установлено взрывное устройство, а в доме есть пулеметное гнездо. Что будете делать?"
В классной комнате сидели люди с разным опытом боевых действий. "Не идти туда, - сказал один офицер SEAL, - это не стоит риска". Кое-кто с ним согласился.
Заместитель командира взвода сказал: "Надо перепланировать задание". Кое-кто с ним согласился.
Я замолчал и дал им подумать. "Я задам вам вопрос, - сказал я классу. - Если вы выезжаете на задание по спасению заложников с вероятностью прямого столкновения можете ли вы быть уверены в том, что в доме нет пулеметчика, а во дворе не установлен взрывной заряд?" Все замотали головами, так как понимали, что эта опасность подстерегает их всегда. Вы должны всегда предполагать, что встретитесь с этой опасностью во время каждого задания и вы должны подумать, как избежать последствий такой встречи. Думать по другому означает быть плохим лидером. В этом и состоит планирование задачи: никогда не принимать ничего за данность, готовиться к вероятным неблагоприятным исходам и запасным путям, повышать вероятность успеха задачи и снижать риски для бойцов, которые выполняют задачу.
Наше подразделение выполнило задачу по спасению заложников несмотря на новые данные разведки о смертельных угрозах, потому что мы уже учли эти угрозы в своих планах. Мы предусмотрели конкретные шаги по тому, как избежим урона от взрывного устройства, где бы оно не находилось - снаружи или внутри здания. Мы тщательно спланировали действия, чтобы для противника был элемент неожиданности, так что даже если у врага были пулеметные позиции, они бы все равно ничего не знали про то, что мы идем, пока не было бы слишком поздно. Поэтому нам не надо было менять планы, мы были готовы. И как результат хорошего планирования и четкого исполнения этого плана, плюс немного удачи - нас ждал успех.
И стандартные практики планирования SEAL можно применять к бизнесу и личной жизни.

Что такое задание? Планирование начинается с разбора стоящей перед вами задачи. Лидеры должны предоставить четкие инструкции для своей команды. Если лидер понимает задачу, то он может передать это знание ключевым исполнителям. Слишком широкая или невнятная постановка задачи приводит к тому, что исполнители теряют фокус, действуют неэффективно, и рамки задачи незаметно раздвигаются.
Задание должно объяснять общее назначение и ожидаемый результат действий. Исполнители на передовой, которым поручено выполнить задачу, должны глубоко понимать причины, по которым им поручили что-то делать. Несмотря на простую форму, замысел руководства (Commander's Intent) является наиболее важной частью вводной на задачу.

Краткое руководство по созданию замысла руководства
Задание/Цель. Предназначение задачи (задачи более высокого уровня). Здесь приводятся обоснования почему надо выполнить ту или иную задачу. Обычно приводится в форме Кто, Что, Когда, Где и Почему. Также допустимо использовать формулу Действия-Результаты-Итоговая ситуация.
Конечное состояние. Описание желаемого состояния, например, выполнение задачи. 
Последовательность. Шаги плана, курс действий, последовательность получения результатов.
Начальное состояние. Описываете всю относящуюся к делу информацию, включая ограничения и решения, которые необходимо принять. Какая оперативная обстановка, время до начала действий и т.п.
Ключевые решения. Какие решения надо принять в ходе исполнения?
Антицели. Описания нежелательных исходов. Антицели должны дополнять список ключевых решений так, чтобы было понятно, как их принимать в нужный момент.
Ограничения. Все, что ограничивает вам и что вы должны учесть - от регламентов до погоды и местности.

По Gustavsson, P.M., Hieb, M.R., Niklasson, L., Eriksson, P. and Moore, P. (2008d) "Machine Interpretable Representation of Commander's Intent". In: Proceedings of the 13th International Command and Control Research and Technology Symposium (ICCRTS). Bellevue, Washington, USA. Available at: http://www.dodccrp.org/events/13th_iccrts_2008/CD/html/papers/188.pdf. 188.

Если все исполнители понимают замысел руководства, то они смогут принимать решения в соответствии с этим замыслом непосредственно в ходе исполнения, без постоянного согласования с верхами. При планировании надо рассмотреть различные варианты курсов действий, включая использование людей, ресурсов и возможностей по обеспечению. После того, как руководство выбрало курс действий, надо перейти к подробному планированию. Такое планирование позволяет наилучшим способом задействовать все имеющиеся в распоряжении ресурсы, т.к. опирается на самую актуальную информацию и практические знания исполнителей.
Лидеры должны поручить планирование своим подчиненным в как можно большей мере. Линейные руководители должны нести полную ответственность за планы и их исполнение. Вовлечение младшего персонала критично для того, чтобы найти смелые и неординарные решения и заложить их в планы. Даже если вы поручите небольшой кусочек плана исполнителям, это повысит их вовлеченность в исполнение задачи, они лучше будут понимать подоплеку планов и будут куда более эффективными и результативными в ходе исполнения.
Руководитель наблюдает за планированием со стороны и главное тут - не углубиться чрезмерно в детали планов. Когда руководитель удерживает дистанцию, он видит всю картинку целиком и обеспечивает соответствие плана замыслу. Руководитель, который удерживает дистанцию, становится "тактическим гением" - он определяет слабые места плана, которые могут привести к его провалу. И задача лидера состоит в том, чтобы устранить эти слабые места перед приведением планов в жизнь.
После того, как планы составлены, их надо довести до сведения всей команды и всех остальных участников. Лидеры должны аккуратно представить только необходимую информацию в очень простой, ясной и краткой форме. Нельзя допустить перегрузки участников информацией. Планирование и доведение планов должно быть открытым обсуждением, с вопросами и ответами даже со стороны младших участников. Если исполнители не понимают планов или боятся задавать вопросы, то способность команды достигать целей резко снижается. Поэтому лидеры должны задавать проверочные вопросы своим подчиненным, вызывать обсуждение планов и удостовериться, что все все понимают.
После обсуждения планов и изучения замысла руководства, люди должны обсудить и понять свои роли и роли других участников. Так они смогут до конца понять планы реагирования - кто должен что делать в каком случае, у кого просить поддержки при возникновении сложной ситуации. И можно легко проверить, успешно ли были доведены планы до участников - достаточно спросить у них, понимает ли команда и другие участники в чем их роль?
План должен избегать реализации выявленных рисков насколько это возможно. SEAL известны тем, что идут на рисковые задания, но они перед этим тщательно высчитывают все возможные риски.  Хороший план увеличивает вероятность успеха до максимума и сводит риски к минимуму. Но сосредотачиваться надо на рисках, с которыми можно работать. Нужны подробные планы избегания рисков, чтобы все, кто задействован в исполнении задачи, понимали что делать, если возникли препятствия или дела пошли не туда. Не надо бояться рисков, кто не рискует, тот не пьет шампанского.
Лучшие команды не только тщательно планируют свою работу, но и анализируют потом насколько их планы сработали. Это помогает им лучше планировать действия в будущем. Но для такого разбора эффективности планов надо выделить время. Когда SEAL возвращаются с задания, даже если они измотаны и очень хотят отдохнуть, они все равно проводят "post operation debrief". На нем команда кратко разбирает все этапы выполнения задачи, определяет что сработало, а что нет и что можно улучшить в следующий раз, чтобы не повторять совершенных ошибок.

Вот описание процесса планирования, которое мы использовали:
Анализ задачи.
- Понять замысел руководства и миссию, понять конечное состояние (цель).
- Договориться и зафиксировать ваш замысел руководства, миссию и конечное состояние.
Определить необходимый персонал, ресурсы и временные рамки.
Распределить планирование.
- Дать полномочия ключевым исполнителям проанализировать возможные курсы действий.
Определить наилучший курс действий.
- Выберите самый простой курс действий.
- Сосредоточьте усилия на выбранном курсе действий.
Дайте ключевым исполнителям полномочия по разработке планов, которые реализуют курсы действий.
Спланируйте запасные пути для каждого этапа действий.
Как можно лучше спланируйте реагирование на риски, на которые можно повлиять.
Дайте вводные и поручите разработку планов линейным руководителям.
- Отойдите в сторону и побудьте тактическим гением.
Постоянно проверяйте ход планирования и задавайте вопросы по планам, удостоверьтесь, что вся вновь поступающая информация учтена в планах, а сам план адекватен ситуации.
Доведите план до всех участников и обеспечивающих подразделений.
- Тщательно обсудите замысел командования.
- Задавайте вопросы и устройте обсуждение в команде, убедитесь, что все все понимают.
Проведите анализ того, насколько сработали планы.
Проанализируйте полученный опыт и используйте его при дальнейшем планировании.

Конструкция, поведение, функция и сервис

Представьте, что у вас есть продуктовый бизнес, допустим, вы разрабатываете, производите и продаете автомобили, телефоны или компьютерные программы. Если вы производите автомобиль, то все детали должны подходить друг-другу, а каждый последующий автомобиль, который вы делаете на производственной линии должен как можно больше походить на другой, в этом смысл серийного производства. Тем более программы, они вообще идентичны до последнего бита. Чтобы производство могло собрать идентичные единицы продукции, разработчики должны передать им комплект документации, который описывает единственно верный вариант конструкции. Такой единственно верный вариант конструкции называется в английском языке point design, а на русском - "конструкция, отвечающая заданным требованиям".

Хотя point design и описывает автомобили с размерами, в идеале абсолютно идентичными от одной машины к другой, нас как пользователей автомобиля интересует изменения этого размера. Действительно, что в кресло можно было удобно сесть, оно должно деформироваться под нами, а не быть строго того размера, которого его выпустили на заводе. Чтобы колеса ехали по дороге и мы не чувствовали неровностей, они должны менять свою форму, поглощать удары. 

Даже микропроцессор в автомобиле, хотя мы этого не видим, при работе постоянно меняется физически:

Посмотреть как физически меняется микропроцессор во время своей работы можно в симуляции

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

В конструкции нас интересует не какое-то ее одно фиксированное состояние, а набор состояний, поведение.

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

Так мы пришли к простой мысли - у каждой конструкции есть свое поведение. И именно поведение какой-то конструкции нам интересно и полезно. Отличие подвески МакФерсон от многорычажной нас интересует ровно потому, что они просто по-разному ведут себя.

Теперь разберемся в том, что такое функция и чем она отличается от поведения. Представьте, что вы положили на кресло автомобиля мешок со свинцовыми чушками весом 500 кг. Оно прогнется так, что подушки сиденья лопнут, а может и пружины порвутся. Если в обычной квартире устроить бассейн на 5 кубометров, то пол провалится. Если телефон унести далеко от станции базовой станции, то он потеряет сигнал и по нему нельзя будет позвонить. То, что кресло ломается, пол дома проваливается, а телефон перестает обеспечивать связь - это тоже поведение. Но это поведение за рамками контекста эксплуатации. У каждой конструкции есть какие-то рамки контекста, в которых его поведение будет полезным и его можно будет использовать по назначению. Чтобы отделить полезное поведение продукта от поведения конструкции вообще, есть понятие функции.

Поведение конструкции автомобиля (набор состояний) вне контекста эксплуатации

Функция - полезное поведение конструкции в рамках контекста эксплуатации.

У нас появилось слово "контекст", что это означает с практической точки зрения? Это означает, что функцию мы моделируем совсем по-другому. У функции есть входы и выходы, функция преобразует входы в выходы. Допустим, есть автомобиль, у него есть конструкция, у этой конструкции в рамках контекста дорожных дорог и заправок есть полезное поведение - он перевозит людей и грузы. На вход функции автомобиля поступают люди и груз в одном месте, а на выходе - люди и груз в другом месте, куда автомобиль их привез. При проектировании функцию автомобиля разбивают на составные подфункции, например, есть кресло автомобиля, у кресла есть конструкция, у конструкции есть поведение - деформироваться под тяжестью и придавать форму гнущимся предметам:

Накидка приняла форму кресла

На входе функции кресла человек, на выходе человек в эргономичной позе. Аналогично багажник, у багажника есть конструкция, у конструкции есть поведение - ограничивать объем, и есть функция - обеспечивать хранение предметов при перевозке. На входе функции багажника предметы и грузы, а на выходе защищенные от  дождя и ветра предметы и грузы.

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

И хотя это именно у конструкции есть какая-то функция, разработка и проектирование начинаются именно с размышлений о том, как продукт будет работать, о его функционировании. В целом разработчику проще подумать так: "Вот есть человек, вот есть машина, вот есть дорога, по дороге будут встречаться заправки. Вначале человек должен сесть в машину, значит, у машины должна быть функция посадки людей, на входе которой будет стоящий перед ней человек, а на выходе человек в салоне автомобиля. Какая конструкция могла бы обеспечить такую функцию? Заходим мы в машину через дверь, давайте посмотрим какая конструкция дверей подходит больше? Теперь у нас есть человек в салоне автомобиля, он не может всю дорогу стоять, ему нужно сесть, значит выход предыдущей функции - человек в салоне автомобиля будет входом следующей функции, посадки в сидячее положение. На входе этой функции человек в салоне автомобиля, а на выходе человек в эргономичной позе. Эту функцию может выполнить вот такая конструкция кресла". Функции связаны между собой входами и выходами и они позволяют рассматривать комплексное поведение продукта, планировать его использование, для того, чтобы создать оптимальную конструкцию, которая будет наилучшим образом вести себя в данном контексте использования.

Инженеры разделяют рассмотрение конструкции и функции. Функциональное рассмотрение позволяет обсуждать логику поведения и использования системы, а конструктивное рассмотрение позволяет принимать такие проектные решения,  которые наилучшим образом реализуют согласованные командой проектировщиков функции. И вот конструкция, отвечающая заданным требования (point design) и есть такое конструктивное исполнение, которое обеспечивает такое наилучшее поведение.

При проектировании инженеры разбивают автомобиль на части целого - он состоит из кузова, шасси, электрики с электроникой, отделки салона, стекол; и функционально - автомобиль должен ездить вперед и назад, разгоняться и тормозить, поворачивать вправо и влево, защищать от погоды и столкновений. Такие разбиения называются конструктивными, или PBS, plant breakdown structure, и функциональными, или FBS, functional breakdown structure.

Теперь "склеим" конструкцию и функцию. Вот есть автомобиль в контексте использования - есть дорога, заправки, водитель, пассажиры и грузы. Функция автомобиля - перемещение пассажиров и грузов. Эта функция одинакова для Феррари и Газика, они оба перемещают пассажиров и грузы. Но вот сервис эти двух автомобилей разный, это очевидно. Сервис - это выполнение функции с каким-то уровнем (уровнем сервиса, service level) на каких-то условиях (соглашение об уровне обслуживания, service level agreement). И сервис, конечно, является поведением продукта, но мы фиксируем как уровень сервиса так и контракт на выполнение сервиса только для определенной точки пространства и времени. Эта точка называется "интерфейсом". Вы не можете получить обслуживание в МакДональдс, если сядете на скамеечке рядом, вам надо будет подойти к стойке и сделать заказ по определенным правилам. Вы не можете уехать с вокзала или улететь на самолете, сидя у себя дома, вам надо прибыть на вокзал или в аэропорт и занять свое место по строгим правилам. Вы не можете отправлять сообщения в WhatsApp силой мысли и в зоне плохого приема.

Сервис - это функция с определенным уровнем исполнения этой функции, у которой есть контракт на ее исполнение, и которая оказывается в определенной точке пространства и времени.

Теперь, когда вы понимаете, что такое функция, конструкция и сервис, можно разобраться, а что же такое системный уровень и зачем он нужен.