Обсуждение

О! Пасиб!

1) Раздел "Системный подход". Некорректно употреблено понятие "элемент". Элемент - это неделимая часть (по опреледению и этимологии слова). А система состоит из компонентов (частей), которые в свою очередь могут представлять собой (под)системы. Не очень удачное определение системы. Для примера, другое определение системы: -- Системой является совокупность компонентов, объединенных упорядоченным образом. -- Компоненты находятся под влиянием объединяющей их системы, а поведение самой системы изменяется при исключении любого из ее компонентов. -- Упорядоченная совокупность компонентов осуществляет некоторую деятельность. -- Совокупность компонентов определена с позиции некоторого заинтересованного лица. Система - это взгляд заинтересованного лица на некоторую область (собственной) деятельности. Заинтересованное лицо может представлять собой группу (заинтересованных лиц). Именно поэтому, целесообразно говорить, что системы это всегда социо-технические системы. В противном случае (чисто технических систем) у вас просто выпадает весь раздел про акторов, роли, практики. И далее в отсутствии социальной составляющей вы не сможете говорить о результатах, качестве и целях, поскольку это тоже принадлежит людям. 2) Раздел "Архитектурный подход". В рассказе об отличиях документоцентрической и датацентрической следовало бы помянуть структурированную и неструктурированную информацию. Далее вы всё сводите к учёту. Но учёт не обязательно представляет собой структурированные данные. Бухгалтерия - яркий пример этому (учёт есть, структурирования нет). Онтологии (и таксономии) - это прежде всего структурированные данные (знания). При описании уровней абстрации описания системы. Строка "нормативные (показатели эффективности)" не совсем корректно. Эффективность - это один из показателей качества. Лучше написать "нормативные (показатели качества, например, эффективность)". 2) Раздел "Деятельностные подходы" Было-бы целесообразно помянуть "регулярную деятельность". Перефразирую вашу же мысль: "Всё что произошло более 3 раз, это регулярная деятельность". В разделе "Системный подход" всё-таки целесообразно упомянуть холистический взгляд (можно трактовать это как холистическое свойство) на систему. Дело в том, что в разделе "Деятельностные подходы" вы в явном виде описываете "назначение процесса как целого". Другими словами, вы оперируете понятиями, которые не ввели. В определении процессного подхода конфликт (двусмысленность) понятия "практика". Абзацем выше вы говорите, что "практика - это подисистема". А в определении "практика - это элемент". Так делима или неделима на части практика? Понятие "процесс" можно вложить (онтологически специализировать) в понятие "проект". -- Процесс - это проект, не требующий пересмотра целей при получении результата. Деятельность - это система практик, где каждая практика это проект. При этом существуют разновидности проектов: целеизменяемые (проекты) и целенеизменяемые (процессы). 3) Раздел "Процессный подход" Опять же, для гармонизации процессного и проектного подходов под "зонтиком" деятельности (системы): -- Результат процесса - это цель проекта, не требующая пересмотра (изменений). Можно не воздерживаться от понятия "бизнес - процесс". Просто объяснить, что "бизнес" это и есть деятельность. А "бизнес - процесс" это и есть "процесс деятельности". Это одно и то же, только разными словами.

