Анализ системы менеджмента со стороны руководства в лаборатории процедура

### Время на прочтение

Блокноты Jupyter — это, уже довольно давно, один из самых неоднозначных инструментов в среде дата‑сайентистов. Одни яро критикуют Jupyter, другие горячо поддерживают этот проект. Но, тем не менее, многие согласятся с тем, что блокноты Jupyter, при правильном их использовании, могут быть очень ценным инструментом. Именно этому и посвящена данная статья — вторая в серии моих материалов про науку о данных и машинное обучение.

Я поделюсь здесь методическими рекомендациями по использованию Jupyter Notebook для разведочного анализа данных.

![](https://habrastorage.org/getpro/habr/upload_files/b09/a3c/f27/b09a3cf276aabb540e11c21ca92c6926.png)

### История Jupyter

Для начала нужно ответить на вопрос о том, почему блокноты Jupyter нашли широкое применение в научном сообществе. Когда Data Science стала популярной темой, блокноты Jupyter ещё не существовали. Сначала был IPython — интерактивная оболочка для Python, встраиваемая в различные IDE, например, Spyder. Эти IDE пытались повторить работу RStudio или Matlab и получили популярность среди исследователей.

В 2014 году проект Jupyter вырос из IPython. Блокноты стали популярными благодаря исследователям, перенесшим свой опыт из научной сферы в бизнес. Однако подходы к использованию блокнотов в учреждениях не всегда подходят для анализа данных в организациях. Часто дата‑сайентистам сложно следовать бизнес-требованиям.

### Использование блокнотов Jupyter в бизнесе

Эта статья рассматривает блокноты Jupyter с точки зрения применения в реальных проектах. Jupyter вызывает много споров, но я поделюсь своим мнением о них:

- Блокноты Jupyter следует использовать ТОЛЬКО для разведочного анализа данных и для расчётов от случая к случаю.
- Блокнот — это всего лишь отчёт. Важность кода должна быть минимальной, результаты работы важнее.
- Код в блокноте должен быть скрыт, чтобы уделять внимание лишь результатам анализа.

### Примеры вопросов, на которые можно ответить с помощью блокнотов Jupyter

![](https://habrastorage.org/getpro/habr/upload_files/15f/1ab/255/15f1ab25505bb0b0855bce10ef2c28ed.png)

### Применение блокнотов Jupyter

Блокноты Jupyter идеально подходят для решения различных задач в различных областях:

- Исследование данных
- Анализ экспериментов
- Анализ воздействия на бизнес
- Моделирование

### Рекомендации по эффективному storytelling

При создании заметок в блокноте Jupyter, вы в основном рассказываете историю или отвечаете на вопрос о выполняемой исследовательской задаче. Но это не означает, что вы должны показывать тем, кто увидит блокнот, проделанную работу для вывода определенных заключений.

## Структурирование содержимого блокнотов Jupyter

Составляя блокнот — всегда описывайте то, что окружает исследуемую задачу. Одних только данных не достаточно для того чтобы рассказать связную историю. Поэтому надо показывать весь анализ в том контексте, в той сфере деятельности, к которым он относится. Благодаря этому читателям блокнота будет легче и удобнее воспринимать прочитанное. Для подкрепления своих заявлений используйте ссылки на статьи из базы знаний компании. Соберите эти ссылки в отдельном разделе блокнота.

### Пример шаблона блокнота для разведочного анализа данных

![Шаблон блокнота](https://habrastorage.org/getpro/habr/upload_files/607/ebd/967/607ebd9674d3089c14746169e0619b9a.png)

### Как организовать код в Jupyter Notebook

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

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

### Перемещение вспомогательных функции в обычные Python-модули

Поделюсь советами по поводу работы с кодом в блокнотах Jupyter.

#### Использование Python-модулей

В общем случае можно сказать, что импорт функций, определённых в Python‑модулях — это лучше, чем определение их прямо в блокноте. Начнём хотя бы с того, что в Git сравнения разных версий.py‑файлов гораздо легче читать, чем сравнения разных версий кода блокнотов. При таком подходе читателю, чтобы разобраться в блокноте, не надо знать о том, чем именно занимается функция.

Например, обычно в блокнотах применяются функции для чтения данных, для выполнения SQL‑запросов, для предварительной обработки, преобразования, расширения используемых наборов данных. Все эти функции стоит перенести в.py‑файлы, а затем импортировать в блокнот, чтобы читатель видел лишь вызовы функций. Если тому, кто проверяет блокнот, нужно больше деталей — он всегда может заглянуть в соответствующий Python‑модуль.

Настройка функций для визуализации данных в Python

Я нахожу такой подход особенно полезным, например, при оформлении функций, ответственных за визуализацию данных.

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

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

Пример модуля

import matplotlib.pyplot as plt
import numpy as np

def create_barplot(data, x_labels, title=, xlabel=, ylabel=, bar_color=b, bar_width=0.8, style=seaborn, figsize=(8, 6)):
    Создаёт настраиваемую столбчатую диаграмму с использованием Matplotlib.
    
    Параметры:
    - data: Список или массив с данными, которые нужно вывести на диаграмме.
    - x_labels: Список подписей для оси x.
    - title: Заголовок диаграммы.
    - xlabel: Подпись для оси x.
    - ylabel: Подпись для оси y.
    - bar_color: Цвет столбцов (по умолчанию - синий).
    - bar_width: Ширина столбцов (по умолчанию - 0.8).
    - style: Стиль Matplotlib, используемый для диаграммы (например - seaborn, ggplot, default).
    - figsize: Кортеж, задающий размер фигуры (ширину и высоту).
    
    Возвращает:
    - Ничего
    
    
    # Задать стиль Matplotlib
    plt.style.use(style)
    
    # Создать фигуру и ось
    fig, ax = plt.subplots(figsize=figsize)
    
    # Сгенерировать позиции x для столбцов
    x = np.arange(len(data))
    
    # Создать диаграмму
    ax.bar(x, data, color=bar_color, width=bar_width)
    
    # Задать подписи для оси х
    ax.set_xticks(x)
    ax.set_xticklabels(x_labels)
    
    # Задать подписи и заголовок
    ax.set_xlabel(xlabel)
    ax.set_ylabel(ylabel)
    ax.set_title(title)
    
    # Показать диаграмму
    plt.show()

## Пример использования в ячейке блокнота
create_barplot(data, x_labels, title=”Customizable Bar Plot”, xlabel=”Categories”, ylabel=”Values”, bar_color=”skyblue”, bar_width=0.6, style=”seaborn”, figsize=(10,6))

Создавая подобные Python-модули, помните о том, что код, находящийся в них, является частью вашего проекта по разведочному анализу данных. Поэтому, если только вы не используете этот код в каких‑то других частях проекта, он не должен быть идеальным. Достаточно — чтобы он был бы читабельным, чтобы его могли бы понять те, кто делает код‑ревью блокнота.

Разделение функционала

Функции для вывода графиков, для загрузки и подготовки данных, для расчёта каких-то метрик, рекомендуется размещать в обычных Python-модулях. Это позволяет, в тексте самого Jupyter-блокнота, сосредоточится на разведочном анализе данных.

Использование SQL в ячейках Jupyter-блокнота

В некоторых случаях данные находятся не в памяти (например — в объекте pandas DataFrame), а в хранилище компании (вроде Redshift). В подобных случаях большая часть операций по исследованию и первичной обработке данных выполняется посредством SQL.

Существует несколько способов использования SQL в блокнотах Jupyter. Так, JupySQL позволяет писать SQL‑код прямо в ячейках блокнота и выводит результаты запросов так, как если бы они были бы датафреймами pandas. SQL‑скрипты, кроме того, можно хранить в сопутствующих файлах, или в дополнительных Python‑модулях, о которых мы говорили в предыдущем разделе.

Применение того или иного способа работы с SQL зависит, в основном, от нужд конкретного проекта.

Если вы заняты анализом, в ходе которого используется несколько таблиц из хранилища данных, и вы хотите продемонстрировать коллегам качество и правильность этих данных, тогда, как правило, самый лучший вариант — это показ SQL‑запросов в самом блокноте. Те, кто делает код‑ревью, оценят то, что они могут сразу видеть то, как именно выполняются запросы к таблицам, то, какие соединения данных выполняются для получения определённого результата, то, какие фильтры понадобилось применить, и так далее.

Но если вы всего лишь генерируете набор данных для проверки модели машинного обучения, и главное в блокноте — показ различных метрик и объяснимость выходных данных — тогда я порекомендовал бы как можно лучше скрыть операции по подготовке набора данных и держать запросы в отдельном SQL‑скрипте или в Python‑модуле.

Рассмотрим примеры, демонстрирующие применение обоих подходов.

Чтение и выполнение запросов из .sql-файлов скриптов

Можно пользоваться .sql-файлами, которые открывают и выполняют из блокнота посредством библиотеки для соединения с базами данных.

Предположим, имеется следующий запрос, хранящийся в файле select_purchases.sql:

SELECT * FROM public.ecommerce_purchases WHERE product_id = 123

Для его выполнения можно определить такую функцию:

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

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

df = execute_sql_script(‘select_purchases.sql’, connection_params)

Использование JupySQL

До недавнего времени для выполнения SQL‑запросов из блокнотов Jupyter обычно использовалась библиотека ipython‑sql. Но в апреле 2023 года её создатель сообщил о том, что её дни сочтены, и порекомендовал переключиться на JupySQL — её форк, над которым ведётся активная работа. Теперь все улучшения и новые возможности будут появляться только в JupySQL.

Для того чтобы установить библиотеку ради использования её с Redshift, надо сделать следующее:

pip install jupysql sqlalchemy-redshift redshift-connector ‘sqlalchemy<2’

(Её можно использовать и с другими базами данных, вроде snowflake или duckdb).

В Jupyter-блокноте теперь можно будет использовать «магическую» SQL-команду %load_ext для включения SQL, и применить следующий фрагмент кода для создания объекта sqlalchemy.engine для Redshift:

А потом достаточно передать объект engine «магической» команде:

%sql engine –alias redshift-sqlalchemy

С этого момента всё выглядит крайне просто — берём «магическую» команду и пишем любые запросы, которые нужно выполнить. Их результаты попадут в выходные данные ячейки:

%sql SELECT * FROM public.ecommerce_purchases WHERE product_id = 123

Проверка того, что код ячеек выполняется по порядку

Рекомендую всегда выполнять все ячейки с кодом перед отправкой блокнота в репозиторий. Блокноты Jupyter сохраняют выходное состояние каждой ячейки после её выполнения. Это означает, что код, который был написан или отредактирован, может не соответствовать тем данным, что присутствуют на выходе ячейки.

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

Один из способов проверки того, что все ячейки блокнота были выполнены в правильном порядке — это использование хука pre‑commit nbcheckorder. Он проверяет, выполняются ли ячейки друг за другом. Если это не так — это указывает на то, что ячейки не были выполнены одна за другой, и хук не даёт сделать коммит в Git‑репозиторий.

Вот пример файла .pre-commit-config.yaml:

– repo: local rev: v0.2.0 hooks: – id: nbcheckorder

Если вы ещё не пользуетесь pre‑commit‑хуками — я очень рекомендую вам взять на вооружение этот маленький инструмент. Советую начать их изучение с этого материала. Позже можете обратиться к подробной документации по ним для того чтобы разобраться со всеми их возможностями.

Очистка выходных данных ячеек

Вот совет, который даже лучше, чем предыдущий: очищайте выходные данные ячеек блокнотов. Одно из преимуществ, которое это даёт, заключается в том, что это позволяет игнорировать состояния ячеек и их выходные данные. Но, с другой стороны, это принуждает тех, кто делает код‑ревью блокнота, выполнять код локально в том случае, если им нужно увидеть результаты работы кода.

Для решения этой задачи можно воспользоваться, вместе с другими pre‑commit‑хуками, хуком nbstripout, делая это в соответствии с пояснениями его автора на GitHub.

– repo: local rev: 0.6.1 hooks: – id: nbstripout

Ещё можно воспользоваться командой nbconvert –ClearOutputpPreprocessor в пользовательском pre-commit хуке, как рассказано здесь.

Создание отчётов с помощью Jupyter Notebook и предоставление их заинтересованным лицам

Теперь мы подошли к вопросу, на который нет чёткого ответа. Как лучше всего поделиться блокнотом с членами команды и с другими заинтересованными лицами?

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

Команды «переводчиков»

Члены таких команд уверены в том, что управленцам или продакт‑менеджерам неудобно читать Jupyter‑блокноты в их исходном виде. Поэтому они адаптируют результаты своих анализов и отчёты в расчёте на ожидаемую аудиторию.

«Переводчики» берут результаты своих изысканий из блокнотов и добавляют их в базы знаний компаний (например — Confluence, Google Slides и так далее). Среди отрицательных побочных эффектов такого подхода можно отметить то, что из‑за этого, в некоторой степени, теряется связь с исходными блокнотами. Дело в том, что так сложнее становится просмотреть историю различных версий отчёта. Но «переводчики» защищают свою позицию тем, что это позволяет им эффективнее донести результаты их исследований до заинтересованных лиц.

Если вам близка эта идея — рекомендую поддерживать связь между экспортированным документом и блокнотом Jupyter, на котором он основан, сделав так, чтобы они всегда были бы синхронизированы. При таком подходе можно пользоваться блокнотами, в которых будет меньше текста и выводов, уделив внимание, в основном, необработанным фактам или свидетельствам чего‑либо, которые дают сами данные. А система документации компании будет использоваться для расширения резюме исследований и для комментирования полученных результатов. В таком случае можно разделить то, что получается на выходе исследования: код, с помощью которого изучают данные, и результаты их изучения.

Команды, дающие всем доступ к исходным блокнотам

Такие команды используют локальные Jupyter‑блокноты и дают доступ к ним всем остальным бизнес‑подразделениям компаний, создавая решения, привязанные к базам знаний и инфраструктуре компаний. Дата‑сайентисты из таких команд твёрдо уверены в том, что все, кто заинтересован в результатах их работы, должны обладать возможностью понять то, что имеется в их блокнотах. Они уверены и в том, что нужно поддерживать чёткую связь между результатами исследования и исходными данными.

Но вряд ли члены финансового отдела компании обратятся к GitHub или к Bitbucket для того чтобы почитать блокноты дата‑сайентистов.

Я видел несколько решений, реализованных в этой сфере. Например — можно воспользоваться чем‑то вроде nbconvert для генерирования PDF‑файлов из блокнотов Jupyter. Блокноты можно экспортировать и в HTML. Это позволит легко делиться ими с кем угодно, даже с теми, кто не входит в состав технических команд.

Блокноты можно даже переместить в хранилище Amazon S3 и захостить их там в виде статических, уже сформированных веб‑сайтов. Можно воспользоваться механизмами CI/CD для того чтобы создавать из блокнотов HTML‑страницы, рендерить их и отправлять в хранилище в том случае, когда код добавляется в некую ветку репозитория.

Команды — приверженцы инструментов сторонней разработки

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

И, помимо этого, Deepnote и SageMaker позволяют делиться блокнотами с коллегами. Доступ к блокнотам может выглядеть и как разрешение на их чтение, и как организация совместной работы в реальном времени с использованием той же самой среды выполнения блокнотов.

Существуют и опенсорсные альтернативы этим инструментам, такие, как JupyterHub. Но для приведения их в рабочее состояние требуются неоправданно большие усилия на их настройку и поддержку. Локальное развёртывание JupyterHub может оказаться не самым удачным решением, прибегать к которому имеет смысл лишь в очень редких случаях (например — когда речь идёт об очень особенных рабочих нагрузках, требующих применения весьма специфического аппаратного обеспечения). Используя облачные службы вы можете задействовать экономические механизмы, связанные с масштабированием. Они гарантируют применение архитектур, гораздо лучше защищённых от сбоев, чем способны предложить компании, работающие в других сферах бизнеса. Размышляя об опенсорсных решениях, нужно учесть стоимость их первоначальной настройки. Нужно обеспечить, чтобы команда, занимающаяся ИТ‑системами компании, поддерживала бы эти решения в рабочем состоянии, давая дата‑сайентистам доступ к ним. Нужно гарантировать информационную безопасность решения и защиту данных. Получается, что выбор управляемых сервисов позволяет избежать бесконечных сложностей, связанных с поддержкой собственной инфраструктуры.

В целом — дам такой совет относительно исследования подобных продуктов: если ваша компания уже работает с провайдером облачных услуг вроде AWS, Google Cloud Platform или Azure — то, возможно, стоит подумать о внедрении у себя и решений этого провайдера, нацеленных на Jupyter‑блокноты. Это позволит упростить работу с инфраструктурой компании и будет менее рискованно, чем выбор совершенно нового провайдера.

Освоение методических рекомендаций по работе с Jupyter Notebook

В этом материале мы обсудили методические рекомендации и советы по оптимизации работы с блокнотами Jupyter.

Вот самый главный вывод, который можно сделать:

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

В итоге скажу, что я горячо рекомендую дата‑сайентистам пользоваться платформой Jupyter Notebook, но — только для разведочного анализа данных и для создания отчётов.

Продакшн‑артефакты, такие, как модели, наборы данных, или гиперпараметры, не должны быть напрямую связаны с блокнотами. То, на чём они основаны, должно находиться в продакшн‑средах, которые можно воспроизводить и перезапускать. Например, это SageMaker Pipelines или Airflow DAG — отлично поддерживаемые и хорошо проверенные системы.

О, а приходите к нам работать? 🤗 💰Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.Присоединяйтесь к нашей команде

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

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

Для эффективной работы системы менеджмента качества анализ СМК должен быть организован по «каскадному» принципу. Т.е. он должен включать в себя анализ СМК на уровне линейного персонала (рабочие, служащие, ИТР), подразделений, и организации в целом. На каждом из уровней периодичность такого анализа и объем будут различны. Форма проведения анализа СМК будет зависеть от масштабов организации.

Для выполнения анализа системы качества желательно разработать четкий порядок его проведения на всех уровнях. Процедура анализа СМК со стороны руководства позволит эффективно использовать этот инструмент управления. Кроме того, она даст возможность наладить «вертикаль» системы отчетности для принятия адекватных решений. Например, анализ СМК на уровне линейного персонала служит исходными данными для анализа СМК на уровне подразделения, результаты которого, в свою очередь, являются входными данными для анализа СМК на уровне организации в целом. Таким образом реализуется принцип СМК – принятие решений на основе фактов.

Документированная процедура позволит организовать и контролировать процесс анализа СМК со стороны руководства.

Для этого, в процедуре необходимо установить:

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

Входные данные анализа СМК

Чтобы получить эффективные результаты от анализа СМК со стороны руководства, он должен быть хорошо подготовлен. В зависимости от уровня управления, подготовка исходных данных и их состав будет меняться. Стандарт ISO 9001:2015 определяет источники данных для анализа СМК. Следует отметить, что это именно источники данных, а не конкретный состав. Источники данных на всех уровнях управления могут быть одинаковыми, а вот конкретный состав будет изменяться от уровня к уровню.

Например, одним из источников данных, указанных в стандарте, является результат мониторинга и измерений. Для оперативного уровня управления конкретными данными могут являться – объём выполненных работ, количество изготовленных изделий и т.п. Для уровня подразделений (тактический уровень) – исполнение бюджета, количество новых заказов и т.п. Для стратегического уровня (организация в целом) – объём полученной прибыли, объём затрат и т.п.

При подготовке исходных данных для анализа СМК со стороны руководства не стоит концентрировать внимание исключительно на вопросах качества. Это приведет к снижению эффективности анализа СМК.

При подготовке исходных данных для анализа СМК организация должна рассмотреть следующие вопросы:

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

– достижение целей в области качества. Цели в области качества создают плановую основу деятельности каждого сотрудника. Для эффективной системы качества характерной является ситуация, когда цели детализируются с уровня организации до уровня процессов, подразделений и отдельных сотрудников. Таким образом, становится возможным организовать управление по целям. Анализ системы качества позволяет контролировать достижение целей и своевременно вносить коррективы в деятельность компании;

– показатели процессов и соответствие продукции или услуг. В зависимости от уровня управления меняется «горизонт» охвата проблем со стороны руководителей. Высшее руководство не может детально контролировать каждый процесс и каждую единицу продукции. В тоже время, руководители нижнего звена не в состоянии определить проблемы, связанные с системными ошибками. Информация о работе процессов и качестве продукции должна агрегироваться при переходе от уровня к уровню;

– несоответствия и корректирующие действия. Анализ со стороны руководства даёт возможность на каждом из уровней управления определить, какие ошибки возникают в ходе работы и выработать необходимые решения по устранению их причин. Для каждого из уровней управления «масштабность» причин будет своя, состав действий, также свой;

– данные мониторинга и измерений. Стандарт обязывает организацию осуществлять мониторинг и измерение объектов, существенных для системы качества (см. п.п. 9.1.1). Результаты измерений позволяют судить о результативности работы. Для каждого уровня управления эти данные имеют разную степень детализации. На оперативном уровне они подробно представляют характеристики объекта измерения, на тактическом и стратегическом уровне происходит их агрегация;

– результаты аудитов (проверок). Для эффективно работающей системы необходимо рассматривать результаты всех проверок, а не только результаты аудитов СМК. На каждом уровне могут выполняться свои проверки, имеющие конкретные цели. Поэтому, установив в процедуре, какие виды проверок и аудитов существуют на каждом из уровней управления, организация значительно упростит работу сотрудников;

– деятельность внешних поставщиков. От работы поставщиков во многом зависит качество продукции и услуг организации. Большинство проблем взаимодействия с поставщиками возникает на оперативном уровне, а принятие решений – на тактическом и стратегическом уровнях. Проведение анализа системы качества на различных уровнях даёт возможность получения объективной информации для принятия правильных управленческих решений;

Подготовку исходных данных для анализа СМК необходимо осуществлять регулярно. В зависимости от уровня управления она может выполняться разными сотрудниками. Для уровня стратегического управления такую подготовку может осуществлять представитель руководства по качеству или руководитель службы качества. На тактическом уровне за подготовку данных может отвечать руководитель соответствующего направления (например, начальник производства, главный инженер, финансовый директор и т.п.). На оперативном уровне подготовкой данных может заниматься руководитель подразделения.

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

Выходные данные анализа СМК

Также как для входных данных, для выходных данных стандарт ISO 9001:2015 задает только источники необходимой информации, но не устанавливает конкретных показателей. Выходными данными анализа СМК со стороны руководства могут являться любые решения и действия, направленные на улучшение работы.

В соответствии со стандартом ISO 9001:2015 решения и действия могут касаться:

Для каждого уровня управления эти решения могут быть выражены по-разному, в различных действиях. Форма представления решений также может быть разной. В частности, для стратегического уровня, решения могут оформляться в виде протокола, а для оперативного уровня может оказаться достаточным ведения записей в личном дневнике руководителя.

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

Процедура "Анализ СМК со стороны руководства"

Данная процедура разработана в соответствии с требованиями новой версии стандарта ISO 9001:2015.

Процедура "Анализ СМК со стороны руководства" представляет порядок проведения анализа на следующих уровнях:

Для каждого уровня управления представлена схема анализа и даются необходимые пояснения.

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

Документ включает в себя 13 страниц.

Новая версия стандарта ИСО 9001:2015 не использует термин записи по качеству, тем не менее, такое понятие в системе качества и в стандартах ИСО серии 9000 осталось. Записи по качеству стали частью более общего термина – документированная информация.

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

Записи по качеству являются базой для анализа результативности и эффективности работы как системы качества, так и организации в целом. Это связано с тем, что этот вид документации системы качества предназначен для фиксации сведений о выполняемой работе.

В частности, записи по качеству предназначены:

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

Виды записей по качеству

Подтверждение пригодности применяемых ресурсов для мониторинга и измерений

Свидетельство о калибровке, график поверки, паспорт на прибор, свидетельство об аттестации методики и т.п.

Подтверждение пригодности базы эталонов (если используется своя собственная, а не государственная)

Свидетельство об аттестации, методика аттестации эталонов

Сведения об образовании, подготовке, квалификации и практическом опыте

Сертификаты, аттестаты, данные кадрового учета

Доказательства, что требования к процессам по выпуску продукции и требования к продукции выполнены

Протоколы контроля и мониторинга процессов, протоколы аудита процессов, Акт сдачи-приемки работ, акт приемки продукции

Результаты анализа требований, относящихся к продукции и действия, вытекающие из этого анализа

Протокол анализа рисков, Согласующие подписи на договоре, ТЗ

Входные данные для проектирования и разработки, относящиеся к требованиям к продукции

ТЗ, задание на разработку, проектирование

Выходные данные проектирования и разработки

Проект, схемы, чертежи, пояснительные записки и т.п.

Результаты анализа изменений проектирования и разработки, Результаты утверждения проектирования и разработки, Результаты проверки проектирования и разработки

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

Результаты оценки поставщиков и все действия, признанные необходимыми на основе этих оценок

Протокол оценки поставщиков, утвержденный список поставщиков

Сведения об особой идентификации продукции, для которой требуется прослеживаемость

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

Акт приёмо-передачи, дефектовочная ведомость, извещение о браке, протокол разногласий, запись в базе данных информационной системы

Сведения об изменениях в производстве продукции или предоставлении услуг

Протокол анализа изменений, план изменений производственных процессов, план корректирующих действий, план развития системы качества

Сведения, указывающие лицо или лиц, ответственных за выпуск продукции

Накладные приёмки, акт приёмки ОТК, сертификат соответствия, подпись ответственного за выпуск продукции

Характер несоответствий и все предпринятые последующие действия, включая разрешения на отклонения

Классификатор дефектов, карточки разрешений на отклонения, акт списания в брак, Протоколы контроля работ, Акт сдачи-приемки работ

Результаты деятельности организации и результативность системы качества

Контрольные листки, протоколы измерений или испытаний, акты приемки, контрольные карты, отчеты по аудиту, протоколы несоответствий

Результаты внутренних аудитов и последующие действия

Отчет об аудите, протоколы отклонений

Протокол анализа результативности СМК

Характер несоответствий, результаты корректирующих действий

Лист несоответствий, протокол несоответствий, отметка в контрольной карточке, отметка в плане корректирующих действий