1. Системи ведення майстер-даних (MDM (Master Data Management))
2. Опис системи ведення майстер-даних для процесів управління технічним обслуговуванням і ремонтами Prostoev.NET-НДІ...
3. ДСТУ ISO / ТС 8000-1-2009
4. Як побудувати класифікатор обладнання, і навіщо він потрібен?
5. До якого рівня потрібно описувати обладнання, і як це зробити швидко?
6. Як не заплутатися в різноманітті різного устаткування і його параметрах?
7. Як очистити історичні дані?
11. Як бути, якщо даних немає?
13. З якими системами сумісно рішення Prostoev.NET-НДІ?
15. Скільки коштує система?
16. Що робити, якщо часу на підготовку даних у нас зовсім немає?

У даній статті автор висвітлює проблему уніфікації довідкової інформації для впровадження різних систем класу АСУ ТОіР і представляє систему, що дозволяє істотно спростити роботи по створенню стартового масиву даних для їх запуску, а також налагодити процес підтримки поновлення майстер-даних. Будь-який новий проект підготовки даних, необхідних для ERP / EAM систем, починається з нуля, тобто з розробки проектних рішень, необхідних для однакової підготовки стартових довідників. Очевидно, що таких проектів багато, вони не пов'язані між собою, правила і принципи формування структури даних абсолютно різні, і в результаті такого підходу ми отримуємо абсолютно різний опис, здавалося б, одного обладнання. Уникнути деякої кількості помилок в таких проектах дозволяє використання зовнішніх консультантів або реалізація проекту з використанням спеціалізованих інформаційних систем для підготовки даних. В даний час проблема уніфікації довідкової інформації вирішується з використанням різних рішень класу MDM (Master Data Management), тобто систем ведення майстер-даних.

джерело: Журнал Prostoev.NET №3 (8), 2016 р

Автор: Скворцов Д., директор з розвитку ТОВ «Простоев.НЕТ».

Всі питання по темі управління активами, розробки довідників і техкартою задавайте мені, Оксані Ноздріну, на пошту: [email protected]

Практичні будь-які сучасні інформаційні системи мають на увазі, що для їх ефективного використання вся інформація, яка в них зберігається, повинна відповідати певним критеріям. Причому в області забезпечення якості інформації є також свої документи стандартизації, які описують вимоги до якості (див. ДСТУ ISO / ТС 8000).

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

Будь-який новий проект підготовки даних, необхідних для ERP / EAM систем, починається з нуля, тобто з розробки проектних рішень, необхідних для однакової підготовки стартових довідників. Очевидно, що таких проектів багато, вони не пов'язані між собою, правила і принципи формування структури даних абсолютно різні, і в результаті такого підходу ми отримуємо абсолютно різний опис, здавалося б, одного обладнання. Уникнути деякої кількості помилок в таких проектах дозволяє використання зовнішніх консультантів або реалізація проекту з використанням спеціалізованих інформаційних систем для підготовки даних.

Системи ведення майстер-даних (MDM (Master Data Management))

Проблема уніфікації довідкової інформації в якийсь предметної області не нова. В даний час вона вирішується з використанням різних рішень класу MDM (Master Data Management), тобто систем ведення майстер-даних. Щоб бути більш зрозумілою, відзначимо, що в нашій країні є більш стійкий термін - НДІ (нормативно-довідкова інформація). По суті, ці визначення (Master Data та НДІ) є синонімами.

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

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

Опис системи ведення майстер-даних для процесів управління технічним обслуговуванням і ремонтами Prostoev.NET-НДІ

Компанія «Простоев.НЕТ» узагальнила досвід реалізованих проектів в області підготовки даних для впровадження різних систем класу АСУ ТОіР і розробила власний додаток, що дозволяє істотно спростити роботи по створенню стартового масиву даних для їх запуску, а також налагодити процес підтримки поновлення майстер-даних.

Рішення Prostoev.NET-НДІ не вимагає установки на персональний комп'ютер або сервер замовника, так як надається у вигляді веб-сервісу.

Основними користувачами рішення Prostoev.NET-НДІ є:

• проектні групи з масового збору даних про обладнання для запуску систем АСУ ТОіР,
• фахівці відділів підтримки НДІ, в завдання яких входить розробка і підтримка уніфікованих майстер-даних для систем АСУ ТОіР,
• фахівці, в завдання яких входить розробка типових технологічних карт ремонтів і дефектні відомості для уніфікації даних, необхідних для планування ремонтів.