Спасибо за комментарии. 1. Система состоит из систем, а на нижнем уровне (когда мы не собираемся декомпозировать дальше) из элементов, это согласно ISO 15288. Есть разные стандарты системной инженерии, в некоторых из которых даже предписываются наименования для разных уровней иерархии в декомпозиции системы (в том числе "подсистема", "компонента", "сборка" и т.д.). Мы выбрали "элемент" как самое часто встречающееся название для первого уровня декомпозиции (кстати, в большинстве других вариантов слово "подсистема" используется довольно низко по уровням иерархии, а не на верхнем уровне). Дело в том, что мы старались не сочинять свои термины, и не брать их произвольно из литературы. У нас есть тексты вполне определенных стандартов, и мы следовали как раз им. 2. То же (попытка строгого следования стандартам, а не произвольное философствование из головы) относится к предложенному определению системы. Никаких "компонентов, объединенных упорядоченным образом" не было во встречавшихся нам определениям, зато наличие элементов (именно этот термин!) и связей между ними (причем для связи требовалась интеракция, взаимодействие элементов, а не просто "ассоциативная связь") было во всех встреченных определениях. Социотехничность вводится путем обязательного указания назначения системы. Так, Вселенную нельзя представить системой, пока не укажешь ее назначения ;) Особо отметим, что у нас не через понятие система втаскиваются акторы и процессы, а наоборот: понятие процесса рассматривается с точки зрения системного подхода, понятие система втаскивается в понятие процесса (если вообще что-то можно сказать про "втаскивание понятий" на таком высоком уровне. Хотя слово "подход" обозначает именно такое "втаскивание" -- и в этих терминах у нас не столько процессный подход к системе, сколько системный подход к процессам). 2. Понятие "структурированные" очень расплывчато. Любой матерный текст структурирован на слова (даже если в нем трудно выделить предложения), а слова -- на буквы. Буквы структурированы (ежели в растре) на пиксели. Мне кажется, что сборка-разборка в разные осмысленные документы более важны, и именно это свойство подчеркивается в определениях из литературы. Нормативные показатели (эффективности) -- это не столько качества, сколько прямые плановые предписания, "выполнить которые -- долг, перевыполнить -- честь". Например, приказано выкачать за текущие сутки из скважины 248 тонн нефти, произвести на вот этом блоке 898МВт-часов электроэнергии по такому-то графику. 3. Как я понимаю, все что "нерегулярная деятельность" -- это просто поведение, набор разрозненных действий. Другое дело, что слово "регулярная" так же многозначно, как и те слова, которые мы употребляем. Холистический взгляд не нужно вводить, его нет в стандартах системной инженерии. В тех редких случаях, когда нужно отнестись к мереологии (отметить, где говоришь о части, а где о целом), можно просто указать, как мы и сделали, указав про "систему в целом". Для этого указания не требуется вводить специальное слово. Не нужно же мне вводить слово "проза" для того, чтобы написать этот текст ;) 4. Насчет связи процесса и проекта: мне не кажется, что результат процесса -- это цель проекта (и поэтому оговорка про требование изменений для меня вообще несущественна). Про разграничение бизнеса и процесса у нас будут другие пятьдесят страниц. Бизнес -- это телеологический взгляд на деятельность (по Jan Dietz).

> Нормативные показатели (эффективности) -- это не столько качества ... Нет. Я не это имел в виду. Качество _всегда_ измеримо (по определению из ИСО 9000). Существуют показатели качества. Например первичные показатели: -- производительность -- экономичность -- эффективность -- результативность -- качество труда и т.п. Существуют и вторичные (производные) показатели - различные индексы качества.

В ФЗ "О техрегулировании" нет такого понятия "корпоративный стандарт". Есть поняите "стандарт организации". Желательно, чтобы методология не противоречила законодательству. А какой смысл вводить новый термин "процессный стандарт" для reference model? Чем не нравится существующий термин "эталонная модель"? Не очень удачное понятие "работа" (поручение работы). Лучше для Task из 15288 использовать слово "задание" (слово "задача" тоже плохо). Так мы приходим к "списку заданий", который легко привязывается как к ролям, так и "управлению заданиями" (task managemet, management). Раздел "Пути реализации Концепции". Непонятен набор выделенных для описания процессов. Например, процесс "управление инфраструктурой" и процесс "управление проектами" не могут быть в одном списке (перечислении). Это процессы разного уровня в иерархии ЖЦ. Раздел "Оценка управления ЖЦ" Если вы говорите, что Концепция это стандарт, то напрашивается: -- в начале методики в перечислении подходов как-то упомянуть процесс стандартизации (стандартный подход :-) -- в саму Концепцию включить описание: = метода оценки соответствия; = процесса "управления оценкой" соответствия стандарту (Концепции) = знаки соответстия Прагматика знаков соответсвия. Речь не идёт о "знаках качества СССР". Когда я работал с японскими компаниями, они делали это так. Рисовали схему процессов и цветом (знаками) помечали процессы, не соответствующие стандартам (требованиям). Сразу было видно: -- "узкие" места производственной стандартизации; -- динамику (при сравнении схем различных сроков давности).

Я это вполне понимаю. Поэтому я и говорю, что не про качество (даже измеримое) говорю. Я говорю про то, что вам начальник дает производственное задание на день. И оценивает вашу работу по этому показателю. Вам даются плановые значения Key Performance Indicatior, а после работы проверяется, насколько реальные значения соответствовали плановым. А качество -- это совсем другая история.

