Обсуждение

Можно пользоваться инклюдами. Насколько я помню, текст ANSI-стандарта на язык Ада состоял из одной страницы, где утверждалось, что "настоящим руководством" является текст ISO-стандарта на язык Ада. А может быть, наоборот, не уверен.

... Начнём с горизонтального полёта ...

Документ есть бумага. Нормы устанавливаются актами.

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

"софт по работе с нормами " - по описанию, да и по задачам очень похож на софт по управлению требованиями (requirements management).

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

Нормы устанавливаются по-всякому, в том числе другими нормами ;) Я про то, что нужно не путать носитель (документ, даже если он называется "акт") и его содержание -- нормы. А содержание рассматривать "россыпью". В конкретной ситуации применимы не документы-акты целиком, а только отдельные их нормы. Поэтому невозможно слесарю вручить в руки огромный документ "нормы безопасности производства работ" и послать закрывать задвижку номер 24. Ему бы технологическую карту в руки дать, куда сведены все требования из всех документов, подходящие к данной ситуации. Если про уравнивание давление перед открытием основного вентиля для предотвращения гидравлического удара написано в "требованиях по безопасности", в технологической карте написано "повернуть вентиль на 270 градусов", а "надеть рукавички" почему-то затесалось в требованиях по качеству (ибо управители качества заметили, что без рукавичек на этой операции страдает качество выполнения последующих операций), то жди беды. Сейчас же эти три пачки документов либо произвольно дублируют друг друга, либо просто лежат отдельно, а знания передаются в изустной традиции без рефлексии, в чем же эти знания состоят и какой там на самом деле процесс. Кроме того, нужно еще сообразить, что нужно оставить в изустной традиции, а что обязательно положить на бумагу (т.е. что нужно самим, а не проверяющим ;)

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

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

Задачка разработать систему для зам.генерального директора крупного холдинга Вячеслава Алексеевича захватывает. Особенно в плане интерфейса. Очень большой монитор.Лучше настенный. Визуализация предельна. Лучше 3Д. Клавиатуру убираем совсем. Голосовой ввод и управление. Однако тестирование системы выглядит неразрешимой проблемой :-) Но если это большой холдинг там есть зам на корпоративное управление, и зам производство, и зам на управление качеством, и свой зам на техрегулирование и многое другое. Или это теперь не так?

После нашего ухода - уже не так :-)

У тебя там путаница: Система обеспечения качества относится к системе норм .... среди других можно указать: -- собственно технологические нормы -- нормы технического регулирования -- нормы качества Система обеспечения качества - это матанормы к технологическим нормам: КАК надо проектировать, учитывать и использовать технологические нормы. Основных систем две - технологические (они же качества, они же требования) и безопасности (они же ограничения). Метасистема "обеспечения качества" содержит требования к порвым нормам, метасистема "концепция технического регулирования" - ко вторым.

"Корпоративное управление"? Вообще-то это термин, и про него никогда у нас ничего не было! С управлением качеством - это одна из задач, изничтожить как отдельную подсистему.

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

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

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

Как не было?! А паттерн "идеального акционера" -- это же ровно оно!

У меня другая картина мира: есть технологический процесс с тремя типами норм: а) достижения результата "согласно ТЗ" as is "на авось как обычно", б) обеспечение достижимости и стабильности характеристик "согласно ТЗ" (качество, минимизация систематических и случайных сбоев, дефектов, отклонений характеристик), в) обеспечение специальных характеристик безопасности. Я утверждаю, что "система управления качеством" и "система технического регулирования" не являются отдельными системами, они именно что метанормы модификации технологического процесса (а) нормами типов (б) и (в). Текущий же вариант замешивает в рамки одной системы и метанормы к (б), и нормы к (б); и метанормы к (в) и сами нормы к (в), а нормы (а) остаются отдельными и бесхозными -- при всех декларациях о необходимости связи а, б и в. Связи при этом получаются, понятно, "по возможности", как нам недавно рассказывали. Точная цитата: "внизу делают, как могут, а не как требуется". Ибо требуется по-дурацки: не модифицировать основной процесс, а по факту иметь "отдельный процесс обеспечения" как (б), так и (в).

Существование системы (а) как отдельной не очевидно. Не бывает никакого as is при пустом множестве норм. В исходном состоянии, без норм (б), вообще нет деятельности, система стоит неподвижно. Если она хоть как-то двигается к цели - значит есть нормы категории (б). Нормы (б) вытекают из наличия цели, нормы (в) из регулирования, а нормы (а) - и есть результирующая.

В жизни не так. В жизни есть нормы (а) получения результата. Но чтобы исключить сбои, к ним добавляются нормы (б). Как раз деминговщина этим занимается (сделать замеры, найти причину отклонений, устранить причину отклонений). Так что всегда есть (а), и непрерывно идет апдейт (б). У тебя же (а) и (б) едины -- ведут к достижению цели. Да, ведут. Но различным путем. Можно сказать так, что (а) -- это базовый процесс as is. А (б) -- это маржинально вводимые нормы с целью получения устойчивого выхода. У тебя же все дано "статично". Я утверждаю, что есть нормы, обеспечивающие результат, а есть нормы, обеспечивающие качество результата. Конечно, это все про результат, легко спутать. Результирующая -- это (а)+(б)+(в). (а) -- это хотелка производителей, (б) -- внешние требования от рынка, (в) -- внешние требования от регулятора.

Не вижу - как провести границу между а и б. "Хотелка производителей" - это бессмысленное словосочетание. Они хотят выпускать продукт удовлетворящий хоть кого-то, то есть (б) сразу есть в картине. Про пополнение и маржинализм я согласен, но это тем более не позволяет выделить группу а и ткнуть в неё пальцем. Получается что а - это самая первая норма, а всё остальное появилось как дополнения из б. Типа: Цель - выпускаем автомобиль. Норма получения результата - должны быть колёса на раме. Но чтобы купили, добавим нормы качества - должна быть крыша от дождя. И теперь уже далее, вплоть до - должна быть сенсорная крышка пепельницы с индикацией заполнения на жидких кристаллах.