Документація – вступна сторінка
AyMINE – Technical doc. (in English)
abra
crm
- Модуль Контакти та адресної книги
- Системні права та налаштування CRM-модуля
- Огляд замовлень клієнтів
- Довідник
- Список і управління каталогами
- Політика конфіденційності та ділової інформації
- Надсилайте масові повідомлення відповідно до GDPR
- Патік масової електронної пошти
- Вихід і встановлення преференцій
для масової - Як коректно забути дані про людину
- Масові повідомлення електронної пошти
- Контракти, договори
- Партнер за контрактом
- Групи клієнтів
- Каталог або люди і компанії
- Контакти
- Швидко доступні контакти
sabre
hr
- Модуль персоналізації
- Цифровий кадровий архів
- Персоналізація – права користувача
- Облік кандидатів на роботу
- Посада
- Член команди – Працівник
- Огляд працівника
- Огляд власного персоналу
- Відповідальний персоналіст
- Синхронізація працівників та користувачів системи
- Трудовий договір
- modulesafety
- personalfolder
sys
- Системний модуль фреймворку AyMINE
- Клієнт
- Настроювання шлюзів для зовнішніх повідомлень
- Повідомлення із зовнішнім світом
- Правила для зовнішніх повідомлень
- Документи
- Додаткові функції з файлами
- Копіювання та переміщення файлів між об'єктами
- Презентація зображення
- Публічне посилання на документ
- Останні файли
- Дошка
- Розташування об'єкта на дошці оголошень
- Елементи клієнта
- Огляд і коментарі
- Безпека повідомлень і внутрішніх дискусій
- Переклади
- Зв'язки між об'єктами
- Типи сесій (відносин)
- Ролі та команди груп
- Користувач системи
- Адміністрація користувача
- GDPR та користувачі системи
- Безпечний вхід
- Адміністрація користувача
- Криптогаманець
- moduleclientoptions
frm
- introhelp
- introhelp_objectdetail
- AyMINE Framework
- Політика зберігання паролів
- Права користувача framework
- Модулі AyMINE
- Замки користувача
- Системні дозволи
- introhelp_deleting
- introhelp_settings
- introhelp_objectlist
- introhelp_dashboard
- introhelp_generalinfo
- introhelp_icons_dnadrhal9000_mar-22-220246-2023_caseconflict
- introhelp_icons
- Записи AyMINE
tsk
- 8D report
- Основним елементом FMEA
- FMEA
- FMEA - ймовірність виявлення
- Процес аналізу FMEA
- FMEA - ймовірність виникнення
- FMEA - оцінка тяжкості
- Модуль керування завданнями та інформаці
- Адміністрація модуля Управління завданнями
- Системні права модуля керування завданнями
- Події
- Акції, події та наради
- Персональний календар
- Журнал активності
- Згода керівника
- Чому не можна видалити деякі дані
- Область
- Область / проект / методологія
- Огляд областей
- Шаблони міток
- Управління тегами
- Мої області
- Подія
- Архівний пакет
- Кваліфікація, здібності / вміння
- Рівні компетентності та кваліфікації
- Необхідні здібності
- GDPR та облік кваліфікацій
- Право на управління кваліфікацією користувачів
- Кваліфікація користувача або контакту
- Команда проекту
- Рішення
- Об'єкти, які приймаються рішення
- Варіант прийняття рішень
- Шаблон плану / стратегії
- Визначення проекту
- Зразок запису
- Зразок ризику
- Визначення пакета
- шаблон завдання
- Активація події із завдання
- Управління відповідальністю – RACI matice
- Повідомлення про події
- Об'єкти, що відносяться до шаблонного завдання
- Події, що починаються
- Призначення нового завдання
- Обговорення
- Бізнес-подія
- Кнопки для активації події
- Події подій
- Покращення та запобіжні заходи
- Інформація
- Ключове слово
- Проведення наради
- Методики та правила
- Обов'язок
- Поняття
- Директиви та політики
- Управління змінами в проекті
- Проблеми, тікети та їх управління
- Центр обслуговування клієнтів
- Внутрішня довідка
- Об'єкти, яких стосується проблема
- Управління інцидентами, невідповідність якості
- Проект
- Графік проекту
- Команда проекту або команда до робочого процесу
- RACI-матриця для project
- Повернути план проекту за baseline
- Записи та журнали
- Записані дії
- Вимоги
- Вимоги до вступників
- Ризик
- Завдання
- Терміни викликів
- Огляд завдань
- Вплив завдання на право змінювати підключений obje
- Особисте завдання
- Член команди
- Об'єкти, які обробляються в задачі або вирішуються
- Завдання працівника
- Тест
- Типи тестів
- Попередження
- Попередження – приклад використання
- Попередження для себе
- tsktask_kanban
- moduleclientoptions
am
- amasset
- Модуль управління активами
- Процедура відбору та закупівлі
- Аналітична модель
- Постачальник продукту
- Категорія продуктів
- Властивість продукту або продукту
- Мета проекту
- Комерційна пропозиція
- Перерахувати пропозицію та замовлення
- Права доступу до пропозицій і цін
- Системний запит про стан замовлення
- Продукти та товари
- Стан продукту та його зміна
- Одиниці продуктів
- Критерії якості
- Про критерії якості продукції
- HARA продукту
GDPR та користувачі системи
Система повністю підтримує дотримання GDPR. Але його виконання залежить і від правильного використання.
- GDPR та видалення облікових записів користувачів
- приклад: чому інформація про минулих працівників важлива
- Працівники, які припинили трудові відносини та GDPR
- Анонімізація - забуття
GDPR та видалення облікових записів користувачів
Система технічно підтримує видалення облікових записів користувачів, але в ряді випадків це неможливо. Перед видаленням необхідно переконатися, що користувач не несе відповідальності за проекти та області, оскільки вони не повинні залишатися без користувача.
приклад: чому інформація про минулих працівників важлива
Працівнику було доручено перевірити правильність розрахунку вантажопідйомності мосту. Пізніше він пішов з роботи, але для вашої компанії залишається необхідним знайти не тільки того, хто робив розрахунок, але і те, яка у нього кваліфікація та сертифікація.
У документації мосту є протоколи, в яких, ймовірно, вказані імена людей, які проводили перевірки. Але у випадку аудиту чи проблем недостатньо прізвища, необхідно також відшукати іспити та сертифікати, що підтверджують його кваліфікацію. Вони можуть знадобитися і через багато років.
Ще складніша ситуація виникає, коли з'ясовується, що працівник не виконував роботу як слід, а то й обманював. Потім потрібно ще й ретроспективно подивитися, які роботи були під його відповідальністю, і їх треба переглянути. Без інформаційної системи та збережених зв'язків із завданнями це було б майже неможливим завданням, яке потребує зворотного перегляду проектних архівів за багато років. Завдяки зв'язкам в системі ви отримаєте необхідну інформацію буквально в кілька кліків.
Працівники, які припинили трудові відносини та GDPR
Працівник, який пішов, на підставі GDPR законодавства може вимагати, щоб його забули. На практиці неможливо повністю забути працівника, оскільки є законні підстави (наприклад, документація про заробітну плату), а також законні потреби компанії (наприклад, описаний вище приклад), які вимагають, щоб інформація зберігалася. Тим не менш, компанія зобов'язана стежити за тим, щоб користувач був "забутий" там, де законні підстави або законні інтереси неможливо застосувати.
Приклад: Працівник пішов з компанії і вимагає, щоб його забули. Підприємство повинне стежити за тим, щоб інфорації про нього не були доступні в компанії понад законних обов'язків і законних інтересів. Крім людей з доступом до архіву відділу кадрів, інформацію про минулу роботу люди повинні отримувати тільки тоді, коли це необхідно - наприклад, під час аудитів і перевірок роботи, розслідування проблем або навіть злочинності.
У AyMINE забуті акаунти користувачів мають особливий статус. Ім'я користувача змінено, а реальну особу можна отримати лише шляхом, який потребує спеціальних дозволів. Таким чином, можна з'ясувати, хто виконував завдання, рішення чи іншу діяльність, але інформацію отримують лише працівники, які мають для цього підстави.
Скасування облікового запису видаляє особисту інформацію
Скасування облікового запису призведе до видалення всієї особистої інформації, створеної користувачем у системі:
- Нетипові примітки до об'єктів
- Персональні знаки на об'єктах
- Особисті кишені з предметами
Однак, скасування облікового запису не видаляє особисті дані – ім'я та електронну пошту.
Анонімізація - забуття
Виконати вимоги GDPR можна і за допомогою анонімізації. Анонімізувати можна тільки скасовані рахунки.
Анонімізація гарантує, що працівники, які працюють з системою, не зможуть дізнатися, що колишній користувач, чий аккаунт був анонімізований, мав обліковий запис у системі. Рахунок буде представлений з анонімним ім'ям.
Однак для забезпечення законного обов'язку в анонімному акаунті зберігається в історії запис, як працівник фактично назвався. У разі вимоги щодо історичної ідентифікації працівника цю інформацію можна відстежити. Водночас персональні дані працівника більше не можуть стати предметом масової обробки даних, автоматизованої профілізації або доступними для користувачів, крім цільового пошуку конкретних даних для криміналістичних причин.
Анонімізація не видаляє ім'я користувача з історичних записів, які вказують у звітах про діяльність, хто виконав дану операцію. Цей запис, еквівалентний підпису працівника на внутрішньому документі, не порушує принципів GDPR. Вона не може бути предметом подальшого опрацювання.
Анонімізація повністю відповідає вимогам GDPR. Він не повинен відповідати внутрішнім правилам організації, і перед його виконанням адміністратор повинен переконатися, що він виконаний відповідно до внутрішніх методик і правил.