
Когда слышишь ?положение о системе управления качеством?, первая мысль — толстая папка с кучей бумаг, которую инспектор листает раз в три года. И это главная ошибка. В ООО Хэнань Цзюйхэ Текнолоджи мы через это прошли: изначально создали красивый, идеально структурированный документ, полный шаблонных фраз из ГОСТ Р ИСО 9001. А потом оказалось, что наши же инженеры по внедрению ERP-систем его не читают. Зачем? Процессы-то в реальности шли иначе. Вот с этого момента начинается настоящее понимание. Положение о системе управления качеством — это не формальность для сертификата, а, скорее, описание правил игры, которые все знают и используют. Если его нет в ежедневной работе — значит, оно мертво.
Итак, мы сели переделывать. Не с нуля, а вытаскивая из отделов их реальные инструкции, чек-листы, даже переписку в чатах по решению инцидентов. Например, в отделе разработки был негласный алгоритм приемки модуля: сначала код-ревью у тимлида, потом прогон на тестовом стенде, который собирал стажер. В официальном положении о СМК этого не было, там был общий пункт ?проведение испытаний?. Мы его расшифровали, прописали ответственных, входные и выходные данные. Главное — согласовали с теми самыми тимлидами. Без их ?да, так и работаем? любой пункт — пустой звук.
Тут же всплыла классическая проблема: разрыв между ?управлением? и ?качеством?. Руководство хотело видеть в положении KPI и сроки. Специалисты — четкие технические критерии. Пришлось искать баланс. В раздел по проектам цифровой трансформации мы вписали не только этапы (анализ, проектирование, внедрение), но и контрольные точки с измеримыми результатами. Скажем, не ?провести обучение клиента?, а ?достигнуть коэффициента освоения функционала не менее 85% по итогам тестирования?. Это уже конкретика, которую можно проверить.
Интересный казус произошел с закупками. По старым правилам, отдел закупал софт по критерию ?соответствие техническому заданию?. Но когда начались сбои в интеграции, выяснилось, что ТЗ было расплывчатым. В новую редакцию положения мы добавили обязательный этап — валидацию требований к стороннему ПО силами ведущего разработчика. Не просто ?проверить?, а подписать личную ответственность. Количество инцидентов упало, правда, и сроки закупок немного выросли. Пришлось объяснять финансистам, что это — цена качества, а не бюрократия.
Самое сложное — не написать, а внедрить. Мы решили не заваливать сотрудников ООО Хэнань Цзюйхэ Текнолоджи многостраничным фолиантом. Вместо этого сделали серию коротких, минут по 15, разборов на летучках. Брали один процесс из положения — например, управление инцидентами в службе поддержки — и показывали на реальном кейсе: вот был сбой у клиента с сайтом https://www.hnjhkjjt.ru, вот как по регламенту должна была сработать эскалация, вот где мы задержались. Живые примеры цепляют лучше любой теории.
Еще один лайфхак — визуализация. Схемы процессов из Visio повесили не только на стенды, но и в рабочие чаты в Telegram. Важно было показать не идеальную прямую линию, а разветвления: ?если данные от клиента неполные, перейти к шагу 2.3 и запросить лог-файлы?. Это убрало множество уточняющих вопросов. Кстати, сам сайт компании стал частью системы: в разделе для клиентов мы вынесли чек-листы для подготовки данных перед началом проекта. Это тоже элемент управления качеством на входе, просто вынесенный вовне.
Были и провалы. Пытались ввести еженедельный аудит по всем пунктам положения. Через месяц команды взбунтовались — слишком много времени уходило на отчеты, а не на работу. Откатились, оставили только ключевые контрольные точки по итогам этапов проекта. Вывод: избыточный контроль убивает смысл. Система управления качеством должна помогать, а не мешать. Теперь мы смотрим не на процент заполненных форм, а на динамику повторяющихся ошибок. Если их стало меньше — система работает.
В сфере цифровой трансформации, которой занимается наша компания, процессы меняются стремительно. Вчерашнее положение о тестировании может устареть за полгода из-за появления нового инструмента мониторинга. Поэтому мы отказались от версии в PDF. Документ живет в корпоративной wiki-системе, где любой сотрудник может предложить правку через встроенную систему комментариев. Раз в квартал ответственный редактор (не начальник, а назначенный из ключевых инженеров) собирает эти предложения и актуализирует текст.
Это породило новую культуру. Специалисты стали чаще ссылаться на пункты положения в рабочих обсуждениях: ?коллега, по п. 4.2 нам нужно зафиксировать это решение в протоколе?. Не как на догму, а как на полезную памятку. Особенно это важно в проектах, где задействованы несколько отделов — разработки, аналитики и техподдержки. Единые правила игры снижают трение.
Еще один важный аспект — связь с бизнес-результатами. Мы начали выстраивать метрики, которые показывают, как соблюдение регламентов влияет на итоги. Например, время отклика на запрос клиента или количество успешно сданных проектов с первого предъявления. Оказалось, что в проектах, где все этапы строго следовали прописанному в положении процессу, доработок по итогам приемки было в среднем на 30% меньше. Это уже не абстрактное ?качество?, а конкретная экономия ресурсов. Такие цифры — лучший аргумент для скептиков.
Многие думают, что система управления качеством — внутренняя кухня. Но для клиента, особенно в B2B, это показатель надежности. Когда мы на старте проекта показываем не просто красивые презентации, а структурированный процесс управления рисками или приемки этапов, взятый из нашего положения, доверия становится больше. Клиент видит, что работа будет не хаотичной, а управляемой. Наш сайт https://www.hnjhkjjt.ru теперь содержит не просто описание услуг, а отсылки к методологии, что сразу задает профессиональный тон.
Более того, мы стали использовать наработки из СМК в качестве готовых решений для клиентов. Некоторые заказчики, особенно из среднего бизнеса, просили помочь навести порядок в их собственных процессах. Мы не продаем это как отдельную услугу, но делимся фрагментами своих регламентов — конечно, адаптируя под их специфику. Это укрепляет партнерские отношения и показывает экспертизу не на словах, а на деле.
В итоге, что у нас получилось? Положение перестало быть папкой в шкафу. Оно стало рабочим инструментом, который эволюционирует. Ключевой урок: не начинайте с ГОСТов и идеальных формулировок. Начните с боли — с того места, где процессы сейчас дают сбой. Опишите, как их надо исправить. Согласуйте с теми, кто будет это делать. И тогда ваш документ будет дышать. В ООО Хэнань Цзюйхэ Текнолоджи мы на этом пути, и он никогда не заканчивается. Качество — это не пункт в плане, а постоянный разговор о том, как сделать лучше.