
Когда слышишь ?развитие системы управления качеством?, первое, что приходит в голову — это горы документов, сертификаты на стенах и ежегодные аудиты, от которых все устали. Но на самом деле, если отбросить формальность, речь идет о том, как сделать так, чтобы организация не просто ?соответствовала?, а действительно становилась лучше. В моей практике, особенно в сфере цифровых трансформаций, часто вижу, как компании вроде ООО Хэнань Цзюйхэ Текнолоджи изначально воспринимают СУК как необходимую бюрократию для тендеров, а не как инструмент для внутреннего развития. Это ключевая ошибка, с которой приходится сталкиваться постоянно.
Помню один из ранних проектов, где мы внедряли элементы управления качеством под конкретную задачу — повышение надежности цифровых сервисов для клиента. Изначальный запрос был прост: ?нам нужен сертификат?. Но когда начали копать, выяснилось, что их отдел разработки и служба поддержки живут в параллельных реальностях. Инциденты фиксировались где попало, доработки не отслеживались. Мы начали не с написания политики качества, а с серии рабочих сессий, где просто нарисовали на флипчарте, как идея от клиента проходит через всю компанию до результата. Это был переломный момент.
Тут важно не скатиться в создание еще одного ?отчета для руководства?. Суть в том, чтобы выявить реальные точки принятия решений. Например, в ООО Хэнань Цзюйхэ Текнолоджи при реализации проектов цифровой трансформации критичным оказался этап приемки требований от заказчика. Раньше это была переписка в почте, теперь — обязательная фиксация в системе с согласованием двух ключевых лиц: проектного менеджера и ведущего архитектора. Небольшое изменение в процессе, но оно сразу отсекло массу будущих претензий по ?а мы думали иначе?. Это и есть развитие системы — через микро-изменения в ежедневной работе.
Частая ловушка — пытаться автоматизировать хаос. Видел, как компании покупают дорогие ITSM-платформы, загружают в них свои старые, неработающие регламенты и удивляются, почему ничего не изменилось. Развитие СУК должно начинаться с ревизии того, что есть, пусть даже это будет набор Excel-таблиц и чат в Telegram. Если процесс в этих кустарных условиях дает сбой, то перенос его в ?продвинутую систему? только усугубит проблему. Нужно сначала навести порядок в логике, а потом уже выбирать инструмент.
Еще один больной вопрос — метрики. Все любят красивые графики, но часто они не отвечают на главный вопрос: ?Становится ли нашим клиентам лучше??. В сфере услуг, как у ООО Хэнань Цзюйхэ Текнолоджи, классический ?процент отклонений от сроков? может быть менее показателен, чем, скажем, ?количество итераций на этапе согласования технического задания?. Последняя метрика напрямую говорит о качестве входных данных и четкости коммуникации.
Мы в одном проекте долго бились над снижением количества багов в тестировании. Собирали статистику, строили отчеты. Пока не спросили у тестировщиков: ?А что главная причина??. Оказалось, что в 70% случаев корень — в неоднозначном описании функциональности в ТЗ. Сместили фокус с измерения багов на измерение качества спецификаций — и ситуация начала улучшаться. Это показало, что система управления качеством должна измерять не только выходы, но и входы ключевых процессов.
При этом важно не перегружать команды сбором данных. Идеальная метрика та, которую можно собрать автоматически, как побочный продукт работы. Например, время от создания заявки в службу поддержки до ее первого ответа легко берется из логов тикет-системы. А вот оценка удовлетворенности клиента после каждого проекта — это уже отдельное действие, и его нужно встраивать в процесс аккуратно, чтобы оно не превратилось в формальность.
Сегодня без цифровизации самого развития системы управления качества не обойтись. Но здесь кроется масса подводных камней. Работая с поставщиками вроде ООО Хэнань Цзюйхэ Текнолоджи, вижу, что успех внедрения любой платформы для управления процессами (Jira, Confluence, специализированные QMS) на 90% зависит от неметрических факторов: принятия командой, простоты интерфейса, скорости работы.
Был показательный случай: внедряли систему документооборота для процедур СУК. По функционалу — идеально, все ГОСТы учтены. Но люди ее ненавидели, потому что на загрузку одного документа уходило 3 минуты из-за медленного интерфейса и кучи обязательных полей. В итоге все вернулись к общему сетевому диску, а система числилась ?внедренной? только для аудита. Вывод: инструмент должен решать проблему пользователя, а не создавать новую. Иногда простая shared-папка с четкой структурой эффективнее навороченного ПО.
Другой аспект — интеграция. Система управления качеством не должна быть островком. Ее данные должны быть связаны с проектным управлением, CRM, системой поддержки. В идеале, когда инженер фиксирует проблему в коде, это автоматически создает запись для анализа причин в рамках СУК, а не отдельный отчет, который ему нужно заполнять вручную. Над этим мы как раз работали в последнем цикле улучшений для внутренних процессов на hnjhkjjt.ru, пытаясь связать GitLab, Jira Service Desk и базу знаний.
Можно прописать идеальные процедуры, купить лучшие инструменты, но если в компании культура ?виноват тот, кто ошибся?, а не ?как система позволила ошибиться?, все усилия насмарку. Развитие СУК — это в первую очередь работа с культурой. Нужно поощрять сообщения о проблемах, а не наказывать за них.
В нашей практике мы ввели ежемесячные короткие ?разборы полетов? без руководства, где команды обсуждали один небольшой сбой или костыль в процессе. Без поиска виноватых, только с целью понять: ?Что в нашем процессе позволило этому случиться и как это исправить??. Первые месяцы люди молчали. Потом, увидев, что никто не пострадал, а предложенные улучшения реально внедряются, начали делиться. Это медленный, но единственно верный путь.
Особенно это касается компаний, оказывающих услуги цифровой трансформации. Клиент ждет agility и прозрачности. Если внутри компании царит жесткая иерархия и страх, то ни о каком настоящем agile и качественном сервисе речи быть не может. Система управления качеством должна создавать безопасную среду для анализа ошибок и экспериментов. Без этого она — просто папка с документами на полке.
Цикл Деминга (PDCA) все знают, но применяют единицы. Часто ?действие? (Act) вырождается в написание отчета и забывание до следующего аудита. Настоящее развитие системы управления качества происходит, когда улучшения становятся частью ежедневных или еженедельных ритуалов команды.
Мы, например, в рамках проектов ООО Хэнань Цзюйхэ Текнолоджи добавили в еженедельные стендапы не только вопросы ?что сделал? что будешь делать??, но и ?что можно улучшить в нашей совместной работе на этой неделе??. Это занимает пять минут, но за месяц набирается несколько конкретных, небольших идей, которые тут же можно пробовать. Одна из таких идей — создать шаблон-чеклист для передачи проекта от продаж в производство — сэкономила кучу времени и нервов.
Главное — не гнаться за глобальными изменениями. Одно небольшое, но работающее улучшение в процессе важнее толстой стратегии развития на пять лет. Это как техника кайдзен: постоянные мелкие шаги. Система должна быть живой, а это значит, что ее документы и процессы должны регулярно, пусть и понемногу, меняться. Если за год в регламентах не появилось ни одной правки — это плохой знак. Значит, система либо не используется, либо не развивается.
В итоге, возвращаясь к началу, развитие СУК — это не про документы для аудитора. Это про ежедневные решения, про инструменты, которые не мешают, а помогают, про культуру, где не боятся говорить о проблемах, и про дисциплину маленьких, но постоянных улучшений. Именно такой подход позволяет таким компаниям, как ООО Хэнань Цзюйхэ Текнолоджи, не просто поставлять услуги цифровой трансформации, но и демонстрировать высокое качество на собственной практике, что, в конечном счете, и является самым убедительным аргументом для клиента.