Можете пошагово подсказать, как получить программный код (желательно на нескольких разных языках, windows), например, для программы "калькулятор". Что нужно установить и что нарисовать?
Можете привести расчет надежности своего "отказоустойчивого кластера"? Или подобного. Включая состояние "отказ, необнаруженный внутренней системой управления кластера".
Не увидел семантического сахара. Это обычный инструментарий SCADA (в 90-х на трасе моде пилил) и Mindstorms EV3 (семикласснику помогал). Если говорить о языках программирования (коде), то можно вспомнить 90-е: код на основе UML (Rational) или EPC (колхоз на ARIS script).
Хотелось бы так: нарисовал схемку - и жмешь кнопку: "дай код js", а рядом с ней "дай код VBA". Как дальнейшее развитие BPMN, только с формированием "всего кода" из схемы.
Семантический сахар, - это когда один образ (та же схема), а на выходе - различные вариации созданной логики, т.е. разные синтаксические представления (языки программирования) одного образа из разных компонент, склеенных семантическим сахаром. Например, в части визуализации алгоритмов: разные обертки \ представления \ графические нотации Одного алгоритма, см.
В подвале дома г-жи Раку оборудована мастерская по изготовлению гончарных изделий. Данный процесс предполагает выполнение нескольких задач – надо размять глину, сформовать изделие, обработать и подсушить его, покрыть глазурью, обжечь в печи.
От какой величины минимального блага, бедняк начинает получать удовольствие? Где средняя мера?
Полагаю, что подход может быть на основе чувства голода (тот же концепт). Голодающему дали немного еды (одну котлету), потом он питается нормально, потом переедает. Однако начав с одной котлеты, он все равно "развиваясь" не сможет съесть двадцать - это физиологический предел его желудка. Люди (объемы их желудка) тоже разные, но физиология "в целом" одна (плюс - минус пара котлет).
Также и с благом: должен быть благо-физиологический барьер. Если пофантазировать и привязать объем благ к котлетам (для некоторых они тоже благо): получил одно благо - съел котлету (в нагрузку за благо), получил второе благо - еще одну котлету и т.д. Ну а далее от жадности к благам: все равно больше предельного благ "не впихнёшь" в виртуальный желудок благ, эквивалентный "котлетному".
Если про человечность, то это видимо и про чувство меры, в том числе применительно к объему пользуемых человеком благ (даже если они сами с неба на него свалились). Только ограничивать потребление, что благ, что пищи (от ожирения страдает все больше число людей) - далеко не каждый способен.
Это котлетный эквивалент потребных благ. Говорят, что у каждого человека свой уровень потребления благ. Нет - это его жадность (она видимо безграничная), а человеческий эталон - он примерно одинаков, как и объем его желудка.
Можно с серединой пирамиды потребностей Маслоу поиграться: только верхние ее уровни сложно нормировать.
В любом случае, "архитектурный репозитарий" нужно хранить в каком-либо формате.
Как и в каком формате хранить данные (логику) моделей? Архитектурные модели и данные о всех моделях компании и связях между моделями, атрибутами моделей, атрибутами объектов моделей. Модели процессов, структуры и иерархии процессов, организационных единиц, данных, документов и т.п. Да еще так, чтобы эти форматы были открытыми и «прозрачными».
Понятно, что речь не про формат Graphviz DOT (Mermaid, PlantUML и т.п.), т.к. это лишь промежуточное представление (синтаксические инструменты «обертывания» смысла в «цветные картинки»). Использовать реляционное (связанные таблички) представление данных модели, как это сделано во всех CASE\ BPMS системах, – это вариант постоянных экспортов \ импортов (ARIS XML) в закрытые проприетарные форматы каждой системы (ARIS Document format, ADF). Решением задачи может стать подход "Semantic BPM" (Semantic EA).
Чтобы лучше понять разницу между процессным, проектным и продуктовым подходом, можно познакомиться со
Повторюсь, что в части "процессный vs продуктовый подход" - в обоих случаях речь про клиентоориентированность и при пиаре процессного подхода, эти же мантры про клиентоориентированность повторяются слово в слово как и при пиаре продуктового подхода. В целом «продуктовый подход» - это некая свежая «маркетинговая обертка» старого «процессного подхода», см. CBOK 3.0:
Клиенто-ориентированность в процессно-ориентированном подходе
В этой главе рассматриваются организационные факторы, на которые следует обратить внимание компании, стремящейся стать клиенто– и процессно‑ориентированной.
Основная идея заключается в том, что организация должна взять под контроль потоки работ, создающие ценность для клиентов и для компании и пересекающие традиционные границы внутри организации.
... Процессная организация представляет собой надстройку над традиционной схемой организации, призванную усилить нацеленность на потребителя и на процессы.
А также п. 2.4 [CBOK30]: BPM нацелен на создание ценности для потребителя
...
Главный урок этого примера и ключевая концепция BPM – бизнес‑процесс создает ценность для потребителя в форме продукции или услуг. Суть BPM заключается в оптимизации того, как эта ценность создается.
Организации, достигшие успеха в управлении бизнес‑процессами, выращивают и воспитывают культуру клиентоориентированности на корпоративном уровне, на уровне функций и ниже, до уровня ролей.
/ Конец цитат.
Чем эти мантры CBOK (клиенто-ориентированность) отличаются от мантр продуктового подхода в деятельности компании? Какую сравнительную табличку подходов посоветуете? Хотелось бы найти не общие фразы, а конкретику именно на противопоставлении.
Уточняющий Вопрос: Допустим есть компания с процессным подходом. Что нужно изменить в орг-структуре компании, чтобы реализовать продуктовый подход?
По статье:
Улыбка – отныне ваш «продукт».
Неужели при процессном или даже функциональном или даже до-функциональном подходе "Улыбка" не была - продуктом? По моему - она всегда продукт, вне зависимости от подхода. В любой деятельности есть конечный продукт, предоставляемый клиенту - и это результат продуктового процесса (продукт из каталога продуктов компании).
Подход с карточками, типизацией и т.п. - базовый и не только в ZettelKasten. Что-то подобное делал в Excel (поля это - свойства объектов, каждый набор объектов одного типа - отдельный лист, связи, теги и т.п.).
Родственное направление: semantic ZettelKasten – как «младший брат» semantic Wiki, семантическая база знаний и т.п. Напомним, что обычный ZettelKasten (Obsidian, Logseq, Joplin и т.п.) изначально имеют графовую подсистему, но такую же убогую (см. «Вопрос»). Такой sZK/ sPKM: Personal Knowledge Models with Semantic Technologies обсуждается, но широкого применения не нашел и имеет ту же проблему – задание сложной графической нотации отображения (визуализации) ...
Если есть opensource ZettelKasten на RDF, подскажите.
Пользователь без знания UML \ plantUML заполняет табличку, жмет кнопку "Нарисовать" (или в реальном времени, как это в ARIS и sequencediagram). Заполнение таблички было бы проще, чем https://sequencediagram.org/
А если посмотреть еще дальше, то строить подобное хотелось бы через RDF (единый формат семантики и исходник для дальнейших dot, Mermaid, PlantUML и др.), идея тут:
Там блочный вариант, без ветвления в графическом виде. Если к нему "прикрутить" EPC (ветвления и др.), то получился бы указанный выше вариант (JS из ЕРС).
Также было бы хорошо добавить генератор dot (graphviz), как это сделано, например, в drawio (mermaid), т.к. добавляется возможность редактирования схемы (в отличие от многочисленных вьюверов).
Поколения Эльбрусов (название картинки, там 4 объекта)
На данный момент архитектура Е2К развилась до 6 поколения,
Где показаны все поколения?
Помню горячие обсуждения E2K на forum_ixbt.com (и еще где-то) в конце 90-х. Сейчас эти топики - там потерли (остались только начиная с 2000-х, но они более прохладные). Если кто-то знает, где такие еще сохранились - подскажите, будет интересно освежить в памяти.
Немного иначе, но более комплексно и глобальнее и тоже про ТАРМ (стандартизация, унификация и т.п.), но не про коммерческий сектор, а государственный (чиновники) и военный.
Новая любовь российского энтерпрайза — типовое автоматизированное рабочее место.
«Старая любовь» называлась: Унифицированный защищенный АРМ для органов государственного и военного управления различного уровня, код «Холст Соломатина». Более двух десятков лет назад (начало 2000-х) Соломатин устроил большой переполох, выкатив концепцию «ХОЛСТ» от ВНИИНС им. Соломатина. Он предложил линейку унифицированных защищенных АРМ для чиновников и военных и хотел законодательно закрепить унификацию (читай использование только своих Холстов). Отрасль пережила шок: неужели теперь почти все деньги утекут Соломатину? Это унифицированное «ядро» было бы практически основной строчкой в большинстве спецификаций на закупку в гос и воен-проектах автоматизации.
Конечно такая «глобальная концепция» не прошла (отдельно конечно Холсты продавались), в первую очередь из-за страха потери доли в распилах. «Железо» в таких типовых АРМ конечно – «обычное китайское».
Повсеместное использование «Холстов» долго обсуждалось и даже «впиталось» в виде проектных решений многих НИОКР того времени. До этого была линейка АРМ «Багет» на 486, но ее кампания была куда «скромнее». Масштаб кампании по «охвату / захвату рынка» Холстами – был «общегосударственным» и чувствовался мощный административный ресурс - лоббирование в верхах, поэтому и возникла (прежде всего в ВПК) паника, т.к. некоторое время дело «шло» к «победе Холста» (Соломатина).
На базе операционной системы ОС МСВС 3.0 (ее модификаций) и СУБД “Линтер ВС” 6.0 (ее модификаций) во ВНИИНС создан и совершенствуется по результатам эксплуатации защищенный стационарный ПТК “Холст-АСУ-С”, предназначенный для обеспечения построения защищенных АС обработки закрытой информации и создания локальных вычислительных сетей (ЛВС) для органов государственного и военного управления различного уровня. Программно-технический комплекс “Холст-АСУ-С” обеспечивает построение различных функциональных АС на базе единого программного, унифицированного информационно-лингвистического обеспечения, а также унифицированных интерфейсов и протоколов обмена данными в ЛВС с заданными требованиями внутриобъектового (внутри органа госуправления) и межобъектового (между разнородными органами госуправления) информационного взаимодействия с обеспечением защиты информации от несанкциоированного доступа и от компьютерных вирусов.
…
Таковы основные первоочередные проблемные вопросы, решение которых позволит ВНИИНСу определиться с местом и ролью в реализации Национальной российской программной платформы для создания защищенных от несанкционированного доступа АСУ государственного и военного управления, базирующихся на эффективных системах поддержки принятия решений.
На схожую тему пишу статью. Вот небольшой фрагмент:
Эволюция подходов и орг-штатных структур к управлению организацией (процессами организации)
1 Кустарный подход и мануфактура на примере ДоФордизма
Мелкосерийное производство, изготовление авто на заказ (не на склад). Бригада на первых этапах из «универсальных солдат» (Бригада-У, универсалы) – которые вместе собирают один автомобиль. Это высокопрофессиональные мастера, знающие процесс «сборки от и до».
Бригадир – фактически является владельцем процесса: управляет процессом (руководит), подсказывает (инструктор) и контролирует, оптимизирует процесс и т.п.
Более того, Бригадир – еще и владелец продукта, т.к. заказы индивидуальные и он с Заказчиком детально предварительно проговаривает все индивидуальные особенности заказа (авто). В зависимости от запросов заказчика типовой проект (регулярный процесс) авто мог трансформироваться в «целый проект».
Бригада-Ф (функциональное) уже имеет специализацию, кто-то лучше подгоняет детали между собой (не было стандартных, подгонка была индивидуальная и авто получались даже разных размеров), кто-то лучше регулирует сход-развал или работу двигателя и т.п. Однако это все равно было внутри одной бригады (без «функциональных колодцев»). Каждая бригада собирала свой автомобиль в рамках сквозного процесса (end-to-end), при этом могла получать обратную связь от заказчика на разных этапах производства.
Получается идеальный (абсолютный) «процессный подход», даже процессно-продуктовый, а в случае значительных изменений от типового варианта (стандартной конфигурации): проектно – продуктовый.
Пруфы - см. Вумек, Машина, которая изменила мир и т.п.
Вопросы по статье. К новомодному сегодня «продуктовому подходу»: 20-30 лет назад ровно те же «преимущества»:
приписывались Процессному подходу. Такое впечатление, что многим хочется продать тот же процессный подход, но в новой «продуктовой» упаковке (обертке).
В чем различие процессного и продуктового подходов? Без высокопарных слов.
И про Лошарика (АС-31) не забудьте.
Можете пошагово подсказать, как получить программный код (желательно на нескольких разных языках, windows), например, для программы "калькулятор". Что нужно установить и что нарисовать?
Можете привести расчет надежности своего "отказоустойчивого кластера"? Или подобного. Включая состояние "отказ, необнаруженный внутренней системой управления кластера".
Дайте ссылку на пятерку лучших и бесплатных СУТ-шаблонов Excel.
Не увидел семантического сахара. Это обычный инструментарий SCADA (в 90-х на трасе моде пилил) и Mindstorms EV3 (семикласснику помогал). Если говорить о языках программирования (коде), то можно вспомнить 90-е: код на основе UML (Rational) или EPC (колхоз на ARIS script).
Хотелось бы так: нарисовал схемку - и жмешь кнопку: "дай код js", а рядом с ней "дай код VBA". Как дальнейшее развитие BPMN, только с формированием "всего кода" из схемы.
Семантический сахар, - это когда один образ (та же схема), а на выходе - различные вариации созданной логики, т.е. разные синтаксические представления (языки программирования) одного образа из разных компонент, склеенных семантическим сахаром. Например, в части визуализации алгоритмов: разные обертки \ представления \ графические нотации Одного алгоритма, см.
ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
Напомнило начало из Минцберга (Структура в кулаке):
Off-line никак?
Полагаю, что подход может быть на основе чувства голода (тот же концепт). Голодающему дали немного еды (одну котлету), потом он питается нормально, потом переедает. Однако начав с одной котлеты, он все равно "развиваясь" не сможет съесть двадцать - это физиологический предел его желудка. Люди (объемы их желудка) тоже разные, но физиология "в целом" одна (плюс - минус пара котлет).
Также и с благом: должен быть благо-физиологический барьер. Если пофантазировать и привязать объем благ к котлетам (для некоторых они тоже благо): получил одно благо - съел котлету (в нагрузку за благо), получил второе благо - еще одну котлету и т.д. Ну а далее от жадности к благам: все равно больше предельного благ "не впихнёшь" в виртуальный желудок благ, эквивалентный "котлетному".
Если про человечность, то это видимо и про чувство меры, в том числе применительно к объему пользуемых человеком благ (даже если они сами с неба на него свалились). Только ограничивать потребление, что благ, что пищи (от ожирения страдает все больше число людей) - далеко не каждый способен.
Это котлетный эквивалент потребных благ. Говорят, что у каждого человека свой уровень потребления благ. Нет - это его жадность (она видимо безграничная), а человеческий эталон - он примерно одинаков, как и объем его желудка.
Можно с серединой пирамиды потребностей Маслоу поиграться: только верхние ее уровни сложно нормировать.
Схожие темы:
Диаграмма последовательности
ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
В любом случае, "архитектурный репозитарий" нужно хранить в каком-либо формате.
Как и в каком формате хранить данные (логику) моделей? Архитектурные модели и данные о всех моделях компании и связях между моделями, атрибутами моделей, атрибутами объектов моделей. Модели процессов, структуры и иерархии процессов, организационных единиц, данных, документов и т.п. Да еще так, чтобы эти форматы были открытыми и «прозрачными».
Понятно, что речь не про формат Graphviz DOT (Mermaid, PlantUML и т.п.), т.к. это лишь промежуточное представление (синтаксические инструменты «обертывания» смысла в «цветные картинки»). Использовать реляционное (связанные таблички) представление данных модели, как это сделано во всех CASE\ BPMS системах, – это вариант постоянных экспортов \ импортов (ARIS XML) в закрытые проприетарные форматы каждой системы (ARIS Document format, ADF). Решением задачи может стать подход "Semantic BPM" (Semantic EA).
Повторюсь, что в части "процессный vs продуктовый подход" - в обоих случаях речь про клиентоориентированность и при пиаре процессного подхода, эти же мантры про клиентоориентированность повторяются слово в слово как и при пиаре продуктового подхода. В целом «продуктовый подход» - это некая свежая «маркетинговая обертка» старого «процессного подхода», см. CBOK 3.0:
Клиенто-ориентированность в процессно-ориентированном подходе
Клиенто – ориентированность подается как ключевая составляющая процессно‑ориентированности (процессного подхода) [CBOK30]:
Глава 8 Процессная организация
В этой главе рассматриваются организационные факторы, на которые следует обратить внимание компании, стремящейся стать клиенто– и процессно‑ориентированной.
Основная идея заключается в том, что организация должна взять под контроль потоки работ, создающие ценность для клиентов и для компании и пересекающие традиционные границы внутри организации.
... Процессная организация представляет собой надстройку над традиционной схемой организации, призванную усилить нацеленность на потребителя и на процессы.
А также п. 2.4 [CBOK30]: BPM нацелен на создание ценности для потребителя
...
Главный урок этого примера и ключевая концепция BPM – бизнес‑процесс создает ценность для потребителя в форме продукции или услуг. Суть BPM заключается в оптимизации того, как эта ценность создается.
Организации, достигшие успеха в управлении бизнес‑процессами, выращивают и воспитывают культуру клиентоориентированности на корпоративном уровне, на уровне функций и ниже, до уровня ролей.
/ Конец цитат.
Чем эти мантры CBOK (клиенто-ориентированность) отличаются от мантр продуктового подхода в деятельности компании? Какую сравнительную табличку подходов посоветуете? Хотелось бы найти не общие фразы, а конкретику именно на противопоставлении.
Относительно проект или процесс, нечто похожее:
В толковый словарь Business Process Management: Процесс vs Проект
Уточняющий Вопрос: Допустим есть компания с процессным подходом. Что нужно изменить в орг-структуре компании, чтобы реализовать продуктовый подход?
По статье:
Неужели при процессном или даже функциональном или даже до-функциональном подходе "Улыбка" не была - продуктом? По моему - она всегда продукт, вне зависимости от подхода. В любой деятельности есть конечный продукт, предоставляемый клиенту - и это результат продуктового процесса (продукт из каталога продуктов компании).
Подход с карточками, типизацией и т.п. - базовый и не только в ZettelKasten. Что-то подобное делал в Excel (поля это - свойства объектов, каждый набор объектов одного типа - отдельный лист, связи, теги и т.п.).
Один из ключевых вопросов остается про графическую визуализацию и семантику:
Если есть opensource ZettelKasten на RDF, подскажите.
Возможен и такой: "Смарт-инструменты «Таблица -> Схема» для UML \ plantUML", по аналогии с ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
Пользователь без знания UML \ plantUML заполняет табличку, жмет кнопку "Нарисовать" (или в реальном времени, как это в ARIS и sequencediagram). Заполнение таблички было бы проще, чем https://sequencediagram.org/
А если посмотреть еще дальше, то строить подобное хотелось бы через RDF (единый формат семантики и исходник для дальнейших dot, Mermaid, PlantUML и др.), идея тут:
Semantic BPM. Семантика и синтаксис бизнес-процессов
Я про примеры онтологий, а не их фрагментов. Например, https://github.com/dfrant/InformationSecurityOntology
Кашу ссылками не испортишь (с), см. https://habr.com/ru/articles/795883/
Где ссылки на примеры рассматриваемых онтологий?
1 "Low-сode конструктор логики с экcпортом" в JS из ЕРС (Дракон - уж слишком редкий зверь):
ЕРС (и) или Дракон
На таком Low-сode конструкторе хотел бы построить нечто SmartDesign - подобное: https://habr.com/ru/articles/810851/
jsDOT SmartDesign
2 Нечто подобное: "Low-сode конструктор без ветвлений" - показан на Рисунок 9. Модель структуры
https://www.hse.ru/edu/vkr/84176040
Там блочный вариант, без ветвления в графическом виде. Если к нему "прикрутить" EPC (ветвления и др.), то получился бы указанный выше вариант (JS из ЕРС).
3 Есть обратные конструкторы, например:
https://code2flow.com/
Пример для:
ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
По Вашей классификации, это "набросчики" или нет (любопытно)?:
https://habr.com/ru/articles/570716/
хобот - это хабр?
Где показаны все поколения?
Помню горячие обсуждения E2K на forum_ixbt.com (и еще где-то) в конце 90-х. Сейчас эти топики - там потерли (остались только начиная с 2000-х, но они более прохладные). Если кто-то знает, где такие еще сохранились - подскажите, будет интересно освежить в памяти.
Немного иначе, но более комплексно и глобальнее и тоже про ТАРМ (стандартизация, унификация и т.п.), но не про коммерческий сектор, а государственный (чиновники) и военный.
«Старая любовь» называлась: Унифицированный защищенный АРМ для органов государственного и военного управления различного уровня, код «Холст Соломатина». Более двух десятков лет назад (начало 2000-х) Соломатин устроил большой переполох, выкатив концепцию «ХОЛСТ» от ВНИИНС им. Соломатина. Он предложил линейку унифицированных защищенных АРМ для чиновников и военных и хотел законодательно закрепить унификацию (читай использование только своих Холстов). Отрасль пережила шок: неужели теперь почти все деньги утекут Соломатину? Это унифицированное «ядро» было бы практически основной строчкой в большинстве спецификаций на закупку в гос и воен-проектах автоматизации.
Конечно такая «глобальная концепция» не прошла (отдельно конечно Холсты продавались), в первую очередь из-за страха потери доли в распилах. «Железо» в таких типовых АРМ конечно – «обычное китайское».
Повсеместное использование «Холстов» долго обсуждалось и даже «впиталось» в виде проектных решений многих НИОКР того времени. До этого была линейка АРМ «Багет» на 486, но ее кампания была куда «скромнее». Масштаб кампании по «охвату / захвату рынка» Холстами – был «общегосударственным» и чувствовался мощный административный ресурс - лоббирование в верхах, поэтому и возникла (прежде всего в ВПК) паника, т.к. некоторое время дело «шло» к «победе Холста» (Соломатина).
На примере ПТК “Холст-АСУ-С”:
На схожую тему пишу статью. Вот небольшой фрагмент:
Пруфы - см. Вумек, Машина, которая изменила мир и т.п.
Вопросы по статье. К новомодному сегодня «продуктовому подходу»: 20-30 лет назад ровно те же «преимущества»:
а) ориентация на результат и клиенториентированность, б) процесс делится на подпроцессы, в рамках которых специалисты разных направлений вместе выполняют задачу в) много других общих и как-бы правильных фраз
приписывались Процессному подходу. Такое впечатление, что многим хочется продать тот же процессный подход, но в новой «продуктовой» упаковке (обертке).
В чем различие процессного и продуктового подходов? Без высокопарных слов.
Причем «хороший продуктовый подход» часто противопоставляется «плохому проектному», например:
А как же типовые проекты?
Результат проекта - есть продукт (по ссылке утверждается, что нет)?