top of page

Психологічна енкциклопедія

Модель SHELL: як аналізувати взаємодію людини з програмами, обладнанням, середовищем і людьми

7 жовт.
Читати 17 хв

Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика


Модель SHELL — це концептуальна модель людських факторів, яка допомагає системно розбирати, як людина взаємодіє з процедурами й програмами, фізичним обладнанням, робочим середовищем та іншими людьми. Її головна одиниця аналізу — не «помилкова людина», а якість стику між людиною та іншими елементами системи. Саме на цих стиках виникають непорозуміння, перевантаження, прихована неоднозначність, невдалий зворотний зв’язок, координаційні провали та інші умови, здатні погіршувати виконання й безпеку.


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


SHELL має високий практичний статус у галузі безпеки, особливо в авіації. У керівництві FAA з управління ризиками безпеки 2024 року модель прямо включено до інструментів системного аналізу: FAA наголошує, що відповідність або невідповідність між блоками моделі — тобто інтерфейс — настільки ж важлива, як і властивості самих блоків. Водночас SHELL не є психометричним тестом, універсальною теорією поведінки чи самодостатнім методом кількісного прогнозування аварій. Це якісна аналітична рамка, яка вказує, де і як шукати проблеми взаємодії.


Що таке модель SHELL


SHELL організовує аналіз навколо центрального людського елемента. Навколо нього розміщують чотири типи взаємодії: із Software, Hardware, Environment та іншим Liveware. Звідси п’ять літер назви: S–H–E–L–L. Центральний L позначає людину, діяльність якої аналізують; другий L — інших людей, з якими вона взаємодіє.


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


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


Походження: від SHEL до SHELL


Історично вихідною була модель SHEL, запропонована Елвіном Едвардсом 1972 року. FAA у матеріалі з історії людських факторів називає її ранньою моделлю, що структурувала взаємодію пілотів і техніків із системами повітряного судна, органами керування та операційним середовищем. Пізніше Френк Гокінс розвинув подання моделі у відому форму SHELL, чіткіше виділивши взаємодію людини з іншими людьми.


Історія важлива з двох причин. По-перше, модель народилася в безпеково критичному контексті, де помилка рідко пояснюється однією причиною. По-друге, терміни моделі відбивають мову своєї епохи. Слово Software у SHELL історично означає значно більше, ніж комп’ютерний код, а Liveware — технічний ярлик для людського елемента, який сьогодні доречніше пояснювати просто як «людина».


Що означають літери SHELL


S — Software: процедури, правила, інформація і програмна логіка


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


У цифрових системах до S природно входять також програмна логіка, екранні правила, повідомлення, назви команд, послідовності діалогів, права доступу та інші нематеріальні механізми, які визначають, що система дозволяє, вимагає або повідомляє користувачеві. Проте SHELL не встановлює жорсткої онтологічної межі між «програмою» і «обладнанням»: аналітик сам задає корисну межу системи. Наприклад, логіку підтвердження небезпечної команди можна віднести до Software, а фізичний пульт і розташування клавіш — до Hardware.


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


H — Hardware: обладнання, органи керування і фізичний інтерфейс


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


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


Ця частина SHELL перетинається з ширшою людино-машинною взаємодією: оператор має не просто «користуватися обладнанням», а сприймати його стан, розуміти активний режим, виконувати керувальні дії та бачити їхній результат.


E — Environment: фізичне й операційне середовище


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


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


Проблема L–E виникає, коли середовище змінює здатність людини бачити, чути, рухатися, концентруватися, підтримувати темп або безпечно завершувати завдання. Яскраві відблиски можуть зробити дисплей нечитабельним; шум — маскувати звуковий сигнал; тісний простір — ускладнювати доступ до органу керування; переривання — руйнувати послідовність дії.


L — Liveware: центральна людина


Центральний Liveware — це людина, чия взаємодія з системою є фокусом аналізу: оператор, водій, пілот, технік, диспетчер, клініцист, користувач програмної системи, інженер або інша роль. Людина має знання, навички, досвід, очікування, обмеження уваги й пам’яті, сенсорні та моторні можливості, поточний рівень втоми, мотивацію, стрес і здатність адаптуватися.


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


Другий L — інші люди


