Управління інцидентами, невідповідність якості

Мета управління проблемами полягає в тому, щоб кожна проблема була оцінена і повністю вирішена. Вирішення проблем включає в себе порядок денний відділу якості, а також допомогу клієнтам і користувачам.

• Життєвий цикл проблеми
• Запис проблеми
  • Виникнення проблеми
  • Вирішення проблеми
  • Стани вирішення проблеми
• Документація проблеми
• Правильний опис проблеми
• Документація рішення
• Може Вас зацікавити

Проблем ніхто не хоче, але вони є невід'ємною частиною будь-якого великого твору. Тому системи управління якістю приділяють їм велику увагу, оскільки їх вирішення є ключовим кроком не тільки в їх усуненні, але і в загальному поліпшенні.

Контроль і вирішення проблем є частиною як управління проектами, так і звичайного управління процесуальною сферою фірми. Звичайно, це також частина загального управління системою якості.

Проблемою ми позначаємо ширшу групу подій, які часто мають окремі назви в термінології фірми. Окремі типи можна відрізнити за допомогою циферблата, визначеного відповідно до корпоративної методології:

• Невідповідність – Відхилення від стандарту, як правило, визначається внутрішнім аудитом. Невідповідність може не призвести до збою.
• Проблема – Неясність щодо вирішення, наприклад, під час розробки, а також, наприклад, проблеми на виробництві (наявні дефекти)
• Дефект – Неправильний вихід, який не відповідає жодній з вимог входу.
• ініціатива – пропозиція, зауваження або застереження від будь-кого з групи адресатів. При подальшому аналізі, як правило, визначають, як класифікувати її більш детально – наприклад, як проблему, але, наприклад, пропозиції щодо покращення.

Життєвий цикл проблеми

Кожна проблема повинна бути помічена якомога швидше, коли вона з'являється. Звичайно, тільки в тому випадку, якщо воно не вирішується відразу (то, напевно, це не проблема).

Коли проблема реєструється, вона залишається «активною», тобто вирішеною до її завершення. Проблема має, по суті, той же життєвий цикл, що і завдання або вимога. Передбачається, що усунення проблеми хтось візьме на себе, до того часу він може залишитися відкритим без розв'язувача.

Запис проблеми

Більшість процесуальних методологій вимагають, щоб були записані всі або більшість зазначених нижче даних. Перевірте, можливо, власну методологію вашої організації, що саме вона вимагає.

Виникнення проблеми

Документація при створенні журналу проблеми повинна включати:

• Опис, як проявляється проблема
• Ідентифікація того, хто і коли його повідомив (не обов'язково той, хто його записав)
• Коли він почав проявлятися, виник або вперше з'явився на нього
  **Кому дістанеться проблема управління?

Вирішення проблеми

В рамках подальшого аналізу повинні створюватися записи:

• Причина проблеми – Її висновки можуть вимагати більш детального аналізу, наприклад, «Root-Cause», «Fishbone», 8D-звіт та ін. Ці аналізи повинні бути включені в документацію проблеми, оскільки вони є важливою документацією процедури. Причина задокументована на власній вкладці в деталях.
• Процедура вирішення – Які події та висновки були зроблені при вирішенні проблеми:
• Події: Документовані у формі події (вкладка діяльності)
• Висновки: Записано в процедуру розв'язання (під сам опис проблеми). Що стосується припущень, речей для обговорення або пропозицій, то ми рекомендуємо задокументувати дискусію на тему проблеми. Примітка: дискусія архівується так само, як і сам об'єкт, і тому є документацією рішення, яке можна переглянути, а потім провести аудит.

Стани вирішення проблеми

• Новий – після створення, проблемою досі ніхто не займається
• Безкоштовно вирішити – Проблему "куратор" назвав в очікуванні того, хто візьметься за неї
• В рішенні – Хтось відповідає за проблему
• Вирішений – Проблема була вирішена і чекає підтвердження адміністратором. Якщо проблему безпосередньо вирішує адміністратор, то проблема взагалі не потрапляє в цей стан.
• Завершено – Проблема повністю вирішена. У стан він потрапляє або шляхом його вирішення контролером, або шляхом підтвердження того, що проблема вирішена (контролером, коли її вирішив хтось інший).
• Відсортований – Проблему перестав мати сенс вирішувати. У цей стан розв'язувач може перенести його вручну за допомогою команди. Проблема знята, наприклад, у тому випадку, якщо вона стосувалася контракту, який був скасований.

Документація проблеми

Проблеми можуть залишатися відкритими взагалі як би довго. Система не має інструменту, щоб оцінити актуальність проблеми, а тому не організує її вирішення в цілому. Однак для проблеми слід зазначити, до якого часу її слід усунути, а проблеми, які перевищать цю дату, виділені на робочому столі.

Документація проблеми має й інші переваги:

• Збільшення представництва членів команди, які таким чином легше передають порядок денний, який необхідно вирішити
• Передача досвіду в інших і пізніших проектах, які можуть отримати досвід, на що звернути увагу і на що розраховувати, що може статися
• При якісній документації вирішення проблеми можна отримати в інших проектах або заходах взагалі досвід вирішення проблеми.
• Виконання вимог методологій, таких як PMBOK, ISO 9001, [ASPICE](https://www.qm.pdqm.cz/pdqm.cz/https/////(https/uk///////, щоб не розглядати наші інші проблеми, які розглядаються в якості якості якості документа/ISO-2), а також не як інші інші інші проблеми, які розглядаються в якості документації.

Документація рішення

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

Особливо при вирішенні більш складних проблем часто проблема ділиться на часткові проблеми або інші часткові проблеми проявляються. Таким чином, можна вказати часткові підзавдання до проблеми, або зв'язати проблему логічним зв'язком з іншим.

Може Вас зацікавити

• Проблеми, інциденти, helpdesk, білети – термінологія
• Об'єднання проблем та їх спільне вирішення
• Предмет проблеми або зв'язок між проблемою і тим, що вона стосується