То, что вы называете "учёт" хорошо было бы тоже привести к международным стандартам. Судя по картинке из презентации (слайд "документы и данные в датацентрическом подходе") вы имеете ввиду процессы content management. В качестве "печки", от которой можно начинать танцевать, я бы предложил стандарты AIIM

> оценивает вашу работу по этому показателю Вот именно это и называется качество. Начальник оценивает качество работы исполнителя в соответствии с данным заданием по установленным показателям качества. Кроме как через качество работу (задание) просто невозможно оценивать (измерять). Самые привычные (на заводе) измерители результативности (двести гаек), производительности (101% по сравнению с предыдущим отчётным периодом), экономичности (на 10% дешевле, чем ...) и т.п. Это всё показатели (индикаторы) качества. Ключевые индикаторы деятельности (Key Performance Indicatior) это не более чем подход качества, вложенный в процессный подход. Измерение (оценка) процессов.

Качество -- это когда мы пытаемся работать с разбросом этих показателей (например, по Deming). А когда даны эти показатели сами по себе, концепцию качества привлекать незачем. Хотя "формально" -- да, продукт, соответствующий показателям, должен бы удовлетворять требованиям потребителей. Мы тут следуем общей традиции, не допуская шовинизма (рассмотрения только с точки зрения какого-то одного подхода) даже для таких подходов, как процессный, проектный, качества, системный и т.д. В инициативах MIMOSA говорят не про качество, а про то, что есть описания исторические, и еще в них учитываются KPI. Ежели придут спецы по качеству, пусть построят view, предложив свой viewpoint (для этого отправим их к приложению D ISO 15288, где явно говорится о том, что любителей качества нужно отправлять именно по этому пути, наряду с любителями безопасности, ремонтопригодности и прочим свойствам системы, обеспечиваемым всей совокупностью процессов). Разборка с качеством обязательно будет, но потом: когда будем выяснять, чем "качество" из приложения D отличается в ISO 15288 от "качества" в процессе управления качеством.

Мы уже неоднократно пытались подвести понятие "учет" хоть под какие-то международные стандарты. Но пока у нас не получалось, ибо мы все время пытаемся изобразить учет датацентрический, а все стандарты тут про документоцентрику. Про учет (record keeping) много говорит ISO 15289, и мы в ближайшее же время им займемся поподробнее -- но он опять-таки документоцентричен насквозь. Content management (в том числе в варианте ECM -- не enterprise content management, a engineering content management) обычно как раз документоцентричен. Данные контентом не назовут :) Про AIIM спасибо, мы про них знаем. Увы, понятие "учет" одно из самых трудных для объяснения. Мы еще неоднократно с этим будем сталкиваться. Думаю, нам немного будет полегче, когда FIATECH выдаст в следующем году стандарты hand-over для датацентрического подхода.

Согласен, про корпоративный стандарт нужно поправить. "Эталонная модель" -- не эталонная (для сравнения), а "стандарт" (для сравнения), не "модель", а "описание" (то есть "описание для сравнения" = стандарт). "Список работ" не хуже, чем "список заданий". Но понятие работы более общее, чем понятие задания. Задание -- это порученная работа, в том числе и порученная себе. А задание -- это обычно порученное кем-то. Набор выделенных для описания процессов взят из списка 25 обязательных процессов системной инженерии согласно версии ISO 15926. Управление инфраструктурой и управление проектами в этом списке в одной процессной подгруппе. Кстати, у ЖЦ нет иерархии (ибо ЖЦ -- это эволюция системы, последовательность смены ее состояний, в отличие от процессов ЖЦ, которые эту смену состояний ЖЦ обеспечивают). У нас есть отдельные Требования к Концепции управления ЖЦ, там все ваши предложения учтены (кроме "знаков соответствия"). При этом Концепция инвариантна к нотации записи процессов, и даже не факт, что нотация будет одна. Мы предполагаем, что у наших клиентов есть стандарты системной инженерии, и наши тексты нужны для того, чтобы получить возможность говорить по-русски, и для того, чтобы задать некоторую форму работы по созданию описания жизненного цикла (life cycle model). Мы не считаем, что наши тексты самодостаточны так, что могут читаться вместо стандартов, а не вместе с ними.