Задания из курса 3.1. Системная инженерия

Убедитесь, что для каждой части вашей рабочей системы у вас запланирована работа по её проектированию, изготовлению, сборке-наладке-отладке, проверке.

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


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

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


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

Целевой системой является этап автоматизации предприятия, проект в череде проектов развития с соответствующей документацией, изменениями в процессах, расширение автоматизированных функций предприятия-клиента как внутри, так и возможно во вне. В зависимости от размера клиента и его стадии развития(уровня зрелости) коммуникация между отделами как внутри его организации, так и с нашими отделами может использовать разные подходы к координации и проведению работ. Встречаем весь набор барьеров интероперабельности предприятий, как концептуальные(уровень договора), так и технические и организационные. Решаем разные проблемы/аспекты, опять же как на уровне договора - аспект бизнеса, так и службами, процессами и данными, которые иногда смежная сторона "не понимает.

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

проверить

Разберём разницу между службами (сервисами) и процессами в контексте интероперабельности по стандарту ГОСТ Р ИСО 11354 максимально просто.

1. Службы (сервисы)

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

  • Примеры:
    • Отправка уведомлений по email.
    • Проверка наличия товара на складе.
    • Аутентификация пользователя.
  • Суть интероперабельности служб:
    Разные системы должны уметь “понимать” и использовать эти функции друг друга. Например, CRM-система может вызвать сервис отправки email из другой системы, не зная, как он устроен внутри.
    Ключевое:

Службы — это “кирпичики”, которые можно комбинировать. Они решают конкретные узкие задачи.


2. Процессы

Это последовательность шагов, которые выполняются для достижения цели. Процессы объединяют несколько служб и действий.

  • Примеры:
    • Оформление заказа:
      1. Проверить наличие товара (сервис 1).
      2. Создать заказ в базе данных (сервис 2).
      3. Отправить клиенту подтверждение (сервис 3).
    • Техническое обслуживание оборудования:
      1. Получить данные с датчиков (сервис 1).
      2. Анализировать риски поломки (сервис 2).
      3. Запланировать ремонт (сервис 3).
  • Суть интероперабельности процессов:
    Разные системы должны уметь координировать свои процессы, даже если они используют разные службы. Например, процесс из ERP-системы может запускать процесс в производственной системе, передавая данные между ними.
    Ключевое:

Процессы — это “сценарии”, которые управляют тем, как службы взаимодействуют между собой. Они описывают логику работы.


Разница на примере

Представьте, что вы строите дом:

  • Службы — это отдельные инструменты: молоток, дрель, пила. Каждый делает что-то своё.
  • Процессы — это инструкция, как использовать эти инструменты: сначала залить фундамент (используя бетономешалку), потом возвести стены (используя кирпичи и раствор), потом установить крышу.

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

Почему это важно по ГОСТ Р ИСО 11354

Стандарт подчёркивает:

  1. Службы должны быть стандартизированы, чтобы их можно было легко подключать в разных системах.
  2. Процессы должны быть гибкими, чтобы их можно было адаптировать под новые требования или изменения в технологиях.


Написан и опубликован пост с рефератом на 3-5 страниц по hyperautomation. В реферат добавлено несколько абзацев про перспективы hyperautomation в вашей организации.

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

Ключевой элемент гиперавтоматизации — сочетание RPA с машинным обучением и обработкой естественного языка (NLP).
ИИ-модели могут распознавать текст в сканированных документах, таких как счета-фактуры или отчеты, извлекать нужные данные (даты, суммы, наименования) и передавать их RPA-ботам для заполнения форм. Это устраняет необходимость ручного ввода даже в случаях, когда информация представлена в нестандартных форматах. Так, в логистике система на основе ИИ может анализировать накладные, определять адреса доставки, а RPA — автоматически вносить эти данные в транспортные системы.
Тут подробнее Портал 1С:ИТС , на 1 квартал 2025 года работает

Преимущество гиперавтоматизации — в её способности работать с устаревшими системами, не имеющими API. RPA-боты взаимодействуют с интерфейсами программ так же, как люди: кликают кнопки, вводят текст в поля форм. Это особенно полезно в банковском секторе, где legacy-системы всё ещё широко используются. Обработка кредитных заявок может включать автоматический сбор данных из PDF-отчетов, их верификацию через ИИ и заполнение анкет в банковском ПО без участия сотрудника.

