Обсуждение

Проблема, конечно, стара. Однако, из любопытства, почему по вашему мнению русское "предприятие" не подходит для этого. "enterprise architecture" - архитектура уровня предприятия "enterprise system" - система уровня предприятия В отличие от "departamental system, architecture" - система, архитектура уровня подразделения.

Вроде, я прямо в постинге прописал ответ: потому что церковь "предприятием" назвать нельзя. И госучреждение -- необязательно "предприятие". PraxOS -- он не только для предприятий, он для любых организаций.

Позволю изложить свою точку зрения. Если заглянуть в словарь Даля, то слово "предприятие" в русском языке означало "дело" (которым занимаются люди в силу своего положения или интересов), под которое попадают и приведенные Вами примеры "церкви" (скорее церковного учреждения) и "государственного учреждения". То есть предприятие было связано с "деятельным" аспектом рассматриваемого предмета, образования в человеческом обществе. И мне кажется, что возврат к истокам смыслового наполнения термина, является равноправной техникой по отношения к введению в оборот нового слова. Может быть, даже более приритетной. С другой стороны, приведу другой аргумент в пользу Вашего тезиса о том, что понятие "организация" - это очень широкое понятие. В частности, организация бывает и у муравьев (т.е не является атрибутом человеческой деятельности), в то время как enterprise (предприятие), как правило, для описания объектов за рамками человеческой деятельности не используется. P.S. Анатолий, Ваш ответ несет несколько эмоциональную окраску. Поэтому хотелось бы уточнить не нарушают ли мои комментарии возможных правил Вашего блога относительно содержания и формулировки комментариев, с которыми я могу быть не знаком.

Комментариий: Во-первых, об ощущениях когда впервые сталкиваешься с этим. - Тексты становятся непонятными. О чем пишут - неясно. - Когда становится ясным, что произошла подмена термина, то содержательная картинка восстанавливается. - Однако, остаются вопросы. А собственно говоря зачем это было сделано? - Делается анализ исходного термина. И оказываются понятными мотивы авторов. Действительно, оригинально, модель более широкое понятие, включающий описание как частный случай. Т.е. имеет место ситуация обратная по оотношению к использованию более широко понятия "организация" для первода термина "enterprise". Возможно, я что-то упустил. Было бы интересно увидеть соображения Максима или Анатолия. Остающиеся вопросы к авторам: - не совсем понятно следует ли отказываться от термина модель вообще или только в рамка конкретного подхода (в данном случае DEMO)? - как быть с языковой сложностью когда "модель" и " моделирование" заменятся "описанием". Возникающая неоднозначность неудобна.

Про замену "model" "описанием" (мы не меняли русского слова "модель" на "описание", мы перевели английское слово "model" русским словом "описание") мы подробно писали в Глоссарии текста "Понятийный минимум подхода системной инженерии к управлению жизненным циклом". В тексте "Подход DEMO. Метод архитектурного описания организаций" мы только использовали определенное в другом месте слово, сославшись на текст "Понятийный минимум..." и дав ссылку на то место, где его можно взять в Сети. Кратко повторю несколько аргументов: а) в ISO 42010 прямо говорится, что "model" -- это одиночное связное описание, такое как чертеж или диаграмма, или текст. Совершенно очевидно, что речь идет не о "модели", а об отдельном "документе" (сам стандарт удивительно документоцентричен, хоть и исходит из айтишных кругов), б) совершенно верно, model -- это роль системы A, по которой мы что-то узнаем о конкретной системе B. Если система A заведомо знаковая, то мы свободно можем называть ее описанием. Более того, при этом мы не предполагаем, документоцентрическое описание или датацентрическое. При датацентрическом описании различается внутреннее физическое представление, концептуальная схема и внешнее представление данных, это разделение было введено стандартом ISO 9007 и кратенько описано в тексте по DEMO), то итоговые документы-описания получаются "выпиской" набора данных во внешнем представлении, они вторичны. А исходное описание-данные (соответствующее концептуальной схеме) мы рекомендуем называть "информационной моделью". Так что слово "описание" с одной стороны более узкое, чем философское слово "модель" (соответствует только знаковым моделям), а с другой -- более широкое, чем "информационная модель" (ибо включает не только наборы данных = информационные модели, но и не разобранные на отдельные данные первичные документы). Так что мы и слово "модель" сохранили (для общефилософского использования, но только по делу), и слово "описание" интуитивно понятно не только программистам, но и инженерам, и даже менеджерам, и слово "информационная модель" тоже стало особенным, и мы легко отличим теперь документ (который "модель" лишь в теории) от базы данных (которая много более похожа на модель, точнее информационную модель системы). Если очень хочется использовать глагол, то "моделирование" остается для информационной модели (и мы надеемся, что информационных моделей будет все больше и больше, а бумажных документов все меньше и меньше), а для случая, когда форма (документарная или набора данных, соответствующего какой-то онтологии/концептуальной схеме) неизвестна, то можно использовать слово "описывание" (глагол "описать" не вызывает никаких негативных эмоций -- "описать организацию" ничуть не менее понятно, чем "отмоделировать организацию").

Возврат к уже умершим значениям слов в нашем узком кругу называется "найшулизм" (наш хороший знакомый Витайлий Найшуль увлекается этим в промышленных масштабах) и доказал полную бесперспективность. Язык живой, и если что в языке умерло, то оно умерло неслучайно, и его уже не воскресишь. Мой ответ не несет особой эмоциональной окраски, он просто не в засушенном академическом языке, а в живом разговорном стиле. Что касается ваших комментариев, то они никаких правил моего блога не нарушают (этих правил особых и нет вовсе). Возможно, в данном конкретном случае я удивился и поэтому написал слово "вроде" -- вы спросили еще раз о том, что я (как мне показалось) специально разъяснял в тексте постинга. Но тут я не могу быть уверенным на 100%, что это ваша вина в невнимательности чтения -- в равной мере это может быть моя вина невнятности объяснений. У нас еще есть переписка (неопубликованная), в которой рассматривался даже много бОльший круг терминов, нежели помянули мы в наших открытых материалах или предложили вы. Например, попробуйте сказать про региональное УФСБ -- "предприятие" :)

По поводу "найшулизма" и вообще крайностей. По моему-мнению, избегать надо ЛЮБЫХ крайностей. С этой точки зрения утверждение, что "умершее слово не воскресишь", также является крайностью. Не вижу причин, мешающих слову получить вторую жизнь. Один из известных примеров, приходящих на ум - судьба термина "логика" от Аристотеля да наших времен. По поводу второго утверждения хотелось бы задать уточняющий вопрос. Не пытались ли вы выстроить слова из обозначенного круга терминов в некоторую иерархию (в смысле конкретизации применения), которая позволила бы адаптировать терминологию к конкретным условиям проекта? И как бы продолжение первого вопросв - что Вы думаете по поводу использования PraxOs представлений (views) применительно к конкретной предмтной области? Безусловно с предметником удобнее разговаривать на его языке (по поводу УФСБ). P.S. Возможно, я повторяюсь в своих вопросах и ответы уже существуют в текстах блога или на сайте. К сожалению, способ организации материала в виде блога иногда затрудняет работу с объемными описаниями :).

What does CRISP stand for? Is this link the right one ? - http://www.crisp-dm.org/index.htm Or do you mean something else?

