
Когда слышишь ?проведение аудитов систем управления качеством?, многие представляют себе толстые папки с чек-листами и формальные беседы. Это, пожалуй, самый живучий миф. На деле, если аудит — это просто сверка с требованиями ISO 9001, то толку от него мало. Ценность — в том, чтобы увидеть, как система *живет* в компании, а не как она описана в документах. Вот, к примеру, работая с разными поставщиками, в том числе с такими, как ООО Хэнань Цзюйхэ Текнолоджи, я постоянно сталкиваюсь с одним: в сфере цифровой трансформации документация по СМК часто идеальна, а вот связь между процессами разработки, внедрения и обратной связи от клиента может быть разорвана. И это как раз та ?щель?, куда нужно смотреть в первую очередь.
Начинал я, как и многие, с формального подхода. Придешь, запросишь руководство по качеству, процедуры, записи. Всё красиво, всё соответствует. Но потом начинаешь разговаривать с инженером, который непосредственно настраивает решение для клиента. И выясняется, что ?процесс управления изменениями? из процедуры он в глаза не видел, а вносит правки в конфигурацию по договорённости в чате. Система на бумаге есть, а на практике — параллельная реальность. Это классика.
Особенно ярко это проявляется в ИТ-компаниях, которые быстро растут. Они получают сертификат, но культура процессов не успевает за ростом штата. Проведение аудитов в такой ситуации — это не поиск несоответствий, а скорее диагностика. Нужно показать руководству: вот здесь ваши люди придумали более быстрый способ, который работает, но он не встроен в систему. Риск в том, что этот способ зависит от конкретного человека. Задача — не зарубить его, а легализовать и контролировать.
Был у меня показательный случай на одном проекте внедрения ERP. Команда внедренцев работала в авральном режиме, все процедуры тестирования и приемки шли в обход регламентов — чтобы успеть к сроку. По документам — полный порядок, акты подписаны. А через полгода у клиента посыпались ошибки в отчётности, потому что не были задокументированы ключевые настройки. Аудит постфактум выявил, что корень проблемы — в срыве именно тех самых внутренних процессов управления конфигурацией. Урок: если при аудите видишь, что все работы идут ?по плану?, но команда выгоревшая и работает по ночам — это красный флаг. Значит, система управления качеством не работает как инструмент помощи, а существует как досадная формальность.
Вот возьмем сферу деятельности компании ООО Хэнань Цзюйхэ Текнолоджи — цифровая трансформация. Это не про производство деталей, где всё можно измерить и взвесить. Здесь продукт часто нематериален, а ключевые процессы — разработка, интеграция, поддержка. Аудит системы управления качеством в такой компании должен фокусироваться на совсем других точках. Например, как осуществляется передача знаний от команды внедрения к службе поддержки? Как фиксируются и анализируются инциденты от клиентов? Часто бывает, что техподдержка работает с симптомами, а причина ошибки кроется в изначально некорректно собранных требованиях, что является сбоем в процессе управления проектом.
На их сайте, hnjhkjjt.ru, видно, что компания позиционирует себя как ведущий поставщик услуг. Это сразу наводит на мысль об аудите цепочки создания ценности. Качество итогового решения для клиента зависит не только от кода, но и от того, как проведён предпроектный анализ, как согласовываются изменения в ходе работы, как проводится обучение пользователей. Если аудитор зациклен только на тестировании ПО, он упустит главное.
Одна из частых проблем, которую я наблюдаю — разрыв между ?продажами? и ?производством?. Отдел продач может пообещать клиенту кастомную доработку за три дня, не проконсультировавшись с разработчиками. В документации СМК может быть прописана процедура согласования, но на практике её игнорируют ради сохранения клиента. Аудитор должен уметь вытащить на свет именно такие кейсы, задав неудобные вопросы и продактам, и разработчикам по одному и тому же проекту. Разница в ответах будет самой ценной находкой.
Многие думают, что главный инструмент аудитора — чек-лист. Я давно от этого отошел. Чек-лист — это костыль, который мешает думать. Мои главные инструменты — это умение слушать и задавать вопросы ?почему??. Например, вижу запись о проведённом внутреннем аудите. Вместо того чтобы проверять, стоит ли галочка, спрашиваю: ?А какой самый значимый найденный вами недостаток был на прошлом аудите? Что было сделано для его устранения? Можно посмотреть объективные свидетельства??. Часто в ответ — тишина. Значит, внутренние аудиты проводятся для галочки, а это мёртвый процесс.
Ещё один момент — работа с рисками. В СМК по ISO 9001:2015 это основа. Но на практике раздел ?риски и возможности? в документации часто представляет собой формально списанные общие фразы. Настоящие же риски живут в головах руководителей проектов. Полезно во время аудита попросить привести пример одного реального проекта и обсудить: какие были ключевые риски по ходу работы? Как их выявляли? Как реагировали? Это даёт гораздо более честную картину, чем чтение формального реестра.
При проведении аудитов в области разработки и внедрения ПО я всегда обращаю внимание на систему контроля версий и ведение backlog. Хаос в коммитах или задачах, которые годами висят в ?To Do?, — это прямое свидетельство проблем в процессном управлении. Можно сколько угодно писать процедуры, но если в Jira или Битрикс24 бардак, то и вся система управления работает с перебоями.
Самая большая ошибка аудитора — встать в позицию надзирателя. Люди сразу закрываются, начинают давать формальные, безопасные ответы. Цель — не поймать на ошибке, а помочь увидеть точки роста. Я всегда начинаю с того, что говорю: ?Мы здесь не для того, чтобы искать виноватых, а чтобы понять, как система работает, и найти способы сделать вашу работу ещё эффективнее?. Это меняет атмосферу.
Бывает, наталкиваешься на скрытое сопротивление. Руководитель среднего звена может бояться, что аудит выявит проблемы в его отделе, и он получит нагоняй. Здесь важно отделить системную проблему от человеческого фактора. Если процедура неудобна и все её обходят — это проблема процедуры, а не людей. Свои наблюдения я часто формулирую так: ?Я заметил, что ваша команда для оперативного решения вопроса использует мессенджер, хотя процедура предписывает создавать заявку в системе. Как вы думаете, почему сложилась такая практиция? Что не так с системой??. Это провоцирует на конструктивный разговор.
Итоговая беседа по результатам аудита — это искусство. Нельзя просто зачитать список несоответствий. Нужно выстроить причинно-следственные связи, показать, как одно упущение в процессе сбора требований тянет за собой проблемы в поддержке. Когда аудируемые сами начинают в ходе дискуссии говорить: ?Ага, значит, из-за этого у нас потом клиент был недоволен...?, — это победа. Значит, аудит стал не контролем, а частью системы улучшений.
Так что же такое проведение аудитов систем управления качеством по-настоящему? Это умение видеть живые процессы за документами, слышать настоящие проблемы за формальными отчетами. Это не разовая акция, а часть управленческой культуры. Для компании, будь то производственное предприятие или поставщик цифровых решений вроде ООО Хэнань Цзюйхэ Текнолоджи, ценность аудита — в его прикладном, а не сертификационном результате.
Главный показатель успешного аудита для меня — это когда через какое-то время после отчета мне звонят или пишут не для формального отчета об устранении несоответствий, а чтобы посоветоваться: ?А вот у нас возникла такая ситуация, как бы вы посмотрели на это с точки зрения процесса??. Значит, люди начали думать в этой парадигме. Значит, система управления качеством перестала быть абстракцией и стала рабочим инструментом.
Никакой идеальной системы не существует. Она всегда в развитии. И хороший аудит — это не фотография недостатков, а диагноз с рекомендациями по лечению. Он должен оставлять после себя не список косяков для исправления, а понимание и желание эти процессы улучшить. Всё остальное — просто бюрократия, от которой все устали.