Однако гиперавтоматизация не ограничивается переносом данных. ИИ добавляет когнитивные функции: предсказание, классификацию, оптимизацию. В бухгалтерии ИИ может анализировать исторические данные, чтобы предугадывать ошибки в заполнении форм, а RPA — корректировать их до отправки. В ритейле гиперавтоматизация помогает автоматизировать формирование отчетов: ИИ анализирует продажи, выделяет тренды, а боты обновляют dashboards в реальном времени.
Подробнее как пример инструмента Портал 1С:ИТС

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

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

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

Перспективы гиперавтоматизации связаны с развитием когнитивных технологий. Уже сейчас системы способны обучаться на основе обратной связи: если RPA-бот сталкивается с ошибкой, ИИ анализирует её причину и корректирует алгоритмы. Это делает процессы всё более автономными.
В юриспруденции гиперавтоматизация может использоваться для анализа договоров: ИИ выделяет ключевые пункты, а RPA вносит правки в шаблоны.

Гиперавтоматизация трансформирует бизнес, объединяя скорость RPA с интеллектом ИИ. Она решает не только задачи автоматизации, но и оптимизирует процессы, делает их прозрачными и адаптивными. Компании, внедряющие такие решения, получают конкурентное преимущество за счёт повышения эффективности и снижения издержек. Однако успех зависит от грамотной интеграции технологий, обучения сотрудников и обеспечения безопасности данных.


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

Служба доставки – это подразделение, занимающееся доставкой. Процесс доставки – это поведение службы доставки. Проверьте: перевод службы на английский – server, а услуги – service. Вы путаете server и service? Программисты, кстати, часто путают: у них service это поведение server в одной фразе, а в другой фразе того же текста service будет синонимом server, который осуществляет этот service (но дальше они server назовут уже аппаратуру, hardware). Каждый раз надо по ситуации разбираться, что там за помянуты типы – и чётко различать систему и её поведение, не путать бег и бегуна.

Вы и в своём тексте за типами не следите: “Целевой системой является этап автоматизации предприятия”. Этап это не вещь, нельзя показать пальцем на место в пространстве-времени, где находится этап – только на место во времени.

Для удержания собранности на типах, особенно типе целевой системы (вещь! не описание, не процесс, не характеристика – физический объект!), у нас время от времени проводятся тренировки, типа описанной в Тренировка "Вы пойдёте к топ-менеджеру?" или "Барышня-мадам".: ailev — LiveJournal

Спасибо за замечание, полезно задумался

Уточню, чтобы добраться до сути.

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

Если искать физичность … работающая как надо программа — это вещь?

Цифровая копия(конечно недокопия, модель, набор параметров, необходимых, но недостаточных для полной копии) предприятия «по данным» о каких то ресурсах разной ликвидности и компетентности в своей отрасли/домене,о деятельности - вещественна базой данных на диске?

  1. Кусок кода, встроенный/добавленный в программу, изменяющий реальный процесс деятельности/алгоритм выполнения … пусть сервиса доставки.

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

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

Это хорошо, когда ты знаешь, что делает организация, для которой ты выполняешь заказ/проект/сервис — вовлекает, если посчастливиться в большое и полезное дело создания «космического аппарата» + ты явно не ошибешься делая свою подсистемку, т.к. цель/модель/образ у тебя в голове, пусть и не твоя а над-над- над ЦС.

Не частенько, но бывает — сделайте нам «отсюда и до забора».

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

Тесты, приемка, да, спасибо, свободны.

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

Здесь описание - вроде физичная ЦС, вещь.

В общем заземление и физика не оспоримо прагматичны.

И кто-то наверху всегда знает, что в итоге хотел сделать … или делает … или не всегда … или то, что хотел-понял что не сделает и делает что получиться, но пока не знает на что хватит ресурсов )

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

Если вы не знаете, что там в окружении, а просто выполняете чью-то просьбу “от забора до обеда” – ну, количество rework будет запредельным, будете 10% времени делать, 90% времени переделывать, и ещё проблемы с оплатой этих работ наверняка будут.