Наш главный терминологический материал сегодня -- это текст "Понятийный минимум подхода системной инженерии к управлению жизненным циклом". В нем дан минимальный набор терминов для обсуждения затрагиваемых PraxOS вопросов, и пояснено, почему они по-русски именно такие, а не другие. Это не текст блога, не страничка wiki -- это как раз объемный текст, в котором довольно легко ориентироваться. Так, в подходе PraxOS нет "представлений" (views), а есть тематические группы описаний -- в глоссарии это словоупотребление прописано и объяснено. Более того, скорее всего, вы имели ввиду не тематическую группу описаний, а тематический метод описаний (viewpoint) -- ибо использование метода описаний как раз и порождает конкретные описания, а использование этих описаний специалистами в своей предметной области является рутиной и не стоит ее специально обсуждать. Много важнее вопрос, откуда эти описания получаются, в каком они языке, насколько удобно эти описания получать и прочие вопросы, которые относятся не столько к самим описаниям, сколько к методу их получения. Стандарт ISO 42010 как раз очень хвалят именно за то, что он зафиксировал разделение view и viewpoint и позволяет теперь разделять разговор об описаниях, и разговор о методах их получения. Весь разговор про терминологию, онтологию и т.д. -- это разговор про метод описания, а не сами описания. Разговор про описания -- это разговор уже про решение конкретной проблемы с использованием данного конкретного описания. Разговор об "описании как таковом, как типе, шаблоне" -- это явно разговор о методе. Применительно к конкретной предметной области мы предлагаем использовать для обсуждения как раз терминологию PraxOS, ибо предполагаем, что в данной предметной области нет соответствующих терминов. Так, в региональном УФСБ нет термина "тематическая группа описаний", и поэтому нет такого "языка предметника", для которого потребовалось бы выбрать этот термин или альтернативный. Другое дело, что сам "язык предметника" порождает описания, которые нужно как-то называть (равно как и сам язык -- метод описания, задающий онтологию и нотацию для описаний предметной области). Вот тут-то и пригождается терминология PraxOS, когда приходится иметь дело сразу с несколькими предметниками, у каждого из которых свой специфический язык. Насчет "иерархии терминов" -- конечно, все эти термины должны быть выстроены в иерархию. Эта иерархия -- какая-то из онтологий (ISO 15926 или Gellish, вопрос выбора сейчас обсуждается). Для этого выстраивания формальные определения PraxOS задаются специальным образом, позволяющим их встраивание в иерархии классов (иногда называемые таксономиями) по отношению специализации. Подробней об этом можно почитать, например, в текстах по Gellish (поглядите по ссылкам в профайле сообщества gellish_ru. Конечно, в этой иерархии затем находятся места и для специфических терминов конкретных предметных областей (например, названий конкретных классов описаний -- типа "отчет разведчика" и даже конкретных описаний "отчет разведчика ноль ноль восемь о шпионе номер ноль ноль семь", хотя тут будет задействован другой тип отношения, а именно -- конкретизации, а не специализации). Но это предмет уже другого обсуждения, это "управление информацией", текст я как раз сейчас пишу. Когда опубликую, тогда обсудим подробней.

Ни в коем разе не этот. Речь идет о "элементарной организации", определяемой в реферируемой книжке Jan Dietz "Enterprise Ontology". Кстати, все упоминаемые нами книжки есть в Сети (см., например, ссылки в http://community.livejournal.com/openmeta/199621.html).

Анатолий, а) будучи вновь заинтригован проблемой перевода этого термина, б) все-таки чувствуя некоторое несоответствие (диссонанс) между понятиями скрывающимися за терминами "enterprise" и "организация" в) пытаясь продолжить понимание предложенного коллаборативного подхода к поддержанию PraxOS и его содержанию я потратил некоторое время на ознакомление с тем какое понятие скрывается за эти термином у Дитца, а также в повседневной практике (на примере словаря Merrium-Webster). По результатам хотел бы поделиться результатами и задать один вопрос по практике PraxOs. Итак, Дитц: It turns out that the notion of enterprise ontology could be beneficial not only for managers and designers of organizations and information systems, but also for the employees and the clients of an enterprise, be it a commercial company or a government agency. Let us start by noting that managing an enterprise, but also getting services from it as a client or collaborating with it as partner in a network, is nowadays far more complicated than it was in the past. In a similar manner, imagine that it is possible for you to acquire the right amount of the right kind of knowledge of the operation of the company from which you bought something you want to complain about, or of the government agency from which you are trying to get a license but have not succeeded yet. In summary, imagine that the business processes of these enterprises have become transparent to you. Из этого контекста как бы напрашивается вывод, что понятие "enterprise" как бы неразрвно связано с экономическим аспектом деятельности. (Кстати, не здесь ли источники противоречия с примером УФСБ, которое в российской действительности последние десятилетия связано с экономикой в "положительном" - борьба с коррупцией и отрицательном "крышевание" смыслах). И такая связь с экономикой находит потверждение и в толковом словаре. Привожу выдержки: 1: a project or undertaking that is especially difficult, complicated, or risky 2: readiness to engage in daring or difficult action : initiative 3 a: a unit of economic organization or activity ; especially : a business organization b: a systematic purposeful activity Т.е. при использовании термина "enterprise" всегда присутсвует экономический аспект. Что означает, что перенос проблематики книги на более широкую почву (переводя исходное понятие термином организация) возможно и является обоснованным, однако не передает точную трактовку автора текста. P.S. Кстати интересна этимология этого слова, которая полностью созвучна русскому предпринимать, предприятие. Etymology: Middle English, from Anglo-French, from entreprendre to undertake, from entre- inter- + prendre to take — more at prize Date: 15th century Но для меня как результат приведенных размышлений важен ответ на следующий вопрос, отнсящийся к процедурным моментам PraxOS. Как предлагается снимать подобные конфликты (противоречия) в рамках работы над PraxOs? Спорить до конца? Оставлять два термина с замечаниями? Что-то другое? Т.е. некоторая практика, принятая в вашем сообществе.

