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

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

Кейс. Intel «Copy Exactly!»: проєктування як точне відтворення

Кейс за первинною публікацією Intel Technology Journal, Q4 1998 р.

Метод «Copy EXACTLY!» був розроблений компанією для покоління техпроцесу 0,5 мкм і відтоді став ключовою частиною виробничої стратегії компанії — так первинна публікація прямо датує його появу, і поширене твердження про походження методу з 1980-х цьому суперечить. Філософія методу сформульована дослівно: усе, що може вплинути на процес або на порядок його виконання, копіюється до найдрібніших деталей, окрім випадків, коли це фізично неможливо або дає незаперечну конкурентну перевагу для зміни. Зіставлення нового майданчика з еталонним відбувається на чотирьох рівнях — фізичні входи процесу (витрати газів, температури, тиски), вихід кожного кроку, тестові структури модульного рівня і характеристики готового продукту, — і на кожному рівні застосовують формальні статистичні тести.

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

Чому для трансферу технологічного процесу компанія обрала точне копіювання замість локальної оптимізації на кожному новому майданчику?

Показати розбір

Для теми 5 кейс показує третій вид проєктування впритул: перенесення вже спроєктованої системи — це не привід «покращити на місці», бо кожна локальна оптимізація руйнує порівнянність двох майданчиків і робить розбіжність нез’ясовною. Межа кейсу: первинне джерело не наводить жодної кількісної метрики приросту якості виходу, і поширене датування методу «з 1980-х» суперечить самому тексту статті — це період покоління 0,5 мкм, а не 1980-ті роки.

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