Система менеджмента качества: как разобраться в стандартах и запустить процесс их внедрения в компании

    Положительные моменты использования стандартов ISO и системы менеджмента качества доказаны опытом многих компаний, в том числе и в сфере информационных технологий. Об этом уже много написано, поэтому пропагандировать ISO и систему менеджмента качества я не берусь. Задача моей статьи — показать, что с помощью двух не очень сложных схем можно понять смысл процесса внедрения системы менеджмента качества и получить конкретные, четкие рекомендации, какие документы для этого требуются. Таких схем, которые приведены в статье, вы не найдете ни в одном руководстве. Именно поэтому я решил поделиться ими с читателями Хабра.


    Источник

    Схемы помогут сориентироваться в многочисленных регламентных документах. Первая – детально сравнивает стандарты ISO 9001-2015, ISO 9001-2001, стадии жизненного цикла программного обеспечения по разным ГОСТам, описывает этапы внедрения системы менеджмента качества и необходимые для этого документы. Вторая схема посвящена документированию бизнес-процессов при разработке автоматизированных систем. В конце статьи я привожу пошаговую инструкцию для тех, кто внедряет систему менеджмента качества. В статье даны ссылки на источники информации. Причем приведенный минимум достаточен для первичного ознакомления с темой.

    Стандартизация по ту сторону добра и зла


    В 2015 году вышел международный стандарт, регламентирующий управление качеством, – ISO 9001-2015, а в 2016 году на его основе выпустили отечественный стандарт ГОСТ Р ИСО 9001-2015 [1]. Сертификация по этим стандартам даёт много бонусов. Свидетельство соответствия ГОСТ Р ИСО 9001-2015 (ISO 9001:2015) подтверждает клиентам, партнерам, инвесторам, что бизнес управляет качеством. Сертификат ISO 9001 помогает выйти на международный рынок. Кроме того, наличие сертификата ISO обязательно для участия в некоторых государственных тендерах и конкурсах.

    Промышленность и бизнес в нашей стране всегда стремились к полному соответствию стандартам, что автоматически трактовалось как синоним качества. Вот пример ориентации на ГОСТ, а не на потребителя. На упаковке плавленого сыра мы увидим номер ГОСТа, что вроде бы подтверждает его высокое качество. Но рядом мельчайшим шрифтом написано о содержании в составе пальмового масла (это ГОСТу не противоречит). Однако производитель умалчивает, что пальмовое масло может быть и техническим (ведь оно раза в два дешевле), а как оно воздействует на здоровье потребителя, производителю безразлично.

    Много букв, не осилил


    Согласно системе стандартов ИСО главное — не слепое соблюдение стандартов, а ориентация на конкурентоспособное качество. Последнее включает не только контрактные отношения поставщика и заказчика, но и полное удовлетворение потребностей клиента (потребителя). Стремление угодить клиенту, непрерывное отслеживание качества и постоянное его «улучшение» создают культуру качества, значительно отличающуюся от той, в основе которой – система простого соблюдения стандартов.

    Для разработчиков программного обеспечения (ПО) и автоматизированных систем (АС) работа в рамках системы менеджмента качества (СМК) непонятна и затруднительна. Правила и требования СМК действительно громоздки. Они насчитывают полтора десятка международных стандартов серии ИСО 9000 и ИСО 10000. Количество отечественных стандартов с учетом отраслевых и сосчитать трудно – их точно не менее сотни. Плюс существуют еще и десятки руководств и учебных пособий [6, 7]. Даже просто прочитать эти тысячи страниц затруднительно, а осмыслить их и сформировать программу конкретных действий для внедрения системы менеджмента качества у себя на предприятии (или даже просто в рамках рабочей проектной группы) еще сложнее.


    Источник

    Чтобы получить сертификат о внедренной системе менеджмента качества для участия в тендерах и конкурсах, компания часто обращается в консалтинговую фирму, оплачивает заказ, а фирма оформляет необходимые документы, выдает сертификат. Компания предъявляет сертификат заказчику и продолжает работать так, как и работала ранее, ничего не меняя в своей деятельности. К системе качества это имеет очень отдаленное отношение.

    О жизненном цикле в деталях


    Организация, которая принимает стратегическое решение следовать требованиям ГОСТ Р ИСО 9001, должна учитывать следующие основные моменты и документально их задекларировать.

    • Все, что происходит в организации в процессе ее деятельности, должно следовать положениям ГОСТ Р ИСО 9001, о чем конкретно должно быть прописано в «Руководстве по качеству», в инструкциях и регламентах, описывающих процессы проектирования (производства). Так, внутренние документы должны отражать изменения размеров, структуры организации, изменения целей производства товаров и услуг, меняющиеся процессы производства.

    • Требования к системе менеджмента качества, установленные в ГОСТ Р ИСО 9001, являются дополнительными по отношению к требованиям на производимую продукцию. (Это очень важно, так как главным являются требования заказчика.)

    • Система менеджмента качества организации может использоваться внутренними и внешними сторонами. Например, органы по сертификации могут использовать систему, чтобы оценить, способна ли компания выполнить требования потребителей и регламентов.

    Основные положения упомянутых выше стандартов перечислены в наименовании разделов этих стандартов [1, 2]. Главное – это понятие жизненного цикла изделия (в том числе программного обеспечения, автоматизированных систем), на основе которого строится вся детализация процесса в рамках работы над проектом.

    Чтобы сопоставить и проанализировать большое количество стандартов и нормативных документов,  рассмотрим приведенную ниже схему (Рисунок 1). Это попытка классифицировать различные формулировки жизненного цикла (ЖЦ) применительно к разработке программного обеспечения и автоматизированных систем.


    Рисунок 1. Стадии жизненного цикла при разработке автоматизированных систем в трактовках различных действующих стандартов. Рисунок кликабелен.

    Два верхних ряда представляют перечень стадий жизненного цикла в рамках нового ГОСТ Р ИСО 9001-2015 (первый ряд) и ГОСТ Р ИСО 9001-2001 (второй ряд). Несмотря на некоторые различия в формулировках, стадии жизненного цикла в указанных стандартах почти идентичны.

    Отличия между стандартами проявляются только в подробных разъяснениях к каждому этапу цикла. Отметим, что в новом стандарте появилось понятие «Контекст организации». Его смысл – в изучении того, как внешняя или внутренняя среда влияет на перспективы предприятия. ГОСТ Р ИСО 9001-2015 в пунктах 4.1 и 4.2 требует выявить внешние и внутренние факторы и связанные с ними риски и возможности. Таким образом, смысл глубокого анализа или изучения «контекста» заключается в сборе и анализе данных о внешней среде и текущем состоянии бизнеса, о ключевых факторах успеха (что определяет победу и проигрыш), о состоянии сектора рынка, его структуре, динамике и т.д. Для расшифровки этого понятия и конкретизации деятельности в соответствии с этим требованием нужно тщательно проанализировать все возможные риски, возникающие в процессе. Подробнее о понятии «контекста» можно прочитать в статье Ибрагимова Р. [3].

    Третий ряд схемы показывает стадии жизненного цикла при разработке программных средств в трактовке ГОСТ 12207, который создан специально для процессов разработки ПО [4]. Здесь также нет принципиальных отличий трактовок жизненного цикла по сравнению с предыдущими стандартами.

    ГОСТ 12207 – действительно, довольно жесткий стандарт. Выполнить все его требования при разработке ПО – задача непростая. Но нам важно отметить, что пугающее число стандартов по системе менеджмента качества и требований в них сводятся к тщательному документированию всего процесса проектирования, разработки и сопровождения.

    Посмотрим на четвертый ряд схемы. Здесь представлены процессы жизненного цикла в трактовке ГОСТов 34-й серии [5], опубликованных в далеком 1990 году. Эта серия стандартов была разработана так конкретно и тщательно, что ею пользуются практически без всяких изменений до сих пор. Многие заказчики при формулировке требований к документации на автоматизированные системы ссылаются в основном на ГОСТы именно этой серии. Поскольку этапы жизненного цикла в трактовках ИСО 9001, ГОСТ 12207 и ГОСТов 34-й серии совпадают,  это означает, что, выполняя требования последнего из перечисленных ГОСТов, то есть предъявив заказчику перечисленные документы, мы автоматически работаем в соответствии с системой качества по ИСО 9001.  

    Последний ряд в схеме – примерный перечень документов, который необходим для организации системы качества в компании.

    Очень надеюсь, что приведенная схема значительно упростила вам жизнь. Поскольку теперь у вас уже есть полный перечень стадий жизненного цикла, есть перечень работ, который необходимо выполнить на каждой стадии, и перечень документов, которые должны завершить каждую стадию. Разумеется, этот перечень по требованию заказчика может быть откорректирован в сторону сокращения или добавления новых документов, не указанных в ГОСТе. Но это право заказчика, и исполнитель обязан выполнить его рекомендации.

    К сожалению, это далеко не все. Пока мы разобрались лишь с производственной составляющей, т. е. с процессом разработки ПО или АС.

    Бизнес-процессы — основа основ


    За кадром остались следующие процессы: контрактная работа, организация и управление проектом и собственно обеспечение качества. Это тоже самостоятельный организационный процесс. Описывать эти процессы в текстовом формате — дело неблагодарное, все описания уже есть в многочисленных руководствах [6, 7]. Поэтому попытаемся отобразить перечисленные бизнес-процессы в виде еще одной схемы (Рисунок 2).

    Каждый из этих процессов (по вертикали) отмечен на рисунке своим цветом. Отдельно выделены позиции, завершающие отдельные этапы или весь процесс в целом. Бесцветными остались промежуточные шаги процесса или документы. Все процессы идут параллельно. Они неразрывны, на что указывают стрелки-связи между отдельными элементами.

    В схеме я пытался отобразить некий обобщенный вариант процесса. В каждом конкретном случае, конечно, могут быть свои нюансы и отличия.

    Исполнителю, пользуясь приведенной схемой, необходимо проанализировать свои конкретные бизнес-процессы и выявить те элементы, которые требуют регламентирования. Например, продукция любой ИТ-компании, очевидно, проходит тестирование. Есть ли в вашей компании регламент, в котором прописано, что относится к критическим багам, а что к некритическим и в какие сроки их требуется устранять? Наверняка, определенные инструкции на этот счет есть. Утвержденный регламент по этой позиции — это и есть система менеджмента качества. Причем тестирование затрагивает одновременно производственное направление и администрирование, так как руководство должно отслеживать своевременное исправление ошибок.

    Проделав подобную работу по всем процессам, вы можете доказать заказчику, какие вы «СМКашные» и «ИСОшные». Еще лучше будет, если компания с самого начала очередного проекта составит подобную схему для своих конкретных условий и использует ее в работе и для контроля.


    Рисунок 2. Бизнес-процессы при разработке автоматизированных систем: документирование по системе качества. Рисунок кликабелен.

    Движемся к цели


    Итак, вот шаги, которые необходимо сделать для внедрения (а не просто оформления) системы менеджмента качества в организации.

    1. Создать подразделение, группу или назначить отдельного исполнителя, чтобы он занимался вопросами СМК.

    2. Разработать и оформить Программу качества, в том числе «Руководство по качеству» для организации (департамента, группы разработчиков конкретного проекта). Программа и Руководство должны содержать разделы, перечисленные в ГОСТ Р ИСО 9001-2015, и расшифровку этих разделов. В них должна декларироваться готовность организации выполнить требования стандарта в конкретных условиях этой организации или в рамках проекта.

    3.  Регламентировать процессы разработки и создания программного обеспечения или автоматизированных систем. Для этого нужно составить стандарты организации (или инструкции), в которых прописать все действия, связанные с проектированием, разработкой, тестированием и реализацией проекта, организацией и управлением проектом, обеспечением качества и контрактной работой.

    4.  Регламентировать отчетность и ответственность исполнителей и руководства по каждому этапу жизненного цикла проекта.

    5.  Представить пакет разработанных документов в консалтинговую фирму, имеющую соответствующую лицензию, для инспектирования документации и выдачи заключения о соответствии работы по СМК в рамках стандарта ГОСТ Р ИСО 9001-2015. Исправить замечания и получить сертификат.

    6.  Продолжать проектную работу, строго следуя разработанным регламентирующим документам.

    Мы еще не затронули вопросы ежегодного подтверждения сертификации по ИСО, внешнего аудита, подтверждающего работу по СМК. К сожалению, результат освоения системы менеджмента качества редко поддается денежной оценке. Он, как правило, проявляется в стабильности работы коллектива, надежности получаемых результатов. И эта работа стоит того.

    Литература


    1.   ГОСТ Р ИСО 9001-2015. Системы менеджмента качества. Требования. — М.: Стандартинформ, 2016.
    2. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования. — М., Стандартинформ, 2001.
    3.   Ибрагимов Р., ISO 9001:2015 и практический анализ «контекста» и построение стратегий. — Management, № 2 (34), 2015. — С. 13-18.
    4. ГОСТ Р ИСО МЭК 12207 Информационная технология. Процессы жизненного цикла программных средств. — М.: Госстандарт России, 1999.
    5. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. — М.: Издательство стандартов, 1991.
    6.   Глудкин О.П., Горбунов Н.М. и др. Всеобщее управление качеством. Учебник для вузов. Под ред. О. П. Глудкина. — М.: Горячая линия — Телеком, 2001. — 600 с.
    7.   Круглов М.Г. Инновационный проект. Управление качеством и эффективностью. — М.: РАНХиГС, 2011. — 350 с.


    Источник
    ГК ЛАНИТ 306,48
    Ведущая многопрофильная группа ИТ-компаний в РФ
    Поделиться публикацией
    Комментарии 17
    • +3
      Спасибо, особенно крутые схемы. На самом деле, многие компании нуждаются во внедрении стандартов качества, но относятся к процессу формально — сертификацию прошли, и довольно. На практике ничего не применяется, хотя при должном внедрении могло бы облегчить кучу процессов. Нужна заинтересованность в таких качественных изменениях, должен быть идеолог + его команда. Почти как миссионерство в Новое Время или коммунизм в СССР — насаждать, убеждать, обращать. Сотрудники увидят результат — сами будут поддерживать. Но это такие нервы, такие нервы!
      • +3
        Вы попали в больную точку. Процесс внедрения СМК действительно идет со скрипом. Данная публикация — это проба. Может быть, стоит подумать о развитии темы.
      • +3

        Работал в компании, которая одно время сертифицировалась на это исо9001.
        В промышленном производстве, особенно большом, внедрение этого исо, вероятно, вещь полезная и позволяет получить хорошо задокументированный алгоритм с помощью которого можно получать на выходе продукт не ниже среднего качества.
        В сфере производства ПО, на мой взгляд, сертификация эта в большинстве случаев излишняя. В общем-то, любой более-менее соблюдаемый минимальный процесс разработки укладывается в это исо и требует только большого геморроя по документированию. Всё, что нужно — наличие отдела тестирования и какой-нибудь системы таск/баг-трекинга. Само их наличие — это 90% той практической пользы, которой можно добиться от исо9001 для процесса разработки. На другой чаше весов находится довольно большой геморрой по сертификации и подтверждениям этих сертификатов. Первый очень большой геморрой — документировать все процессы, согласно требованиям стандартов. Что-то, возможно, изменить (но, опять же повторю — любой более-менее существующий процесс в софтварной компании — можно сертифицировать на требования стандарта — главное, чтобы хоть какой-то процесс был). Следующий (и последующий ежегодный) геморрой — заставить сотрудников прочесть (и попытаться запомнить) относящиеся к их ролям части документации. С точки зрения рядового сотрудника — это ужос-ужос… :( Даже простое чтение этого бреда на птичьем языке выматывает почти полностью :). А читать надо, поскольку процесс сертификации (и последующего подтверждения) предполагает, что проверяющие могут выцепить любого рядового работника и начать задавать ему вопросы (а нерядового работника будут спрашивать почти наверняка).
        В общем и целом резюме такое — для средней софтовой компании с точки зрения практической внутренней пользы (в смысле, станем сертифицированными и у нас всё станет лучше разрабатываться) польза, возможно, есть, но только если до этого в компании был полнейший бардак. Польза есть "внешняя" — если клиентам, заказчикам и прочим партнёрам компании требуется, чтобы все их контрагенты были сертифицированы, либо при наличии сертификата вы получаете конкурентные преимущества на рынке. В общем, если у вас нет и не планируется таких партнёров, то сертификация, на мой взгляд, совершенно не нужный геморрой для большинства софтовых компаний (подчёркиваю, именно софтовых — в других отраслях совершенно другая ситуация).

        • +3
          К большому сожалению, многие не софтверные компании думают точно так же, как и Вы — «это просто никому не нужный геморрой». Вы также правы и в том, что наибольшей выгоды от использования СМК добьются те компании, в которых царит полный бардак. Но весь вопрос в том, что оценить степень этого бардака изнутри практически невозможно. Ни для кого не тайна, что многие сотрудники стремятся избежать формализации в работе, считая её излишней нагрузкой и «завинчиванием гаек».
          По большому счету СМК — это элементарный порядок и элементарная ответственность. Доводить же документирование и отчетность до абсурда — просто вред для самой идеи. Каждая компания должна это понимать. В статье я хотел показать возможность именно «разумной целесообразности» в том многообразии стандартов, которое существует сейчас.
          • +1
            «Надо делать хорошо и не надо плохо и тогда будет хорошо!» :)

            Проблема в том, что методологии вроде СМК ущербны с точки зрения чудовищной предрасположенности к бюрократии ради бюрократии, когда в реальной жизни по документам просто невозможно работать из-за взаимных блокировок разных регламентов и баснословной цены по их оперативной взаимоувязке и актуализации. Стоит на полгода забить с актуализацией и всё, треть регламентов надо актуализировать, причём вместо работы. Потому и лежат на полочках рядом с миссиями и стратегиями компаний. Где компаниям брать множество адекватных аналитиков, умеющих делать понятно и рядовым сотрудникам и владельцам компаний? Мне кажется, что такие уникумы сродни единорогам. При этом это множество аналитиков не должно страдать от естественной текучки персонала. Сколько регламентов правил и вводил, обязательно после прохождения сквозь сменяющихся девочек-документоведов и оформителей регламенты превращаются в нечитаемые бюрократические талмуды, которые не открываются в итоге никем, кроме внедряющего и девочек-документоведов. А сотрудники друг-другу как всё устроено на словах и на пальцах рассказывают. И не видно выхода, ибо проблема в человеческой природе, а не в методологиях
            • +2
              Методологии вроде СМК предполагают увеличение бюрократии. Да, это проблема! Но есть еще одна проблема, и она еще серьезнее, и ее, как правило, совершенно не осознают. Когда руководитель проекта держит все вопросы и все текущие изменения у себя в голове, а остальные исполнители смотрят ему в рот и ждут указаний. Пропал руководитель на три часа (пробки, ДТП, поликлиника) и все остановилось. СМК существует для того, чтобы все вертелось независимо от того, что случайно выпало отдельное звено. Приведенный Вами пример на зацикленности в нечитаемых бюрократических талмудах — типичный случай формального подхода к СМК, составлении документов ради документов. Когда этот процесс поручают «девочкам», которым нужно сделать побыстрее документ, лишь бы от них отстали, то и получаем то, что получаем. И составлять документы СМК на проект должны не аналитики, у которых рвотная реакция на эти документы, а специалист по СМК. Где его взять — вопрос второй, и решать его должен руководитель.
          • 0
            И я, и я, я тоже «Работал в компании, которая одно время сертифицировалась на это исо9001» :)
            Мой опыт оказался таковым, что руководство (вроде как) хотело не только сертификат, но и работающую СМК. Всё сделали по инструкции, проблема оказалась только одна — руководство само не хочет исполнять правила, прописанные в СМК. Ну то есть требовать то всегда проще, чем меняться самому, а, как известно, рыба гниёт с головы. Даже не смотря на то, что в результате многие сотрудники изначально прониклись идеей, всё быстро перешло в сферу бюрократии, так как при попытке работать по СМК люди, с точки зрения не изменившего своих понятий руководства, зачастую оказывались в роли крайних. Инициатива снова начала беспокоить инициаторов, и люди поняли, что проще сделать по бумажкам, а работать как всегда. В результате по бумагам для руководства СМК работает, на самом деле — нет. Так СМК стало никому не нужным геморроем.
            • +1
              Ну что тут можно сказать. Можно повторить мой предыдущий комментарий. Можно также напомнить, что в стандарте ИСО 9001-2000 записано: «Высшее руководство должно продемонстрировать свои обязательства относительно создания и поддержания осознания важности удовлетворения требований заказчика; разработки политики качества и целей в области качества, а также планирования качества». Если этого нет, так этого таки нет.
              • 0
                Ну я, как один из входивших в группу внедрения, всё это читал, проходил курсы и прекрасно понимаю :)
                Я, собственно, фактом из жизни ваши комментарии подтверждаю, типа +1. СМК добавляет бюрократии, да, но, если СМК реально работает, в финале где-то даже упрощает жизнь. А вот если СМК не работает — остаётся только бюрократия.
                • 0
                  вот в этом-то «должно» и вся соль проблемы. Кому должно? Зачем с его точки зрения должно? Когда в импортную компанию приходят аудиторы уважаемой компании, которым финансово важна репутация аудиторской компании, то да, появляется двустороннее «должно». Наёмный менеджмент может быть сменён советом директоров из-за найденных нарушений и последовавшего падения акций, а аудиторам важно не потерять реноме и будущие заказы, из-за всплывшего недосмотра на то, что на практике в аудированной компании никакого соответствия процессов требованиям, скажем, SOX, нету, хотя в бумагах есть. А у нас для чего? СМК не единственная панацея от фактора автобуса, есть тысячелетиями отработанные локальные управленческие методы, которые работают, знай себе правильно «натягивай» прямых подчинённых и требуй того же от них.
                • 0

                  Ну, так это… Проблемная ситуация же зафиксирована, благодаря документированным процедурам. На следующем подтверждении предъявляете проверяющему зафиксированное нарушение, проверающий даёт время на исправление либо отзывает сертификат :)

                  • 0
                    Ну да, ну да, я прям представил эту сценку :) У нас в государстве же всё так просто не бывает. Зачем простым трудягам такие головняки, лучше тогда сразу самому уволиться, если уж так бумаги заполнять не хочется, да и нет проблем.
              • 0
                статья хороша. А вообще, СМК — вещь полезная там где в ней есть необходимость. Иначе это становится очередной аппарат в структуре компании.
                • 0
                  Согласен с последней Вашей мыслью. Очень трудно сохранить тонкую грань между действительной необходимостью документировать процесс и тупой обязаловкой оформлять документ на каждый чих.
                • 0
                  Отличные схемы! Спасибо большое!

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое