ISO 9001 для IT-компаний и разработчиков ПО: как адаптировать стандарт
👁 68
ISO 9001 в IT и разработке ПО: ключевые процессы СМК для Agile/Scrum, документация, KPI, аудит и сертификация для IT-компаний и разработчиков программного обеспечения. Тел.: 89005746601.
ISO 9001 для IT-компаний и разработчиков ПО: как адаптировать стандарт
IT-компании и разработчики программного обеспечения нередко воспринимают ISO 9001 как стандарт для промышленных предприятий — тяжеловесный, бюрократический и плохо совместимый с принципами гибкой разработки. Это заблуждение дорого обходится: крупные заказчики (государственные структуры, банки, промышленные холдинги, международные корпорации) всё чаще включают наличие сертификата ISO 9001 в обязательные требования тендерной документации или в критерии квалификационного отбора поставщиков. ISO 9001:2015 является принципиально технологически нейтральным стандартом: он не предписывает конкретных методологий разработки, инструментов или процессов — он устанавливает требования к системе управления качеством в части определения процессов, постановки измеримых целей, управления рисками, мониторинга результатов и непрерывного улучшения. Это означает, что Agile, Scrum, Kanban, DevOps и любые другие методологии разработки полностью совместимы с ISO 9001 — при условии, что организация умеет связать свои гибкие практики с требованиями стандарта. Ключевые разделы ISO 9001, применяемые в IT с наибольшим акцентом: §8.1–8.6 (жизненный цикл разработки ПО как «операционные процессы»), §8.3 (проектирование и разработка), §8.4 (управление субподрядчиками — аутсорс-разработчики, облачные провайдеры), §9.1 (KPI — sprint velocity, defect density, uptime), §10 (управление инцидентами и улучшение). Настоящее руководство разбирает, как адаптировать ISO 9001 к реалиям IT-компании без создания «бумажного мусора» и с максимальной практической пользой.
💻
ISO 9001:2015
совместим с Agile, Scrum, DevOps; стандарт не требует конкретных методологий — только определённости процессов и измеримости результатов
🎯
§ 8.3
Проектирование и разработка — ключевой раздел для IT; SDLC, Sprint, Release — всё укладывается в §8.3 при правильной интерпретации
📊
KPI-набор
defect density, MTTR, sprint velocity, uptime SLA, customer satisfaction (NPS) — измеримые цели СМК для IT §9.1
⏱️
3–6 месяцев
типичный срок внедрения СМК ISO 9001 для IT-компании; при наличии зрелых Agile-процессов и DevOps-практик — быстрее
Ключевые процессы IT-компании в контексте ISO 9001
📋
Управление требованиями к ПО
§8.2: требования к продукции/услуге
§ 8.2
🏗️
Проектирование и разработка ПО
§8.3: design and development — SDLC
§ 8.3 — Ключевой
🧪
Тестирование и контроль качества ПО
§8.6: выпуск продукции/услуги
§ 8.6
🤝
Управление аутсорс-разработчиками
§8.4: внешние провайдеры
§ 8.4
🚀
CI/CD и управление релизами
§8.5: предоставление услуг; Change Management
§ 8.5
🛡️
Управление инцидентами и багами
§10.2: несоответствия и КД
§ 10.2
😊
Управление клиентами и SLA
§8.2 + §9.1.2: удовлетворённость
§ 9.1.2
⚠️
Управление рисками проектов
§6.1: действия по рискам
§ 6.1
Как Agile и Scrum соотносятся с ISO 9001
🔄 Agile / Scrum практики
Как они уже «содержат» элементы ISO 9001
User Stories и Acceptance Criteria = §8.2 (определение требований к продукту); AC — это и есть критерии приёмки по ISO 9001
Definition of Done (DoD) = §8.6 (критерии выпуска продукции); DoD фиксирует, что считается завершённым
Sprint Backlog и Burndown = §8.3.2 (планирование разработки); прозрачность прогресса
Retrospective = §10.3 (непрерывное улучшение); регулярный анализ и improvement actions
Bug Tracker (Jira/GitLab) = §10.2 (несоответствия и корректирующие действия); главное — систематическая регистрация и анализ
Code Review = §8.5.1 (управление производством); верификация результатов разработки
📐 Что ISO 9001 добавляет к Agile
Элементы, которых часто не хватает в Agile-командах
Контекст организации (§4.1–4.2) — формальное понимание внешних и внутренних факторов; реестр заинтересованных сторон с их ожиданиями
Системный реестр рисков (§6.1) — не только project-level риски в Scrum, но и организационные, технические и клиентские риски с мерами
Управление внешними провайдерами (§8.4) — аутсорс-разработчики, облачные провайдеры AWS/Azure, API-сервисы: формальные критерии квалификации и мониторинга
Анализ удовлетворённости клиентов (§9.1.2) — регулярная, структурированная обратная связь (NPS, CSAT), а не только Sprint Review
Анализ со стороны руководства (§9.3) — ежегодный/полугодовой обзор СМК: KPI, аудиты, риски, цели — принятие решений об улучшениях
§ 8.3 — SDLCРаздел 8.3 «Проектирование и разработка» является центральным для IT-компаний. Он охватывает весь жизненный цикл разработки: §8.3.1 — общие положения о планировании; §8.3.2 — планирование (Sprint Planning в Scrum); §8.3.3 — входные данные (Requirements); §8.3.4 — управление процессом (Code Review, CI/CD); §8.3.5 — выходные данные (Build, Release); §8.3.6 — изменения (Change Management). Каждый Sprint / Release / Milestone является «design and development project» по §8.3
§ 8.4 — АутсорсУправление внешними провайдерами (§8.4) критично для IT: аутсорс-разработчики и freelancers; облачные инфраструктурные провайдеры (AWS, Azure, GCP); open-source компоненты и SaaS-зависимости; CDN, DNS, сторонние API; PaaS-платформы. СМК требует: реестр критических внешних зависимостей; критерии квалификации и мониторинга; SLA с провайдерами; процедуры при недоступности критических сервисов
§ 7.1.5 — РесурсыРаздел «Ресурсы для мониторинга и измерений» (§7.1.5) в IT: инструменты автоматизированного тестирования (Selenium, JUnit, Postman) должны быть калиброваны/верифицированы; средства мониторинга инфраструктуры (Prometheus, Datadog) — проверены на корректность; инструменты статического анализа кода (SonarQube) — настроены согласно политикам качества. «Пригодность к использованию» — ключевая фраза §7.1.5 для IT
§ 10.2 — ИнцидентыУправление несоответствиями (§10.2) в IT = система управления инцидентами и дефектами. Требования ISO 9001: каждый инцидент/баг регистрируется; выполняется анализ первопричин (Root Cause Analysis, RCA); определяются корректирующие действия; проверяется их результативность. Bug Tracker (Jira, GitLab Issues, Azure DevOps) при правильной настройке полностью покрывает §10.2. Ключевое требование — систематичность регистрации и анализа, а не разовые решения
KPI и цели в области качества для IT-компании
🏗️ KPI разработки
Defect Density (на 1000 LOC)≤5
Sprint Velocity (стабильность)±15%
Покрытие тестами (unit)≥70%
Bugs escaped to production/спринт≤2
Code Review Coverage100%
CI/CD Success Rate≥95%
🚀 KPI продакшн / SLA
Uptime (доступность системы)≥99,5%
MTTR (Mean Time to Restore)≤4 ч
MTBF (Mean Time Between Failures)≥30 дн.
P1 Incidents/месяц≤1
SLA соблюдение (support)≥95%
Change Failure Rate≤5%
😊 KPI клиентского опыта
NPS (Net Promoter Score)≥45
CSAT (удовлетворённость)≥4,3/5
Количество требований «возврат» (rework)≤10%
On-Time Delivery проектов≥85%
Retention Rate клиентов≥80%
Время закрытия тикета поддержки≤8 ч (P2)
Документация СМК для IT-компании
📋 Обязательная документация ISO 9001 (IT)
Политика в области качества (§5.2) — декларация о качестве разрабатываемых продуктов и предоставляемых услуг
Цели в области качества (§6.2) — KPI с целевыми значениями: defect density, uptime, NPS, on-time delivery
Область применения СМК (§4.3) — описание продуктов и услуг, типов проектов, методологий разработки
Карта процессов (§4.4) — основные (разработка, тестирование, поддержка) и поддерживающие процессы
Процедура CI/CD и управления релизами — стадии pipeline, критерии перехода, Rollback-процедура
Регламент управления инцидентами — классификация P1–P4, SLA, RCA-процедура, эскалация
Политика ветвления и контроля версий (Git branching strategy) — Git Flow или Trunk-Based Development
Регламент управления зависимостями — внешние библиотеки, OSS-лицензии, уязвимости (SBOM)
Процедура onboarding разработчиков — стандарты кода, инструменты, права доступа, обучение
Регламент оценки и аудита аутсорс-разработчиков — критерии квалификации, NDA, код-ревью, SLA
Процедура анализа удовлетворённости клиентов — анкеты NPS/CSAT, частота, анализ, action plan
Пошаговое внедрение ISO 9001 в IT-компании
1
GAP-анализ существующих практик vs ISO 9001
Инвентаризация существующей документации (Wiki, Confluence, Notion); оценка зрелости процессов разработки (Scrum, CI/CD, Code Review); выявление «белых пятен» в части §8.4 (аутсорс), §6.1 (риски), §9.1 (KPI), §9.3 (анализ руководства); определение трудоёмкости доработки. Рекомендуется: провести с командой QA и CTO
1–2 нед.
2
Определение контекста и области СМК
§4.1–4.3: SWOT IT-компании (конкуренты, технический долг, рынок найма); реестр заинтересованных сторон (клиенты, инвесторы, регуляторы в части InfoSec, сотрудники); чёткая область применения СМК — какие продукты/услуги входят: заказная разработка, SaaS, аутсорс-разработка, техподдержка
1 нед.
3
Картирование и описание SDLC-процессов в формате ISO 9001
Разработать карту процессов с явным маппингом на разделы ISO 9001; описать SDLC через призму §8.3 (входные данные — требования, проектирование — архитектура, разработка, верификация — тестирование, релиз); формализовать Definition of Done; определить KPI каждого процесса; назначить владельцев процессов
2–3 нед.
4
Разработка «пробельной» документации и интеграция с инструментами
Разработать только недостающую документацию (не переписывать то, что уже работает); связать СМК с реальными инструментами: Jira/GitLab Issues → §10.2, Confluence Wiki → §7.5, Slack/Teams → §7.4, Grafana/Datadog → §9.1; обучение команды изменениям; апробация на 1–2 реальных проектах
3–6 нед.
5
Внутренний аудит и анализ со стороны руководства
Проведение внутреннего аудита всех разделов ISO 9001; акцент на §8.3 (SDLC), §8.4 (аутсорс), §10.2 (Bug Tracker). Первый Анализ со стороны руководства (§9.3): CTO/CEO + QA Lead — обзор KPI первых спринтов/месяцев СМК, рисков, несоответствий; протокол с решениями об улучшениях
2–3 нед.
6
Сертификационный аудит: Stage 1 + Stage 2
Stage 1 (документарный): орган по сертификации проверяет готовность документации СМК; Stage 2 (аудит на месте): интервью с разработчиками, CTO, QA, PM — реальная проверка работы СМК; демонстрация Jira, GitLab, Dashboard KPI; при успехе — сертификат ISO 9001 на 3 года с ежегодными надзорными аудитами
2–3 дня
Временная шкала проекта сертификации ISO 9001 для IT
Нед. 1–2
GAP-анализ + контекст + область СМК
Нед. 2–5
Карта процессов + KPI + маппинг Agile→ISO
Нед. 5–11
Документация + интеграция с Jira/Confluence
Нед. 11–14
Внутренний аудит + анализ руководства
Нед. 14–20
Сертификационный аудит Stage 1+2 → Сертификат ✓
* Стартап / небольшая команда (до 20 чел.) с зрелыми Agile-практиками: 3–4 месяца. IT-компания среднего размера (20–100 чел.): 4–6 месяцев. Крупная IT-компания (100+ чел., несколько продуктов): 6–10 месяцев
Стоимость внедрения и сертификации ISO 9001 для IT
Консалтинг по внедрению СМК
₽150 000–500 000
Разработка документации
₽50 000–200 000
Обучение внутренних аудиторов
₽20 000–50 000
Сертификационный аудит (10–30 чел.)
₽80 000–200 000
Сертификационный аудит (30–100 чел.)
₽200 000–450 000
Ежегодный надзорный аудит
₽50 000–130 000/год
Итого «под ключ» (до 30 чел.)
₽250 000–550 000
Итого «под ключ» (30–100 чел.)
₽450 000–1 000 000
⚠ Пять типичных ошибок при внедрении ISO 9001 в IT-компании
Первая — «задокументировали, как хотелось бы, а не как работаем»: описание процессов в Confluence рисует идеальную картину разработки без связи с реальными практиками. При Stage 2 аудите аудитор просит показать последние 5 Bug Reports — и в Jira оказывается хаос без RCA и закрытых корректирующих действий. Вторая — измеримость только на бумаге: в политике качества написано «мы обеспечиваем SLA 99,9% и NPS ≥50», но в компании нет системы мониторинга uptime и никто не считал NPS за последний год. §9.1 требует реальных измерений. Третья — игнорирование §8.4 для облачных провайдеров: IT-компании часто забывают, что AWS/Azure/GCP с точки зрения ISO 9001 — внешние провайдеры, критически влияющие на качество услуги. Необходимы SLA с ними (или ссылка на публичные SLA), Disaster Recovery Plan и оценка критичности зависимостей. Четвёртая — Definition of Done существует, но не применяется: DoD написан, но в реальных спринтах пропускается при дедлайне. Аудитор попросит показать записи о прохождении DoD для последних 3 спринтов — и обнаружит нарушение §8.6. Пятая — сертификат ради сертификата без вовлечённости команды: если только QA Lead и консультант понимают ISO 9001, а разработчики воспринимают СМК как «бюрократию от менеджмента», аудитор это выявит через интервью в первые 20 минут. Сертификат получить не удастся.
Реестр Гарант — внедрение и сертификация ISO 9001 для IT-компаний и разработчиков ПО
Помогаем IT-компаниям и разработчикам ПО внедрить ISO 9001:2015 без лишней бюрократии: GAP-анализ существующих Agile/DevOps-практик на соответствие ISO 9001, маппинг Scrum-событий, Definition of Done, Bug Tracker и CI/CD на разделы стандарта, разработка только необходимой документации с интеграцией в Jira/Confluence/GitLab, формирование измеримых KPI (defect density, uptime, MTTR, NPS), регламент управления аутсорс-разработчиками и облачными провайдерами (§8.4), обучение внутренних аудиторов с акцентом на IT-специфику, сопровождение сертификационного аудита Stage 1 и Stage 2.
