Друга стаття про міфологічну свідомість теж буде короткою. Сьогодні я розповім, до яких проблем призводить міфологічна свідомість при моделюванні архітектури підприємства.
Відома модель Захмана намагається відповісти на питання, що таке архітектура підприємства, і розповідає про те, як вона повинна моделюватися. Основою цієї моделі є питання, на які пропонується відповісти: хто, коли, де, чому і як робить щось над чимось. Здається, що це логічний фреймворк для опису архітектури підприємства, і багато хто думає, що так воно і є.
Однак, навіть побіжний погляд на цей фреймворк залишає почуття незадоволеності, тому що не зрозуміло, як відповісти на питання: хто і чому виточив деталь? Хто: Іване Івановичу, чи токарю, роль якого виконував Іван Іванович? Чому: тому що токар отримав завдання, або тому що Іван Іванович уклав контракт, відповідно до якого він зобов'язується виконувати роль токаря в обмін на їжу? Чому: тому що Іван Іванович хоче поїсти, або потім, що деталь потрібна в складальному цеху?
Більш глибоке вивчення цього фреймворку змушує задуматися над його застосовністю до опису технологічних процесів. Наприклад, нехай кукурудза росте в полі. Застосовуючи модель Захмана, я повинен відповісти на питання. Хто? Кукурудза. Що робить? Росте. Чому? Тому що так влаштований світ. Навіщо? Та хто ж його знає, навіщо росте кукурудза?!
Читач, натренований в описі архітектур підприємств, швидко мене поправить. Він скаже, що я неправильно ставлю питання. Треба питати: хто вирощує, чому він вирощує, що вирощує. Але тоді виходить, що я можу описати діяльність суб'єкта, який вирощує кукурудзу, але не можу описати саме зростання. Змирившись з тим, що я не можу описати процес зростання, у мене все одно залишаються невирішені питання: хто і чому вирощує кукурудзу (див. вище)?
Виходить, що, ставлячи начебто логічні питання, я в кращому випадку отримую кілька відповідей, а в гіршому, не отримую їх взагалі. Якщо взяти граничний випадок, коли у нас є повністю роботизоване підприємство, на якому взагалі немає людей, то відповіддю на питання «хто?» буде - «ніхто». В результаті ми взагалі нічого не можемо сказати про це підприємство! Правда, є один вихід з цієї ситуації, трохи лукавий, - треба лише скористатися міфічною свідомістю і одушевити роботів. Тоді, одушевивши неживе, ми зможемо відповісти на питання: хто? Робот. Чому? Тому що так влаштований цей робот, або тому що програміст його так запрограмував. На друге запитання ми знову отримуємо дивні відповіді. Чому ж так вийшло, і які питання насправді варто ставити? Я спробую коротко викласти свою думку з цього приводу, розповівши про ті логічні помилки, які я знайшов у моделі Захмана.
Якщо подивитися на питання, які задаються в моделі Захмана, можна переконатися, що вони в точності відповідають теорії діяльності. Діяльність - це психічна функція суб'єкта (групи суб'єктів). Тому, відповідаючи на запитання Захмана, ми будуємо модель психічної функції суб'єкта (суб'єктів). Наука, що вивчає психічні функції суб'єктів, називається психологія. Виходить, що Захман відповідає на питання, якими задаються психологи: навіщо суб'єкт робить ту чи іншу дію? Або як мотивувати суб'єкта на виконання тих чи інших дій? Ці питання, безумовно, цікаві і важливі, але чи є відповіді на них описом архітектури підприємства? Щоб відповісти на це питання, треба зрозуміти, що ж таке підприємство?
Як же насправді відбувається проектування підприємства і які артефакти при цьому виникають? Перш ніж проектувати підприємство, будується модель вимог до нього. Модель вимог формується на основі вимог, які пред'явлені до цього підприємства з боку всіх його учасників, контрагентів і стейкхолдерів. Аналог в ІТ - вимоги до програмного продукту. Далі на основі цих вимог будується модель процесів підприємства з необхідним ступенем деталізації. Аналогом в ІТ буде перелік функцій програмного продукту. Далі будується модель функціональних об'єктів, або, кажучи спеціалізованою мовою, технічних місць, які повинні брати участь у перерахованих раніше процесах. Аналогом в ІТ буде опис процедур, і пояснення які процедури в яких функціях беруть участь. Далі підбираються ті одиниці обладнання, які можуть виконувати ролі перелічених технічних місць. Аналог в ІТ - це програмний код.
Підприємство - це функціональний об'єкт, який створений задовольняючим певним вимогам. У цьому сенсі підприємство нічим не відрізняється від такого об'єкта, як годинник, або виробнича лінія. Часто замість терміну функціональний об'єкт можна почути термін технічне місце. Технічне місце відрізняється від одиниці обладнання тим, що одиниця обладнання виконує роль технічного місця. Наприклад, трансформатор виконує роль перетворювача напруги, при цьому в різний час різні трансформатори можуть виконувати роль одного перетворювача. Ще одним прикладом технічного місця є посада, відділ, підрозділ, штат. Наприклад, токар бере участь у функції виготовлення деталей. Це - технічне місце, роль якого в різний час можуть виконувати різні одиниці обладнання (фізичні особи). Про складнощі моделювання технічних місць та одиниць обладнання я коротко написав у статті Моделювання активів підприємства: сучасні стандарти і практика.
При моделюванні технічних місць, ми описуємо процеси і учасників цих процесів. Зауважу, що саме учасників, а не виконавців, - трансформатор не може перетворювати напругу, тому що він не є одушевленою істотою. Про це я писав у минулій статті Моделювання активності і міфологічна свідомість. Якщо все ж сказати, що трансформатор «перетворює» напругу, то це - метонімія, яка розкривається так: трансформатор, виконує роль перетворювача напруги, який (перетворювач) бере участь у процесі перетворення напруги. Про метонімію можна прочитати в книзі «Метафори, якими ми живемо», автори: Джордж Лакофф, Марк Джонсон. Іншою поширеною метонімією буде вислів: «комп'ютер вирішує завдання». Ті ж, хто дійсно вважає, що трансформатор, або комп'ютер щось робить насправді, одушовують неживе, користуючись міфічною свідомістю.
Зауважимо, що до цього моменту ми ні слова не сказали про цілі, про виконавців і причинно-наслідкові зв'язки. Ми лише говорили про вимоги, про функції та учасників цих функцій - технічні місця. Цілі залишилися на етапі формування вимог до підприємства і далі вони не пішли. Ми можемо знати ці цілі, а можемо не знати, - для моделі підприємства це не має ніякого значення. Модель підприємства відповідає на питання: як ми задовольняємо вимоги, а не те, звідки взялися ці вимоги. Виконавців теж немає, тому що нам не треба користуватися теорією діяльності, щоб описати учасників активності. Ми не будуємо причинно-наслідкові зв'язки. Якщо ж треба побудувати модель причинно-наслідкових зв'язків, то це ще одна додаткова модель. Це знання, якими користуються технологи при проектуванні підприємства, і я не бачив, щоб хтось будував такі моделі. Це - галузеві знання, і вчать їм в інститутах по багато років. Змоделювати, чому летить літак - нереально важко, і ніхто цього не робить. Просто моделюють політ літака.
Отже, модель Захмана не включає в себе вимоги до підприємства, включає в себе модель процесів, але досить специфічним способом - із зазначенням на виконавців процесу, яких, як я вже сказав можна знайти тільки в теорії діяльності, і не поділяє модель технічних місць і модель одиниць обладнання.
Як я сказав раніше, модель Захмана швидше про діяльність. При цьому було б непогано, якби модель Захмана використовувалася за призначенням, - як спосіб опису діяльності. Це давало б можливість аналізувати мотиви і зацікавленість людей в їх роботі, але біда в тому, що ця модель використовується невірно. Наприклад, на питання «чому токар точить деталь?» можна отримати відповідь: «вона потрібна в складальному цеху». Але необхідність її в складальному цеху не відповідає на питання, чому токар точить деталь. Відповідь була не на поставлене питання, а на якесь інше. Наприклад, для такої відповіді правильним було б питання: в якому процесі, або в якій операції повинна брати участь виточена деталь? Або на якому робочому місці вона потрібна? Ви бачите, що це зовсім не питання «чому?». Крім того, мене сильно бентежить наділення Захманом комп'ютера або інформаційної системи здатністю щось робити. Швидше за все, він не одушовує їх, але використовує метонімію в моделюванні, що на мій погляд, неприпустимо.
Правильними питаннями будуть: Які існують вимоги до підприємства? Які процеси протікають на підприємстві? Які технічні місця в яких процесах беруть участь? Які одиниці обладнання виконують ролі яких технічних місць і коли?
Власне, все. З наступаючим, і до нових зустрічей!