Другий Liveware позначає інших людей, від яких залежить виконання: членів команди, керівників, суміжні зміни, диспетчерів, техніків, лікарів і медсестер, пасажирів, клієнтів, користувачів, підрядників та інших учасників. Інтерфейс L–L охоплює комунікацію, координацію, розподіл ролей, передавання зміни, взаємний контроль, лідерство, командні норми та спільне розуміння ситуації.


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


Чотири головні інтерфейси SHELL


Практична сила SHELL з’являється, коли аналіз переходить від назв блоків до інтерфейсів. Саме «стик» описує механізм, через який системна умова впливає на дію.


  • L–S — людина ↔ процедури, правила, документація, символіка, програмна логіка та інформаційні сценарії.

  • L–H — людина ↔ фізичне обладнання, органи керування, дисплеї, інструменти й матеріальна конфігурація робочого місця.

  • L–E — людина ↔ фізичне та операційне середовище, у якому виконується завдання.

  • L–L — людина ↔ інші люди: комунікація, координація, передавання інформації, командна робота й взаємний контроль.


У FAA Safety Risk Management Guidance прямо підкреслено, що збіг або незбіг блоків є так само важливим, як характеристики самих компонентів. Це принципово: перелік «погана процедура, складне обладнання, шум, втомлений оператор» ще не є системним аналізом. Потрібно показати, як саме кожний фактор змінював можливості сприйняття, рішення, виконання, контролю або відновлення.


SHELL і ситуаційна обізнаність


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


L–S може створити неправильне очікування через двозначну процедуру або назву режиму. L–H може приховати стан через слабку видимість індикатора. L–E може маскувати сигнал шумом або відблиском. L–L може передати неповну картину під час зміни персоналу. У цьому сенсі SHELL допомагає перейти від загальної фрази «оператор не усвідомлював ситуацію» до конкретних умов, які зробили правильне розуміння менш імовірним.


Як проводити аналіз за моделлю SHELL


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


Крок 1. Визначити центральну роль і конкретне завдання


Почніть не з абстрактного «працівника» або «користувача», а з конкретної ролі в конкретному сценарії: диспетчер приймає передачу сектора; технік виконує діагностику; оператор реагує на аварійний сигнал; користувач змінює небезпечний параметр у програмі. Одна й та сама система може мати різні SHELL-карти для різних ролей.


Крок 2. Відновити фактичний перебіг подій


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


Крок 3. Описати S, H, E та L у межах сценарію


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


Крок 4. Перевірити чотири інтерфейси


Для L–S запитайте, чи відповідали інструкції фактичній системі, чи були правила зрозумілими та здійсненними, чи збігалися терміни й логіка. Для L–H — чи були органи керування й відображення стану розрізнюваними, доступними та передбачуваними. Для L–E — які умови могли змінювати сприйняття або виконання. Для L–L — як передавалися інформація, відповідальність і контроль.


Крок 5. Сформулювати невідповідність як механізм


Корисний запис має форму «умова → зміна взаємодії → наслідок». Наприклад: «дві сусідні кнопки однакового розміру без захисного розведення → дія на дотик погано розрізнюється → зростає ризик активації сусідньої функції». Або: «процедура використовує стару назву режиму → оператор шукає її в новому інтерфейсі → збільшується час і ймовірність вибору функціонально схожого режиму». Такий опис сильніший за ярлики «неуважність» або «порушення процедури».


Крок 6. Перевірити, що лежить за межами SHELL


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


Крок 7. Перетворити знахідки на зміни системи


Коригувальна дія має відповідати механізму. Якщо проблема в L–H, навчання не виправить нерозрізнювані органи керування так надійно, як редизайн. Якщо проблема в L–S, додаткове нагадування не замінює узгодження процедури з реальною логікою системи. Якщо проблема в L–L, варто змінювати структуру передачі інформації, точки підтвердження й розподіл відповідальності. Після зміни потрібна перевірка: тестування, симуляція, спостереження, повторний аналіз даних або інший метод, відповідний ризику.


Приклад: аварійний сигнал у автоматизованій системі


