
Когда слышишь ?внешняя система управления качеством?, первое, что приходит в голову большинству — это папка с сертификатами, пара обязательных аудитов в год и куча бумаг для тендеров. И в этом кроется главная ошибка. На деле, это не статичный ?комплект документов?, а живой, часто неудобный и очень затратный по времени процесс интеграции. Если относиться к этому как к формальности, можно потратить кучу денег и получить ноль практической пользы. У нас в ООО Хэнань Цзюйхэ Текнолоджи через это прошли, причём не с первого раза.
Начиналось всё стандартно. Для крупного проекта с одним нашим давним партнёром в нефтегазе потребовалось подтвердить соответствие их внешней системе управления качеством. Мы, как ведущий поставщик услуг цифровой трансформации, решили подойти ?по-умному?: взяли готовые политики качества у знакомых, адаптировали под наш профиль, провели внутреннее обучение по шаблонам. Казалось, что цифровизация — наш конёк, и с документами справимся играючи.
Аудитор из партнёрской организации приехал и за час задал три вопроса, на которые у нас не было внятных ответов. Не про стандарты ISO, а про конкретику: ?Как ваша система управления изменениями в ПО, которую вы внедряете для клиента, стыкуется с нашей системой отчётности по инцидентам? Покажите не схему, а реальный журнал за последний квартал?. Или: ?Вы декларируете цикл PDCA для улучшения услуг. Продемонстрируйте на примере одного завершённого проекта, как данные о сбое на этапе тестирования (которые вы собираете) привели к изменению в ваших внутренних регламентах?. У нас были красивые схемы на сайте hnjhkjjt.ru, но не было связки между тем, что мы делаем на самом деле, и тем, что требовала их система.
Это был провал. Но именно он стал точкой роста. Мы поняли, что внешняя система управления качеством — это не про наши внутренние бумаги. Это про создание прозрачных и предсказуемых мостов между нашими рабочими процессами и процессами заказчика. Особенно в цифровой трансформации, где продукт часто нематериален и постоянно меняется.
Следующий шанс появился с проектом по цифровой модернизации складской логистики для производителя автокомпонентов. Их система качества была жёстко привязана к стандартам автомобильной промышленности, с жёстким контролем сроков и traceability (прослеживаемостью) каждой операции.
В этот раз мы начали не с документов, а с диалога. Сели с их QA-менеджером и буквально построили карту соприкосновения: где этапы нашего цикла разработки (сбор требований, Agile-спринты, тестирование, выпуск обновления) касаются их этапов (планирование поставок, приёмка, инвентаризация). Оказалось, что ключевых точек контакта всего пять, но каждая — потенциальный источник риска.
Например, они требовали, чтобы любое обновление ПО, влияющее на формирование отчётности, сопровождалось уведомлением за 72 часа и протоколом приёмочных испытаний, подписанным ответственным лицом. Наш же процесс релиза был более гибким, с еженедельными обновлениями. Пришлось не просто ?задокументировать? наш процесс, а фактически создать для этого клиента параллельный ветки релизов с дополнительными контрольными точками. Это замедлило скорость поставки конкретно для него на 15%, но зато полностью удовлетворило требованиям их внешней системы управления качеством. Клиент увидел не формальность, а понимание его бизнес-реальности.
Казалось бы, наша компания — адепт цифровизации. Внедряем же системы для других. Логично было использовать свои же наработки, например, платформы для сквозного отслеживания задач и автоматизации отчётности, чтобы закрывать требования внешних систем. Но и здесь не всё гладко.
Мы попробовали использовать один из наших внутренних инструментов для автоматического формирования отчётов для аудита по требованиям стандарта ГОСТ Р ИСО 9001. Настроили дашборды, связали их с Jira и Git. Получилось красиво, но... Аудитор, пришедший от нового заказчика из сферы госзаказа, попросил предоставить те же данные, но в форме подписанного бумажного журнала с регистрационными номерами. Их внутренний регламент не признавал скриншоты веб-интерфейса в качестве первичного документа.
Этот случай научил нас, что цифровизация процесса в ответ на внешнюю систему управления качеством должна быть двусторонней. Иногда приходится параллельно вести и ?цифру?, и ?бумагу?, потому что система заказчика меняется медленнее, чем технологии. Или, как вариант, заранее включать в договор пункт о признании электронных артефактов. Но это уже вопрос переговоров, а не просто техники.
Можно прописать идеальные процедуры, купить дорогой софт для управления качеством, но если инженер или менеджер проекта не понимает, зачем ему тратить два часа в неделю на заполнение форм для ?какого-то внешнего аудита?, вся система рухнет. У нас был период, когда отдел разработки тихо саботировал новые требования по документированию каждого code review для проекта, работавшего по стандартам медицинского оборудования.
Они справедливо возмущались: ?Мы и так всё делаем, зачем эта бюрократия??. Проблему решили не приказом, а разъяснением. Устроили сессию, куда пригласили специалиста по регуляторике из смежной области. Он на живых примерах показал, как отсутствие записи о принятом решении по уязвимости в коде на этапе review привело к многомиллионным штрафам и отзыву продукта для другой компании. После этого заполнение формы перестало быть ?бумажкой для аудитора?, а стало осознанным актом снижения юридических и репутационных рисков для проекта и, в итоге, для самого разработчика.
Построение культуры, где требования внешней системы управления качеством воспринимаются как часть профессиональной ответственности, а не как досадная помеха, — это самая долгая и сложная часть работы.
Внедрение и поддержание работы в рамках строгой внешней системы — это всегда затраты. Время сотрудников, возможно, замедление процессов, стоимость программного обеспечения, услуги консультантов. В ООО Хэнань Цзюйхэ Текнолоджи мы долго искали аргументы для внутреннего обоснования этих затрат, помимо очевидного ?без этого не возьмут в проект?.
Со временем пришло понимание, что грамотно интегрированная внешняя система управления качеством — это мощный инструмент для внутренней оптимизации. Те самые журналы инцидентов и анализ первопричин (root cause analysis), которые мы вели для заказчика из энергетики, открыли нам глаза на систематическую ошибку в нашем процессе передачи проекта от presale-отдела к команде внедрения. Мы её исправили, и количество рекламаций на старте проектов упало почти на треть.
Другой пример — требования к компетенциям персонала. Чтобы соответствовать уровню квалификации, требуемому нашими основными промышленными партнёрами, нам пришлось выстроить чёткую систему внутреннего обучения и аттестации инженеров. В итоге это повысило общий уровень команды и позволило брать более сложные и дорогие проекты. Получается, что инвестиции в соответствие внешним требованиям трансформировались в инвестиции в собственный человеческий капитал и операционную эффективность.
Так что же такое внешняя система управления качеством в итоге? Для меня сейчас — это не коробка с документами, а внешний ритм, под который нам приходится настраивать часть своих процессов. Этот ритм разный у каждого серьёзного заказчика. Где-то это жёсткий бит стандартов аэрокосмической отрасли, где-то — более гибкий, но не менее требовательный пульс сферы fintech.
Самое важное — перестать бороться с этим ритмом или имитировать его. Нужно встроить его в свою мелодию, иногда меняя её аранжировку. Это болезненно, требует ресурсов и постоянного внимания. Но именно эта способность — гибко и осмысленно интегрироваться в чужие экосистемы качества — становится сегодня ключевой компетенцией для поставщика вроде нас. Это уже не вопрос соответствия, а вопрос выживания и роста на сложном рынке. И наш сайт hnjhkjjt.ru — это уже не просто визитка, а отражение той самой зрелости процессов, которую мы с трудом, но отстраивали под давлением этих самых внешних систем.