0:00
Следующая модель, которую бы я привел в отношении этой истории,
это модель взаимодействия.
Помните, мы говорили: субъект-объект, заказчик- подрядчик.
Вот модель управления: старик и старуха.
Ну, кто тут управляющий?
Старик – нет, старуха.
>> Скорее, старуха.
>> Старуха, конечно старуха.
И, так сказать, объект управления – старик.
Вот это такая схема управления, которую мы видим в этой сказке.
Следующая модель взаимодействия – более сложная.
Вот это модель взаимодействия между системами S1 и S2,
то есть между хозяйством старика и старухи и золотой рыбкой.
Как происходит взаимодействие?
Старуха выставляет требования старику.
Старик доносит эти требования до золотой рыбки.
То есть система S1 выступает как заказчик.
Руководитель системы выставляет требования,
исполнитель доводит эти требования до подрядчика.
Золотая рыбка принимает эти требования и исполняет их.
Ну, в данном случае речь идет, скажем,
о замене корыта: старое корыто заменено на новое корыто.
Вот система взаимодействия,
это уже второй тип модели взаимодействия (заказчик-подрядчик),
которую можно применить к этому фрагменту.
Хорошо.
Теперь очень интересный вопрос,
инженерный вопрос: а каким образом подрядчик,
в данном случае золотая рыбка, исполняет требования?
То есть ведь она осуществляет некую волшебную услугу.
То есть она создает объекты по требованиям.
Вот смысл этой услуги.
Поэтому продукт...
Помните, у нас была модель продукта?
Продукт – это волшебная услуга по требованиям, и дальше в отношении
каждого продукта можно составить перечень процессов жизненного цикла этого продукта.
Что в данном случае?
Первый процесс: принятие заказа.
Второй процесс: сбор данных.
Ну, как я понимаю, помните, когда старик уже пришел,
вернулся к старухе, корыто уже было на месте.
То есть там очень быстрое такое проектирование, создание объекта.
Поэтому я так понимаю, что в рамках такой модели современной цифровой экономики,
как я сейчас могу трактовать эту историю, там был какой-то способ наблюдения,
либо космическое наблюдение, либо авиационное,
наблюдение с дрона, с другого летающего объекта, которое восстановило,
так сказать, просканировало и восстановило модель корыта.
Дальше эта модель корыта с дрона была передана в центр обработки заказов.
Там была смоделирована модель корыта как модель 3D,
и дальше, если есть модель 3D, мы все хорошо понимаем,
что ее легко можно создать методом 3D печати.
Так я понимаю, что был послан какой-то дрон, нет, виноват, не дрон...
Был послан робот, у которого под мышкой была 3D печать,
ну вот там, помните, елка стояла, наверное он за елкой прятался.
И вот этот робот, собственно, взял и напечатал корыто.
Почему я говорю, что не корыто было послано, потому что дальше по сказке там
более сложные объекты создаются и конечно их рационально создавать сразу на месте и
3D печать ставить на объекте, и выращивать этот объект сразу,
не отходя далеко от места его привязки.
Итак, создание объекта в этом случае делается через Интернет вещей,
информационно-коммуникационные технологии, робот с 3D печатью и моделирование.
Дальше, объект, который создан – корыто – применяется, ну еще есть одна стадия,
в конце сказки это происходит, – утилизация этого объекта.
Вот перед нами классическая схема жизненного цикла продукта: получить заказ,
или придумать идею, спроектировать, создать, применить, утилизировать.
Хорошо.
И вот эти модели – зачем мы их делаем?
Вообще-то мы их делаем для того, чтобы разложить всю ситуацию на части,
провести анализ и вообще понять, почему вся эта история плохо кончилась?
Что в ней можно улучшить?
Ну вот эти модели помогают нам, в частности, понять,
что основная проблема была связана с тем,
что отсутствовала обратная связь у заказчика и подрядчика.
И та же самая старуха не обращала внимание на условия исполнения заказа.
Волнуется синее море – а старуха не замечает!
И поэтому, вот, отсутствие обратной связи
и плохое управление требованиями привело к тому,
что вся история вернулась к разбитому корыту.
Ну вот где-то вот так.
Но я хочу сказать, что вот эта история: старик, старуха,
золотая рыбка и управление требованиями вообще в инжиниринге типична.
Недочеты в управлении требованиями – это типичная
ошибка плохого инжиниринга рукотворных объектов.
Вот приведу еще пример: недавно в
Швеции утонул корабль «Васа», ну вы знаете эту историю.
Сначала они хотели создать большой корабль, потом уже начали
создавать и сказали: «Нет, мы будем создавать очень большой корабль».
Потом, когда уже почти построили очень большой корабль, они сказали: «Нет,
мы создадим самый большой корабль в мире».
И создали.
Но этот корабль недолго плавал – несколько сотен метров, и утонул на глазах у всех.
Вот вам пример плохого управления требованиями.
Ну скажите, напоминает сказку про старика и старуху, и золотую рыбку?
>> Очень даже.
>> Да. А в чем напоминает?
В том, что здесь одни и те же архетипы, одни и те же модели,
одни и те же компоненты, которые влияют на эту ситуацию.
Ну вот, поэтому вывод из рассмотрения этих историй заключается в том,
что знать и применять модели Специализации 2.0,
в которой одновременно рассматриваются и продукты, и предприятия, – полезно.
>> Ну, конечно, наверное,
в описанных вами ситуациях управлять требованиями было очень сложно.
И все же Специализация 2.0, это совсем относительно недавняя разработка,
и хорошо, что она появилась, в общем-то.
Хорошо.
Можно ли привести какие-то примеры из практики?
>> Хорошо.
Из текущей практики?
>> Да. >> Те примеры, которые я показал,
это тоже реальная практика.
Знаете, я и в Стокгольм поехал посмотрел.
Да, этот «Васа» стоит в музее.
И в золотую рыбку вы же верите, конечно?
Мы все понимаем, что это реальная ситуация.
Поэтому это два реальных примера.
Другое дело, что вы, может быть, хотите какой-то ближайший пример?
>> Да. >> Вот который произошел прямо-прямо вот в
наши дни?
Хорошо, ну давайте вспомним такую историю, расскажем ее один к одному.
Это история о технологических присоединениях.
Романов Алексей АлександровичДоктор технических наук, профессор.
Кондратьев Вячеслав ВладимировичДоктор технических наук, профессор
