Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия»



    Попытался прокомментировать статью Ричард Хэмминг: Глава 28. Системная Инженерия» через свое понимание проблем «системной инженерии» и с учетом «современности», а также связанных или даже частично дублирующих ее EA \ BPM.

    Выдержки из оригинала показаны цитатами, из других источников – курсивом. Плюс рассуждения вокруг системотехники.

    Системная инженерия или Systems engineering (SE) – также давно известное направление, как и BPM (Business Process Management) и EA (Enterprise Architecture). Найти, где заканчивается SE и начинаются ЕА и ВРМ – сложно. Уж очень все эти три направления «по-развивались», особенно в маркетинговой плоскости.

    Любое проектирование «большого и сложного» — должно базироваться на SE. Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)

    Есть рассказы (байки) КАК АРХИТЕКТУРА ПРЕДПРИЯТИЯ ДОПОЛНЯЕТ СИСТЕМНУЮ ИНЖЕНЕРИЮ

    Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE, а в стандартах SE – постоянно говорится о «моделировании» и «процессах».
    Таким образом, сложно представить ЕА или BPM без «довеска» SE: итого получаем троицу ЕА-BPM- SE.

    Так как SE — это проектирование всего «большого и сложного», то по «определению» оно пересекается практически со всем известным из «Best Practice» & ххBOK, включая «SE & PMBOK», «SE & ITSM», но ограничимся указанной «тройкой», причем с учетом изложенного в моих циклах с критикой ЕА и ВРМ:

    Enterprise Architecture vs алхимия предприятия
    Бизнес-процессы: Как все запущено и запутано (ВРМ)

    Ключевой вывод: Если ЕА и ВРМ считаем алхимией, а SE не опровергает их подходы, а наоборот «дополняет», а зачастую «дублирует и повторяет», то можно поставить под сомнение утверждение, что SE – это инженерная дисциплина.

    Проблема современных SE – такая же, как и для ЕА и ВРМ – нет детальных опубликованных примеров их апробации. Почти все проекты закрыты через NDA, ДСП и «военная тайна», нет пошаговых примеров по реализации проекта. Зато много зарабатывающих на SE ассоциаций, много маркетинга, курсов, продаж и т.п.

    Немного про SE


    Системная инженерия — междисциплинарный подход, определяющий полный набор технических и управленческих усилий, которые требуются для того, чтобы преобразовать совокупность потребностей и ожиданий заказчика и имеющихся ограничений в эффективные решения и поддержать эти решения в течение их жизненного цикла (ISO 24765).
    sewiki.ru

    Из книжки «Системная инженерия для чайников» от IBM

    Системная инженерия — это междисциплинарный подход к созданию крупных комплексных систем, которые соответствуют определенному набору экономических и технических требований.
    В аэрокосмической и оборонной промышленности системная инженерия используется уже давно, и многие из полученных опытным путем знаний применяются в других сферах.


    Wiki Systems engineering
    — совсем скупо.

    Впрочем, как и Wiki Системотехника

    При том, что Советская школа системной инженерии \ системотехники не уступала на тот момент западной.

    Почему-то первенство SE отдают США (вопрос дискуссионный):
    Согласно легенде системная инженерия впервые появилась как метод ведения работ в военной отрасли США, когда нужно было скрестить два сверхсложных инженерных проекта: атомный проект по созданию ядерного оружия и проект создания баллистических ракет, необходимых для доставки этого оружия. Не было никаких голов “генеральных конструкторов”, которые могли были бы справиться с решением этой задачи, и пришлось изобретать методы совладания со сложностью подобного сверхпроекта.
    Системноинженерное мышление

    Сомневаюсь, что советские аналогичные проекты не использовали такие же SE-подходы.

    SE – это про проектирование, внедрение и сопровождение систем, причем сложных систем. Процесс решения задач методами системной инженерии включает в себя постановку проблемы, нахождение принципиальных технических решений, моделирование системы, оптимизацию, архитектуру, изготовление и запуск, опытную эксплуатацию, а также анализ эффективности полученного продукта (изделия типа «система»).

    Причем, что очень важно – этот подход стоит, прежде всего, на страже интересов потребителя разработки (заказчика), а не консалтера или разработчика. Во всяком случае, так изначально задумывалось.

    Стандарты системной инженерии

    Наглядным отражением задач SE можно считать (условно) картинку (впрочем, как и задач PMBOK): Проект «Тарзанка»

    1. Начало


    В первых трех абзацах «Глава 28. Системная Инженерия» через «Человек смотрел, как строят собор» говорится о простой истине: «За деревьями не видеть леса». Это типовая ситуация, когда люди концентрируются на частностях и не видят «целого». Об этом очень много написано. Кое-что есть у меня:
    3.5 Леса, деревья, листья
    можно разделить на две задачи (категории): задачу описания «леса» (процессы в «крупную клетку», взгляд с высоты «птичьего полета») и достаточно детальных «процессов — деревьев»
    Они демонстрируют узость взглядов в своей работе и редко, если вообще когда-либо, связывают её с более общими целями системы.

    Такая узость взглядов является основной характеристикой бюрократа.
    Скорее не «бюрократа», а узкоспециализированного специалиста. Действительно, попытки оптимизировать «отдельный участок» не всегда приводят к улучшению работы «системы в целом».
    Системная инженерия — это попытка всегда держать основные цели в голове и понимать, для чего совершается каждое локальное действие, и как оно влияет на общий результат.
    Т.е. умение видеть и «лес» и «деревья», понимать законы развития (жизнь) «леса» и совсем другие законы (жизнь) «деревьев», причем у каждого «дерева» – свои собственные законы.

    Собственно это механизм перехода от крупного масштаба рассмотрения к мелкому и обратно.
    Естественно, я очень скоро понял, что наибольшую ценность от новых машин могут извлечь только сами ученые при работе напрямую.
    Я проецирую эту мысль на наше время, как необходимость привлечения самих бизнес-пользователей «напрямую» к описанию и оптимизации своих бизнес-процессов без использования ИТ-специалистов (BPM-специалистов, ЕА-архитекторов и прочих алхимиков) и программистов.

    Об этом рассказывал в статье Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
    На протяжении долгих лет не угасает стремление (мечта №2) — найти простой путь моделирования процессов непосредственно их участниками (задействованными в процессе) без привлечения BPM-специалистов «по отрисовке квадратиков и кружков», а также выполнение построенных таким образом процессов. Отсюда и сильная тяга (надежда) к формату BPMS
    Обязательства в каждом случае были: (1) непосредственный вклад, (2) вклад в долгосрочной перспективе и (3) очень долгосрочный вклад. Также я понял, что под пунктами (2) и (3) одна из моих функций в исследовательском отделе была не столько решением существующих проблем, сколько разработкой методов решения проблем, расширением диапазона возможностей и обучением других тому, что мне удалось обнаружить, чтобы они смогли в дальнейшем применить, продолжить и улучшить результаты моих усилий.
    Это же я пытаюсь донести в цикле ЕА «Enterprise Architecture vs алхимия предприятия», т.е. показать, что трансформация существующих подходов к ЕА и ВРМ должна быть направлена на:
    не столько решением существующих проблем …
    т.е. не разработка сиюминутного описания ЕА, к тому же закрытого по NDA и ДСП, т.е. чисто монетаризацией этого направления. Причем очень спорно, что проблемы действительно «решены», т.к. часто неудачный (провальный) проект ВРМ \ ЕА \ SE выдается за удачный, но узнать истину – нельзя.
    сколько разработкой методов решения проблем, расширением диапазона возможностей и обучением других тому, …
    это возможно только путем открытого обсуждения и не столько самих «методов решения проблем» — методологий и загадочных фреймворков, сколько демонстрации на конкретных примерах, апробации теоретических «Best Practice» и публикации практических «Best Practice». К сожалению, этого в современных ЕА и ВРМ и SE — нет.
    … что мне удалось обнаружить, чтобы они смогли в дальнейшем применить, продолжить и улучшить результаты моих усилий.
    Многих практиков ЕА и ВРМ и SE интересует только личная выгода, но вот развитие направления в целом, точнее переход от «алхимии» к «химии» — мало кого. Бизнес по ЕА и ВРМ и SE – процветающий: консалтинг, коучинг, инструменты и т.п., но что касательно практики и «теории по Ленину» – имеем ноль: «Нет ничего практичнее хорошей теории». Нет никаких доказательств в открытом доступе практичности, вообще ничего из практики по ЕА и ВРМ и SE — нет.

    Всё «практическое», т.е. все примеры — или коммерческая или государственная тайна. Кто сказал, что методологии и выполненные по ним проекты – успешные? На основе чего? И с какой выгодой?
    Тем не менее, позже я понял, что мне стоит обращать внимание не только на нужды Исследовательского Отдела, но и на все потребности Лабораторий.

    Потом это был AT&T, Страна за пределами AT&T, научные сообщества и сообщества инженеров, и, в итоге, весь мир. Таким образом, у меня появились обязательства перед самим собой, моим отделом, подразделением, компанией, родительской компанией, страной, миром ученых и инженеров и каждым жителем планеты.
    Таких обязательств и побольше бы нашим согражданам. Особенно тем, кто или практикует SE или учит других методам SE. Особенно тем, кто отвечает за развитие отечественного SE.

    Применительно к теории SE и к нашей стране: после развала ГОСТа, современные подобные организации (подобные гос-институты, включая Росстандарт, Роскачество и т.п.) ориентированы на монетизацию (путем сертификации, техрегламенты и прочее), регулирование и т.п., но никак не на развитие науки и инженерных практик, включая SE.

    Это все — к вопросам: стандартизация, унификация, типизация, свободный обмен лучшими практиками. Отечественная SE – это ГОСТы серий 34.ххх и многие из 15.ххх и 2.ххх.

    Обязательность их исполнения осталась в прошлом, но это обеспечило на то время мощный потенциал, прежде всего, при производстве военных систем (ГОСТ РВ 15.ххх и 2.ххх.).
    Максимум, что сейчас делается – это переводы зарубежных ГОСТов.

    Собственные (отечественные) методологические разработки в этих областях – нулевые.
    Зачем нам это сегодня? Хотя, когда-то наша страна была пионером в этих отраслях, как минимум, в подходах к стандартизации и унификации к проектированию сложных систем.

    Правильно – не нужно нам это, т.к. у нас:

    а) полно западных наработок — пусть в массе своей и относящихся к алхимии, но для монетизации это не существенно;
    б) есть и много «нефть и газ», что всем (во всяком случае, многим) дает достаточно «хлеба и зрелищ». Когда есть много «хлеба и зрелищ» стимул к развитию атрофируется.

    Я убежден, что ЕА и ВРМ и SE могут быть также представлены и досконально формализованы как подходы к кодированию информации. И эти направления когда-нибудь станут настоящими научными и инженерными дисциплинами.
    В системной инженерии очень просто говорить правильные слова, и многие люди научились говорить их, когда им задают вопросы в рамках этой темы, но как и во многих видах спорта, таких как теннис, гольф или плавание делать всё необходимое в целом оказывается сложно. Следовательно, системных инженеров стоит судить не по тому, что они говорят, а потому, что они в итоге делают и производят. Существует много людей, которые говорят о хорошей игре, но на деле не могут сыграть в неё.
    Я бы развил мысль далее — «системных инженеров стоит судить не по тому, что они говорят, а» по результату.
    И где отечественный авиа, авто – пром, где отечественный «SE-пром» (развитие 34.ххх), где хоть что-то отечественное из инженерии, системной инженерии? Умеем лишь переводить «западную алхимию», перепродавать западную «комплектуху» и из нее лепить системы (комплексировать), что в ИТ, что везде: 80% от суперджета и современных жигулей – импортные детали и технологии.

    Конечно, по этому критерию нужно судить не только инженеров, но и вождей и всех граждан (с молчаливого согласия которых все это), но вот — инженеров, причем ответственных за «большие системы» и за отечественную «системную инженерию», — в первую очередь. Не хотел о политике, но это вытекает из цитат из Хэмминга: «судить, что они в итоге делают и производят». А что реально производят? Производят в основном их западные коллеги.

    Первое правило системной инженерии


    Если оптимизировать компоненты, то, вероятнее всего, производительность системы будет испорчена.
    Проблема с заземлением дифференциального анализатора – как то не совсем мне очевидна. Это скорее технический дефект.

    Я бы привел другой пример, не особо показательный, но в ином направлении: помним старую игрушку — Диггер. Играли – играли, все было хорошо.

    Потом появились новые компьютеры и … на них играть стало невозможно, хотя их архитектура была совместимой. Из-за значительно прироста скорости – «бедного Диггера» мгновенно «съедали»: очень быстро работала новая система, т.к. уж очень «хорошо» оптимизировали вычислительную мощность компьютера.

    Со временем для подобных игр появились программы — «замедлители», т.е., чтобы поиграть нужно было «повесить балласт» на производительность для ее сопоставления с производительностью старых машин. Вывод: иногда к таблетке «оптимизатор» нужно прилагать таблетку «анти-оптимизатор».

    Еще пример оптимизации: некоторые умельцы форсировали движки на серийных автомобилях. После этого «рвало» полуоси (трансмиссию), особенно «гранаты» на переднеприводных автомобилях. Конечно, оптимизация должна быть комплексной с учетом «слабого звена» в общей системе (цепи).

    Хотя в данном случае, мероприятия условно можно отнести к «оптимизационным», это просто увеличение мощностей, в первом случае — вычислений, во втором крутящего момента.

    Это примеры когда не работает принцип: «кашу маслом не испортить»: в сложных системах он не всегда работает.
    Зубрение перед экзаменом — пустая трата времени.

    Не совсем понял критику. Вообще основная цель процесса обучения – это тренировка. Тренировка и развитие памяти человека (наращивание его ОЗУ), мыслительного процесса (вычислительная мощность CPU и DSP мозга). Примеры онтологий, понятийных аппаратов. Это просто позволит аналогию для практических задач. Задачи разные – подходы к решению одинаковые (общесистемные).

    Очень мало (почти ничего) из изученного применяется на практике – это видимо норма любого обучения. Но это по принципу: «тяжело в ученье, легко в бою». В один миг может устареть кавалерия и быть заменена на танки, но элементы тактики (прорыв обороны, обход с фланга) останутся прежними.

    Кстати к вопросу обучения в отечественных ВУЗах, часто наблюдается парадокс: двоечники добиваются блестящей карьеры (уходят в топы), а отличники «протирают штаны» инженерами (рядовыми сотрудниками).
    Системная инженерия — это процесс, которому трудно следовать, так легко потеряться в деталях!
    Да, верно, но только — пока эти направления: SE, ЕА, ВРМ — находятся на уровне развития «алхимия». Когда это станет реальной наукой и будут детальные и обоснованные (доказанные) и апробированные походы, то «следовать будет просто», даже начинающему.

    По «букварю» — уж не знаю какому: букварю SE, ЕА или ВРМ (или все это схлопнется в одно направление) можно будет пошагово построить любую АСУ или предприятие. Сравнение с алхимией относится более явно к ЕА и ВРМ, чем к SE, SE – все-таки более продвинулась по сравнению с ними, в первую очередь, благодаря стандартизации.

    Хотя и на SE уже наложена «лапа маркетинга». Ключевая проблема SE (повторюсь) – это отсутствие, также как и для ЕА и ВРМ, – публикуемых примеров реализации методик SE (проектов).
    В итоге, если смотреть в целом, в обучении Математике появились большие пробелы. Мы практически не затрагиваем (1) важный метод Математической индукции, (2) после краткого упоминания в связи с квадратичными уравнениями в алгебре мы практически полностью игнорируем любое упоминание комплексных чисел до того рокового дня, когда появляются сложные собственные значения и собственные функции, и бедный студент знакомится с двумя новыми сложными концепциями одновременно и, естественно, это сбивает его с толку, (3) вкратце упоминается полезный метод неопределенных коэффициентов, (4) практически полностью игнорируются доказательства невозможности, (5) игнорируется дискретная математика, (6) не прилагаются усилия к тому, чтобы вывести размышления студентов из обучающих примеров к значимым концепциям, применимым в реальном мире.
    Подобные проблемы, уверен, существовали и в СССР. С одной стороны советское образование славилось более «комплексным подходом» («широким взглядом») по сравнению с узкоспециализированным «западным». Но, с другой стороны, это же приводило к еще большему отдалению от «реального мира».

    Про современное отечественное образование скажу так: как раз сейчас в стране сделан упор к «концепциям, применимым в реальном мире». Только «реальный мир» в стране – это не индустриальная эпоха, поэтому в моде концепции «бухгалтерско-маркетинговые».

    В стране «экономистов и бухгалтеров — как собак нерезанных», школы и университеты маркетинга и т.п. В то время как наука и инженерия – оказалась на «обочине», поэтому наши спутники «падают как мухи», а про отечественные самолеты, автомобили, компьютеры и телефоны – уже никто даже не обсуждает (не верит).

    Не обсуждает всерьез, т.е. только на уровне маркетинга, гос-пропаганды (чудовищный механизм), инвестиций в «правильные кормушки», пиара отдельных личностей и проектов, как правило, частно-государственных.

    На инженерных специальностях вместо научных дисциплин часто преподается откровенная алхимия. Про преподавание алхимии:
    «Со временем, на обложках подобных учебных пособий и книг внезапно проявится надпись «Пособие по алхимии», а некоторые уже сейчас способны разглядеть пока еще расплывчатые контуры такой надписи». habrahabr.ru/post/345948

    Как раз поэтому:
    … многие люди знают, что сказать, но не многие могут фактически применить это на практике, когда придет время действовать в реальном мире. Большинство из вас не может!
    Не может, — потому что будущих инженеров учили маркетингу и алхимии. Системный подход, системный анализ – хоть и обязательный атрибут любой «Концепции и стратегии» в красочных буклетиках консалтеров, но в реальности это просто «управленческая уловка».

    Упоминания про «У них была производственная линия, …» — это про промышленный конвейер и т.п. (Г. Форд), напрямую к SE отношения, видимо, не имеет. Хотя любое проектирование – это фактически такой же проектный конвейер.

    Причем, если грамотно его организовать, то требования к компетенциям и «творчеству» работников на таком конвейере по выпуску «АСУ и предприятий» будут существенно снижены, при одновременном повышении качества и минимизации сроков проектирования.
    Гибкость в проектировании дает не только возможность лучше справляться с изменениями, которые неизбежно возникнут после установки системы, но также вносит вклад в вашу собственную работу в виде небольших изменений, которые неизбежно возникают как на более поздних этапах проектирования, так и во время полевых испытаний системы. Я не понимал, насколько много может быть изменений в ходе испытаний, до того как принял участие в полевом тесте проекта Nike на островах Кваджалейн.
    Большая ошибка в акте приемочных испытаний большой системы сделать запись: «Ошибок нет». Правильно указать: «на этапе испытаний ошибок не выявлено», потому что они обязательно есть, только их еще не нашли и не устранили.

    Даже наличие литеры Э1 и последующих литер Оn (ГОСТ 2.103—2013) на опытные образцы системы не гарантирует отсутствие ошибок. Оперативное внесение изменений параллельно в конструкцию и документацию (Гибкость в проектировании) – это норма при каскадном проектировании (хотя это почему-то приписывают только «гибким» agile), что при строительстве, что при производстве.

    Второе правило


    Часть проектирования системной инженерии — подготовка к изменениям, чтобы пройти через них успешно и не снизить производительность других частей.
    Этот тезис развился в отдельные современные направления «Управление изменениями», «Управление требованиями», в некоторых частных случаях, например, ITIL — «управлениями релизами» и т.п.
    Как я писал ранее, период полураспада подходов к проектированию составляет 15 лет — половина идей, которые вы узнаете сейчас, будут бесполезны через 15 лет.
    Сомнительный тезис. Проецируя на себя: мне намного больше дало изучение подходов к разработке военных систем (АСУ) и строительных ГОСТ и СНИП, которые я изучал 20 лет назад, чем современная литература примерно о том же, только в обертке «ЕА \ ВРМ» и с «маркетинговыми фишками», «цели бизнеса» и т.п.

    Хорошей технической литературы со временем становится все меньше, но основная проблема – она (иголка) теряется в «стоге сена», образованным маркетинговым мусором и тиражируемым по всему интернету. Нарастающий «как снежный ком» вал маркетинга и алхимии, неподтвержденных практикой теорий и домыслов – современная реальность.

    Вместо этого хотелось бы видеть такой же по объему архив (репозитарий) реальных примеров, проектов, апробаций и результатов детального анализа внедряемых систем по этим методологиям и фреймворкам.

    Вообще, с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
    Если будет разработана качественная теория, то она будет «бессмертна» и востребована.
    Хотя она может (должна) развиваться, но не со сменой курса на 180 градусов.

    Кстати, тогда же я сравнивал стадии проектирования в ГОСТах на АСУ (24.ххх, 34.ххх) и в строительных (21.ххх) и других (ЕСКД-ЕСПД), стадии в методологии АРИС и еще в чем-то (не помню уже). И все сводилось к одному:

    1) предпроект (аванпроект, концепция и т.п.)
    2) эскизный проект, технический проект, рабочий проект
    3) испытания, приемка, внедрение

    В разных методологиях – разные термины, но суть на удивление – одинакова (классический каскад), в том числе и внутри указанных стадий. Причем независимо от масштабов: строим радиостанцию, танк, здание, АСУ, предприятие.

    Этот «классический каскад» — фактически основа «системного подхода» к проектированию сложных систем.

    Интересно, что эти самые «разные методологии», в которых указаны одни и те же SE-принципы, могут относиться как непосредственно к SE, так и ЕА и ВРМ. Например, стадии проектирования ТОГАФа обсуждаем в комментариях к Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие

    Так зачем такой зоопарк методологий?
    Мы говорим о «серьезных изделиях», полагаю, что использование agile (как альтернатива каскаду) и т.п. «как основы» при разработке что танка или самолета, что ядерного реактора или систем типа «мертвая рука» — никому в голову не придет.

    Третье правило


    Чем точнее вы отвечаете спецификациям, тем хуже будет производительность при перегрузке.
    Это элемент «оптимизации». За отход от оптимизации – в сторону «повышения надежности», запаса прочности и производительности и т.п. – нужно «платить», платить «неоптимизацией». Если мы хотим иметь запас «прочности», включая запас производительности, то оптимизацию – лучше не ставить приоритетом.

    Более тонкий корпус делает более дешевым и более легким изделие, но менее ударопрочным (при одном и том же материале) и защищенным. Поэтому дома и мосты должны строиться с запасом прочности.
    Вся оптимизация — это управление компромиссом. Можно сэкономить «на спичках» и построить точно по заданным требованиям, но потерять главное качество.
    … я верил, что маленькие задачи были относительно более важными, чем большие.
    Это продолжение тезиса «За деревьями леса не видеть леса». Вообще, этот тезис – один из основных в SE и часто повторяется, см. в том числе, книжку «Системная инженерия для чайников» от IBM.

    Оптимизируя «каждое дерево», можно загубить весь лес. Хотя бы потому, что одни деревья станут очень большими («локальной оптимизации отдельных лиц») и закроют тенью всех остальных, что их погубит, т.е. «достигнуть глобальной оптимизации всей системы» не получится.
    Вестерман, как и я, полагает, в то время как клиент может знать о некоторых симптомах, он может не понимать реальных их причин. А это глупо, пытаться вылечить только симптомы. Таким образом, не смотря на то, что системные инженеры должны слушать клиента, они также должны попытаться выудить из него более глубокое понимание феномена. Поэтому работа системного инженера — определить в более глубоком смысле, какова проблема и как перейти от симптомов к реальным причинам
    Это вылилось в различные ветки, например, в ITSM: «Управление обращениями», «Управление инцидентами», «Управление проблемами» и т.п. Это методы связывания разных следствий (инцидентов) к одной причине (проблеме).

    Причинно-следственные связи и поведение элементов в сложной системе – не очевидны и для выявления этих связей выделяют целые направления, например, «Управление конфигурацией», когда через визуальное представление (картинку) связей элементов можно приблизиться к пониманию проблемы.

    Вестерман полагает, что, по-видимому, искусство системной инженерии лучше изучать в команде, включающей как старые, так и новые лица. При этом он говорит о том, что более опытных коллег стоит постепенно убирать из процесса и вводить новых людей в команду. Я не знаю, как передать мой личный опыт «одинокого волка». Я могу только рассказать о том, что делал и как себя вел в определенных ситуациях.
    И я про это же: достаточно опубликовать конкретные проекты по SE, ЕА, ВРМ и показать, откуда были взяты направляющие «что и как сделать» (стандарты, фремворки) и как были применены эти самые стандарты и фреймворки, какие проблемы возникли и как были решены. Всего лишь «только рассказать» и показать на конкретном подробном реальном или вымышленном примере.
    Но позвольте уточнить еще раз. Системная инженерия должна строиться на прочной основе классического упрощения до конкретных проблем с определенным решением.
    «Врага нужно бить поодиночке», а сложную задачу решать по частям (т.е. декомпозировать, упрощать) и т.п. – это все заповеди SE, такие же, как про «лес и деревья».
    Какой на Ваш взгляд ключевой документ по SE? Не методология типа ГОСТ или ISO/IEC 15288
    или даже Systems Engineering Body of Knowledge (SEBoK)
    а практический документ для конкретной системы (артефакт проекта).

    Это не схема работы системы, показывающая принцип ее действия или детальная спецификация и даже не проектная «клюква» (набор проектных документов по каждому элементу системы) и география (территориальное размещение компонентов системы).

    Это Схема деления изделия на составные части (ГОСТ 2.711-82). В этом и заключена детализация системы на элементы: изделия на отдельные под-изделия – составные части, которые в свою очередь являются изделиями (возможно даже изделиями типа «сложная система», некоторые покупные и т.п.).

    Заходишь в кабинет главного конструктора, а у него почти во всю стену 6х3 весит всего одна «Схема деления» и с достаточно мелкими элементами (несколько сотен). Это к высказыванию Хэмминга:
    Системная инженерия — это попытка всегда держать основные цели в голове и понимать, для чего совершается каждое локальное действие, и как оно влияет на общий результат. Тем не менее, здесь нет какой-то одной конкретной большой картинки.
    Это и есть «одна конкретная большая картинка», да еще и с децимальными номерами и пояснениями типа «разрабатываемое» или «покупное» изделие.

    Аналог «нашей» Схемы деления по ГОСТ — это «D.1.3 Структура системы» из «ихнего» ISO/IEC 15288, только «наша» оформлена в виде стандарта еще в 1982 и с более детальной нотацией. Вообще, при чтении «современных» западных стандартов на SE, вспоминается аналогии из ГОСТ 2.ххх, 34.ххх, а также из ГОСТ РВ 15.ххх.

    С точки зрения ЕА, такая «одна конкретная большая картинка» — это заполненная табличка Захмана по конкретному предприятию (фреймворк Захмана показан в предыдущей моей статье). Видимо при декомпозиции большой системы на подсистемы потребуется составление под каждую — собственной (отдельной) таблички Захмана.
    Я уже упоминал об этом, но позвольте заметить еще раз: решение, которое не дает более глубокого понимания — плохое решение, но, возможно, что это всё, что возможно сделать в текущем временном ограничении. Целью системной инженерии должно быть более глубокое и долгосрочное понимание сущности проблемы, в то время как клиент всегда хочет увидеть оперативное избавление от текущих симптомов. Опять же, конфликт, ведущий к мета-системной инженерии!
    В идеале пользователь (клиент) всегда ждет от ERP, АСУ и т.п. режим: «пришел на работу, нажал Большую красную кнопку и ничего более делать не нужно: система сама поработает. Главное не забыть при завершении рабочей смены отжать Большую красную кнопку».

    Видимо – это несбыточная мечта или порог, после которого последует SkyNet.
    Как пример углубленного понимания системы и её проблем, я хочу рассмотреть проект управляемых ракет Nike.
    У меня сложилась уверенность, что рассвет системной инженерии «там» (США) и системотехники «здесь» (СССР) пришелся на период холодной войны. После «потепления» у нас оно вообще оно погибло и исчезло как отечественная «Best Practice», а там трансформировалось в некий инструмент маркетинга (вообще, лидер в этой номинации ISO 9000). Видимо ничто так не мобилизует человека, как угроза его выживанию.
    Системная инженерия — это безусловно увлекательная профессия, которую трудно практиковать.
    Проектирование АСУ и предприятия, процессов организации – всегда подразумевают практику SE. Почитать по SE много чего есть, на мой взгляд, это еще не наука, но через фильтр «маркетинга» можно фильтровать полезность.

    Поэтому читать книжки (тем более статьи) по ЕА и ВРМ и SE нужно прошептав: «Осторожно маркетинг», исключения составляют книжки (включая, западные) и отечественные ГОСТы советского периода. Отфильтрованное от маркетинга можно применять, но непонятно где: отечественная наука и промышленность «на коленях», вся идеология, методология и вся «комплектуха» — западные.

    Неплохая практическая книжка по SE применительно к АСУТП: «Проектирование АСУТП», Нестеров.

    Практиковать «по полной программе» системную инженерию можно видимо только в оборонке, но там совсем иной уровень используемых технологий, а недавний лозунг «импортозамещение» (читай элементарная индустриализация) — уже видимо похоронен. Следовательно, говорить о пост-индустриализации – просто смешно, мы еще (точнее уже) находимся (откатились) в «до-индустриализации».

    Что такое SE


    Systems engineering в понимании Хемминга – это то же самое, что «системная инженерия 2018» и системотехника сегодня? Скорее всего «да».

    SE — это подходы к проектированию систем. Каких систем? Любых, но сложных. Точнее земных. Солнечную систему проектировать видимо нужно по другим методологиям. В идеале SE должны объясняить как строить не только технические системы, но и экономические, социальные (включая коммунизм, почему бы и нет? To be «светлое будущее», roadmap №2 на основе framework «1917»).

    Простые системы также можно проектировать по SE, но это будет «не оптимально».

    Универсальность SE обусловлена «взятием на вооружение» принципа «системного подхода», комплексного взгляда на разрабатываемое (модернизируемое) изделие – как на «сложную систему».

    Как правило, «деталь» и «программа» – не включаются в категорию «система». В такую категорию выделяют нечто сложное, например, «самолет» или «большая программа» (ERP), тем более — объекты типа АСУ и «предприятие» — это настоящие «системы».

    Точно также, как PMBOKу — все равно какие проекты по нему реализовывать, то и для SE – собственно не так важно какие изделия типа «система» по нему строить и внедрять.
    Хотя системы типа «самолет», «АСУ» и «предприятие» — должны проектироваться по разным ответвлениям SE (принцип общий, но есть специфика).

    Вследствие общности проектирования любых АСУ и произошло объединение в рамках одного ГОСТ 34.ххх подходов к проектированию АСУ разных классов и просто «автоматизированных систем».

    Вообще, когда я читаю многие современные статьи и «открытия» по теме SE, ЕА, ВРМ, то часто возникает ощущение, что это уже ДАВНО читал, причем не в ГОСТах. Вспоминаются статьи двадцатилетней давности, типа «Сага о корпоративных информационных системах и их пользователях», см. ее начало
    Интересно, у кого-нибудь есть подобное Дежавю?
    Тогда все книжки на тему «Корпоративные информационные системы» были про ЕА, ВРМ вперемешку с SE. Понятия КИС, АСУ, ИТКС сегодня «постарели», но проблемы остались точно такие же.

    Заключение


    Системная инженерия \ системотехника, ЕА, ВРМ – в целом если не «одно и то же», то родственные понятия. Основные различия в их позиционировании и в маркетинге. Впрочем, как и понятия: ERP, CRM, Системы документооборота и т.п. Например, идентичный модуль «обработка клиентской заявки» может быть основным элементом любой из указанных программных систем.

    Системная инженерия, ЕА, ВРМ – должны когда-нибудь стать настоящей наукой и инженерией, точно также как и «коды Хэмминга». Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»), проектирование, проверку качества и точности исполнения изделий класса «система».

    Неважно, какая это «система»: АСУ, включая, АСУ войсками, АСУТП или государственные информационные системы, «электронное правительство», или целое «предприятие» (ЕА), включая, домохозяйство, бизнес (ИП, МСБ, «корпорат»), государство.

    В этом случае любой начинающий проектировщик мог бы с легкостью, аналогичной описанию «кода Хэмминга», использовать SE, ЕА и ВРМ в своей практике.

    Основной мотив SE и вообще автоматизации

    Все сводится к тому, что есть механизм и система управления (СУ) этим механизмом. Механизм – это автомобиль или аппаратно-программный комплекс и т.п. Управляет механизмом человек или робот (автомат, демон) или совместно.

    Робот всегда действует по инструкции, а человек или по инструкции или по «своему усмотрению». Поэтому бизнес-правила, логика исполнения, алгоритм и т.п. — хранятся в инструкции, программе или в «черепной коробке» исполнителя. Главное, что они (правила) всегда есть.

    Методики SE нацелены на минимизацию последнего, причем как в процессе проектирования системы (т.е. проектирование по шаблону, фреймворку), так в процессе сопровождения системы (также по шаблону, регламенту).

    Когда возникает необходимость «принятия решения человеком», что проектных решений — главным конструктором, что заключение важной сделки – директором, то это регламентируется (ограничение полномочий и т.п.), фиксируется и документируется.

    Соотношение логик: логики из «бумажной инструкции», зашитой в программу логики (алгоритм ПО) и логики, зашитой в «черепную коробку» исполнителя, – определяют «уровень автоматизации», «уровень формализации», в том числе, «уровень детализации описания ЕА». SE направлен на минимизацию «творчества» (контроль «вольности») и построение четко регламентированных процессов проектирования и сопровождения сложных систем. Четкий регламент проектирования и внедрения.

    Если в простых системах все это не столь критично, то в сложных, особенно критически важных – это просто необходимое условие. Управление «сложностью» требует четкого и простого понятийного аппарата и простых шагов реализации процесса, какую бы сложную систему мы не проектировали.

    На сегодня SE не позволяет полноценного проектированная ни в области ЕА (проектирование предприятия или его АСУ), ни проектирования процессов (BPM). Можно конечно сказать, что это не является задачей SE, но это лишь отговорка.

    Тем не менее, стандарты SE более понятны, чем ЕА и BPM, и более полезны, но насколько я понимаю, с каждым годом происходит сокращение проектов, реализуемых по ним. Во всяком случае, (по субъективным ощущениям и публикациям) 20 лет назад их было больше, чем 10 лет назад, а сегодня их меньшее, чем 10 лет назад.

    Будущее SE

    Меня удивляют современные подходы абсолютной закрытости проектирования гражданских систем, тем более государственных за бюджетные средства. Когда эта «стена рухнет» и будет проектирование «не вслепую», а с учетом огромной базы примеров и прототипов, то будет совсем другой подход к SE, а также, соответственно, и к ЕА и ВРМ и другим направлениям проектирования.

    Разрабатывать ТЗ на систему, у которой тысячи аналогов – какой смысл? SE необходимо только для уникальных систем, которых еще ни у кого не было, т.к. они разрабатываются впервые. Таких систем, не более 0,1% из всей массы. Разговоры, что все системы и все предприятия – уникальны и их нужно проектировать «с нуля» через ТЗ и RFP, — это «маркетинговый трюк».

    Со временем (видимо при коммунизме) основой построения систем будет заимствование действительно лучших решений, а не решений, выдаваемых консалтерами за «лучшие», чтобы лишь их продать. Референтные (эталонные) модели, типовые проекты (типовые формы проектов), прототипы, унификация решений – вот ключевые элементы будущего проектирования. Это возможно только при открытом проектировании и свободном обмене проектными решениями.

    По аналогии со Студопедией (информационный ресурс для студентов, чтобы помочь им в написании рефератов, курсовых, контрольных работ, дипломных работ и докладов) должны появиться аналогичные Проектопедии для проектировщиков.

    Статью подготовил «на скорую руку» за день, так чтобы ее читали прямо «вдогонку» к переводу «Ричард Хэмминг: Глава 28. Системная Инженерия», поэтому где-то неточно выразил мысль и, возможно, где-то «погорячился» (не особо подбирал «смягчающих» глаголов, «рубил правду-матку»), допустил неточности и опечатки.

    Ваш, bipiem
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 118
    • +1
      Любое проектирование «большого и сложного» — должно базироваться на SE

      Нет.


      Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE?

      Нет.


      Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE

      Нет.


      Так как SE — это проектирование всего «большого и сложного», то по «определению» оно пересекается практически со всем известным из «Best Practice» & ххBOK, включая «SE & PMBOK», «SE & ITSM»

      И тоже нет.


      Если ЕА и ВРМ считаем алхимией, а SE не опровергает их подходы, а наоборот «дополняет», а зачастую «дублирует и повторяет»,

      А из чего вы взяли, что системная инженерия "дополняет", "дублирует и повторяет" методы enterprise architecture и BPM?


      то можно поставить под сомнение утверждение, что SE – это инженерная дисциплина.

      А где это утверждение было сделано? Открываем первую попавшуюся википедию, читаем: "Systems engineering is an interdisciplinary field of engineering and engineering management". Все ровно как в ваших цитатах — междисциплинарный подход. В SEBoK то же самое, и делается упор на междисциплинарность. Вроде, никто не говорит, что это инженерная дисциплина. Так что вы ставите под сомнение утверждение, которого никто не делает.


      Я проецирую эту мысль на наше время, как необходимость привлечения самих бизнес-пользователей «напрямую» к описанию и оптимизации своих бизнес-процессов без использования ИТ-специалистов (BPM-специалистов, ЕА-архитекторов и прочих алхимиков) и программистов.

      К сожалению, опыт показывает, что большая часть бизнес-пользователей не обладает достаточной квалификацией. Причем я не говорю о BPM, EA или SE — существенная часть пользователей не способна самостоятельно корректно описать существующие процессы. Аналитика совершенно не зря является отдельным этапом.


      Умеем лишь переводить «западную алхимию», перепродавать западную «комплектуху» и из нее лепить системы (комплексировать), что в ИТ

      Вы опять по себе судите, да? Я в этом году как двадцать лет разрабатываю программные системы, и часть из них успешно применяется зарубежом. Так что я не знаю, как вы, а я вполне успешно имею дело с отечественной ИТ-индустрией, включая экспортную.


      Да, верно, но только — пока эти направления: SE, ЕА, ВРМ — находятся на уровне развития «алхимия». Когда это станет реальной наукой и будут детальные и обоснованные (доказанные) и апробированные походы, то «следовать будет просто», даже начинающему.

      Недоказуемое утверждение. Вы знакомы со спецификой гуманитарного знания? (и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами) Так вот, многие люди вообще не считают, что к гуманитарному знанию применим научный подход (та его часть, которая с экспериментами и доказательством). Есть множество устоявшихся и признанных отраслей гуманитарного знания, в которых непросто следовать начинающему. Да даже и в STEM есть куча таких отраслей, чего уж.


      Проецируя на себя: мне намного больше дало изучение подходов к разработке военных систем (АСУ) и строительных ГОСТ и СНИП, которые я изучал 20 лет назад, чем современная литература примерно о том же, только в обертке «ЕА \ ВРМ» и с «маркетинговыми фишками», «цели бизнеса» и т.п.

      Откройте оригинал, в котором написано следующее:


      I cited earlier the half-life time of engineering details as being 15 years — half of the details you learn now will probably be useless to you in 15 years.

      Так вот, в программировании, и вообще в IT это более чем верно; более того, я склонен думать, что сроки сейчас еще меньше.


      Какой на Ваш взгляд ключевой документ по SE? [...] Это Схема деления изделия на составные части (ГОСТ 2.711-82). В этом и заключена детализация системы на элементы: изделия на отдельные под-изделия – составные части, которые в свою очередь являются изделиями (возможно даже изделиями типа «сложная система», некоторые покупные и т.п.).

      И как этот "ключевой документ" отвечает на (а) вопросы управления жизненным циклом и (б) вопросы о целях и задачах?


      Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»)

      Сама природа бизнес-требований такова, что их формализация возможна только до определенной степени. И это как раз не инженерное знание.


      Разрабатывать ТЗ на систему, у которой тысячи аналогов – какой смысл?

      Гигантский, очевидно. Как вы предлагаете разрабатывать систему без ТЗ?


      SE необходимо только для уникальных систем, которых еще ни у кого не было, т.к. они разрабатываются впервые.

      Нет, SE необходима для всех (достаточно сложных) систем, потому что иначе вы не справитесь с реализацией. Напоминаю еще раз, SE — это дисциплина.


      Со временем (видимо при коммунизме) основой построения систем будет заимствование действительно лучших решений

      Осталось всего ничего — придумать критерий "лучшего решения".

      • +1
        SE необходима для всех (достаточно сложных) систем, потому что иначе вы не справитесь с реализацией

        … я сам себе противоречу, конечно же. Нет, SE не необходима, потому что есть люди, которые справляются с проектами без всякой SE. Но все равно, необходимость SE на проекте определяется не уникальностью системы, а ее сложностью и навыками людей, участвующих в реализации.

        • 0
          Но все равно, необходимость SE на проекте определяется не уникальностью системы, а ее сложностью и навыками людей, участвующих в реализации.

          Зачем SE, если нужно просто тупо повторить уже имеющийся прототип. Типовая система, понятно как она работает, проектные риски минимальные, есть на нее описание и т.п.
          Фактически «серийное производство». Даже если завод-изготовитель (компания – разработчик) будет другой, то к чему ТЗ, проекты (эскиз, тех., раб.) и т.п.? Какой бы сложной система не была.
          Типовые системы нужно тиражировать, а не «изобретать велосипед» в придачу с SE. Только уникальные нужно проектировать.
          навыками людей, участвующих в реализации.

          Это не причем. Промышленная разработка (конструкторское бюро, КБ, «фабрика» программистов и т.п.) даже высокотехнологичных изделий должна опираться не на «гениев», а на базовый уровень разработчиков.
          Поэтому и предельно регламентируются все этапы конвейера разработки, чтобы получить гарантированное качество вне зависимости присутствия на конвейере (в КБ) «гения».
          • 0
            Зачем SE, если нужно просто тупо повторить уже имеющийся прототип.

            Чтобы понять, что этот прототип применим к задаче. Чтобы понять, как его повторять. Чтобы внедрить и поддерживать.


            Это не причем. Промышленная разработка (конструкторское бюро, КБ, «фабрика» программистов и т.п.) даже высокотехнологичных изделий должна опираться не на «гениев», а на базовый уровень разработчиков.

            Вот именно поэтому "причем". Гениям не нужна системная инженерия, им не нужно планирование, им много что не нужно. Все эти вещи придумываются для того, чтобы декомпоновать задачу до уровня, доступного не-гениям.

        • 0
          Часть 1
          Уважаемый lair, благодарю Вас за внимание к моей статье, однако позволю себе ответить только на те Ваши замечания, которые содержат ненулевую аргументацию.
          А из чего вы взяли, что системная инженерия «дополняет», «дублирует и повторяет» методы enterprise architecture и BPM?

          Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?

          А где это утверждение было сделано? Открываем первую попавшуюся википедию, читаем: «Systems engineering is an interdisciplinary field of engineering and engineering management». Все ровно как в ваших цитатах — междисциплинарный подход. В SEBoK то же самое, и делается упор на междисциплинарность. Вроде, никто не говорит, что это инженерная дисциплина. Так что вы ставите под сомнение утверждение, которого никто не делает.

          Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?
          Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями? При этом она остается инженерной дисциплиной. А какой по-Вашему?

          К сожалению, опыт показывает, что большая часть бизнес-пользователей не обладает достаточной квалификацией.

          Конечно, только внешние консалтеры ей обладают. Мне это напоминает анекдот:
          Про исследовательский бизнес есть анекдот. Около стада овец приземляется вертолет. Из вертолета выходит человек в костюме от Kiton и предлагает пастуху сделку: овца в обмен на точную информацию о поголовье стада. Пастух соглашается, человек подключает ноутбук к серверу NASA, получает необходимое спутниковое фото и печатает отчет на 150 страницах, из которого следует, что в стаде 3141 овца.
          Забирает гонорар, но тут пастух делает ответное предложение: «Я точно называю твой бизнес, а ты отдаешь овцу назад».— «Идет».— «Ты — консультант».— «Как узнал?» — «Ты пришел, когда не звали, взял плату за то, что я и без тебя знаю, да и в моем деле ты ноль — отдавай мою собаку!»

          Вы про такую аналитику?
          Я в этом году как двадцать лет разрабатываю программные системы, и часть из них успешно применяется зарубежом. Так что я не знаю, как вы, а я вполне успешно имею дело с отечественной ИТ-индустрией, включая экспортную.

          За Вас я рад. Однако почти все мои соотечественники и я юзают западное ПО. Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.

          Есть наверно отдельные спец-форумы, где более точно покажут, что вокруг происходит, но мне казалось, что «невооруженным» глазом ХОРОШО видно окружающие нас отечественные программы, компьютеры и гаджеты.

          Один и свежий пример. Купили телефончик Хонор, две недели поработал (настройки заводские, ничего не меняли), потом он перестал принимать пароль. Далее recovery boot. И всё: Game Over.
          Далее — запрос аккаунта гугл (FRP) – который не принимается (типовая ситуация, судя по отзывам в инете). Про блокировку запроса аккаунта гугл (FRP) написано сотни статей, Прочитал 20 статей, попробовал 20 способов (перебор secret code – это только один из них) не сработали.
          Случайно подошел пример, размещенный на совсем не ИТ-форуме.
          Каждый из нас – потенциальная жертва подобной политики гугл. Все андороиды подвержены такой фитчи или багу или как еще это назвать. Уверен, что нечто подобное случается и с «огрызками».

          Это что «технологическая независимость»? Отечественный софт? Это игла, на которой сидит каждый обладатель смартфона с андроид начиная с такой – то версии.
          Кстати это тема как для «прокачки» в терминах SE, так и ЕА\НА (подсистемы home office, системная архитектура в НА).
          Продолжение по второй части.
          • +1
            те Ваши замечания, которые содержат ненулевую аргументацию.

            Бремя доказательства лежит на утверждающем.


            Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?

            Из отсутствия подтверждающих цитат.


            Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?

            Да, именно так.


            Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями?

            Нет. Открываем SEBoK: "Interdisciplinary approach governing the total technical and managerial effort required to" (выделение мое). Управленческие усилия — не инженерная дисциплина.


            (С другой стороны, будем честными, я вот пошел искать определение инженерной дисциплины — и не нашел. Bad for me. Каким определением пользуетесь вы, говоря, что SE — не инженерная дисциплина?)


            Конечно, только внешние консалтеры ей обладают.

            Нет, ей обладают люди, которые занимаются анализом как дисциплиной, не важно, внешние они или внутренние.


            Вы про такую аналитику?

            Нет, я про качественно проведенный бизнес-анализ.


            Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.

            … а это какие, если не секрет?


            Каждый из нас – потенциальная жертва подобной политики гугл.

            Не используйте продукты гугл.


            Это что «технологическая независимость»?

            А я нигде не говорил про технологическую независимость. Я в нее и не верю, собственно говоря.

            • 0
              Бремя доказательства лежит на утверждающем.

              В данной ситуации: в статье приведены аргументы, Вы же на них просто заявили: «Нет», «И тоже нет», не представив аргументацию по этим «нет». Поэтому бремя переложено на Вас.
              Из отсутствия подтверждающих цитат.

              В самом начале:
              Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE, а в стандартах SE – постоянно говорится о «моделировании» и «процессах».
              Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)

              Это не цитаты, но смысл дают ясный.
              Вы действительно считаете, что в SE нет про моделирование процессов и архитектуру? В том же: ISO/IEC 15288 про это говорится.
              Управленческие усилия — не инженерная дисциплина.

              Они есть во всех процессах, системах и т.п. Это очень общий термин. Управление – это вообще нечто, присутствующее во всем и везде (типа «святого духа»). В любой «Best Practice» — о нем много и разного сказано.

              Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина».

              … а это какие, если не секрет?

              На память не помню, но много попадалось в заголовках новостей: всякие там реестры отечественных разработчиков софта, гранты куда-то и т.п. Если не найдете, скажите – погуглю.
              Не используйте продукты гугл.

              Ну очень смешно. Рад бы не использовать. Я же говорю, что гугл и механизм запроса аккаунта гугл (FRP) – зашиты в КАЖДЫЙ телефон с андроид:
              С появлением системы Android 5.1 Lollipop у пользователей появились не только новые полезные функции, но и откровенно тупящие «фичи». К примеру, Google FRP Lock, он же «защита от сброса настроек», суть которой заключается в защите телефона от злоумышленников, которые решили обойти блокировку смартфона путём сброса настроек.

              После сброса настроек пользователь обязан войти в Google аккаунт, к которому был привязан этот телефон, но очень часто бывает, что телефон просто не принимает правильный аккаунт и пароль.

              А я нигде не говорил про технологическую независимость. Я в нее и не верю, собственно говоря.

              А вот наши предки не только верили, но и добились этой независимости. И всё в стране было отечественное, т.е. сделанное «собственными руками». Сейчас это в прошлом. Прежде всего, потому, что давно нет веры. Но одной веры (если она и вернется) будет явно не достаточно.
              • 0
                В данной ситуации: в статье приведены аргументы

                Да нет же. В статье приведены утверждения, которые ничем не подтверждены. Возьмем первое же:


                Любое проектирование «большого и сложного» — должно базироваться на SE

                Это просто ваше высказывание, чем оно обосновано?


                Это не цитаты, но смысл дают ясный.

                Благодаря тому, что это не цитаты, они дают смысл того, что вы думаете, но нет никакого подтверждения, что так же думают методологи.


                Вы действительно считаете, что в SE нет про моделирование процессов и архитектуру?

                То, что в SE есть что-то про архитектуру и модели, не означает, что SE занимается тем же, что BPM и EA.


                управление – это вообще нечто, присутствующее во всем и везде (типа «святого духа»).

                Нет. В расчете подъемной силы крыла нет никакого управления.


                Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина».

                … и начинаете спорить с собственным же утверждением.


                Но вернемся к вопросу: что такое "инженерная дисциплина"? Каково ее определение? Какими свойствами она обладает?


                На память не помню, но много попадалось в заголовках новостей: всякие там реестры отечественных разработчиков софта, гранты куда-то и т.п. Если не найдете, скажите – погуглю.

                Не нашел.


                Ну очень смешно. Рад бы не использовать. Я же говорю, что гугл и механизм запроса аккаунта гугл (FRP) – зашиты в КАЖДЫЙ телефон с андроид:

                Не используйте андроид.


                А вот наши предки не только верили, но и добились этой независимости. И всё в стране было отечественное, т.е. сделанное «собственными руками». Сейчас это в прошлом.

                Не вижу смысла спорить о прошлом; а в настоящем этой независимости нет. И это одна из причин, почему я не верю в ее достижимость.

                • 0
                  «Любое проектирование «большого и сложного» — должно базироваться на SE»
                  Это просто ваше высказывание, чем оно обосновано?

                  Например, также думают Авторы: В. К. Батоврин. Ф. И. Голдберг. А. В. Александров.
                  Системная инженерия, или системотехника — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем
                  Множество других авторов также подчеркивает, что по SE хоть и можно строить простые системы, но задумалась она именно под проектирование «сложных» и «больших».
                  Странно, что это вызывает у Вас вопросы.
                  То, что в SE есть что-то про архитектуру и модели, не означает, что SE занимается тем же, что BPM и EA.

                  Приводил несколько ссылок:
                  Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
                  Есть рассказы (байки) КАК АРХИТЕКТУРА ПРЕДПРИЯТИЯ ДОПОЛНЯЕТ СИСТЕМНУЮ ИНЖЕНЕРИЮ
                  Пересечение SE с ЕА выделяют в отдельное направление: ESE
                  Если недостаточно, то набираем в гугл: «Systems Engineering» «Enterprise Architecture».
                  Нет. В расчете подъемной силы крыла нет никакого управления.

                  Сам расчет уже предполагает, что нужен для управления.
                  … и начинаете спорить с собственным же утверждением.
                  Но вернемся к вопросу: что такое «инженерная дисциплина»? Каково ее определение? Какими свойствами она обладает?

                  БСЭ: www.ngpedia.ru/id6004p1.html
                  studopedia.ru/4_14767_programmnaya-inzheneriya-kak-inzhenernaya-distsiplina.html
                  Не используйте андроид.

                  Снова смеетесь? Вы в магазин телефонов заходили? На полке лежат только телефоны с андроид и пара «огрызков».
                  У покупателя нет выбора. Точнее есть из «плохо» и «очень плохо».

                  Я не против ОС андроид — я против того, чтобы гугл ставил обязательным условием использования телефона (причем как «звонилка») — условие использования сервисов гугл.

                  Если завтра огрызок и гугл попадут в список запретных в стране организаций, то мобильная связь в стране рухнет. Хотя гугл и не производит телефоны.
                  Даже без такого списка ситуация уже доведена до абсурда: гугл заблокирует Вашу учетку и не даст создать новую и Вы останетесь не только без приложений, но теперь уже и без связи: телефон даже не звонит, т.к. требует для этого учетку гугл.

                  Завтра каждый кран подачи воды в квартиру будет содержать «клапан гугл», требующий «активную учетку», и когда учетку заблокируют, то все погибнут от жажды. Это тем, кто «не верит в технологическую независимость».
                  • 0
                    Например, также думают Авторы: В. К. Батоврин. Ф. И. Голдберг. А. В. Александров.
                    Системная инженерия, или системотехника — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем

                    Не же, не думают. В определении написано: "дисциплина, которая изучает". Это не значит, что изучаемое должно строиться на этой дисциплине.


                    Множество других авторов также подчеркивает, что по SE хоть и можно строить простые системы, но задумалась она именно под проектирование «сложных» и «больших».

                    То, что SE задумывалась под проектирование A, не означает, что для проектирования A обязательно использовать SE.


                    Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)

                    Это отдельное направление. И там все еще не сказано, что это то же самое, что BPM или EA. Это просто применение принципов SE к предприятию.


                    Сам расчет уже предполагает, что нужен для управления.

                    Это не отменяет того, что в расчет управление не входит.


                    www.ngpedia.ru/id6004p1.html

                    Эта ссылка у меня не открывается.


                    studopedia.ru/4_14767_programmnaya-inzheneriya-kak-inzhenernaya-distsiplina.html

                    По этой ссылке сказано, что программная инженерия — это инженерная дисциплина, но нет определения инженерной дисциплины.


                    На полке лежат только телефоны с андроид и пара «огрызков».

                    Это немножко неправда.


                    Я не против ОС андроид — я против того, чтобы гугл ставил обязательным условием использования телефона (причем как «звонилка») — условие использования сервисов гугл.

                    Против — не используйте телефоны с ОС Андроид. Вот вам звонилка.


                    Завтра каждый кран подачи воды в квартиру будет содержать «клапан гугл», требующий «активную учетку», и когда учетку заблокируют, то все погибнут от жажды.

                    Нет, не будет.


                    Это тем, кто «не верит в технологическую независимость».

                    А технологическая независимость ничего не изменит. Просто блокировка учетки будет не у Гугла, а у Яндекса.

                    • 0
                      Эта ссылка у меня не открывается.

                      Да, перестала работать. Вот такие wiki.
                      Это была: Большая энциклопедия нефти и газа, а уже там «инженерная дисциплина».
                      Просто блокировка учетки будет не у Гугла, а у Яндекса

                      Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».
                      Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.
                      Остальные ответы позже.
                      • 0
                        Да, перестала работать. Вот такие wiki.

                        Лишний пример, почему надо не просто кидать ссылки, а приводить атрибутированные цитаты.


                        (на StackOverflow, скажем, просто не пропускают ответы, состоящие только из ссылки)


                        Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».

                        Еще один любитель законно введенных монополий.


                        Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.

                        Спасибо, я как-нибудь без этого обойдусь.

                        • 0
                          С андроидом — уже точно «не обойдусь».
                          Так нас с Вами никто спрашивать и не будет, ни гугл, ни яндекс, ни их кураторы. Блокировки будут (уже есть, как я показал выше) без нашего согласия.
                          • 0
                            С андроидом — уже точно «не обойдусь».

                            Именно поэтому если я хочу независимости от чужих решений, мне андроид не подойдет.


                            Блокировки будут (уже есть, как я показал выше) без нашего согласия.

                            … и чем вам поможет "технологическая независимость", кроме того, кто будет вас блокировать?

                            • 0
                              Именно поэтому если я хочу независимости от чужих решений, мне андроид не подойдет.

                              Введут контроль на все телефон-ОС, а неподконтрольные запретят. По аналогии с ТОР.

                              … и чем вам поможет «технологическая независимость», кроме того, кто будет вас блокировать?

                              У соотечественников рычагов давлении на яндекс и его куратора, все же несколько больше чем на гугл и его куратора. Разве нет?
                              • 0
                                Введут контроль на все телефон-ОС, а неподконтрольные запретят. По аналогии с ТОР.

                                Ну то есть запретят все телефоны (на российском рынке). Круто.


                                У соотечественников рычагов давлении на яндекс и его куратора, все же несколько больше чем на гугл и его куратора. Разве нет?

                                Нет.

                      • 0
                        Это отдельное направление. И там все еще не сказано, что это то же самое, что BPM или EA. Это просто применение принципов SE к предприятию.

                        «Это просто применение принципов SE к предприятию» — и означает «то же самое», применительно к «предприятию».
                        Про «перепевы» ЕА и SE:
                        Если читать wiki Архитектура системы
                        то текст по SE читается, как будто про ЕА.

                        А если открыть ISO/IEC/IEEE 42010-2011 ОПИСАНИЕ АРХИТЕКТУРЫ Systems and software engineering. Architecture description
                        то там (в стандарте на SE) рассказывается про ЕА:
                        4.5 Структуры архитектуры и языки описания архитектуры
                        Примерами структуры архитектуры в терминах настоящего стандарта являются: структура архитектуры Захмана для информационных систем [44], структура архитектуры британского Министерства обороны [27], структура архитектуры открытых групп (TOGAF) [41], модель представления Крухтена «4+1» [23], четыре метода представлений Сименса [10], эталонная модель для открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746] и обобщенная эталонная архитектура предприятия (GERA) [ISO 15704].
                        • 0
                          «Это просто применение принципов SE к предприятию» — и означает «то же самое», применительно к «предприятию».

                          "То же самое" — в смысле, SE. Не "то же самое, что и BPM".


                          Если читать wiki Архитектура системы то текст по SE читается, как будто про ЕА.

                          Если вам что-то читается одинаково, это еще не значит, что это одинаково.


                          то там (в стандарте на SE) рассказывается про ЕА:

                          И снова нет. Там говорится, что приведенные модели являются примерами структуры архитектуры так, как ее (структуру) понимает этот ISO. Это снова не означает, что SE занимается тем же, что и EA, это означает, что пересекается их инструментарий.


                          (я, кстати, вообще не уверен, что это "стандарт на SE", слишком уж заголовок расплывчатый)

                          • –1
                            В чем пересечение ЕА и SE (желательно список)?
                            Что значит:
                            пересекается их инструментарий.
                            • 0
                              В чем пересечение ЕА и SE (желательно список)?

                              Это не ко мне вопрос. Вы начали утверждать, что EA и SE — это одно и то же, вам и приводить список "одного и того же" (два непустых множества не могут быть идентичными, если у них нет пересечений).


                              Если верить приведенному вами стандарту, то некоторые из методологий EA используют те же архитектурные диаграммы, что и какая-то методология SE.


                              Что значит: "пересекается их инструментарий"

                              Это значит, что какие-то из инструментов, используемых SE, используются и в EA.

                              • –1
                                Это значит, что какие-то из инструментов,

                                Что в данном случае, Вы понимаете под «инструментом»?
                                Желательно с конкретными примерами.
                                • 0

                                  Например, нотацию для архитектурных диаграм (я не говорю, что EA и SE действительно используют общую нотацию, но если бы использовали — это был бы такой инструмент).


                                  Но какое это имеет значение?

                                  • –1
                                    Например, нотацию для архитектурных диаграм

                                    Можно еще три — четыре примера
                                    Но какое это имеет значение?

                                    Нужно понимать, что Вы имеете ввиду, т.к. мне кажется, что часто наш диалог напоминает «глухого со слепым».
                                    Если Вы так активно взялись за критику (за что Вам спасибо), то на вопросы по конкретике к SE, ЕА, ВРМ как то странно от Вас слышать:
                                    Это не ко мне вопрос.

                                    • 0
                                      Можно еще три — четыре примера

                                      Нет, сходу в голову не приходит.


                                      Нужно понимать, что Вы имеете ввиду,

                                      А зачем? Что это изменит в аргументации?


                                      как то странно от Вас слышать:

                                      А мне странно от вас слышать просьбы доказать ваши тезисы.

                                      • –1
                                        > Нужно понимать, что Вы имеете ввиду,
                                        А зачем? Что это изменит в аргументации?

                                        Пытаюсь понять Вашу позицию. Понял, что она всегда противоположна моей. Это нормально. Но какая она конкретно — понять не могу. Поэтому и спрашиваю «конкретно».

                                        Если есть конкретная позиция – есть смысл спорить, а если нет, то, видимо, – нет.
                                        Утверждаю, что «пересекаются» – в ответ:
                                        «И снова нет. … это означает, что пересекается их инструментарий.»
                                        Что за «инструменты»? – «Нет, сходу в голову не приходит.»

                                        Меня не устаревают ответы типа: «Если вам что-то читается одинаково, это еще не значит, что это одинаково».
                                        Нужна конкретика. На отвлеченные темы (офтопики) — у Вас конкретика есть (примеры зодчества и т.п.), то теме SE\EA\BPM — нет.

                                        Может быть, есть смысл вначале вникнуть в тему и сформировать собственное мнение, а потом уже обсуждать по существу?
                                        • 0
                                          Пытаюсь понять Вашу позицию. Понял, что она всегда противоположна моей. Это нормально. Но какая она конкретно — понять не могу.

                                          А она очень проста (и я ее озвучивал): вы делаете много расплывчатых утверждений, которые не основаны ни на чем, кроме вашего собственного суждения.


                                          Утверждаю, что «пересекаются»

                                          В том-то и дело, что вы утверждаете совсем не это. Вы утверждаете, дословно: "там (в стандарте на SE) рассказывается про ЕА".


                                          Меня не устаревают ответы типа: «Если вам что-то читается одинаково, это еще не значит, что это одинаково».

                                          Ну так не приводите аргументы типа "текст по SE читается, как будто про ЕА", не приводя ни одного из текстов.


                                          Нужна конкретика.

                                          Прекрасно. Начните с себя. Вы говорите "можно поставить под сомнение утверждение, что SE – это инженерная дисциплина", но не говорите ни что такое "инжереная дисциплина" (вы до сих пор не привели определения), ни кто утверждает, что SE – это инженерная дисциплина. Более того, дальше вы пишете, что это ваше утверждение ("Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина»").

                                          • –1
                                            Ответьте, пожалуйста, прямо: У Вас есть собственная конкретная позиция по SE\EA\ВРМ?
                                            Если есть, то какая?
                                            То, что она уже «по определению» противоположна моей, — это понятно. Не понятно, какая она конкретно.
                                            • 0
                                              Ответьте, пожалуйста, прямо: У Вас есть собственная конкретная позиция по SE\EA\ВРМ?

                                              По BPM — нет. По SE/EA — да, есть: что это существующие дисциплины, которые, будучи разумно примененными, приносят пользу.


                                              (заметим в скобках, что вы снова потребовали от меня конкретики, полностью проигнорировав конкретные вопросы)

                                              • –1
                                                По BPM — нет. По SE/EA — да, есть: что это существующие дисциплины, которые, будучи разумно примененными, приносят пользу.

                                                Яды, «которые, будучи разумно примененными,» ТОЖЕ «приносят пользу.»
                                                Конкретная позиция есть по SE/EA\ВРМ?
                                                Хотя бы чем BPM отличается от EA?
                                                • 0
                                                  Конкретная позиция есть по SE/EA\ВРМ?

                                                  Я ее уже озвучил.


                                                  Хотя бы чем BPM отличается от EA?

                                                  Я же сказал, что по BPM у меня позиции нет.

                                                  • 0
                                                    Я же сказал, что по BPM у меня позиции нет.

                                                    Выходит, что по ЕА – «есть», а по ВРМ – «нет».
                                                    Только ВРМ – это во многом (более половины) тот же ЕА.
                                                    Снова «нет»?
                                                    • 0
                                                      Выходит, что по ЕА – «есть», а по ВРМ – «нет».

                                                      Ну да, а что вас удивляет?


                                                      Только ВРМ – это во многом (более половины) тот же ЕА.

                                                      Это ваше утверждение, которому у меня нет никаких оснований доверять. Но даже если бы оно было верным, что это меняет?

                                                      • –1
                                                        Как минимум, то, что это «перепевы» одного «и тогож» (про отнесение их к алхимии – даже не указываю).
                                                        С чем, насколько я понял – Вы не согласны.

                                                        Хотя я уже потерялся, с чем согласны, а чем нет (знаю точно, что не с моим мнением, поэтому как-нибудь его поменяю под Ваш ответ, для подтверждения своей гипотезы).
                                                        А из чего вы взяли, что системная инженерия «дополняет», «дублирует и повторяет» методы enterprise architecture и BPM?
                                                        … (и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами)

                                                        Вы же утверждали о всех трех дисциплинах.

                                                        Простите, но по этой ветке я «пас». Если человек хочет донести свою мысль (когда его просят), то когда он видит, что его не понимают, он напишет «много букв», как это делаю я и другие участники обсуждения в этом топике.
                                                        • 0
                                                          Как минимум, то, что это «перепевы» одного «и тогож»

                                                          Это никак не вытекает из моих слов. Если вы так считаете — это ваше право, но я могу иметь мнение об одном, и не иметь мнения о другом.


                                                          С чем, насколько я понял – Вы не согласны.

                                                          Я не согласен с вашим утверждением, что "это перепевы одного и того же", потому что приведенные вами аргументы меня не убеждают.


                                                          Вы же утверждали о всех трех дисциплинах.

                                                          Я утверждал, что все они частично являются гуманитарными. Продолжаю так считать, да.


                                                          Если человек хочет донести свою мысль (когда его просят), то когда он видит, что его не понимают, он напишет «много букв», как это делаю я и другие участники обсуждения в этом топике.

                                                          Во-первых, мои "много букв" были раньше, и вы их прекрасно проигнорировали. Во-вторых, я в среднем не считаю, что "много букв" облегчает понимание; зачастую, наоборот.

            • 0
              Часть 2
              и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами)

              Для меня это новость.
              Так вот, многие люди вообще не считают, что к гуманитарному знанию применим научный подход (та его часть, которая с экспериментами и доказательством).

              я все же про то, что можно проверить опытным путем и мне казалось, что все законы и утверждения SE, EA, BPM могут (должны) быть апробированы. При условии, что SE, EA, BPM — устойчиво «встанут» на путь науки и инженерии.
              Так вот, в программировании, и вообще в IT это более чем верно; более того, я склонен думать, что сроки сейчас еще меньше.

              Я привел личный опыт. Для меня именно те сведения были более значимыми, чем «современная литература». Правда, читал избирательно — далеко не все, но ее появилось «очень много», как стог сена (может иголки не заметил).

              Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
              А им намного больше 15 лет.
              И как этот «ключевой документ» отвечает на (а) вопросы управления жизненным циклом и (б) вопросы о целях и задачах?

              На эти вопросы – никак, но это все равно ключевой «документ – артефакт» в SE.
              Хорошо, а Ваше мнение – какой документ самый ключевой?
              Гигантский, очевидно. Как вы предлагаете разрабатывать систему без ТЗ?

              Да, большинство систем должны просто тиражироваться. Даже если есть особенность, то не нужно составлять 50 страниц абстрактных требований, а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.

              ОЧЕНЬ мало людей, кто может составить качественное ТЗ. Почти все ТЗ – это «филькина грамота» и они «работают» в интересах поставщика, а не заказчика: лишь на том принципе, что заказчик никогда грамотное ТЗ не составит. Тогда разработчик говорит «сам дурак» и требует деньги на доработку. Хотя изначально понимает, что нельзя никак сделать качественное ТЗ.

              Чтобы составить грамотное ТЗ – нужно большие трудозатраты (причем периодические и поэтапные уточнения). Мне попадались оценки, что грамотное ТЗ «стоит» не менее 30% общих трудозатрат на проект.
              Иначе получается типовой сценарий, смотрите картинку Проект «Тарзанка»
              Мне казалось, что это уже понятно многим. Сейчас иногда встречается договоренность, что договор предусматривает 30% доработок по уточнению ТЗ при фиксированной стоимости работ.

              ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем. Но это видимо лишь в будущем, пока такие простые истины еще не очевидны и победа за «управленческими уловками» подрядчиков.
              Отвечать лучше отдельным постом, уверен, что это будет отдельная дискуссия.
              Осталось всего ничего — придумать критерий «лучшего решения».

              Вот именно. Я уже про этот «трюк» указывал в статье.
              Под вывеской «Best Practice» — часто «подсовывают» совсем не практику (не публикуют ее, все NDA и ДСП), и совсем не понятно почему она «лучшая». Это вопрос к SE, ЕА, ВРМ.
              • 0
                Для меня это новость.

                Я заметил.


                я все же про то, что можно проверить опытным путем

                Ну вот часть гуманитарного знания нельзя проверить опытным путем.


                Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
                А им намного больше 15 лет.

                А это engineering details? Не думаю.


                Я привел личный опыт.

                Опыт против опыта. 20 лет назад я сидел на платформе, которой сейчас не существует, разрабатывая программы на языке, который сейчас развивается совсем в другую сторону. Никакие детали моего тогдашнего опыта (в отличие от принципов) для меня сейчас неприменимы.


                Да, большинство систем должны просто тиражироваться.

                Чтобы тиражироваться, все равно нужно ТЗ.


                а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.

                … и потом 50 страниц анализа, как эти отличия не конфликтуют с существующей системой.


                Чтобы составить грамотное ТЗ – нужно большие трудозатраты

                Да, это так. Но это никак не значит, что ТЗ не нужно.


                ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем

                Вы не можете внедрить систему без ТЗ. Ну заменится у вас ТЗ на разработку на ТЗ на внедрение — что, легче станет?


                Вот именно. Я уже про этот «трюк» указывал в статье.

                И сам же его и применил.

                • 0
                  Вы не можете внедрить систему без ТЗ.

                  Можно сослаться ровно также: внедрить «точно также» как «там — то» (конкретно где, например, в своей дочерней компании).
                  Обсуждение подходов к ТЗ и проблем «управления требованиями» — заслуживает отдельной статьи.
                  И сам же его и применил.

                  Я критиковал подмену «Лучших практик» (псевдо-лучшие практики), т.е. когда сегодня это крылатое выражение применяется к «непрактикам» (не опубликованным и вообще неизвестно внедренным ли) и «нелучшим» или «лучшим», но с позиций «управленческая уловка», «маркетинговый обман», «лживый пиар» и т.п.
                  Когда я говорю о правильных «Best Practice», то я и подчеркиваю, что первый критерий — это опубликованность: содержание рабочего проекта или возможность доступа к самой конечной системе или другие доказательства «практики». Иначе разговоры уходят в плоскость мифологии.
                  Разобраться бы вначале с первым, а то приходится сравнивать «нули с нулями».
                  • 0
                    Можно сослаться ровно также:

                    Это означает, что вы будете использовать ТЗ, написанно "там-то". А перед этим вам надо доказать его применимость (это я говорю как человек, который несколько раз делал реализации "точно так же, как", а потом выяснялось, что они неприменимы).


                    Когда я говорю о правильных «Best Practice», то я и подчеркиваю, что первый критерий — это опубликованность: содержание рабочего проекта или возможность доступа к самой конечной системе или другие доказательства «практики». Иначе разговоры уходят в плоскость мифологии.
                    Разобраться бы вначале с первым, а то приходится сравнивать «нули с нулями».

                    Нет смысла разбираться с первым, если нет второго. Вот опубликуют люди десять практик — как вы будете их сравнивать на лучшесть? Пока нет этого ответа, непонятно, зачем публиковаться.

                    • 0
                      Это означает, что вы будете использовать ТЗ, написанно «там-то». А перед этим вам надо доказать его применимость (это я говорю как человек, который несколько раз делал реализации «точно так же, как», а потом выяснялось, что они неприменимы).

                      Одна из ключевых мыслей, которую пытаюсь донести через «ТЗ»: не нужно перекладывать внутренние риски подрядчика на заказчика.
                      Если заказчик ткнул на аналог и сказал «хочу такую же», то это уже риск подрядчика, что две системы не совпадут.
                      Здесь еще будет играть фактор, что все стандартное и типовое будет на порядок дешевле и надежнее нетипового и уникального.

                      Нет смысла разбираться с первым, если нет второго. Вот опубликуют люди десять практик — как вы будете их сравнивать на лучшесть? Пока нет этого ответа, непонятно, зачем публиковаться.

                      Когда опубликуют, то желающие сами найдут критерии «хорошо» и «плохо» и выберут исходя из них «свою Best Practice». Главное, чтобы было из чего выбирать и возможность выбора.

                      Самый простой из критериев: функционал \ стоимость.
                      При публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок — и это норма для нашего рынка, некоторые скандалы даже дошли о печати.
                      Дельта будет означать размер маржи подрядчика и откатов. Собственно, во многом из-за этого и не публикуют ни проекты, ни их стоимость. Это же «страшная тайна».
                      • 0
                        Если заказчик ткнул на аналог и сказал «хочу такую же», то это уже риск подрядчика, что две системы не совпадут.

                        Наоборот, подрядчик ничем не рискует: дали ТЗ — сделал по ТЗ. Это заказчику рискует тем, что полученное по его ТЗ его же не устроит.


                        Здесь еще будет играть фактор, что все стандартное и типовое будет на порядок дешевле и надежнее нетипового и уникального.

                        Ну да, будет дешевле. Но будет ли решать нужные задачи?


                        Когда опубликуют, то желающие сами найдут критерии «хорошо» и «плохо» и выберут исходя из них «свою Best Practice».

                        Тогда можно и не публиковать ничего. Люди, которые заказывают работу, уже так делают.


                        Самый простой из критериев: функционал \ стоимость.

                        Теперь давайте найдем способ объективно оценить функциональность.


                        При публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок

                        Нет, не выяснится, потому что вы не системы предлагаете публиковать.

                        • 0
                          ТЗ его же не устроит.

                          Мы же говорили, что в любом случае «обычное ТЗ» его «не устроит», потому что, это «филькина грамота», т.к. за «правильное ТЗ», стоимостью 30% работ по проекту — никто платить не готов.
                          Теперь давайте найдем способ объективно оценить функциональность.

                          Вы считаете, что два технических устройства или два программных изделия нельзя сравнивать (оценивать) по функциональности?
                          Железку с железкой, программу с программой?
                          Нет, не выяснится, потому что вы не системы предлагаете публиковать.

                          Я предлагаю
                          для ЕА – публиковать: корпоративную архитектуру (рабочую) + библиотеку эталонных архитектур (по типам предприятий);
                          для ВРМ – публиковать: рабочие бизнес-процессы (а также всё к ним привязанное, типа RACI, метрики и т.п.) + каталоги типовых процессов (APQC PCF и т.п.);
                          для SE публиковать: эскизный, технический и рабочий проект + исходное типовое решение (по видам изделий).

                          Знак «+» отделяет «рабочую часть» (реализацию) от «эталонной»,
                          т.е. «реальный проектный мир» от «эталонного проектного мира»,
                          примерно как у Канта: «мир вещей» и «мир идей».
                          А Ваша была какая версия?
                          • 0
                            Мы же говорили, что в любом случае «обычное ТЗ» его «не устроит»

                            Это вы говорили. Я с этим не соглашался.


                            И да, речь-то не об этом, а о том, чьи риски.


                            Вы считаете, что два технических устройства или два программных изделия нельзя сравнивать (оценивать) по функциональности?

                            Я считаю, что это сложно делать объективно в общем случае. Вот есть два фотоаппарата, в одном только матричный замер экспозиции, в другом — только точечный. Как должны соотноситься их цены?


                            И это мы еще не перешли к надежности.


                            Я предлагаю

                            И ничто из этого — не система. Между проектом и реализацией — пропасть.

                            • 0
                              И ничто из этого — не система. Между проектом и реализацией — пропасть.

                              Подскажите тогда, в чем Вы видите различие между «проектом», один из документов (обложка) которого показан на рисунке ниже, и «реализацией»?

                              В помощь: Книга Методы инженерного творчества, Шипинский

                              Что вообще по-Вашему возможно публиковать «в принципе»? Какие артефакты? Публиковать «реализацию»?
                              • 0
                                Подскажите тогда, в чем Вы видите различие между «проектом», один из документов (обложка) которого показан на рисунке ниже, и «реализацией»?

                                Я могу взять это "описание программы", пойти и запустить? Нет? Тогда оно для меня бесполезно.


                                Что вообще по-Вашему возможно публиковать «в принципе»? Какие артефакты?

                                Зависит от целей публикации, очевидно же.

                                • 0
                                  Я могу взять это «описание программы», пойти и запустить? Нет? Тогда оно для меня бесполезно.

                                  Такие понятия как «документация на программу» (точнее «программное изделие») Вы как себе представляете?
                                  Указанная документация по-Вашему «бесполезна»? Для чего тогда подобную документацию изготавливают? Ей литеры присваивают?
                                  Зависит от целей публикации, очевидно же.

                                  Пытаюсь от Вас получить прямой ответ, и все никак.
                                  Какие могут быть тогда вообще «цели публикации» и «что» под конкретную цель нужно публиковать?
                                  • 0
                                    Указанная документация по-Вашему «бесполезна»?

                                    Она бесполезна для конечного заказчика в отрыве от программы.


                                    Какие могут быть тогда вообще «цели публикации» и «что» под конкретную цель нужно публиковать?

                                    А это вы предлагаете публиковать, а не я. И вы пишете "при публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок — и это норма для нашего рынка, некоторые скандалы даже дошли о печати". Если это ваша цель, то вам придется выкладывать (а) сами "изделия" и (б) методику и результаты их испытаний. Иначе ваша цель достигнута не будет.


                                    Я-то просто публикую свои разработки в open-source, и мои цели это прекрасно решает.

                                    • 0
                                      Если это ваша цель, то вам придется выкладывать (а) сами «изделия» и (б) методику и результаты их испытаний. Иначе ваша цель достигнута не будет.

                                      Более точно было бы так:
                                      — изделие (система), результат SE, его вообще-то выложить сложно, т.к. в общем случае это «Большая система», включая территориальную сеть, объекты, средства автоматизации и может быть программы (причем не обязательно);
                                      — документация на разработку (конструкторская, программная)
                                      — документация на эксплуатацию (эксплуатационная)
                                      — прочая документация (ПМИ, ТУ и т.п.). Есть еще направления «технологическая док.», «ремонтная док.» и т.д.
                                      Это взгляд со стороны «отечественной SE».
                                      Я-то просто публикую свои разработки в open-source, и мои цели это прекрасно решает.

                                      Что конкретно Вы публикуете? И какие цели это решает?
                                      • 0
                                        изделие (система), результат SE, его вообще-то выложить сложно

                                        Это повод задуматься о реализуемости идеи целиком.


                                        Что конкретно Вы публикуете?

                                        Свои разработки как программиста.


                                        Что конкретно Вы публикуете?

                                        Во-первых, самореализация. Во-вторых, вклад в Open Source.

            • 0

              (del, ошибся уровнем)

              • 0
                По своему опыту SE могу сказать, что оно всегда начинается в оборонных отраслях, затем полезный выхлоп переносится на технологии и бизнес-процессы, необходимые для реализации принятой большой или даже сверхбольшой системы и ее элементов (тут уже речь о BPM+EA), и, наконец (но не в нашей стране), желание подзаработать денег на супердостижениях в ходе реализации такого сложного и передового проекта, который был затеян, приводят к «Best Practice» & ххBOK, а они, в свою очередь, рождают новое поколение прикладных гаджетов, полезняшек и протчая и протчая, в итоге за ту же себестоимость появляется принципиально новый продукт, новое поколение «поющих утюгов» и прочей утвари.
                • 0
                  Можете конкретизировать? «по своему опыту SE» какой-нибудь пример?
                  • 0
                    Возьмем отрасль, в которой мы впереди планеты всей в настоящее время. Системы ПВО/ПРО. Всеобъемлющие по своей структуре, природе элементов, протоколам информационного взаимодействия, всегда построенные на базе разумного компромисса между идеальным представлением заказчика и достижимым уровнем технологий. Для реализации оптимального SE-проекта всегда требуются доработки существующих технологий, поиски новых способов организации взаимодействия как внутри кооперации исполнителей, так и внутри каждого предприятия такой кооперации — ВРМ+ЕА во всей красе и полноте; затем обучить непосредственно персонал этих предприятий, а также персонал, эксплуатирующий систему с учетом и использованием достижений «Best Practice» & ххBOK в этой отрасли. Получаем на выходе конфетку типа С-Х00, плюс новейшие технологии изготовления ее элементов, как правило, поддерживающие масштабирование и тиражирование, плюс новый уровень бизнес-процессов как внутри предприятий-изготовителей, так и по их взаимодействию, плюс новый уровень руководства персоналом, обеспечивающий осознанное выполнение им своих задач. Детализировать далее невозможно. Беда наша в том, что никакого выхлопа в обычную экономику данные достижения не привносят. Хотя… Люди перетекают иногда, что в общем-то, определенную ценность тоже имеет
                    • –1
                      Возьмем отрасль, в которой мы впереди планеты всей в настоящее время. Системы ПВО/ПРО.

                      Вам об этом из зомбоящика рассказали?
                      Лучше ему не верить, обычно в чем «мы впереди планеты всей в настоящее время» там не говорят: коррупция, особенно в оборонке (самая закрытая и коррумпированная структура – это первая военная тайна).

                      Но даже если у нас еще и развивается ПРО (благодаря советскому заделу), то все равно это уже не так критично.
                      Разговоры «про ПРО» (нераспространение ЕвроПРО, надежда на наше ПРО – не важно) – это «газетные байки», политическая пропаганда, примерно то же самое, что я рассказываю по теме ЕА\ВРМ\SE: «управленческие уловки» (management fad), пропаганда, fake news – причем с обеих сторон (мы и США).
                      Нет защиты от МБР, ни у нас, ни у них, и – это вторая военная тайна.
                      Пара ссылок:
                      Межконтинентальная баллистическая ракета — абсолютное оружие. И это не преувеличение.
                      …созданные ещё в 1970–80-е годы средства до сих пор легко преодолевают ПРО.


                      … начинается создание сложных баллистических целей с сотнями и тысячами ложных элементов, и никаких противоракет для всего этого многообразия просто нет.
                      Детализировать далее невозможно.

                      Откуда такой вывод?
                      делением атомного ядра управлять научились, а вот какую-то «детализацию» выполнить не сможем?
                      плюс новый уровень бизнес-процессов как внутри предприятий-изготовителей, так и по их взаимодействию,

                      Операционная модель коррупционных схем? В какой нотации?
                      (шутка,… а может и нет, — для СКР может пригодиться)
                      плюс новый уровень руководства персоналом, обеспечивающий осознанное выполнение им своих задач.

                      Это про что? Про коммунизм? Про В. Губанова и П. Корчагина? Иначе, какое оно «осознанное» — работать, понимая что «результаты труда, так или иначе, присваиваются владельцами капитала»?
                      Беда наша в том, что никакого выхлопа в обычную экономику данные достижения не привносят.

                      А почему у них оборонка «привносит» в гражданку?
                      ТСР\IP, тот же IDEF и масса всего остального IT-шного и даже BPM-ного.
                      В чем сложности «у нас»?
                      Поясните, «не жалея букв». Хотелось бы Ваше «развернутое пояснение», учитывая, что «родина» SE – все же оборонка.
                      • 0
                        К сожалению, безапелляционность утверждений не оставляет мне пространства на развернутый ответ. Не смею детализировать, так как некоторая информация не теряет своей значимости в течение десятилетий. Смею лишь заметить, что реальность, а не фейковость возможностей ПВО/ПРО России подтверждается практически (читайте не геополитические обзоры, а просто информацию из Сирии, а также о результатах испытаний наших систем от С-Х00 до А-Х35). При том, что именно уровень системных проработок обеспечивает не только паритет, но и несомненное преимущество отечественных систем вооружений над уровнем наших «партнеров».
                        А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.
                        • 0
                          безапелляционность утверждений не оставляет ...

                          утверждений моих или конструктора Соломатина?
                          В любом случае, мы оба можем ошибаться.
                          А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.

                          У нас нет МСБ? Мне казалось его давно «как грязи». «На поверхности» ничего не увидел.

                          Не теряю надежды на «Ваше развернутое пояснение, которое очень ценно, учитывая, что «родина» SE – все же оборонка».
                          • 0
                            Соломатина, к сожалению, не знаю в проблематике ПВО/ПРО. Знаю Соломонова (который с другой стороны баррикад :) ), Басистова, Бункина, Ефремова, много можно назвать фамилий. Только зачем? Вопрос ведь заключается в другом. Вопрос в том, что локомотив SE — оборонка. Оно так и есть, здесь мы не спорим. И уровень развития данной отрасли инженерного искусства (знания либо технологии — слишком узко будет сказано) в СССР, а затем России пока еще достаточно высок. Базируется это на универсальной подготовке по программам еще советской средней и высшей школы, учившим не только набору знаний, но и методам самостоятельного их применения и дальнейшего самообразования. Что касается МСБ — его вклад в ВВП России составляет менее 20%. В то же время для Китая это более 60%. И при этих наших жалких 20% не менее половины предприятий МСБ являются инструментами для обнала, к сожалению. Хорошо знаю это, имея опыт работы и в банковской сфере. А почему не перетекает выхлоп из оборонки? Вот недавно была иллюстрация, когда штрафовали предпринимателя на Дальнем Востоке, фермера, который одел на свою буренку приемопередатчик GPS. Незаконно, ёшкин кот! Какие уж тут условия для МСБ вообще и для перетока в него передовых технологий и прочих достижений из оборонки, в частности? Дорога тут предстоит большая и тернистая. Но идти надо!
                            • 0
                              Вопрос в том, что локомотив SE — оборонка. Оно так и есть, здесь мы не спорим. И уровень развития данной отрасли инженерного искусства (знания либо технологии — слишком узко будет сказано) в СССР, а затем России пока еще достаточно высок. Базируется это на универсальной подготовке по программам еще советской средней и высшей школы, учившим не только набору знаний, но и методам самостоятельного их применения и дальнейшего самообразования.

                              Хотелось бы поподробней. Я помогу вопросами:
                              Отечественные SE-ГОСТы, включая РВ 15.ххх устаревают, не развиваются. Что делать оборонке?
                              Использовать их «до последнего» или «садиться» на западные SE?
                              Переходить на SEBOK, BKCASE (МО США там участвует) и т.п.?

                              Ниже обсуждаем профстандарт «Инжнер-Системотехник», «Инженер по SE».
                              Что должно войти в него? Желательно дать предложения в той же ветке.

                              По rusEA что предложите? Внедряем DoDAF или отечественный фреймворк?
                              BPM как используете? Какие другие проблемы отечественного оборон-SE? Как их решать?
                        • 0
                          Операционная модель коррупционных схем? В какой нотации?
                          (шутка,… а может и нет, — для СКР может пригодиться)

                          Встречал попытку от одного украинского консультанта на уровне «рисовалки» с нестандартной нотацией.
                          • 0
                            Как это хоть примерно выглядело?
                            • 0
                              Кружки со стрелочками. Точно не помню, не сохранял, где видел не помню. Но заявка была крутая на анализ системы коррупции. По мне не более чем один из вариантов анализа рисков на уровне определения угроз.
                  • 0
                    Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку». Не может быть одного универсального ТЗ или «архитектуры» или еще чего в этом роде на все случаи жизни и для всех проектов. Для всех могут быть общие требования, которые потом в любом случае необходимо детализировать и творчески применять для каждого конкретного более или менее сложного проекта. Это только болты можно точить по единому стандарту, да и то разный металл для разных областей применения. Даже в бывшем СССР, на опыт которого Вы ссылаетесь, были ГОСТы — общие требования, и потом для каждого изделия уже конкретно своя документация и свои требования.

                    Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода? Я могу представить только так: для всех — общие требования, для каждого свой проект в зависимости от климатической зоны, вида грунтов и сейсмоактивности. Да, могут быть и типовые проекты для постройки одинаковых строений, но только в одном и том же регионе.

                    Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику. Да, не полностью переделывать, что-то можно использовать и оставить как есть, но не полностью 100% это будет применимо.

                    Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
                    • 0
                      Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».

                      Смотря, что под ними понимать.

                      Под «серебряной пулей» я понимаю НОТ и подобные научные подходы (СОВНОТ во главе с Куйбышевым был образован еще в 1923).
                      Про научный подход, унификация, стандартизация, Global BPM, развитие «Open Source» до «Открытый процесс» и т.п. обсуждали в
                      Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
                      Эволюционируя от «Кадры решают всё» к «Процессы решают всё» советская научная мысль пришла бы к этому и сегодняшние павильоны ВДНХ трансформировались бы в выставку Хороших Процессов народного хозяйства (e-выставка ХПНХ). А принцип «Open Process» был бы принудительно инкорпорирован во все отрасли народного хозяйства


                      Не только само производство товаров и услуг, но и инженерия и даже наука может быть организована в виде «промышленного конвейера» (почти по Г. Форду). По открытиям и изобретениям:
                      • Мы не столько изобретаем решения, сколько открываем их. Соболезнования творческим натурам: это всего лишь обрабатывающий информацию голем, начищающий свое собственное эго и озабоченный поднятием кармы.
                      • Интеллект — это социальный эффект, хотя он и ощущается как что-то личное. Человек, отрезанный от других, перестает думать. Мы не можем ни определить проблемы, ни оценить их решения без других людей.

                      и как реализация этого:
                      должен быть всего лишь налажен «промышленный конвейер изобретений», нечто подобное «Системной Инженерии», — как технология «Научной инженерии».
                      Т.е. свод знаний «по проектированию \ производству открытий и инноваций».

                      Подробнее здесь «Социальная архитектура»
                      Я полагаю, что, не смотря на наличие «гениальности», — как важного фактора развитие науки, эволюция науки в целом — идет вне зависимости он него.

                      Лучший пример подобного конвейера, организованного Сталиным и Берия, – это Советский атомный проект.

                      «Волшебные таблетки» это:
                      Это подходы к типовому проектированию — как методологии «Best Practice» типа SE (но очищенного от болтовни, маркетинга и пиара),
                      это реальные и практические «Best Practice» (не псевдо, как сегодня), публикуемые типовые проекты, «полнометражные» примеры, архитектуры, референтные (эталонные) модели, отраслевые подробные классификаторы бизнес-процессов, ЧаВо по их развертыванию (внедрению), регламенты (графические, табличные, текстовые) и т.п.

                      Главное создать среду (инфраструктуру) для обмена опытом путем публикации успешных и неуспешных (это тоже очень важно) реализаций, их артефактов. А эти реализации сами покажут, какие практики «Лучшие», а какие не очень.

                      Вы думаете, что проекты разных системных интеграторов сильно отличаются друг от друга?
                      Да – отличаются.
                      Одни изобретая один и тот же «велосипед», наступили «вслепую» на 50 «граблей», другие при таком же «велосипеде» также «вслепую» на 150 граблей.
                      А если бы им все эти грабли заранее «подсветили» (типовые проекты, эталонные модели и т.п.), то не только легче было бы пройти «инженерной тропкой», но и «изобретать велосипед» вообще не пришлось бы – а лишь его заимствовать (типовое проектное решение).

                      Это как раз позволит: «чтобы не тратить лишние ресурсы»
                      Если мысль не донес, — скажите, я по Вашему тексту отвечу что-нибудь на примерах.
                      • 0
                        Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».

                        Скорее здравый опенсорс по связи теории и практики.
                        Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода?

                        Технический регламент по общим требованиям вполне возможен.
                        Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику.

                        Самое забавное в том, что в обеих случаях главный бизнес-процесс абсолютно одинаков — Оказание услуг (торговли).
                        Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.

                        Помнится меня когда-то учили тому, что решением задачи является сумма общего рещения и решения при заданных начальных условиях.
                      • 0

                        Могу сказать, что в принципе считаю себя Системотехником, так как контролировал разработку достаточно сложной и ответственной системы управления в энергетической сфере.
                        По дисциплинам — да это требует знаний и опыта в достаточно разных сферах — механики, электроники, софта, измерений, стандартизации, тестирования и еще кучи других, так как даже простые решения о том, реализовать ту или иную функциональность в программе, железе, ПЛИС или микроконтроллере с учетом всех факторов, включая ресурсы и наличие/наем нужных разработчиков, даются не так легко.
                        Большим подспорьем в конкретном случае с АСУ является моделирование — потому что дает возможность хоть на раннем этапе оценить требования к системе и прикинуть, как может быть решена основная задача. Но к сожалению тут универсальных средств нет и промоделировать систему управления предприятием на той же системе уже невозможно.

                        • 0
                          Могу сказать, что в принципе считаю себя Системотехником

                          Тогда как по-Вашему, что должно войти в профстандарт «Инжнер-Системотехник», «Инженер по SE»?
                          Насколько понимаю, такого ПрофСтандарта пока нет, но есть, например,
                          Специалист в области проектирования автоматизированных систем управления технологическими процессами

                          • 0
                            Самое забавное в такой профессии это то, что по некоторым исследованиям только 15% людей обладают системным мышлением.
                            • 0

                              Из того, что мне пригодилось и в принципе самое главное:


                              • Умение гуглить и находить информацию в сети Интернет в том числе общение на тематических форумах
                              • Основы электроники и схемотехники
                              • Основы программирование микроконтроллеров
                              • Основы и устройство DSP, цифровой обработки сигналов, цифровых фильтров
                              • Основы ПЛИС
                              • Языки программирования Си, Java(сегодня может быть Питон)
                              • Cтандартизация и сертификация
                              • Основы проведения экспериментов, измерений и анализ их результатов
                              • Метрология
                              • Английский язык
                              • Моделирование — Matlab/Simulink, Pspice
                              • Основы 3D проектирования и моделирования — Solidworks, Comsol Multiphisics.
                              • Менеджмент требований
                              • Основы систем контроля версий, баг-трекеров.
                              • Теория автоматического управления
                              • IoT
                              • Локальные Сети (CAN, RS482, Modbus, Ethernet и т.д.)
                              • Оформление схем и документации по Госту — Спецификаций, Паспортов, Инструкций и т.д.

                              По практике — как минимум 2-3 + дипломник реальных проекта на микроконтроллерах/ПЛИС c использованием отладочных плат от начала и до конца с документацией.


                              Это из того, что вспомнил специфического.

                              • 0
                                Это не системщик в понимании темы.
                                • 0

                                  А кто?


                                  ПС. Забыл еще основы теории надежности

                                  • 0
                                    Инженер по АСУ.
                                    Для системщика по теме обсуждения нужны менеджмент, маркетинг, логистика, кибернетика, теория систем и много еще разной зауми, включая основы бухучета.
                                    Не говоря уже о базовых матстатистике и теории вероятности. ПЛИС и многое прочее в реальности всего лишь практическое приложение к алгебре логики и прочему подобному.
                                    • 0
                                      Для системщика по теме обсуждения нужны менеджмент, маркетинг,

                                      Я тут ругаю маркетинг и менеджмент (точнее их уловки): «управленческие уловки» (management fad), пропаганду, манипуляцию терминами и т.п.
                                      а Вы их системщикам …
                                      Зачем маркетинг — то системщику? Продать свой проект?
                                      • 0
                                        Я еще про психологию забыл! :))
                                        Что изучает маркетинг? — Внешнюю среду. Внешняя среда тоже система. От SWOT анализа Вы отказываетесь? От стратегического планирования тоже? И многих прочих критических элементах систем тоже?
                                        Что есть менеджмент без пены? Это наука об управлении человеческими организациями. Как без него строить социотехническую систему?
                                        • 0
                                          С таким подходом, Вы сюда все запихнете:
                                          А куда же без физики? А куда без сопромата? А куда без…
                                          • 0
                                            Все зависит от того какое предприятие и какую систему Вы рассматриваете. Для ларька по продаже сигарет можно обойтись без них, а если рассматривать атомную электростанцию, то кроме физики и сопромата Вам понадобится еще много чего.
                                      • 0

                                        Но без тех дисциплин, что я привел, системщик тоже будет неспособен разбить задачу на блоки и решить ее наиболее технически оптимальным способом. Не зная, что умеют ПЛИС, например, вы не сможете их правильно применить.
                                        Насчет ваших согласен. Из нетехнических специальностей мне пригодилось:


                                        • основы логистики
                                        • основы бухучета,
                                        • определение себестоимости продукта/системы — калькуляции ROI/RORE
                                        • основы ведения НИР, НИОКР, основные этапы разработки и исследований
                                        • маркетинг, это в принципе для системщика управление требованиями — нет смысла туда углубляться глубже.
                                        • 0
                                          Начнем сначала. Рассмотрим человека. Любой человек — система. Внутри него можно выделить еще ряд систем: пищеварения, дыхания, кровообращения и далее по списку. Вместе с тем человек входи в системы семья, работа, государство и далее по списку.
                                          С моей точки зрения Вы считаете системщиком специалиста по системе автоматизации организации. Но для меня это только одна из подсистем организации. Вспомнилась одна работа. Нужно было автоматизировать один процесс. Чтобы я не отвлекался на мелочи, мне в помощь дали программиста. Мы сделали эскиз и показали его заказчику. Ему очень понравилось и он начал плотно контролировать ход работы. Через некоторое время он потребовал убрать меня из проекта потому что программист сидел целыми днями, а я забегал к нему на пару минут, смотрел и говорил что доделать, а что переделать. Мол мне не за что платить. Я ушел из проекта и он рассыпался. Сам программист сказал что его можно заменить на любого, а меня заменить в этом проекте некем, потому что я детально знаю не только сам процесс, но и потребности с возможностями всего его окружения. С точки зрения многих участников этого форума заказчик скорее всего был прав, ведь за что платить мне больше программиста если я не написал ни строчки кода, только мешал работать. А с моей точки зрения я работал системщиком, которым может работать не каждый программист. :))
                                          • 0
                                            Не зная, что умеют ПЛИС, например, вы не сможете их правильно применить.

                                            Помнится в одном старом американском учебнике по программированию была глава типа «А всегда ли нужно программировать микроконтроллер?»
                                            Идея проста. Одно и тоже устройство можно реализовать в жестком железе (начиная с логических микросхем малой или большой интеграции, одной из которых является ПЛИС) или на универсальный блок запрограммировать специальный софт. Далее никакой техники, одна экономика, демонстрирующая случаи, когда можно все сделать на ПЛИС, а когда лучше микроконтроллер с программой. Оплата программиста в нем считалась значительно больше стоимости железа. :))
                                            • 0

                                              Я вам больше скажу. Одну и ту же систему можно сделать на ПЛИС или DSP, микроконтроллерах ARM или процессорах Intel, материнках в формате ATX, ноутбуке или стойках cPCI,VPX, с использованием интерфейсов Ethernet или CAN или RS485 или своего доморощенного протокола, с использованием PCIexpress или без. И в итоге получить решение, которое функционально делает то же самое, но будет иметь абсолютно разные затраты на разработку и ее длительность, стоимость железа, возможность серийного производства, имеет разные требования к экспертизе разработчиков и еще множество отличий.
                                              Чистая экономика, конечно...

                                          • 0
                                            А «бухучет» — то зачем инженеру?
                                            Управленческий и налоговый учет тоже нужен?
                                            • 0
                                              Мы говорим об инженерах или о специалистах по системе всего предприятия? Система управления без учета неработоспособна. Управлять можно только тем, что можно измерить. В том числе инструментами бухгалтерского и управленческого учета.
                                              • 0
                                                Мы говорим об инженерах или о специалистах по системе всего предприятия?

                                                Ветка называется:
                                                что должно войти в профстандарт «Инжнер-Системотехник», «Инженер по SE»?
                                                Инженер — это точно не бизнесмен и бизнес-навыки «для профессии» вряд ли нужны. Знание предметной области (отрасли) нужно, но при этом достаточно что «бухучет есть» и очень примерно «что это такое».

                                                Если мы говорим об ЕА, то разработчик и администратор ЕА (архитектор) должен находиться в треугольнике «бизнес» — «технология» — «инфраструктура, включая ИТ» — точнее в середине этого треугольника, такой «корпоративный архитектор» (не системный архитектор) должен знать по «соответствующей» выжимке с каждой стороны треугольника.

                                                У системного архитектора уже свой, и другой «треугольник», и его навыки уже будут ближе к инженеру SE.
                                                Поэтому «системотехник» (SE) и «корпоративный архитектор» — это во многом разные направления.
                                                Об этом говорил здесь
                                                «Хочешь быть системным архитектором? Там только свет и чистота…»
                                                Хорошо бы конечно ролевую структуру всех этих SE\ВРМ\ЕА нарисовать.

                                                Есть проект профстандарта на специалиста ВРМ.
                                                • 0
                                                  Извините, но даже генеральный директор, его замы и другие специалисты, не имеющие акции предприятия, бизнесменами не являются. Вы для начала определитесь на каком уровне работают «системотехник» (SE) и «корпоративный архитектор». Если это рядовые специалисты-инженеры, то я тогда вообще ничего не понимаю. По моему скромному мнению вопросы архитектуры и прочие системные вопросы предприятия это вопросы исключительно топменеджмента, имеющего соответственную подготовку и возможности.
                                                  Ну и разумеется разного калибра консалтеров. :))
                                                  • 0
                                                    Вы для начала определитесь на каком уровне работают «системотехник» (SE) и «корпоративный архитектор». Если это рядовые специалисты-инженеры, то я тогда вообще ничего не понимаю

                                                    Ха-рооо-ший вопрос. Уверен, что «корпоративные архитекторы» — не топы, но вот целевые потребители описания ЕА — топы.

                                                    «Классический» Системотехник — это вообще почти всегда внешний подрядчик, т.к. его задача «изо дня в день» разрабатывать что-то новое, сложное и большое.
                                                    Они обычно «живут» в проектных организациях, хотя некоторые «операционные» (классические) компании могут и их себе позволить.

                                                    Это проектная работа, фактически по проектированию предприятия и его «крупных» частей. Жизнь предприятия в условиях постоянных крупномасштабных" изменений — видимо не стоит считать «нормой».
                                                    • 0
                                                      А я наоборот абсолютно уверен в том, что корпоративный архитектор это топ. В ряде компаний он называется «Директор по развитию». Кого он возьмет к себе в помощники это его проблема, имеет право советоваться хоть с уборщицей. А целевой потребитель — вся организация. Кто персонально определяет устав предприятия. Это может быть учредитель, совет директоров и т.д. Вопрос ведь не в описаниях, а в их реализациях. По простейшей архитектурной модели — штатному расписанию принимают на работу и устанавливают зарплату.
                                                      • –1
                                                        А я наоборот абсолютно уверен в том, что корпоративный архитектор это топ. В ряде компаний он называется «Директор по развитию».

                                                        Уверен, что «Директор по развитию» и слов то таких не знает: The Enterprise Architecture Body of Knowledge (EABOK), Захман, ТОГАФ и т.п.

                                                        Вы под ЕА понимаете то, что в этих книжках сказано?
                                                        «Директор по развитию» даже в бизнес-архитекторы записывать не нужно.

                                                        Попробуйте составьте framework своего домохозяйства, как я предлагал здесь:
                                                        3 Конкурс на описание «household architecture»
                                                        А Вы подобное хотите на топов «повесить»?
                                                        А целевой потребитель — вся организация.

                                                        Зачем описание ЕА уборщице и бухгалтеру?
                                                        • +1
                                                          Уверен, что «Директор по развитию» и слов то таких не знает: The Enterprise Architecture Body of Knowledge (EABOK), Захман, ТОГАФ и т.п.

                                                          Слов не знает, но ведь делает именно то, что в них написано! Когда-то в Росссии и слова бизнес не знали.
                                                          Зачем описание ЕА уборщице и бухгалтеру?

                                                          Ну если для Вас организация это уборщица и бухгалтер, то я тогда пас.
                                                          • 0
                                                            Слов не знает, но ведь делает именно то, что в них написано!

                                                            Можно конкретику в терминах ТОГАФ или еще кого из ЕА, про деятельность «Директор по развитию» в роли корпоративного архитектора?
                                                            • 0
                                                              Лениво переводить на «птичий язык».
                                                              Читайте первое что нашел Великий Гугль и возможно увидите то, что роль архитектора предприятия написана несколькими фразами: www.rabota.ru/articles/hr/dolzhnostnaja_instruktsija_direktora_po_razvitiju_dolzhnostnye_objazannosti_direktora_po_razvitiju_obrazets_dolzhnostnoj_instruktsii_direktora_po_razvitiju-3999
                                                              • 0
                                                                Все равно, не понимаю.
                                                                По Вашей ссылке приведена Должностная инструкция директора по развитию, должностные обязанности директора по развитию

                                                                Описание ЕА может разрабатываться вообще без цели «развитие», просто для того чтобы зафиксировать «as is»:
                                                                обычно «бардак в as is», но без надежды его упорядочить.
                                                                • +1
                                                                  Для Вас важнее описание чем работа? «Вам шашечки или ехать?» Описание того что есть в новой нотации ценности не имеет.
                                                                  • 0
                                                                    Я все равно не понял: когда делаем описание ЕА — только «as is» и вне любого развития, то при чем здесь директор по развитию «вообще», и тем более в роли корпоративного архитектора?
                                                                    • +1
                                                                      Ответьте на простой вопрос: Зачем нужно это описание и именно в такой нотации?
                                                                      Чувствую скоро Вы скажете о том, что архитекторы (градостроительные) нужны только для того, чтобы работать экскурсоводами.
                                                                      Зачем новое проектировать? Нам лучше описать то что есть.
                                                                      • –1
                                                                        Зачем нужно вообще ЕА — это другой вопрос (не менее спорный).
                                                                        Мы же обсуждаем другое: Зачем в общепринятом подходе к ЕА (EABOK + куча фреймворков) нужен в качестве архитектора Директор по развитию, тем при описании ЕА типа «как есть»?
                                                                        • +1
                                                                          В карты я с Вами играть не сяду. Передергиваете знатно!
                                                                          Что нужно? Организовать новое предприятие или улучшить работу старого. Для этого можно применить различные инструменты и их сочетания. Само по себе применение этих инструментов никому не нужно за исключением консалтеров, которые на этом живут.
                                                                          Повторяю, вне разницы какие инструменты применяются, главным архитектором предприятия является его Генеральный директор, который делегирует некоторые полномочия своим замам и другим руководителям. В качестве начальника штаба по архитектуре предприятия ближе всего роль директора по развитию. Но во многих предприятиях равноважны главный инженер и главный технолог. А специалист-системщик знающий новомодные нотации максимум, как говорил мой начальник, — «ученый еврей при генерале», то есть буквально штатный консультант, не имеющий права принимать самостоятельное решение.
                                                                        • 0
                                                                          Ответьте на простой вопрос: Зачем нужно это описание и именно в такой нотации?

                                                                          Вы про какую нотацию? Часто в ЕА не накладывается ограничений: рисуй в любой нотации.
                                                                          • +1
                                                                            Ключевое слово — Зачем?
                                                • 0

                                                  В принципе основы бухучета требуются для того, чтобы корректно понимать себестоимость разработанного продукта и как он будет генерировать прибыль. Также чтобы понимать, что зарплату надо платить всем и вовремя, даже если работа есть только для одного — это поможет при планировании цикла разработки.

                                  • 0
                                    bipiem не оставил выбора, придется применить магическое заклинание и открыть портал ACM.
                                    • –1
                                      Да, верно: BPM-алхимики «плодовиты», у них мантр много, не меньше, чем у ЕА-алхимиков и SE. Напомню свои рассказы:
                                      Бизнес-процессы: Как все запущено и запутано. Глава Первая
                                      Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
                                      Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
                                      по EA:
                                      Enterprise Architecture vs алхимия предприятия. Ключевые мифы
                                      Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие

                                      Первый «писк» моды «Adaptive Case Management» пришелся на 2010-11. Тогда он не позиционировался как «убийца BPM» и иногда назывался даже как: adaptive BPM, dynamic BPM, agile BPM и т.п.
                                      Это чтобы «плавно влиться» в рынок в составе раскрученного бренда «BPM».

                                      Потом пришло время «противопоставления»: не покупайте их «старый» BPM, берите наш «свежий» ACM!
                                      О подобном сценарии с BPM\BPMS – рассказывал в указанных статьях.

                                      Когда-то на «птичьем рынке» был классический прием (такой же management fad как в IT) по продаже щенков (BPM\BPMS\ACM etc):
                                      В коробке (Suite) продавца лежат несколько щенков – братьев от среднерослой дворняжки.

                                      Потенциальный покупатель: Какой милый у Вас щенок справа! Породистый? А большим или маленьким он вырастет?
                                      Находчивый продавец: Конечно породистый! Вы что сами не видите? А Вы любите больших или маленьких собак?
                                      — Очень люблю маленьких!
                                      — Как раз – то, что Вам нужно! Он только чуть-чуть подрастет и все!
                                      — Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!

                                      Следующий покупатель:
                                      — Какой милый щенок! Породистый? А большим или маленьким он вырастет?
                                      — А Вы любите больших или маленьких собак?
                                      — Люблю больших собак!
                                      — Как раз – то, что Вам нужно! Он, конечно же, вырастет огромным псом!
                                      — Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!

                                      Пойми своего клиента!

                                      Продавцы на «ИТ-рынке» также Вас спрашивают: «Вам что больше нравится: BPM или ACM»? И независимо от Вашего ответа Вашей покупкой окажется один и тот же «Management-щенок» (может с переклеенной этикеткой).

                                      Однако «высшим пилотажем» сейчас считается подход, когда их уже не противопоставляют друг другу, а говорят так:
                                      «и то и то — круто, поэтому у нас они оба – и в одном флаконе»!

                                      За примером ходить далеко не нужно:
                                      Адаптивный кейс-менеджмент сочетает в себе гибкость, социальную составляющую и возможность накопления опыта — то, чего не хватает традиционному BPM. Но на практике в одной организации могут быть и такие процессы, которые требуют строгой регламентации, и те, которые должны оставаться гибкими.

                                      Если для первых лучше использовать классический BPM-подход, то для вторых необходимо применять «Agile BPM» — то есть, АСМ.

                                      В продукте «ххххх» мы объединяем ACM и BPM-подходы, что позволяет перейти на новый уровень и значительно повысить эффективность в управлении процессами.

                                      Или другими словами:

                                      Покупайте в свой горем:
                                      ACM плюс BPM!
                                      Они — решенье всех проблем:
                                      И с ERP, и с CRM,
                                      А может и с BSDM.
                                      • 0
                                        Во-первых, ACM это не BPM. Основа ACM — это обработка событий и ориентированность на Case (можно интерпретировать как «Дело»). Основа BPM — это в большей степени процессный подход.
                                        Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.
                                        • –1
                                          Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.

                                          Консалтерами все так сознательно запутано, что без упрощения — не разобраться с их «маркетинговой лапшой». А юмору «все возрасты покорны», поэтому не понял упрек на возраст.
                                          А что, на ком-то «шапка горит»?

                                          Пропущенные через «призму» юмора ультрамодные «аргументы консалтеров» позволяют лучше понимать: маркетинговый конвейер спекуляций, «управленческие уловки» (management fad), пропаганду, fake news.

                                          Бытовые аналогии понятным языком показывают «классические приемы» и техники продвижения универсальных волшебных «таблеток» с высокой стоимостью, но сомнительным составом.
                                          Очень многое, что пишут на эту тему и предлагают алхимики — не имеет никакого отношения ни к науке, ни к реальности (но ими позиционируется так).

                                          Основная причина популярности алхимии — это просто закрытие информации, «не публикация» реализаций, нет открытого обсуждения — как деталей самих проектов BPM\ЕА\SE, так и реального их «выхлопа» (восторженные речи на конференциях — не в счет).
                                          Есть позитивные движения, например, общенациональный конкурс «BPM-проект года», но хотелось бы развитие: больше деталей (проекты публиковать целиком) и шире охват (массовость).

                                          По решению задачи отделить «мух от котлет», а область «computer science & engineering» от «alchemy & voodoo» — делаются только первые робкие шаги. Пока алхимия одерживает одну за другой победы над здравым смыслом.
                                          На «Во-первых,» — напишу ответ отдельно.
                                          • –1
                                            Бытовые аналогии понятным языком показывают «классические приемы» и техники продвижения универсальных волшебных «таблеток» с высокой стоимостью, но сомнительным составом.

                                            Аналогии обычно больше показывают того, кто их приводит.

                                      • 0
                                        Ответ на habrahabr.ru/post/346610/#comment_10620262
                                        Удивляюсь, вначале красиво подрожали моей иронии:
                                        bipiem не оставил выбора, придется применить магическое заклинание и открыть портал ACM

                                        и даже создали прикольную картинку с АСМ: правда там слово ВРМ не нужно было затирать, — было бы «комплексней».
                                        Я уж обрадовался, понадеялся, что еще борец с алхимией появился.
                                        Потом, Ваша ирония «растворилась», видимо, из-за того, что иронизировать над ЕА, ВРМ и SE можно, но вот покушаться на «святыню»: АСМ – это «кощунство»! Верно?
                                        Во-первых, ACM это не BPM. Основа ACM — это обработка событий и ориентированность на Case (можно интерпретировать как «Дело»). Основа BPM — это в большей степени процессный подход

                                        «это не BPM» – уже Очень Смешно.
                                        Потому что: «что такое BPM» – никому не известно, смотрим указанную ранее статью «Как все запущено и запутано. Глава Первая»

                                        Неоднократно был свидетелем, когда на крупной конференции или семинаре по «управлению бизнес-процессами» (BPM, Business Process Management – так, на всякий случай), — часами обсуждают ВРМ и подробно рассказывают о ВРМ-проектах. Все чинно, с умным видом.

                                        Затем когда всем становится очевидно, что беседа идет на разных языках и совсем «о разных BPM» начинаются вопросы к докладчикам: так Ваша система – это же не ВРМ!

                                        Затем достопочтенная публика задается вопросом: Что такое BPM? Час приводят «книжные» термины (цитаты из BPM CBOK, других «процессных библий») – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу».
                                        Вы о каком BPM?

                                        «Как все запущено и запутано. Глава Первая»:
                                        … Для успешных продаж «взбрасываются» новые термины и подменяются прежние названия, выдумываются модные фишки, проводится ре-брендинг, вводится тавтология и путаница (см. выше «управление управлением»), а потом создается ореол «успешности» и необходимости внедрений т.п.
                                        Главное: воду сделать мутной, а остальное — «дело техники».

                                        В далеком 2000-ом, в основном употреблялся единственный термин: CASE. И его было достаточно. Когда при проектировании «системы» формализовывали бизнес-логику и укрупненные алгоритмы взаимодействия исполнителей (систем), то в слове CASE понимали S=System и использовали соответствующие инструменты, например, ARIS\EPC.

                                        Когда формализовывали детальные алгоритмы при проектировании ПО, то понимали S=Software и использовали, например, RUP\UML. Уже тогда Rational позволял генерировать код из моделей UML. При этом обходились без разных «BPM\BPMS» и «BPM-like» направлений.
                                        Напомню, что CASE-технология — это инструментарий для системных аналитиков, проектировщиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования систем и разработки ПО. Проблема в том, что этот термин был монетизирован, поэтому нужен «свежий», на котором «еще можно заработать».

                                        Вы про этот CASE?
                                        Основа BPM — это в большей степени процессный подход.

                                        Там же, первой главе:
                                        1.4 Процессное управление и автоматизация
                                        «Говорим BPM — подразумеваем процессное управление»: на протяжении десятилетий от ведущих BPM-консалтеров слышим дифирамбы по процессному управлению. До сих пор считается, что с BPM призван в организации заместить «древний и неэффективный» функциональный подход на «новый и прогрессивный» процессный. …


                                        Теперь к Вашему «священному АСМ»
                                        По Вашей ссылке:
                                        Одни эксперты считают, что ACM это «Pidgin-BPM», примитивная версия BPM, решающая те же проблемы, что и BPM. «Серьезные специалисты», отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти — это считать ACM опцией, дополнительным «бантиком» к BPM.

                                        И это в консервативной wiki! Только это уже говорит, что до практического инженерного понимания этой технологии (или алхимии) предстоит еще долгий путь.

                                        Хорошо. Давайте на паре примеров поймем, что такое АСМ.
                                        Маркетинг и рекламу читать не будем, определений тоже не нужно (алхимия же), только на простых примерах («на пальцах»).

                                        Пример первый, система документооборота.
                                        Я хочу согласовать договор. Есть стандартный конвейер согласования: Отдел 1, Отдел 2, Отдел 3 и т.д.
                                        Все это прошито в Workflow. Я захожу в систему DocFlow, ввожу договор, атрибуты, вызываю преднастроенный шаблон Workflow (с заданными маршрутами) и жму «поехали». Каждому согласанту в соответствии с логикой шаблона даются поручения, выскакивают окошки, требуют заполнения нужных полей и т.п. Потом, когда все отжали нужные кнопки, мне прилетает «Готово». Это в Вашем понимании ВРМ?

                                        Но вдруг в одном экземпляре процесса (согласования договора N) или «кейса» (как правильно?) что-то пошло не так, и договор отклонили, мне прилетает соответствующее сообщение с комментарием. Я читаю, сильно думаю и решаю, что это «нестандартная» ситуация и нужно отправить договор «Иванову», который вообще не участвует в штатном Workflow.
                                        Я жму кнопку: выбрать Иванова и отправить ему договор, а после получения правок от Иванова далее продолжается алгоритм «штатного конвейера».

                                        Это добавка уже реализует подход АСМ? Конечно, ведется архив кейсов, и любой «на моем месте» может вызвать базу знаний и посмотреть как в подобном случае (нештатной ситуации) кто-либо действовал.

                                        Иной Вариант первого примера, когда у меня вообще нет преднастроенного шаблона (т.е. «неструктурированный процесс») и я вручную в DocFlow создаю последовательность поручений (по произвольному списку), прикрепляя файл договора, – это тоже АСМ?

                                        Второй пример покажите на процессе «Управления инцидентами», как он работает в режиме ВРМ и как в режиме АСМ?

                                        Иногда употребляют «Adaptive Workflow Management System» (Pega, Papyrus и др.) — это тоже АСМ? В чем отличие?
                                        • +1
                                          Да, что-то я отвлекся, долго не отвечал.
                                          но вот покушаться на «святыню»: АСМ – это «кощунство»! Верно?

                                          Нет, я его вообще не использую. Но понимаю, и может когда-нибудь он мне пригодится.
                                          Затем когда всем становится очевидно, что беседа идет на разных языках и совсем «о разных BPM» начинаются вопросы к докладчикам: так Ваша система – это же не ВРМ!
                                          Затем достопочтенная публика задается вопросом: Что такое BPM? Час приводят «книжные» термины (цитаты из BPM CBOK, других «процессных библий») – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу».

                                          По-другому и не будет, идея единожды определить, что такое BPM (или EA, или SE, или что угодно) утопична. Люди не выведут единственный, «расово верный», «арийский» BPM. «Не возьмут его под козырек» и стройном шагом не пойдут в светлое будущее.
                                          Вы про этот CASE?

                                          Ваш вопрос не к месту, не нужно подменять понятия.
                                          Пример первый


                                          Второй пример покажите на процессе «Управления инцидентами», как он работает в режиме ВРМ и как в режиме АСМ?

                                          Ну как-нибудь без BPM(N) обойдёмся, там такое не рисуют, так как выглядит это будет глупо, потому что динамическое создание поручений — это как раз не flow. Это как бы «ситуационное управление». На ACM это нарисовать можно, но лучше, чтобы было уже заложено как базовый элемент СЭД.

                                          Иногда употребляют «Adaptive Workflow Management System» (Pega, Papyrus и др.) — это тоже АСМ?

                                          А пёс его знает, у меня же голова не резиновая. Но я вот вижу, что Вы представляетесь специалистом во всём. Но почему-то у Вас «смешались все краски», и Вы не видите разницы, что BPM, что ACM, что ЭВМ, какая к черту разница…
                                          Еще меня терзают смутные сомнения, что Вы придерживаетесь точки зрения: «Есть мнение bipiem, и есть неправильные мнения».
                                          • 0
                                            Я перепутал «Иной Вариант первого примера» и «Второй пример покажите на процессе «Управления инцидентами»».
                                            Не внимательно прочитал, ладно, потом отпишусь, спать надо идти.
                                            • 0
                                              Но я вот вижу, что Вы представляетесь специалистом во всём. Но почему-то у Вас «смешались все краски», и Вы не видите разницы, что BPM, что ACM, что ЭВМ, какая к черту разница…

                                              Потому и смешались, что это «краски алхимиков». Про «специалиста» — странно звучит, «специалиста по алхимии»? Скорее критика современной алхимии.
                                              Вообще, сложно представить специалиста по такому списку:
                                              A list of ALL ENTERPRISE FRAMEWORKS (and Modeling Tools)…
                                              Если хотя бы из этой таблички в номинациях "Body: of Knowledge:" — есть люди, которые могут во всех них хорошо ориентироваться, то им нужно составить перекрестный «путеводитель» и вообще я бы с интересом почитал их статьи об «этой паутине» из «одного и тогож».
                                              Только каждый обычно огораживает отдельную «делянку для бизнеса» и ее «осваивает» (монетизирует), особо «не мешая» другим.

                                              «хВОК», но «БУК» звучит более созвучнее и точнее: часто вообще люди считают что там «на конце» — «book», что по смыслу так и есть.
                                              В указанном списке еще много чего нет, например, нет того же хваленого BPM CBOK.

                                              Составители из Pragmatic Enterprise Consulting, видимо поняв «все многообразие» (всю высоту маркетинговой пирамиды) споткнулись уже на 941 ступеньке и вообще бросили составлять список:
                                              Last updated: 22 February 2013 (941 Frameworks and Modeling Tools)


                                              Если все это было бы действительно так практично, то в этом можно (и нужно) было бы разобраться. Пока же там очень много маркетинга и «налитой воды», дублирования (каждую БУКу дублирует масса «внебучных» аналогов), а сделано почти все это под «маркетинг», «консалтинг», «сертификатинг» и другие продажи.

                                              Хотя, для «видимости» иногда добавлены правильные подходы. Я же за то, чтобы как раз оставить рациональное зерно, но «вытряхнуть» весь маркетинг и домыслы.

                                              Насколько я понял на примере BPM CBOK они пишутся примерно так: собрали группу известных авторов, даже с противоположными взглядами, и дали написать каждому «по чуть-чуть», в итоге получается БУКа из категории письмо «дяди Федору из Простоквашино».

                                              Еще меня терзают смутные сомнения, что Вы придерживаетесь точки зрения: «Есть мнение bipiem, и есть неправильные мнения».

                                              Точнее так: есть
                                              — современная алхимия (как далекий прототип аналогичной науки);
                                              — критика критиков этой алхимии (в т.ч. от bipiem);
                                              — направления к превращению «алхимии в химию».

                                              Одно из направлений — совсем простое: публиковать описания ЕА, каталоги процессов и т.п.
                                              Причем не только — публиковать все это, т.е. «результат» (желательно с цифрой затрат), но и сами проектные подходы: практические методики (на основе которых был получен результат), проблемы при описании ЕА, ход реализации проектов и т.п.

                                              Простой пример: где хоть одна практическая теория \ методика как идентифицировать бизнес-процессы предприятия и составить каталог его процессов? «Воды» и общих рассуждений — много, но «практического» — абсолютный ноль (хочется ошибаться, приведите ссылки на исключения).

                                              В итоге, уверен, выяснится, что результативность проектов и подходов — крайне низкая, а развитие направления ЕА\ВРМ (SE в меньшей степени, они чуть далее продвинулись) в целом, находится примерно на этапе «самолетостроения до братьев Райт».

                                              Примерно как первые конструктора — пилоты:
                                              … порыв ветра сломал крыло его последнего планёра, в результате чего Лилиенталь упал с высоты около 17 м, получив перелом позвоночника. Он умер на следующий день, его последними словами были: «жертвы должны быть принесены»

                                              История авиации
                                              Только в нашем случае, все эти «эксперименты» ведутся не системно и с явной целью «заработать» даже на неудачах (как отдельное высокодоходное бизнес-направление), но главное «безобразие», в большинстве случаев, все это ведется за наш счет (налогоплательщиков).
                                              Практически отсутствует обмен опытом на основе фактов и реальных (проектных) артефактов, т.е. только пиар и домыслы.

                                              В отличие от современных алхимиков, пионеры авиации:
                                              Также как и Лилиенталь, он документировал всю свою работу и фотографировал её результаты, кроме того, он вёл переписку со многими энтузиастами авиации со всего мира.

                                              там же
                                              Открытость — это пол дела, но очень важная.
                                              Далее предстоит методологическая обработка результатов внедрений и т.п., потому что:
                                              Однако большинство этих усилий было обречено на неудачу, так как они разрабатывались любителями, которые не имели полного понимания проблем, …

                                              История авиации
                                              Так же как и самолетостроение, наука «предприятие-строение» станет «взрослой» (станет наукой).
                                              Сейчас гуру позиционируют свои ЕА\ВРМ «технологии» как полеты в космос, с соответствующей стоимостью своих услуг и «методичек».
                                              Это «предприятие-строение» будет настольной книжкой для проектировщиков — «корпоративных и домашних» архитекторов холдингов, МСБ и даже домохозяйств.

                                              Для предприятий будут аналогичные «аэродинамика» и «сопромат» и т.п., которые будут предельно точны и научны, возможно, эти знания также будут оформлены в «ВОК» с прежними названиями, но главное — новые БУКи в отличие от современных, станут практичными. Собственно об этом я говорил уже много.

                                              По примерам ВРМ \ АСМ
                                              Я не понял Ваши примеры, просьба дать пояснения к схемам (видите, туповат, а Вы говорите что «представляюсь специалистом во всём»).

                                              Кроме того, что с моими примерами (документооборот)? Они правильно показывают различие ВРМ \ АСМ?

                                              Также напомню, что, к сожалению, без ответа остался (пример ЕА):
                                              Вроде все подробно, но Теряюсь в догадках, «что делать».

                                              Если нет больше сил доделать начатое описание «Домашнее домохозяйство», то хотя бы изложите (обобщите) что было Вами сделано, что не хватает. И как это «доделать», желательно в формате «для чайников».
                                              Кроме Вас никто вообще ничего не предложил конкретного (несмотря на обилие хваленых БУКов), поэтому «вся надежда на Вас».
                                      • 0
                                        Системная инженерия, ЕА, ВРМ – должны когда-нибудь стать настоящей наукой и инженерией, точно также как и «коды Хэмминга». Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»), проектирование, проверку качества и точности исполнения изделий класса «система».
                                        Неважно, какая это «система»: АСУ, включая, АСУ войсками, АСУТП или государственные информационные системы, «электронное правительство», или целое «предприятие» (ЕА), включая, домохозяйство, бизнес (ИП, МСБ, «корпорат»), государство.

                                        Кстати насчет государства — иногда у меня, как системотехника, действительно руки чешутся бросить все и податься в президенты одного из государств — неудачниц, чтобы начать делать "Систему Управления Государством 2.0". Ведь даже с моим базовым набором знаний видно, когда какие-либо государственные процессы просто не функционируют, когда винтики тупо стоят не на своем месте и крутятся в разные стороны, когда сделано чересчур сложно или забюрократизировано.
                                        Короче много чего с точки зрения построения систем можно было бы в государстве оптимизировать, перенять опыт, но, к сожалению, также с опыта системотехника видно, что Запорожец в Мерседес не переделать никак, а легче все разрушить и разработать полностью новое, но это к сожалению никак не провернуть.

                                        • 0
                                          Кстати насчет государства — иногда у меня, как системотехника, действительно руки чешутся бросить все и податься в президенты одного из государств — неудачниц, чтобы начать делать «Систему Управления Государством 2.0».

                                          Вы не волнуйтесь, даже если и станете президентом, то Вам все равно в нашей стране (думаю и в других тоже) ничего не дадут сделать.
                                          Лучше давайте «снизу» вместе делать SE \ EA \ BPM высокоэффективным инструментом и добавим им «серебряную пулю и волшебную таблетку»

                                          Или хотя бы очистим их от управленческих и маркетинговых «причуд». Первый шаг — раскрытие тайн алхимиков и обзор «платья короля», т.е. публикация проектов SE \ EA \ BPM.

                                          Вместо своей президентской программы, лучше составьте framework своего домохозяйства, как я предлагал здесь:
                                          3 Конкурс на описание «household architecture»

                                        • 0
                                          Я не понял Ваши примеры, просьба дать пояснения к схемам (видите, туповат, а Вы говорите что «представляюсь специалистом во всём»).
                                          Кроме того, что с моими примерами (документооборот)? Они правильно показывают различие ВРМ \ АСМ?

                                          Задача «ИВАНОВУ НА ПОДПИСЬ» добавлена динамически в результате обработки ситуации «Отклонен». Произошла как бы рефлексия кейса, это не соответствует принципам BPM, в котором процесс не может изменить сам себя.
                                          Ключевая разница:
                                          • BPM требует спроектировать процесс заранее.
                                          • ACM (Адаптивный кейс-менеджмент) позволяет изменять кейс в процессе работы.

                                          Управление инцидентами

                                          За основу возьмем информацию отсюда, я не специалист по службе поддержки, но там написано то, что я о ней знал и представлял. Процессный подход там нормально разрисован, повторять его не буду.
                                          Первичный вид с подходом ACM, представлена ниже:

                                          Только не нужно говорить, что это одно и тоже. Конечно и там, и там нарисованы одни и те же действия. Нужно понимать, что оба похода (BPM и ACM) решают задачу, просто один процесс центричный, а другой данные центричный.
                                          • 0
                                            Второй выход (из «Уведомление второй линии поддержки») не нужно рисовать, это я ошибся.
                                            • 0
                                              Дайте прямую ссылочку на описание сей нотациы.
                                              • 0
                                                Это Case Model Management and Notation (CMMN). Замечание: нужно понимать, что: ACM — концепция, CMMN – нотация.
                                                Идею адаптивности понимать и реализовать можно по-разному. В Вашем понимании это будет выглядеть так: Разные алхимики будут говорить: «Вот это ACM, а это нет».
                                            • 0
                                              Прям бальзам на душу. Очень понравилось, полностью согласуется с моим опытом.
                                              • 0
                                                Может быть несколько примеров приведете из опыта. Без фамилий и явок, а «все совпадения — с реальными событиями и лицами — случайны» и т.п.
                                                Многим будет интересно.
                                                • 0
                                                  Хм, надо попробовать, подумаю. Тот же NDA.
                                                  • 0
                                                    Достаточно всего лишь уточнить: Все персонажи являются вымышленными, любые совпадения с реальными людьми и событиями чистая случайность.
                                                    Вот пример, как можно обходить NDA через сказки и мультики:
                                                    Считаем бизнес-процессы. Введение
                                                    Там тоже реальные примеры, тоже запрещенные к разглашению через NDA.

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.