Уявімо операторську систему, де під час зміни з’являється важливий сигнал про перегрів вузла. Оператор бачить кодове повідомлення, відкриває інструкцію, переходить у потрібний режим, але затримує правильну дію. Просте пояснення звучало б як «оператор відреагував повільно». SHELL розкладає ситуацію інакше.


  • L–S: повідомлення містить технічний код, а процедура використовує іншу назву; потрібний крок захований у довгій інструкції; опис не враховує нову версію програмного інтерфейсу.

  • L–H: індикатор критичного стану візуально схожий на менш важливі повідомлення; фізичний перемикач ручного режиму розташований поруч із функціонально іншою командою.

  • L–E: у приміщенні високий фоновий шум, тому звукове попередження слабко виділяється; відблиск знижує контраст дисплея.

  • L–L: попередня зміна знала про нестабільний датчик, але ця інформація не потрапила до структурованого передавання зміни.


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


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


Як застосовувати SHELL до програм і UX


Хоча модель виникла в авіації, її логіка добре переноситься на програмно-апаратні системи. Важливо лише не звужувати S до самого коду. Користувач взаємодіє одночасно з програмною логікою, правилами організації, фізичним пристроєм, контекстом і людьми.


Наприклад, адміністратор у вебсистемі змінює критичний параметр. До L–S належать назва параметра, пояснення наслідків, права доступу, логіка підтвердження, документація й процедура схвалення. До L–H — екран, клавіатура, пристрій автентифікації та фізичні засоби введення. До L–E — переривання, багатозадачність, шум, робота з мобільного пристрою або нестабільний зв’язок. До L–L — погодження з колегою, передавання відповідальності, комунікація з підтримкою та спільне розуміння того, що саме змінюється.


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


Застосування в авіації та транспорті


Авіація залишається найчіткішим інституційним контекстом SHELL. FAA у 2024 році включає модель до системних інструментів Safety Risk Management. EASA у матеріалах з підготовки диспетчерів використовує SHELL як один зі способів пояснювати зв’язок людських факторів з авіаційним середовищем і обладнанням, а британська CAA також має SHELL серед навчальних цілей з людської працездатності та обмежень.


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


Застосування в охороні здоров’я


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


У дослідженні Akiyama та співавторів, опублікованому в Journal of Patient Safety, 34 інциденти, пов’язані з апаратами штучної вентиляції легень, були закодовані з використанням SHELL; автори описали переплетення hardware, software, environment та liveware/liveware взаємодій і вказали на комунікаційні, сигналізаційні та юзабіліті-проблеми. Це хороший приклад застосування моделі до ретроспективного аналізу, але невелика вибірка й конкретний контекст не дають підстав переносити частоти категорій на інші медичні системи.


У більш свіжому дослідженні Fukami (2026) проаналізовано 160 повідомлень про інциденти, пов’язані з ультразвуковими дослідженнями, із національної японської бази. Чинники було класифіковано за SHELL; автор отримав різний розподіл категорій, але не виявив статистично значущого зв’язку категорій SHELL із тяжкістю шкоди. Цей результат добре показує межу моделі: вона структурує опис contributing factors, але сама категорія не є автоматичним предиктором наслідку.


Існують і адаптації моделі для медицини, зокрема Revised Sunflower-SHELL. У публікації Takayanagi і Hagihara модель навчали застосовувати 22 медсестер. Це корисний історичний приклад локальної адаптації, але масштаб і дизайн такого дослідження не підтримують твердження про універсальну валідність модифікації.


Науковий статус і рівень доказовості


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


Сильна частина доказової бази — професійна й нормативно-методична: модель присутня в авіаційних керівництвах і навчальних матеріалах, а її центральний принцип — аналіз інтерфейсів людини з системою — узгоджується із сучасною системною ергономікою. Інша частина доказової бази — емпіричні застосування: дослідники кодують за SHELL інциденти, будують категорії чинників або використовують модель як каркас для інтерв’ю та аналізу.


Ці застосування показують корисність рамки для організації інформації, але не створюють єдиного універсального коефіцієнта точності SHELL. Офіційні описи FAA задають блоки та інтерфейси, а не стандартизований бал, нормативний поріг чи математичну функцію ризику. Тому фрази на кшталт «SHELL доводить, що причиною було L–H» перебільшують можливості моделі. Вона допомагає сформувати й перевірити системну гіпотезу; причинний висновок потребує даних.


Обмеження моделі SHELL


Людина в центрі схеми може випадково стати центром пояснення


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


