Слова-термины важны и неважны

Вчера мы с участниками моего шестидневного тренинга разбирали парадокс "обращайте внимание на слова, не обращайте внимания на слова". У нас письменная или устная речь -- это основной канал получения информации о чьей-то стейкхолдерской роли, интересе этой роли, предпочитаемых методах описания для удовлетворения интереса, описаниях систем (stakeholder -- concern -- viewpoint -- view). Но обольщаться цепочками букв нельзя: в разных словарных сообществах они означают разное, так что те или иные термины просто позволяют иметь гипотезы про используемое стейкхолдером "пространство имён", и ещё обозначают какое-то место в пространстве смыслов. Обращаем внимание на слова как флажки, которые указывают на какие-то места в пространстве смыслов, но ищем обозначаемый словами смысл в пространстве смыслов (подробней про пространство смыслов в моей книжке "Визуальное мышление" -- https://ailev.livejournal.com/1437344.html). 

Помогут ли нам в этом определения? Нет, не помогут (подробней тут: https://ailev.livejournal.com/1365963.html). Но поможет разбирательство с окружением слов: концепты редко используются поодиночке, поэтому и слов-терминов обычно встречается довольно много и можно дальше строить гипотезы о том, как концепты соотносятся между собой (Витгенштейн: ничего нельзя сказать об объекте самом по себе, кроме того, как он соотносится с другими объектами). Для этого нужно поглядеть, какие термины используются рядом (буквально: рядом по тексту) с интересующим вас термином. Определение тут не поможет, а разбирательство с какой-нибудь диаграммой или отрывком текста, набором развёрнутых высказываний -- поможет.

Так что разбираемся со словами-терминами (обращаем на них внимание!), определяем их смысл, вытаскиваем из этих слов безымянный концепт, который на разных профессиональных языках самых разных сообществ имеет самые разные имена -- и дальше работаем с концептом (не обращая на слова-термины внимания!).

Вот вам говорят: "возможности" (для вящей убедительности добавляя "бизнес" -- "бизнес-возможности"). Первый же тест: пытаетесь перевести, например, на английский -- это будет opportunity, или capability? В предпринимательстве обычно opportunity, в оргстроительстве -- capability. Слово business в IT просто означает "организационный". Так что это, скорее всего, "организационные возможности", то есть capability. И учитываем, что capability бывают и в IT (например, обсуждение capabilities в их отличии от tokens см. в 2007 году -- https://ailev.livejournal.com/490654.html).

Но что это означает? Что в голове говорящего? Правильный ответ: неизвестно! Но можно строить гипотезы, ибо вероятность того, что "ихние доллары -- это наши баксы" обычно довольно велика. Их "capability" -- это антагонист для разворачивающихся во времени процессов, уход от засилья процессного подхода, это функциональные объекты предприятия, практики, это ход к жизненному циклу 2.0: функциональное описание жизненного цикла, компетентностное разделение труда по разным практикам-деятельностям, а не разделение работ как супер-процессов. Вот я писал ровно это ещё в 2013 году, когда всё это начиналось (но писал довольно мутно): https://ailev.livejournal.com/1068096.html. А вот по итогам всех дискуссий год назад, в августе 2017 (https://ailev.livejournal.com/1369625.html): "capability -- это поставленная практика, возможность осуществления функции (т.е. готовность предоставления сервиса какими-то модулями, поддерживающими практику)". И там же слова, что необязательно пользоваться всеми значками Архимейта, в том числе значком capability. Это же мнения Максим Смирнов, указывающий на неудачку Архимейта в определении capability: он рекомендует сравнить постановку проблемы в 2012 году https://archimatemusings.wordpress.com/2012/12/27/missing-from-archimate-business-capability/ и получившийся результат в 2016 http://pubs.opengroup.org/architecture/archimate3-doc/chap07.html#_Toc489946034 в своём посте "Что не так с TOGAF 9.2" https://mxsmirnov.com/2018/07/27/togaf-9-2/ (я, кстати, давно говорю, что не ходите люди, в TOGAF, добра от этого не будет). Я вот тоже в 2011 году описывал вселенскую путаницу между использованием слов function и capability в чуть ли не десятке разных методов описания предприятий -- https://ailev.livejournal.com/938820.html.

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

1. Внимание к словам стейкхолдера. Нужно смириться и считать, что стейкхолдер говорит не столько на иностранном языке, сколько уж точно на диалекте с хитрыми значениями некоторых знакомых вроде бы слов. Это миф, что под словом "capability" или "function" (если уж они из одного естественного языка) скрывается одно и то же место в пространстве смыслов -- особенно, если речь идёт о переводах на русский. Переспрашивайте про разные примеры (не определения!), заставьте стейкхолдера попродуцировать разные тексты на его профессиональном диалекте, чтобы было понятно, как именно употребляет стейкхолдер эти якобы всем понятные слова. Подтвердите гипотезы, какие концепты системного подхода наиболее близки к употребляемым концептам стейкхолдера. Так, клиент сказал про "организационные возможности" -- переспросите прямо: может ли он привести пару примеров. Подтвердите ваши гипотезы, используя концепты системного подхода. Например, имеет ли он ввиду работы/процессы/развёртку во времени (динамическое описание), или речь идёт о функциональном описании? Это внешнее поведение для какого-то модуля (сервис, оказываемый на интерфейсе), или внутреннее (функция?). 

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

Если речь идёт о предпринятии (это не опечатка, см. учебник "Системное мышление"), то при таком подходе теряет смысл сама дискуссия о "правильных переводах", например, для понятий языка ArchiMate: можете использовать оригинальные английские термины -- но всё одно ваши клиенты не будут вас понимать. Поэтому смело меняйте эти термины на термины клиентского диалекта, тем не менее оставляя суть концепта, наиболее близкую к концептам системного подхода.

Например, вы пришли в организацию, в которой люди говорят на диалекте, заимствованном из Banking Industry Architecture Network (BIAN) "How-to Giude", http://bian.org/deliverables/bian-how-to-guide/, и узнаёте, что там различают capability и processes, это подробно разъясняется в пункте 1.2 "BIAN How-to Guide Design Principles & Techniques V6.0" http://bian.org/wp-content/uploads/2018/02/BIAN-How-to-Guide-Design-Principles-Techniques-V6.0-Final-V1.0.pdf. Ага, понятно: речь идёт о практиках против работ. Хуже того, они поясняют, что слово capability они тоже не используют, а вместо него для отделения (partitions) разных оргвозможностей друг от друга они используют слова Service Domain. Ага, тоже понятно: сервисный подход (то есть речь идёт о системе, оказывающей сервис), при этом речь идёт о предметной области (не об определении сервиса, а о воплощении сервиса). Так что имеется ввиду сервис, реализующий какую-то практику. Обсуждаем назначение, дисциплину, инструменты и рабочие продукты, исполнители с их компетенциями. Управление жизненным циклом. Поскольку дисциплина (предметная область) определяется тут, то хорошо говорить о переносе знаний. BIAN так и говорит, что Capability Model (про Service Domains) отлично служит для стандарта описания деятельности (слово "деятельность" ещё один словесный маркер для "практики", для функционального описания) банка. Моделировать в Архимейте это хорошо "орг.сервисом" (business service), ибо это внешнее представление для практики.

А вот BIAN Business Scenario -- это процесс, последовательность выполнения практик. Обсуждаем оркестровку, время выполнения, требуемые для выполнения ресурсы, операционный менеджмент. И, конечно, процессы с их винегретом участвующих практик плохи для работы со знаниями предметной области, с их описанием в стандарте. Они уникальны для каждой организации, это практики похожи. Так и пишут: process models due to their very flexibility are not good for defining canonical standards for anything but the most commodity and predictable type of behavior. Моделируем в Архимейте "оргпроцессом" (business process).

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

Теперь берём другой стандарт описания деятельности, в этот раз APICS Supply Chain Operations Reference model (SCOR, http://www.apics.org/apics-for-business/frameworks/scor), SCOR Overview -- https://www.apics.org/docs/default-source/scor/scor_overview-participant-workbook.pdf?sfvrsn=2

Там processes с показываемым между ними material flow, последовательность операций. И менеджерские practices (их там 170 штук, и дальше они оркеструются в процессы). Вау, тут по факту та же терминология, что использована в OMG Essence -- но речь идёт не о сервис-ориентированном подходе, а о просто функциональном рассмотрении, когда речь идёт о практиках. Не внешнее представление (организационная инкапсуляция важна), а внутреннее. Так что моделировать в архимейте эти практики можно сразу оргфункциями (business function), а сервисы будут инкапсулировать выполнение этих практик на каких-то организационных интерфейсах.

В любом случае мы понимаем, что все эти capability и practices это про одно, а process, stages, tasks -- про другое, это разные системные view. 

Мы обязаны их найти в самых разных Body of Knowledge, деятельностных стандартах, архитектурных языках. Нам всё равно, как они там называются, но они должны быть. Мы должны найти слова, которыми обозначаются эти концепты системного подхода в соответствующих профессиональных диалектах (слова важны!), но нам неважно, какие именно будут эти слова (слова неважны!). Если мне нравится какой-то котёнок, то мне неважно, как его зовут (слово неважно!). Но важно, чтобы хоть как-то звали, чтобы я мог отличить его от других. Если хозяева никак котёнка не зовут, я сам его назову приятным мне именем. А если хозяева его уже назвали, то я буду пользоваться именем, которое ему уже дали, но внутри себя я могу его и по-своему называть, это моё дело. Главное, чтобы это своё имя в коммуникацию не лезло. А если это котёнок по имени "Гав!" (слова важны!), то я лишний раз должен убедиться, что речь идёт именно о котёнке, а не о собаке. И если это таки котёнок -- ну что же, будем морщиться, но называть его "Гав!" (про себя называя Муркой или Мурзиком).

Но зачем нужны примеры? Почему нельзя опираться только на определения. Ну, например, чтобы лучше понимать, что обычно (но не всегда!) capabilities и practices это про одно, а процессы про другое. Вот вам capability map (https://bizzdesign.com/blog/archimate-3-0-capability-mapping/) для ArchiSurance:


А вот Microsoft Industry Reference Architecture for Banking (https://bizzdesign.com/blog/reference-architecture-models-with-archimate/):


Видно, что никакой развёртки во времени, никакой стадийности. И видно, что по большому счёту неважно, какими значками Архимейта это показывать. Если хочется сделать акцент на внутренних практиках в работе каких-то подразделений, то оргфункции. Если хочется сказать, что выполнение этих практик доступно извне, то это можно дать оргсервисами. А можно и использовать значок capability, помня, что дискуссий по поводу этого значка множество, и пройти по линии оргсервиса было бы надёжней. Можно поиграться, сказав, что capability -- это оргсистема, оказывающая сервис (но почему-то не совпадающая по границам с оргзвеном/ответственным/actor). Можно всё, если вы понимаете, что а) вы говорите в рамках концепций системного подхода, и б) как это будет услышано на профессиональном диалекте тех стейкхолдеров, с которыми вы будете разговаривать. 

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

Жизнь сложна, и мы её упрощаем, рассматривая пару-тройку концептов (по возможности не впадая в длинные дискуссии о нюансах концептов, принятых в тех или иных дисциплинах), и абстрагируясь от дискуссий о длинных списках имён этих концептов. Концепты узнаём по их терминам (термины важны! без них беда, ничего не узнаем! мычать нельзя, это неинформативно!), но не придираемся к самим терминам (они для нас неважны, а важны обозначаемые ими концепты!). 

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