Алгоритм анализирует входные параметры (например, сроки, стоимость, характеристики товара) и автоматически выбирает оптимальный метод доставки на основе заданных правил. Правила могут подгружаться позже, развиваясь, с появлением новых параметров и инструментов/механизмов.
В зависимости от габаритов товара меняются задействованные роли как “погрузчиков” - человек, электропогрузчик, кран, так и доставщиков, которые могут это делать пешком, на велике, или использованием разной грузоподъемности машин. Может части процесса(этапы) синхронизировать диспетчер, а может бот. Работают разные участники (состав также меняется), разными методами, с задействованием разных инструментов.
От сроков и стоимости, наличия машин, количества заказов “пляшет” выбор методов и набор участников процесса.

Если вы не знаете, что там в окружении, а просто выполняете чью-то просьбу “от забора до обеда” – ну, количество rework будет запредельным, будете 10% времени делать, 90% времени переделывать, и ещё проблемы с оплатой этих работ наверняка будут.

Согласен … но в жизни начальнику виднее: вот тебе вход, сделай на выходе вот это. Остальное - не твои заботы (

Это вы рассказываете симпатическую магию (что описания как-то меняют мир – вы колете булавками куклу Вуду, а там в жизни с описанным человеком что-то происходит). Метод доставки – это как в жизни что-то происходит с доставляемым грузом, а алгоритм меняет только описание. Чтобы изменение описания как-то стало изменением в жизни надо много чего сделать. Ну, и у кого ответственность за это? Кто это изменение проводит, и насколько хорошо? Где граница ответственности того, кто алгоритм меняет – так поменять, чтобы в жизни что-то изменилось (тогда обычно не только алгоритмом надо заниматься), или просто поменять алгоритм, которые меняет описание доставки – и дальше хоть потоп?

Движение DevOps как раз по этой линии рассуждений появлялось – что происходит после того, как программист поменял свой код. Но оно остановилось на “готовая программа, всё работает”. Но дальше – реальный мир, за пределами программы. Его кто менять будет?

1 лайк

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

А мастерство владения инструментом ему кто делает? Это ж как вертолётом управлять, таблеткой эти знания не дашь. Если в жизни с доставкой что-то не так – кто виноват, программа или плохое мастерство её пользователей? Вертолёт упал – пилот виноват, или производитель вертолёта? Кто учит пилотов летать?

Конечно разработчики

Смотря кто смотрит :wink:
У программистов всегда пользователи криворукие, у пользователей программа навсегда сырая и неудобна в использовании.

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

Я больше про барьеры интероперабельности между организациями и конфликты между уровнями, если конечный продукт многу-многу- мно гумно гу передельный )

Я за ответственность на всех уровнях и против безответственности каждого

Просто сложно это все)

Непонятно само собой. Ибо “программа” это одна система, а “программа плюс люди с мастерством” – другая система, а “программа плюс люди с мастерством плюс сделанный этими людьми с мастерством продукт” – третья система. У них разные названия, они стоят разных денег, вложения разного труда.

Класс. :+1:
Стало легче детализировать мысль.
Программа - ответственность разработчиков всегда … если опустить не полноту описания задачи заказчиком … и не рассматривать время, что проект может стать не актуальным к завершению.

“программа плюс люди с мастерством” - ответственность делиться … .как договорятся … зависит от сложности и масштабов проекта, людей, управленческой культуры в организации::системе-заказчике

Ответственный/директор за третью систему(организацию, для которой делается инструмент/программа) чаще всего не убирают заборы(оставляют ответственность) … .по разным причинам(из осознанного: малый уровень доверия пока … или принципы на всю жизнь не позволяют, чаще где то посередине: боязнь развала конфигурации из-за ПО, быстрые бесконтрольные изменения, имхо разумно и понимаемо как причина) … не остается выбора … только “перекидывать через стену”/ принести и отойти у порога, как в известной книжке “Управление конфигурацией для руководителей высшего звена”.
Дальше мы сами попробуем … спасибо … если что - позовем.

Да и это в простом варианте, там еще третья система(“программа плюс люди с мастерством плюс сделанный этими людьми с мастерством продукт”) чаще не совпадает с организацией::система-заказчик в целом.