SHELL слабше описує взаємодії між не-людськими компонентами


Класичний варіант організовано навколо центрального L, тому він не так природно показує, наприклад, Hardware–Software, Hardware–Environment або взаємодію двох автоматизованих підсистем. У сучасних цифрових системах такі зв’язки можуть бути ключовими: програмний модуль неправильно інтерпретує датчик; мережеве обмеження змінює затримку; температурний режим впливає на сенсор. Тут потрібне доповнення технічним системним аналізом.


Організаційний рівень представлений нерівномірно


У різних версіях і галузях організаційні чинники можуть потрапляти до Environment, Software або Liveware–Liveware. Це робить модель гнучкою, але зменшує однозначність категоризації. Якщо головним питанням є управлінські рішення, ресурси, нагляд, культура чи структура захисних бар’єрів, корисніші моделі, що явно мають організаційні рівні.


Категорії можуть перекриватися


Одна проблема часто має кілька валідних класифікацій. Невдале повідомлення на екрані може бути Software як інформаційна логіка і Hardware як фізичне відображення. Неповне передавання зміни — L–L, але його форма може бути задана процедурою L–S. Така неоднозначність не є фатальним дефектом, якщо аналітик прозоро описує механізм і не використовує підрахунок категорій як заміну причинному аналізу.


Модель не дає ймовірності людської помилки


SHELL не є методом Human Reliability Analysis. Вона не визначає human error probability, не моделює час до відмови й не дає універсальних числових коефіцієнтів для ризикових розрахунків. Для кількісної або напівкількісної оцінки людської надійності потрібні інші методи та дані. Загальну логіку того, що таке людська надійність, варто розглядати окремо від категоризації SHELL.


SHELL, модель швейцарського сиру, HFACS і HRA: різні запитання


У safety-практиці ці назви часто стоять поруч, але вони не взаємозамінні. SHELL запитує: де є невідповідність між людиною та процедурою, обладнанням, середовищем або іншими людьми? Модель швейцарського сиру запитує, як слабкі місця в кількох рівнях захисту можуть вирівнятися й відкрити шлях до небажаної події.


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


Практично моделі можна комбінувати: SHELL — для інтерфейсної карти; Swiss cheese — для архітектури захистів і латентних умов; HFACS — для структурованої класифікації людських та організаційних чинників; HRA — для завдань, де потрібна оцінка надійності. Вибір визначається питанням, а не популярністю моделі.


SHELL не дорівнює аналізу першопричини


Іноді SHELL називають методом аналізу першопричин. Точніше вважати її інструментом системного опису, збору й структурування чинників. Навіть FAA 2024 розміщує SHELL серед інструментів системного аналізу, а окремі методи hazard identification, cause analysis та risk assessment розглядає далі окремо.


Це важливе розрізнення. Категорія «L–S» не відповідає на запитання, чому застаріла процедура залишалася в роботі; «L–H» не пояснює, чому орган керування пройшов перевірку проєкту; «L–L» не пояснює, чому передавання зміни не мало обов’язкової точки підтвердження. Для відповіді потрібно рухатися вгору по системі: до проєктування, закупівель, управління змінами, нагляду, культури звітування й контролю ризику.


Типові помилки під час використання SHELL


  • Починати з висновку «винна людина», а потім розкладати її недоліки по блоках.

  • Вважати Software лише комп’ютерною програмою і втрачати процедури, правила, документацію та символіку.

  • Рахувати кількість чинників у кожній категорії й трактувати найбільшу категорію як «головну причину» без причинного аналізу.

  • Вписувати організаційні та технічні проблеми в найближчу літеру, не описуючи механізм взаємодії.

  • Зупиняти аналіз на словах «стрес», «втома», «неуважність» або «недостатня підготовка», не шукаючи умов, що їх створили або зробили критичними.

  • Автоматично призначати навчання як коригувальну дію, навіть коли проблема лежить у дизайні, процедурі, сигналізації чи середовищі.

  • Використовувати SHELL як єдиний метод для складної аварії, де потрібні аналіз бар’єрів, технічна причинність, організаційні рівні або кількісна оцінка ризику.


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


Що модель дає проєктувальнику безпечної системи


