Частина 2. СППР Універсальні алгоритми – Алгоритм для служби підтримки

У статті описаний ще один підхід щодо реалізації системи підтримки прийняття рішень. На основі цієї СППР був реалізований алгоритм для служби підтримки.

Початковий стан – я керував службою впровадження та супроводу у приватної медичної компанії. Філіальна мережа відділень в регіонах, яка працює під управлінням єдиної системи. Так само використовується схоже обладнання на всіх об'єктах. Фактично все обладнання підключено до системи і віддає дані (диализные апарати, лабораторні аналізатори, апарати УЗД і кардіографи, вимірювачі ваги і тиску, водопідготовка, система вентиляції, датчики температури і вологості).

Мережа відділень постійно розширюється. У кожному відділенні є ІТ-спеціаліст. Далеко не завжди цей фахівець, компетентний в різних областях. Завдання стояло досить масштабна по забезпеченню працездатності досить складною з точки реалізації системи.

Проблема
Опис інцидентів фахівцями 1-го рівня підтримки. Мається на увазі те, що одну і ту ж помилку кожен описував як міг, як хотів, як вистачало фантазії… Важко перерахувати всі варіації. Так само хотілося скоротити час на вирішення інцидентів. Особливо тих, які вже одного разу відбувалися і були описані. Тобто потрібно було забезпечити максимальне закриття інцидентів на 1-му рівні підтримки з досить високою швидкістю та якістю.

Мені не подобається існуючий спосіб опису Бази знань. Тому що одна і та ж помилка може бути викликана різними причинами. Відповідно і опис рішень має бути множинним. Чого насправді немає. І сам пошук рішення – досить довгий з точки зору необхідного кількість кроків. За великим рахунком зазвичай База знань – це набір файлів.

Не важливо ще і акуратність опису рішення. Важливо врахувати поняття «Найкраща практика». Наведу приклад. Коли на ранок попередньо налаштований пост самообслуговування частково перестав працювати – перестав працювати тач-скрін, ІТ спеціаліст витратив 2 години і 5 хвилин на усунення інциденту. Я спеціально не став втручатися щоб поспостерігати дії і побачити результат. Причина була в тому, що санітарка шваброю трохи висмикнула USB-шнур тач-скрін. З допомогою алгоритмів ця проблема усувалася протягом максимум 5-ти хвилин.

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

Хотілося скористатися перевагою системи – формуванням протоколу, який описує кроки проходження за алгоритмом. Тобто вирішити проблему того, як послідовно описувати інциденти – копіпаст протокол заявку.

Реалізація
В Алгоритм-Дизайнера була створена первинна структура алгоритму, де були створені розділи для опису:



Для початку був обраний посаду самообслуговування пацієнтів. Тому що пацієнти на початку і в кінці кожної зміни проходили через цей пост. І збій в роботі посту самообслуговування міг призвести до затримки кожної зміни.

Пост самообслуговування пацієнтів:

• Системний блок
• Монітор з тач-скріном
• Колонки (використовуються для голосового помічника)
• Кард-рідер (використовується для ідентифікації пацієнта)
• Ваги
• Вимірювач тиску
• Принтер
• Синтезатор мовлення
• Програма MaximusDriver, яка відповідає за все підключене обладнання
• Програма Maximus, запущена в режимі посту самообслуговування

Оскільки Ваги і Вимірювач артеріального тиску передають дані через COM порт, то існували варіації підключення:

• Через COM-порт
• З використанням MOXA
• Через перехідник USB-COM

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

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

Первинно розроблялася 1-я ситуація, яка дозволяла локалізувати проблему.



Інші ситуації вже дозволяли вирішувати конкретну локалізовані проблему.



Принцип роботи.
При діагностиці в самому початку встановлюється факт того, чи виникла помилка внаслідок оновлення системи. Поясню чому. Справа в тому, що оновлення системи проходило одночасно у всіх відділеннях. Відповідно всі використовували одну і ту ж версію Бази даних і одну і ту ж версію бінарних файлів. Тобто помилки в системі були загальними. Виявлена і виправлена помилка для одного відділення автоматично ретранслировалась на все відділення.

Ситуація локалізації проблеми вийшла більш масштабною. Самі ж ситуації за рішенням більш короткі.

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



Взагалі методика створення СППР дозволяє створювати заглушки на ще не описані випадки. Що дозволяє фактично відразу використовувати систему без ризику того, що виникне помилка в разі відсутності опису якогось розділу.

Функція друку діаграм алгоритму дозволяла візуально оцінювати ланцюжок дій і рекомендацій.

Було ще бажання реалізувати можливість управління за відхиленнями. Що це означає? Зазвичай аналіз збоїв, простоїв тощо Проводиться за підсумками місяця або тижня. Що дає суто статистичну інформацію. По ній, звичайно ж, можна і потрібно приймати управлінські рішення. Але об'єктивно це малоефективно.

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

Приклад отриманого протоколу після проходження за алгоритмом:



Приклад чат-бота Telegram, який працює на ядрі СППР з Частина 3. Чат-бот Telegram на ядрі логіки СППР : @DSSUABot
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.