ДСТУ ISO / ТС 8000-1-2009

Існують принципи якості наступних даних:

a) якість даних, використовуваних для будь-якої мети і прийняття рішень;

b) якість даних, які є придатними і доречними в потрібному місці в потрібний час;

c) якість даних, що відповідають вимогам замовника;

d) якість даних, що запобігають можливі дефекти інформації шляхом вдосконалення обробки, щоб не допустити повторів і пропусків.

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

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

Наприклад, в застосовуваних зараз багатьма механіками відомостях дефектів можна побачити такий запис: «У зв'язку з протіканням сальника на валу насоса провести заміну сальникової набивки і ревізію переднього підшипника насоса». В принципі, все зрозуміло, але створення таких записів по великій номенклатурі устаткування - заняття досить трудомістке, і, найголовніше, швидко отримати статистику по найбільш частим дефектів в цьому випадку практично неможливо.

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

Як побудувати класифікатор обладнання, і навіщо він потрібен?

Класифікація обладнання дозволяє визначити єдині правила для опису об'єктів ТОіР і ведення всієї пов'язаної довідкової інформації.

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

До якого рівня потрібно описувати обладнання, і як це зробити швидко?

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

Як не заплутатися в різноманітті різного устаткування і його параметрах?

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

Як очистити історичні дані?

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

Найбільш типові проблеми, які можна вирішити з використанням функцій програми:

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

Як розробити нормативи на трудомісткість робіт?

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

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

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

Самі значення трудомісткості, кількості персоналу та його кваліфікації, необхідної для виконання операції, визначаються конкретними характеристиками моделі обладнання. Таким чином, ми можемо сформувати єдиний норматив на операції ТОіР будь-якої кількості моделей. Для виключення випадкових помилок в оцінці значень в системі передбачений автоматичний розрахунок середніх показників на кожну операцію. Навіть якщо окремі механіки «переоцінять» трудомісткість окремих операцій, система видасть попередження розробнику нормативів, що дані значення істотно відхиляються від середніх значень. Ця унікальна функція працює завдяки тому, що нормативи зберігаються на весь модельний ряд схожого за конструкцією обладнання.

Як розробити нормативи на ТМЦ?

Якщо відкрити старі документи, що дісталися нам з радянської системи ППР, там можна знайти дані про рекомендованих нормах витрати типової номенклатури запчастин і матеріалів для ремонту певних видів обладнання.

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

Як бути, якщо даних немає?

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

Для якихось операцій в якості таких параметрів можна використовувати масу вузла, для інших - технологічні характеристики обладнання. Найбільш затребувана кнопка у деяких клієнтів - «заповнити всі середніми значеннями», яка дозволяє масово проставити параметри для планування ТОіР схожого за конструкцією обладнання з урахуванням його характеристик. Наприклад, ви можете «розробити» таким чином нормативи на всі електродвигуни, знаючи тільки потужність, частоту приводу і виконання. А двигунів навіть на середньому підприємстві може бути тисяча і більше.

З якими системами сумісно рішення Prostoev.NET-НДІ?

Архітектура рішення дозволяє завантажувати і обробляти історичні дані практично з будь-яких сучасних ERP / EAM систем, а також вивантажувати нормалізовані таблиці в будь-системи. В даний час є досвід підготовки даних для систем Oracle ЕAM, SAP PM, «1С: ТОіР». Налаштування Prostoev.NET-НДІ для інших систем полягає в узгодженні формату вивантаження даних. Основні сутності, необхідні для опису предметної області ТОіР вже є в нашій системі майстер-даних.

Скільки коштує система?

Вартість нашого рішення складається з декількох складових:

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

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

Що робити, якщо часу на підготовку даних у нас зовсім немає?

Дуже часто наші замовники «забувають» про необхідність підготовки стартових даних до запуску своїх інформаційних систем для управління процесами ТОіР. Так вийшло, що останні кілька років нас часто просять зробити неможливе і зібрати дані за 2-3-4 місяці до промислового запуску. Це, звичайно, екстремальні проекти, але наявність налагодженої методології збору, унікальне програмне рішення акселерації обробки даних і досвід залучення великої кількості ресурсів дозволяє нам виконувати і такі проекти. Але ми рекомендуємо планувати заздалегідь і також з радістю надамо послугу «збір даних під ключ».

Для доступу до оригіналів усіх статей отримання дозволу на використання журнал Prostoev.NET .