Yuha
Мамонт
MsKos сказал(а):2) Насколько однозначно применима западная методология "Global 8D", она же - Team Oriented Problem Solving (TOPS)?
Специальным образом организованная процедура рассмотрения, анализа и принятия решения по эвентам безусловно должна быть. Однако проводить сложную, многоходовую и документируемую процедуру типа 8D в рамках FRACAS, нужно для опасных зарегистрированных отказов по причине КПН. Для авиационных происшествий и инцидентов по причине КПН (истинных, а не мнимых "КПН"!) такая или аналогичная, строго формализованная процедура необходима, причем также и строго документируемая, поскольку вопросы безопасности полетов подконтрольны гос.органам, и надо иметь обоснованную "подкладку" под всеми принимаемыми решениями. В таких случаях, тот же шаг D8 может выглядеть даже не совсем уместно...
Мне кажется методология 8D универсальна настолько, что применима к разруливанию любых проблем. Технических и нетехнических. Связанных с БП и не связанных с нею... 8D определяет принципы разруливания проблем, а не степень формализма в реализации самой процедуры, которая может быть различной для разных случаев. Например, если речь идет об авиационном происшествии - состав команды, исследующей причины инцидента и уровень принятия решений по результатам - один, а если Вы имеете проблему систематического нарушения процедуры получения материальных ценностей на складе - другой. В одном и в другом случае будет разный состав и полномочия участников, разный подход к обкладыванию события разного рода аргументацией и фактической доказательной базой. Но механизм разруливания проблемы - 8 последовательных шагов будет один и тот же...
MsKos сказал(а):3) Основной вал эвентов (например у нас за прошедший 2005 год только по ГА РФ - более 4 тысяч) должен подвергаться статистической обработке с целью выявления наиболее "нагруженных" направлений, систем и изделий, и дальнейшей работы по ним, а не рассмотрению каждого эвента с блоком или прибором. В большинстве случаев указанный вал эвентов дают ПКИ, особо выделяются системы 110, 023, 034 и 033. Стало быть в команде (team) FRACAS/8D должны быть обязательно представители вендоров ПКИ. При сегодняшнем уровне взаимоотношений Разработчиков ВС с вендорами ПКИ (их фактическом коллапсе) это весьма проблематично.
Если присутствие самого вендора в процедуре FRACAS проблематично, его роль должны выполнять "ответственные кураторы" на стороне разработчика ВС. При этом, разумеется, конечным выходом процедуры будет не исполненная и проверенная на эффективность корректирующая мера, а "рекомендация" или "претензия", выставленная вендору ПКИ (с копией в органы госрегулирования при отсутствии со стороны вендора доброй воли устранить безобразие)
MsKos сказал(а):4) Разработчик ВС в системе FRACAS способен на корректирующие действия в части изменения спроектированной им конструкции ВС. Причины эвентов, связанные с изготовлением и сборкой ВС остаются на совести Изготовителя ВС. Кроме этого имеются "тонкие" вопросы, завязанные на последующую стоимость принимаемых решений, доработок, поставок. Стало быть в команде FRACAS/8D должны быть представители Изготовителя ВС, что сейчас (впрочем как и всегда) также проблематично.
Как и в случае с вендорами ПКИ, у разработчика ВС должен быть ответственный "куратор" Изготовителя, которому и надлежит нести всю полноту ответственности при отсутствии возможности участия самого Изготовителя. Кстати, тут может действовать простой принцип - отвечаешь сам, пока не возложишь ответственность на того, кто на самом деле должен отвечать. Правда и выход процедуры будет несколько ослаблен - опять прийдется выдавать "рекомендации" или выставлять "претензии", а там - все будет на совести Изготовителя. Но даже и такой половинчатый результат со временем даст эффект. Когда накопится солидная база данных о невыполненных "рекомендациях" и проигнорированных "претензиях", можно будет уже идти на конфликт с ФАКТАМИ НАЛИЦО...
MsKos сказал(а):5) Получается, что внедрение методологии "Global 8D" напрямую зависит от взаимоотношений между Разработчиком ВС, Изготовителем ВС и Поставщиками ПКИ, а один Разработчик ВС проблему решить не сможет, как бы его не обличали полной ответственностью. Это все наши традиционные "национальные особенности". В сегодняшнем отечественном авиапроме это еще очень сложно, и здесь вопросы решают даже не простое обеспечение финансирования работ, а нетривиальные политические рычаги.
Ну, если проблему не удается на уровне горизонтальных связей между равноправными участниками "безобразия", ее следует эскалировать "наверх". Кто может выступать в качестве "верха" в данном случае? Наверное - вышестоящий корпоративный менеджмент (если Разработчик и Изготовитель объединены в корпорацию) или даже органы госрегулирования...
MsKos сказал(а):6) Еще один нюанс. Никто не позволит сломать имеющуюся внутри предприятия, исторически сложившуюся, систему работы по анализу эвентов и принятию по ним решений, ради дорогостоящего внедрения западных стандартов и методологий, возможны только процессы обоснованного совершенствования и реформирования того что есть. Новый промышленный стандарт или методологию по упомянутой проблеме, в полном объеме, можно внедрить только работая с "чистого листа", а это относится, как правило, к вновь создаваемым предприятиям, но не к предприятиям с многолетним стажем работы.
Ну, можно и не называть это "западным стандартом", а выдать его за свой, корпоративный... Тем более, коллегиальность, характерная для 8D, в общем-то нам свойственна...
MsKos сказал(а):7) В дополнение к этому существует еще проблема отсутствия у Разработчика ВС прямых источников финансирования для работ в рамках FRACAS/8D. В состав работ по ОКР эти затраты не включаются (заказчики ОКР не хотят за это расплачиваться), на сопровождение серийного производства Изготовителями ВС принимаются только работы по анализу надежности и вычислению Тс (поскольку этот показатель задан в ТУ), накладные расходы и так раздуты до безобразия и к тому же нет статьи на подобные работы, чтобы закрыться от налоговой инспекции (экономисты бессильны), на разработку и испытания измененной конструкции финансирование можно получить только от какого-либо заинтересованного в том конкретного заказчика, но в случае явного КПН желающих платить особо не находится. Стало быть остается финансирование из прибыли, включая и т.н. "роялти" от продажи ВС по контрактам, но прибылью распоряжаются собрание акционеров и совет директоров, которым по сути нет до этого дела (вся прибыль может пойти на дивиденды и привет!). Вследствие чего система FRACAS на сегодня может попросту отсутствовать, как таковая, в любом виде.
Да, это системный глюк работы наших КБ. Но с другой стороны - есть же у наших разработчиков Главный конструктор для каждого типа ВС - аналог буржуазного Директора программы? В конце концов он должен формировать бюджет своей Программы, в т.ч. предусматривать расходы и на такие работы. И потом, я не верю, что ушлые ребятки, занимающие должности Главных конструкторов не заинтересованы урвать себе кусочек бюджета. Им только нужно аккуратно подсказать обоснование...