Документація – вступна сторінка
AyMINE – Technical doc. (in English)
Модулі
Інтеграція з ERP Abra Gen
Модуль керування завданнями та інформацією
Кваліфікація, здібності / вміння
Кваліфікація користувача або контакту
Рівні компетентності та кваліфікації
Право на управління кваліфікацією користувачів
Попередження – приклад використання
Покращення та запобіжні заходи
Вплив завдання на право змінювати підключений object
Об'єкти, які обробляються в задачі або вирішуються в проблемі
Працівник, відповідальний за завдання
Область / проект / методологія
Проблеми, тікети та їх управління
8D report – системна підтримка
Управління інцидентами, невідповідність якості
Об'єкти, яких стосується проблема
Команда проекту або команда до робочого процесу
Повернути план проекту за baseline
Чому не можна видалити деякі дані
Об'єкти, які приймаються рішення
Аналіз невдач для окремої властивості компонента або процесу
Модуль керування завданнями та інформацією
Адміністрація модуля Управління завданнями
Системні права модуля керування завданнями
Управління відповідальністю – RACI matice
Об'єкти, що відносяться до шаблонного завдання
Модуль Контакти та адресної книги (CRM)
Політика конфіденційності та ділової інформації
Список і управління каталогами
Надсилайте масові повідомлення відповідно до GDPR
Масові повідомлення електронної пошти
Вихід і встановлення преференцій
для масової пошти
Патік масової електронної пошти
Як коректно забути дані про людину
Модуль Контакти та адресної книги (CRM)
Системні права та налаштування CRM-модуля
Управління та автоматизація сайту
Користувацька документація AyMINE
Управління та автоматизація сайту
Модуль персоналізації
Персоналізація – права користувача
Синхронізація працівників та користувачів системи
Модуль управління активами
Перерахувати пропозицію та замовлення
Права доступу до пропозицій і цін
Властивість продукту або продукту
Процедура відбору та закупівлі
Управління фінансами
Метрики та вимірювання
Технічні модулі
Модуль Сейбр
Модуль Enterprise Architect роз'єм (eacon)
Модуль Enterprise Architect роз'єм (eacon)
Посилання до бази даних Enterprise Architect
Системні модулі
Framework – системна основа
Nastavte si, jak váš systém vypadá a funguje
Системний модуль фреймворку AyMINE
Повідомлення із зовнішнім світом
Правила для зовнішніх повідомлень
Розташування об'єкта на дошці оголошень
Копіювання та переміщення файлів між об'єктами
Публічне посилання на документ
Безпека повідомлень і внутрішніх дискусій
Системний модуль фреймворку AyMINE
Настроювання шлюзів для зовнішніх повідомлень
Призначення нового завдання
Виділення завдання відповідно до методології означає чітко визначити, хто за що відповідає, коли робити роботу і як. Автоматизуючи завдання, можна заощадити багато роботи, але найголовніше - дуже допомогти ефективній роботі та співпраці.
[placeContent]
Виділення завдання є діяльністю само собою зрозумілою для кожної команди. Але також це перший і один з найважливіших моментів, коли вирішується, чи дотримується команда робочих процедур, чи ні. Принципова різниця полягає в тому, чи ви призначаєте завдання в основному без вказівки "якось зроби це", або завдання включає в себе всі вірні частини:
- Відповідальність відповідно до RACI матриці
- Терміни
- Робочий процес
Порядок перевірки (checklist) - Чітке посилання на те, з чим потрібно працювати (документи, продукти, клієнти тощо)
Само собою зрозуміло, що вручну задавати всі завдання з усім, що має до цього належати, непросто. Тому закупівлю варто автоматизувати - звичайно, там, де це має сенс. Системи управління якістю повинні включати в робочі процедури все, що входить в правильне завдання, і тому AyMINE автоматизує завдання, пов'язуючи їх з описом в методології (SMJ) - SMJ стає основою для всієї автоматизації процедур.
Коли система створює нове завдання з робочого процесу (зразок завдання), вона призначає правильних працівників відповідно до RACI - матриця відповідальності. Спосіб розподілу залежить від того, чи йдеться про завдання до проекту, чи ні.
команди проекту
Призначення завдання членуУ проекті завдання зазвичай не виникають автоматично, а створюються керівником проекту в рамках планування і розподілу робіт. Правильно вони повинні формуватися на основі зразкового плану проекту. Окремі кроки у зразковому плані проекту є одночасно робочими процедурами проектної методології.
Для проектного завдання кожне завдання має визначену проектну відповідальність - RACI матрицю проектних ролей. При створенні завдання на виконання завдання працівники призначаються відповідно до їх ролей. (Якщо в якійсь ролі буде більше людей, завдання отримає керівник команди, яка може його делегувати).
Якщо в проекті немає працівника з потрібною роллю, він отримує завдання на керівника проекту. Після виконання ролі правильним працівником завдання може бути передане йому. Але ми рекомендуємо завжди займати всі обов'язкові проектні ролі працівниками до планування за типовим планом проекту.
Примітка Для команд проекту не використовуються налаштування відповідальної ролі.
Призначення завдання для компанії
Завдання, особливо коли воно виникає автоматично, має бути призначене тим, хто повинен його отримати на обробку. Тому для завдання є відповідальна роль, на яку покладено завдання.
Як відбувається виділення?
Якщо на роль призначено лише 1 працівника, то завдання покладається на нього.
- Якщо роль виконує кілька людей:
- Мо-я роль керівника, отримує завдання керівника
- Не маючи-я роль керівника, отримує завдання перше в групі
Якщо роль не встановлена, або якщо ніхто не призначений, завдання не створюється!
Примітка Для завдань у бізнес-сфері кваліфікація для проектних ролей ще не використовується. Завдання в бізнес-зону відводиться тільки одній людині, команда для нього не формується.