О системной инженерии

PBL (performance based logistics) и PBS (performance based supportability). Все это означает оплату контрактов по факту выполнения нужной клиенту функции, а не закупку чего-то конкретного. Типа покупается пропускная способность дороги, а не собственно дорога -- оплата за доступность. Очень легко порождать понятия: бери что угодно и добавляй "performance based". * * * 90% всей этой системной инженерии идет от огромных военных контрактов, где нужно создать что-нибудь гарантированно летающее и гарантированно стреляющее. Далее идут транспортники, где нужно мосты делать так, чтобы они не разваливались. Ну, и так далее: проекты от миллиона деталек, и все детальки разные. Для "обычных предприятий" системная инженерия нафиг не нужна -- только для тех, где требуется существенная мультидисциплинарность. * * * В INCOSE обычная для любых сообществ ситуация: их 6000 человек самой разной степени осведомленности, из них примерно 300 человек собираются пару раз в год и плотненько работают несколько дней над документами. Дальше просто: сколько ты этому комьюнити дашь, столько и сможешь взять. А на поверхности обнаруживается только куча пены, как в любом системном подходе. Всяк из этих шести тысяч человек норовит написать какую-нибудь всеобъемлющую онтологию-таксономию, многомерную классификацию или еще что-нибудь всеохватно-бюрократическое, с чем абсолютно невозможно работать. Непонятно, как все это отфильтровывать. Много откровенных "отчетных методов", типа ISO 9000. Но есть и попытки разобраться в сути инжиниринга сложных систем. Основная там мысль -- исправление ошибок поближе к началу, до начала производства. Желательно, еще на этапе работы с требованиями. А требований может быть неожиданно много. Представьте себе какой-нибудь небольшой заводик и детальный набор к нему требований (здание, оборудование, материалы, рабочая сила, планы выпуска -- и чтобы все согласно этим требованиям было продумано, заказано и поставлено в срок. Не думайте, что задача тут проста: "заказать" кому-то строительство "под ключ", это не решить собственно задачу. Это просто сдвинуть ответственность (и прибыль ;) на шаг по цепочке контракторов. Кто-то все равно должен такую задачу "сделать под ключ что-то очень большое и сложное" уметь решать. Вот им и нужна системная инженерия. * * * Гуляет список потенциальных (идет опрос комьюнити) принципов системной инженерии -- всего 70 штук. Вот для примера первые три: -- THE system, not A system: (Problem System, Stakeholder System, Problem Suppression System). -- A system, when stimulated, exhibits behavior a) not achievable by any subset, b) dependent on state of system at instant of stimulus. -- POSIWID – The Purpose Of a System Is What It Does (regardless of the designers’ intents). Интересные там принципы. Да, они банальны, но все равно регулярно сталкиваешься с их несоблюдением! * * * Много лет назад я называл себя "системный архитектор" и страшно этим гордился. Потом поменял это торжественное название на "когнитолог", а затем уже на "консультант". "Просто консультант". Но это не значит, что интерес к системной архитектуре (уже тогда я добавлял -- "необязательно софтовой!") был потерян. Системная архитектура, работа со знаниями, системная инженерия -- это мне до сих пор крайне интересно. Только поменялся режим: нужно уже не столько все это изучать, сколько теперь нужно это все делать, практиковать. * * * Новости Геллиша: скоро будет новая версия, в которой будет отмоделирована онтология измерений. А в браузере/редакторе появится развитый поиск (чтобы искать в информационной модели предприятия). Еще четко будут разделены Словарь Геллиш и набор живущих во времени фактов -- Геллиш База Знаний. А я еще предложил смотреть на Геллиш Вопросы как на зачаток программистского Геллиша (см. подробнее разговор с автором Геллиша: https://sourceforge.net/forum/forum.php?thread_id=2017733&forum_id=89287 * * * Книжку по Геллишу пока решили не переводить: вряд ли у нее будет больше десятка заинтересованных читателей. А этот десяток вполне прочтет и по-английски. * * * Пока представляется: -- если у вас проблемы со стратегией, то стройте карту действий и результатов. В принципе, в этой карте есть рудиментарная работа с требованиями, архитектурой и их трассировкой. -- если у вас проблемы с разбиением работ, сроками и финансированием, то вам к Lean Project Management и CCMP. -- если проблемы с информационной моделью (достали документы, хочется нормальной датацентрики), то вам к ISO 15926 и Gellish -- если проблемы с увязкой всего на свете в огромном и конкретном техническом решении -- ISO 15288 -- организационное строительство и процессы -- юзайте DEMO. * * * Пора опять рисовать карты действий и результатов.