1. Вы совершенно верно заметили, что у Дитца для enterprise важен еще и экономический аспект. Вообще, в рамках рассмотрения enterprise у Дитца может быть телеологическое рассмотрение, от которого он открещивается при рассмотрении organization. Но телеологических рассмотрений может быть несколько разных: экономическое (в разных его вариантах, например голдраттовское финансово-логистическое вдоль производственной цепочки, или традиционное activity based costing -- если "назначение предприятия" понимается как "машинка для производства денег"), инженерно-логистическое (назначение организации -- произвести какой-то продукт или сервис. обратите внимание, я тут использовал слово "организация", а не его подкласс "предприятие", как в предыдущем предложении). В принципе, можно экономическое рассмотрение для некоммерческих организаций свести к "машинке по созданию убытка", а есть новомодные работы, рассматривающие "настоящих клиентов некоммерческих организаций -- их спонсоров (а тех, кому посталяются продукты и услуги -- не клиенты, а "бенефициары"). Но этим сейчас заниматься неинтересно, финансы у нас чуть-чуть потом, на закуску. Наш вывод: organization у Дитца -- это координационное рассмотрение, со включенными в него по необходимости элемента связи с другим рассмотрением, продуктивным. По факту, у Дитца нет производственной организации, инфраструктрной организации и прочих "организаций", которые традиционно рассматриваются в рамках enterprise architecture -- он это все оставляет для понятия enterprise. ОК, ему легко в английском языке. Мы же оставляем общее слово "организация", как объединяющее все аспекты социального образования, призванного а) достигать каких-то целей и б) координировать разделение труда внутри себя. Место DEMO в системной инженерии тем самым -- процессы контрактации (agreement processes). Недаром одно из первых полномасштабных применений DEMO -- это VISI, правила информационного обмена при контрактации. Насчет русского "предприятия" в смысле "он предпринял ряд шагов для достижения своих целей", то это слово в современном русском языке имеет смысл не постоянно действующей организации, а конкретного проекта: типа "он затеял поход на Северный Полюс. Это его предприятие доблестно провалилось". Слово "организация" означает как раз то, что "предпринимает" самые разные инициативы, не разваливаясь при этом и поддерживая нацеленность (разную для разных стейкхолдеров этой организации, поэтому разные стейкхолдеры этой организации заинтересованы в различных методах описания, в том числе метода DEMO для архитектурного описания координации). Мы пока не провели этой глубокой работы по переименованию enterprise-организация, organisation-DEMO-координация в ее связи с продукцией. Но как минимум, мы наметили этот шаг и зафиксировали это намерение письменно. Конечно, это уже нельзя будет считать изложением книжки Jan Dietz, это будет некоторое содержательное движение вперед. Шутка насчет экономического аспекта деятельности регионального УФСБ, конечно, была встроена в само предложение именно этой организации в качестве примера ;) 2. Содержательные противоречия в нашем сообществе принято обсуждать до упора, иногда по нескольку лет, пока не найдутся достаточно убедительные аргументы. Если решение по термину вообще никого не устраивает (как сейчас решение с "продуктивными актами", вместо очевидного "продуктными" или "производственными", не подходящими по разным причинам), то термин мы приводим в угловых скобках. А дальше либо привыкаем, либо находится более подходящее слово.