SHELL корисна не лише після інциденту. Її можна застосовувати проактивно під час дизайну, зміни системи, закупівлі обладнання, створення процедур або підготовки нової версії програмного продукту. Запитання однакове: де майбутній користувач буде змушений компенсувати невідповідність?


  • Для L–S: узгодити термінологію, процедури й цифрову логіку; зробити критичні правила виконуваними в реальному темпі роботи; перевірити документацію на актуальній версії системи.

  • Для L–H: розрізнити критичні органи керування, зробити стани й режими спостережуваними, забезпечити достатній зворотний зв’язок, протестувати фізичну доступність та захист від випадкових дій.

  • Для L–E: тестувати систему у фактичному освітленні, шумі, температурі, просторі, русі та режимі переривань, а не лише в лабораторній тиші.

  • Для L–L: проєктувати передавання зміни, підтвердження, ескалацію, розподіл ролей і спільну картину стану системи так само уважно, як екран або кнопку.


Це відповідає ширшій ергономічній тезі: система має бути спроєктована з урахуванням людських можливостей і обмежень, а не покладатися на постійну компенсацію слабкого дизайну. ISO 6385:2016 саме тому вимагає інтегрованого підходу до людських, соціальних і технічних вимог протягом життєвого циклу робочої системи.


SHELL і культура безпеки


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


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


Коли SHELL особливо корисна


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


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


Короткий чекліст SHELL для аналізу


  1. Хто є центральним людським елементом у цьому конкретному сценарії?

  2. Яке реальне завдання людина намагалася виконати і який результат був потрібний?

  3. Які процедури, правила, інструкції, програмні сценарії та повідомлення формували L–S?

  4. Які фізичні пристрої, дисплеї, органи керування та просторові характеристики формували L–H?

  5. Які умови середовища могли змінити сприйняття, темп, рух, увагу або відновлення після помилки?

  6. З ким людина обмінювалася інформацією, відповідальністю або контролем і що відбувалося на L–L?

  7. Де саме була невідповідність і через який механізм він вплинув на дію?

  8. Які технічні, організаційні чи міжсистемні чинники лежать за межами базової SHELL-карти?

  9. Яка зміна системи усуває механізм проблеми, а не лише нагадує людині «бути уважнішою»?

  10. Якими даними буде перевірено, що зміна справді покращила взаємодію й безпеку?


Поширені запитання про модель SHELL


Що таке модель SHELL простими словами?


Це спосіб перевірити чотири головні стики навколо людини: з правилами й програмами, з обладнанням, із середовищем та з іншими людьми. Модель допомагає знайти, де система погано «підходить» людині й через це створює умови для помилок або нестабільного виконання.


Як розшифровується SHELL?


S — Software, H — Hardware, E — Environment, L — Liveware, L — інше Liveware. У практичному українському поясненні це можна читати як «процедури й програмна логіка — обладнання — середовище — центральна людина — інші люди».


Чим SHEL відрізняється від SHELL?


SHEL — рання форма моделі Едвардса 1972 року. Пізніша форма SHELL, пов’язана з розвитком моделі Френком Гокінсом, чіткіше показує L–L — взаємодію центральної людини з іншими людьми. У сучасній літературі часто зустрічаються обидві назви, але SHELL краще передає чотири типові людські інтерфейси.


Чи означає Software тільки комп’ютерну програму?


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


Чи є SHELL психологічною теорією?


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


Чи можна за SHELL розрахувати ризик у цифрах?


Базова модель цього не робить. Вона структурує компоненти й інтерфейси. Для кількісної оцінки ризику, ймовірностей відмов або людської надійності потрібні окремі методи, валідні дані та доменні припущення.


Чи є SHELL методом пошуку кореневої причини?


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


Чи застосовується SHELL поза авіацією?


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


Чим SHELL відрізняється від моделі швейцарського сиру?


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


Чому в SHELL людина в центрі, якщо безпека системна?


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


Пов’язані статті






Джерела


Akiyama, N., Kajiwara, S., Tamaki, T., & Shiroiwa, T. (2023). Critical Incident Reports Related to Ventilator Use: Analysis of the Japan Quality Council National Database. Journal of Patient Safety, 19(1), 15–22.






International Ergonomics Association. What Is Ergonomics (HFE)?.


International Organization for Standardization. (2016). ISO 6385:2016 — Ergonomics principles in the design of work systems.



 
 
bottom of page