Документація – вступна сторінка
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 продукту
Ризик
Ризики служать для обліку загроз і можливостей, які можуть переломити хід проекту або загальну подію. Метою реєстрації ризиків є взяття їх під контроль.
Загрози (ризики) та можливості
Під ризиком, як правило, мається на увазі все, що може несподівано втрутитися в хід, будь то вплив негативний або позитивний. У звичайній практиці працюють тільки з негативними ризиками – загрозами, тому поняття ризику використовується в значенні загроз. Але ризики в AyMINE дозволяють в цілому відслідковувати і можливості.
#Хто і коли стежить за ризиками
За ризиками найчастіше стежить керівник проекту. Всі методології (з PMBOK і Prince2 на чолі) управління проектами вимагають цього, але не тільки вони. За ризиками повинен стежити кожен у своїй роботі. Таким чином, обов'язок відстежувати ризики та можливості є частиною стандартів у всіх сферах – ISO 9001, ISO 20000, ... CMMI і т. д. Причина в тому, що якщо ніхто не стежить за ризиками, то вони заскочать непідготовлену команду, яка не зможе реагувати. Навпаки, якщо ризик передбачуваний, то можна підготуватися.
Навіщо записувати ризики
Записання ризику саме по собі не зменшує ризик, але все ж це суттєво допоможе, особливо в діяльності, в якій беруть участь більше людей:
- Запис полегшує обговорення, і в команді можна знайти рішення для його запобігання
- Якщо ризик не зареєстрований, легко забути про необхідність його охороняти. Обережних членів команди може лякати, сміливі кидають її за голову; жоден підхід не є оптимальним. Оптимальним є спостереження, якщо він наближається і як з ним протистояти.
- Можна відслідковувати поточний стан
- Можна оцінити, наскільки великі кошти виділяються на запобігання
Опис ризику
Крім очевидних ідентифікаторів та описів, документація ризику містить важливі поля, специфічні для ризиків:
Ймовірність
Ймовірністю ми оцінюємо, наскільки велика ймовірність того, що ризик не відбудеться. Ризикам з малою ймовірністю є причина не стільки приділяти увагу, скільки тим, хто має велику. Таким чином, оцінка ймовірності служить для оцінки того, скільки пеші потрібно присвячувати ризику.
Оцінка ймовірності служить для класифікації значущості ризику. Словесний опис є добровільним і має сенс, особливо якщо ризик обговорюється в команді або якщо цього вимагає внутрішня методологія.
Оцінка ймовірності виражається в термінах, що дозволяють кількісно визначити ймовірність логічним міркуванням. Якщо ймовірність не може бути оцінена, то береться середнє значення 50:50.
Загроза
Загроза описує, які ризики можуть виникнути, якщо вони виникають. Якщо загроза ризику невелика, немає ніяких підстав для цього. Хороше знання того, що може викликати, є ключовим для підготовки до ризику. При цьому він є основним інструментом для запобігання ризикам. Не можна запобігти ризику, але можна подбати про те, щоб не завдати значної шкоди.
Оцінка загрози, як і у випадку ймовірності, служить для класифікації ризику.
Оцінка важливості загрози в значній мірі часто є рекомендованою оцінкою 0..5. Але абстрактні числові значення люди в командах зазвичай пояснюють кожен по-своєму (за своїм характером і ставленням до проекту), і тому доцільніше використовувати критерії з чіткою підказкою. Вони викладені тут методологією – поза бізнесом їх слід розуміти за аналогією до прикладної моделі.
Розпізнавання ризику
Важливим інструментом усунення ризиків є уміння вчасно знати, що вони відбуваються, або значно збільшується вірогідність того, що вони можуть виникнути. Тому важливо мати інструменти, щоб вміти контролювати ризики. (Загальними інструментами є, як правило, непопулярний аналіз і статистика, що відстежує тенденції.) Полу дозволяє відзначити, що потрібно робити, щоб вчасно розпізнати ризик.
Методи розпізнавання не були б ефективними, якби їх не використовували. Більшість методологій якості прописують, як часто потрібно відслідковувати, і цю інформацію можна зберігати тут.
Поріг ризику є симптомом, коли ризик вважається таким високим, що необхідно активно переживати його втручання. Поріг, при якому команди і компанії ризикують, залежить від різних факторів, наприклад, загальної економічної стабільності фірми, характеру менеджера і т.д. і тому проект може змінюватися з року в рік.
Як використовується поріг ризику
З порогом ризику (0 .. 30) порівнюється з рейтингом ризику.
Рейтинг ризику це добуток ймовірності (0..5) та впливу (0..5) ризику. Це значення (0 .. 25) оцінюється з порогом на основі критеріїв:
- 0 = немає ризику (не може виникнути або нічого не викликає)
- 1 ... 4: Незначний ризик
- 5 ... 9: малий ризик
- 10 ... 14: значний ризик
- 15 ... 24: Дуже високий ризик
- 25 = Критичний ризик (Майже напевно настане і матиме істотні наслідки).
Якщо не заповнюється будь-яке значення ймовірності або впливу, ризик вважається об'єктивним, а його рейтинг має найвище значення 30. Таким чином, у порівнянні ризики, які не мають аналізу ймовірності або загрози, виходять як найбільш ризикові.
Частота оцінки
Ризики необхідно періодично оцінювати, чи вони є актуальними. В рамках оцінки необхідно враховувати:
** Чи однакова ймовірність того, що ризик виникне?
Чи не змінився прогнозований вплив?
Якщо ви скорегуєте ризик, він автоматично вважатиметься переглянутим. Якщо ви оцінили ризик як постійно поточний, за допомогою функції Переглянуто перевірку ви підтвердите.
Поле Частота оцінки доцільно залишати порожнім, якщо немає спеціальних причин для заповнення. Якщо значення не заповнюється, частота оцінки визначається рейтингом ризику:
- для рейтингу <20 перевірка планується через 2 тижні
- для рейтингу <25 це 1 тиждень
- для вищого рейтингу 1 день
Якщо значення заповнюється, термін наступної оцінки завжди залежить від зазначеного терміну з моменту останньої коригування ризику.
Типові ризики
Ризик у AyMINE вимагає досить докладного опису – недостатньо його найменування, оскільки тоді очевидно, що ризик не був досліджений. Ризики при цьому часто повторюються в подібних проектах, вони в основному відрізняються ступенем впливу або ймовірністю того, що вони виникнуть. Для того, щоб не створювати ризики знову, організація повинна створити каталог ризиків (у формі методології), де вона зберігає стандартні ризики, і вибрати ті, що мають відношення в проекті або іншій діяльності. Тоді ризик заповнюється на основі зразка автоматично.
Зразкові ризики є частиною методологій і можуть управлятися людьми, які мають право коригувати методології. (Право на роботу з методологіями може бути недоступним для вашої компанії або команди.)