1 ← 10 ← 100

2 ← 20

3

Напомню, что контроль хаоса — это идеология ИТ-разработки бизнес-систем. Соответственно указанные цифры — это обязательные к соблюдению характеристики процесса разработки.
Вообще если немного отвлечься к проблематике вопроса, то уже давно наблюдается несоответствие параметров задач, которые решают бизнес-системы, и параметров, закладываемых в основу самих бизнес-систем. Ну например, к системам управления самолетов или атомных станций понятно почему ставится требование 99,999% отказоустойчивости (100% не бывает и именно поэтому всегда к этим системам будут приставлены люди) — с точки зрения бизнеса именно отсутствие критичных ситуаций является конкурентным преимуществом они операторов АЭС и авиаперевозок от других. Зачем это требование предъявляется к бизнес-системам, владельцы которых конкурируют между собой на совершенно другом рынке и по другим правилам, совершенно не понятно. Разве на банковском или ИТ-шном рынке выигрывают те, чьи карты платежные/операционные системы никогда не дают сбоя, или все таки те, кто вообще первыми вывел на рынок эти самые системы (большой привет Diners Club и Microsoft)?
Логично что для бизнес-систем основным критерием является скорость адаптации, что и заложено в приведенную выше схему-формулу. Важно ответить, что все показатели являются перманентными на всем протяжении жизни системы (вне зависимости от количества внесенных доработок и сложности архитектуры системы, вне зависимости от объема данных и количества пользователей).

Первый ряд: время отклика системы (в секундах).
Время открытия любого интерфейса (максимум 1 секунда) →
Время отклика любой операции (максимум 10 секунд) →
Время выгрузки любого отчета (максимум 100 секунд)

* Это требование и так не соблюдается в большинстве современных систем, а в условиях разработки на скорость, именно время отклика системы обычно отдается в жертву времени внедрению доработок.

Второй ряд: время на внесение изменений в систему (в часах)
Время на любую текущую доработку (максимум 2 часа) →
Время на автоматизацию любого нового бизнес-процесса (максимум 20 часов)

* По сути это то, ради чего потребовалось изобретать концепцию контроля хаоса. Скорость адаптации системы к изменениям является её краеугольным камнем. Популярные в наше время системы с MVC-архитектурой не соответствую и не могут соответствовать этому требованию просто потому, что они своей задачей ставили универсальность структуры, а задачей адаптивных систем является возможность быстро менять любые свои части, в том числе и общую структуру.

Третий ряд: время полной адаптации системы (в неделях)
Время написания новой или капитальной реконструкции старой системы (максимум 3 недели)
* Такого сейчас нет вообще нигде. Речи нет ни то что про недели или даже месяцы — обычно сроки полной адаптации системы изменяются в годах.

Горизонтальный ряд: постоянное стремление к экономии времени.
Каждый из показателей стремится минимизировать себя и прийти к условной единице (минимальному периоду времени).
* Скажем так это дань должного профессии программиста, целью которой является постоянное развитие и улучшение существующего положения вещей.