
Вот скажу сразу: многие до сих пор воспринимают сертификацию системы управления качеством как формальность, необходимую только для тендеров или чтобы повесить красивый диплом в рамочке в приемной. Это, пожалуй, самый живучий миф. На деле, если подходить к вопросу правильно, это становится каркасом, на котором держится вся операционная деятельность. Особенно это видно в сфере, где работает наша компания — цифровая трансформация. Возьмем, к примеру, ООО Хэнань Цзюйхэ Текнолоджи. Когда мы только начинали внедрять процессы для получения сертификата соответствия, скажем, ISO 9001, часть команды искренне не понимала, зачем нам это, если мы ?просто? разрабатываем и внедряем IT-решения. Ответ пришел позже, и он был связан не с маркетингом, а с внутренними сбоями.
Изначально у нас была типичная для растущего стартапа ситуация: гениальные разработчики, горящие глаза, но полный разнобой в процессах. Клиенту в одном проекте обещали одно, в другом — совсем иное по срокам и этапам. Документация велась ?по памяти?, а сдача этапов порой напоминала аврал. Мы решили, что нужна система. И здесь сертификация СМК выступила не целью, а дисциплинирующим механизмом. Нам нужно было не просто получить сертификат, а выстроить такие процессы, которые бы снизили риски, повысили предсказуемость для клиента и, в конечном итоге, нашу собственную репутацию. На сайте ООО Хэнань Цзюйхэ Текнолоджи мы позиционируем себя как поставщика комплексных решений, а это значит, что клиент доверяет нам свой бизнес. Без управляемых процессов это доверие — пустой звук.
Первым делом мы начали с анализа существующих практик. Это было болезненно. Обнаружили, что у нас нет единого понимания, что такое ?качество? для цифрового продукта. Для программиста — это чистый код, для тестировщика — отсутствие багов, для менеджера — удовлетворенность клиента. Все правы, но система не работала на общий результат. Пришлось садиться и прописывать критерии качества на каждом этапе жизненного цикла проекта: от предпродажного анализа, который мы детально описываем в своих кейсах на hnjhkjjt.ru, до пост-релизной поддержки.
Тут и кроется первый практический вывод: подготовка к сертификации заставляет посмотреть на бизнес не как на набор гениальных идей, а как на цепочку взаимосвязанных действий. Каждое действие должно быть описано, измеримо и, что важно, улучшаемо. Мы, например, ввели обязательный чек-лист передачи проекта от отдела продаж к production-команде. Мелочь? Но именно такие мелочи раньше приводили к неделям проволочек.
Самое сложное — не написать политику в области качества (это как раз легко и часто шаблонно), а заставить эту политику работать в ежедневной рутине. Мы наступили на грабли, пытаясь внедрить все и сразу. Скачали кучу готовых процедур из интернета, раздали сотрудникам и ждали чуда. Не вышло. Люди просто игнорировали непонятные им документы, воспринимая это как бюрократическую нагрузку сверху.
Пришлось откатиться назад и начать с малого. Выбрали один, самый проблемный на тот момент, пилотный проект. Вместо того чтобы требовать заполнения объемных отчетов, начали с ежедневных 15-минутных стендапов, где фокус был на трех вопросах: что сделал вчера, что сделаешь сегодня, что мешает? Это уже был элемент процессного управления. Постепенно, на основе реальных проблем этого проекта, мы стали формировать свои, а не шаблонные, регламенты. Например, родилась процедура управления изменениями в требованиях клиента — бич любой IT-разработки.
Еще один камень — метрики. Все говорят, что нужно измерять. Но что? Первое время мы измеряли все подряд: количество написанных строк кода, время, проведенное на совещаниях. Бесполезный шум. Полезными оказались метрики, напрямую влияющие на результат для клиента: процент дефектов, обнаруженных на ранних стадиях (а не на продакшене), соблюдение оговоренных сроков по этапам, индекс удовлетворенности клиента после сдачи каждого модуля. Их мы теперь выносим во внутренние отчеты и анализируем на ежеквартальных management review.
Многие боятся аудита, как огня. Считают его инспекцией, которая ищет, к чему бы придраться. Мы тоже так думали. Но грамотный внешний аудитор (а мы выбирали по рекомендациям, смотрели на его опыт именно в IT-сегменте) — это не надзиратель, а врач-диагност. Его задача — не ?завалить? компанию, а проверить, работает ли система так, как она заявлена, и помогает ли она достигать целей.
Помню, на одном из первых аудитов нас спросили: ?Вот у вас в политике заявлено стремление к постоянному улучшению. Покажите, как вы выявляете возможности для улучшений и что сделали за последний квартал??. Мы начали лихорадочно показывать графики и отчеты. Аудитор посмотрел и задал простой вопрос: ?А как эти улучшения инициируются? По указанию руководства или есть механизм, скажем, от рядовых сотрудников??. Тогда мы осознали пробел: улучшения были реактивными, после проблем, а не проактивными. После этого внедрили простую систему предложений от сотрудников с обязательным рассмотрением раз в месяц.
Этот опыт научил нас, что внутренние аудиты — это не репетиция перед внешним, а самый ценный инструмент самообследования. Назначать внутренним аудитором нужно не того, кто ?проверит бумажки?, а того, кто понимает суть процессов и не боится задавать неудобные вопросы. Иногда лучшие находки делал наш же ведущий разработчик, который аудировал процесс тестирования.
Для компании, которая сама занимается цифровой трансформацией, было бы странно не оцифровать собственную систему управления качеством. Но и здесь есть нюансы. Мы не стали покупать тяжелые корпоративные решения типа SAP. На старте это убило бы всю гибкость. Использовали связку из Trello (для управления проектами и задачами), Confluence (для хранения документации и регламентов) и простых Google-форм для сбора метрик и обратной связи. Главное — все эти инструменты были связаны между собой простыми правилами.
Например, карточка проекта в Trello на этапе ?Сдача? автоматически создает задачу для отдела контроля качества и отправляет клиенту форму для обратной связи. После заполнения формы данные падают в общую таблицу для анализа. Таким образом, мы соблюдаем принцип процессного подхода и имеем цифровое доказательство этого. Для наших клиентов, которые приходят на сайт ООО Хэнань Цзюйхэ Текнолоджи, это тоже важно — они видят, что мы не только говорим о цифровизации, но и живем в ней, управляя своими внутренними стандартами.
Однако цифровизация — не панацея. Самый совершенный инструмент будет бесполезен, если люди не понимают, зачем им это. Поэтому параллельно с внедрением любого софта мы проводили короткие воркшопы: ?Вот этот чек-лист в Trello — как он помогает лично тебе не забыть критичные шаги и избежать переделок??. Когда люди видят личную выгоду, адаптация идет в разы быстрее.
Сертификат на стенде — это просто бумага. А что в реальности? Во-первых, предсказуемость. Мы теперь с высокой долей вероятности можем оценить сроки и риски проекта. Это напрямую влияет на планирование и финансовую устойчивость. Во-вторых, язык общения с клиентом. Когда мы говорим о процессе, этапах, контрольных точках, клиент чувствует себя увереннее. Он понимает, что имеет дело не с группой талантливых одиночек, а с отлаженным механизмом. Это соответствует нашему позиционированию как ведущего поставщика услуг цифровой трансформации.
Были ли неудачи? Конечно. Некоторые процедуры оказались избыточными, и мы их упростили или вовсе отменили. Кто-то из старых сотрудников, не принявший новых правил, ушел. Это тоже часть естественного отбора культуры. Система не должна быть догмой. Если какой-то процесс не добавляет ценности, его нужно менять. Цикл PDCA (Plan-Do-Check-Act) как раз про это.
В итоге, сертификация системы управления качеством для нас — это не разовое мероприятие, а постоянная практика. Это живой организм, который должен расти и меняться вместе с компанией. И главный индикатор его успешности — не отчет аудитора, а стабильно растущее количество долгосрочных партнеров и проектов, которые мы реализуем, в том числе и для тех, кто нашел нас через hnjhkjjt.ru. Когда внутренние процессы отлажены, можно больше ресурсов бросать не на тушение пожаров, а на инновации и развитие — то, что действительно важно в digital-сфере.