Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

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

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.
* * *
Пора опять рисовать карты действий и результатов.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments