Документація – вступна сторінка
AyMINE – Technical doc. (in English)
Модулі
Модуль керування завданнями та інформацією
Кваліфікація, здібності / вміння
Кваліфікація користувача або контакту
Рівні компетентності та кваліфікації
Право на управління кваліфікацією користувачів
Вплив завдання на право змінювати підключений object
Об'єкти, які обробляються в задачі або вирішуються в проблемі
Працівник, відповідальний за завдання
Область / проект / методологія
8D report – системна підтримка
Об'єкти, яких стосується проблема
Повернути план проекту за baseline
Чому не можна видалити деякі дані
Об'єкти, які приймаються рішення
Модуль керування завданнями та інформацією
Адміністрація модуля Управління завданнями
Системні права модуля керування завданнями
Об'єкти, що відносяться до шаблонного завдання
Модуль Контакти та адресної книги (CRM)
Політика конфіденційності та ділової інформації
Список і управління каталогами
Надсилайте масові повідомлення відповідно до GDPR
Масові повідомлення електронної пошти
Вихід і встановлення преференцій
для масової пошти
Патік масової електронної пошти
Як коректно забути дані про людину
Модуль Контакти та адресної книги (CRM)
Системні права та налаштування CRM-модуля
Управління та автоматизація сайту
Користувацька документація AyMINE
Управління та автоматизація сайту
Модуль персоналізації
Персоналізація – права користувача
Синхронізація працівників та користувачів системи
Модуль управління активами
Перерахувати пропозицію та замовлення
Права доступу до пропозицій і цін
Властивість продукту або продукту
Процедура відбору та закупівлі
Управління фінансами
Метрики та вимірювання
Технічні модулі
Модуль Сейбр
Модуль Enterprise Architect роз'єм (eacon)
Модуль Enterprise Architect роз'єм (eacon)
Посилання до бази даних Enterprise Architect
Системні модулі
Framework – системна основа
Nastavte si, jak váš systém vypadá a funguje
Системний модуль фреймворку AyMINE
Розташування об'єкта на дошці оголошень
Копіювання та переміщення файлів між об'єктами
Публічне посилання на документ
Безпека повідомлень і внутрішніх дискусій
Обов'язок
Зобов'язання виражає, загалом, будь-яку зовнішню настанову, яка визначає, що має робити або не повинна робити компанія.
Типовими прикладами обов'язків є:
- Закони – наприклад, GDPR, Трудовий кодекс
*Стандарти, наприклад, ISO 26262, ISO 27000
нормативно-правових актів, наприклад, нормативно-правових актів - Галузеві стандарти
- Суспільний договір з профспілками
- Засновницькі документи компанії
- Рішення загальних зборів
- Рішення власника – типово корпоративні стандарти
Загальними ознаками обов'язків є те, що:
** Вони подаються ззовні.
- Внутрішньо суспільство приймає їх, але безпосередньо на них не впливає.
- Їхніми розпорядженнями повинні керуватися всі внутрішні директиви, правила та процедури.
Обов'язки як частина методології
Обов'язки в прямому сенсі не є частиною внутрішньої системи якості. Внутрішня система повинна формуватися з політик і директив, які перетворюють обов'язки у внутрішню практику.
AyMINE має обов'язки, які проводяться як частина методології; система якості є найбільш поширеним випадком, а також прикладом методології. Основною причиною включення обов'язків до методологій є те, що в основному обов'язки перекладаються саме в рамках однієї методології, і важливо знати, які обов'язки "покриває" система.
AyMINE підтримує більше методологій
У AyMINE ви можете мати більше методологій, і може виникнути ситуація, коли один і той же обов'язок враховується в декількох методиках. Ніколи не ставте себе в систему зобов'язання неодноразово, AyMINE дозволяє краще рішення. В принципі, рішення два – або окрема методологія, або включення в деякі з існуючих.
Створювати самостійну методологію тільки за обов'язком
Якщо обов’язків, спільних між методологіями, більше, то найбільш доцільним рішенням є виділення їх з методології в окрему область – методології з обов’язками.
Обов'язки не відображатимуться на робочому столі методологій, але додатково можна встановлювати зв'язки між директивами та обов'язками. Не показуючи ніяких обов'язків у методиці, на перший погляд буде видно, що вони знаходяться в іншому місці.
Покласти обов'язок в методології, яка є рішенням найбільш
Якщо розв'язується ситуація, коли обов'язок, в принципі, проектується однією методологією, але десь враховується, наприклад, директивою з іншої методології, обов'язок може бути викладений далі в рамках методології, яка в першу чергу нею займається.
Директиви можуть бути пов'язані з зобов'язаннями за будь-якою методологією, тому немає жодних проблем, щоб використати також обов'язки з інших методологій.