Хотелось бы отметить, что в обсуждаемом тексте не очень четко определена эта разница, важная для понимания подхода DEMO. В частности, было бы полезно указать связь между Speech Act Theory и использованием заимствованного из этой теории понятия act. И пояснить, на примере, чем act (АКТ) отличается от action (ДЕЙСТВИЯ), и как они связаны друг с другом.

Специфика данного конкретного текста -- это показать Метод, а также попробовать поговорить о применении DEMO по-русски. Вопросы о теории, как было указано в преамбуле к тексту, остались за рамками работы. Более того, я не уверен, что мы дальше будем развивать DEMO так, как его нам дал Jan Dietz. У нас есть гипотеза, что как раз acts в DEMO пришли из разных viewpoints, и мы на эту тему будем делать более подробное исследование. Мы будем через некоторое время готовить "Понятийный минимум системной инженерии к управлению контрактацией/соглашениями/координацией", где более подробно пропишем про координационные акты и их связь с актами продуктивными, которые (как нам сейчас кажется) пришли из другого (не-DEMO) viewpoint. Собственно, я вкратце именно это и прописал в постинге. Насчет action -- тут нужно еще и отделять этот термин от activity в двух значениях, и уторговывать с определением в Gellish. Так что это отдельная работа, опять таки в рамках следующего такта. Мы, скорее всего, приступим к этой работе сразу после того, как получше определимся с управлением проектами (где тоже задействована Speech Act Theory -- в варианте Last Planner, у меня в блоге были на эту тему ссылки примерно полгода назад).

Кстати, насчет фокуса данной работы на Методе -- в результате стало понятно, что Метод (в котором нужно откуда-то извлечь неформальное описание организации, затем как-то его разметить разными цветами и т.д.) очень и очень ограничен, и мы поэтому не станем фиксироваться на его дальнейшем развитии. Так, этот метод совсем не работает, если описание взято из нормативных документов типа "Положение о подразделении" (этот пример любит приводить vvagr), а такое ведь случается сплошь и рядом. Или если DEMO пытаются использовать для проектирования будущей координации, а не для отражения того, как уже устроена жизнь в существующей организации, что тоже весьма часто.

Скажите а могу я статьи с вашего сайта у себя на блоге публиковать? Е сли да - то ссылку ставить или просто источник указывать?

Публикуйте, конечно. Но обязательно ставьте ссылку (я регулярно правлю тексты старых статей).

Разбирались с боссом про описание разделения зон ответственности в компании. И я упомянул DEMO, как способ описания, который можно для этого использовать. На что босс спросил: мы сейчас на BPMN все описываем, почему нам этого может быть недостаточно? Был бы признателен за комментарий на тему DEMO vs BPMN.

DEMO -- это про то, что кто кому может поручать и кому рапортовать затем об исполнении поручений ("коммуникационная парадигма", как люди общаются по поводу выполнения работ). BPMN -- это про то, кто что в каком порядке делает ("процессная парадигма"). Бывает ещё "артефактная парадигма": кто с какими объектами работает. В разных парадигмах удобно описывать разные аспекты деятельности компании.

Огромное спасибо за обобщение! Складывается впечатление, что DEMO нам тоже нужно.