Русский
Русский
English
Статистика
Реклама

Bpm

Хорошие BPM инструменты, которых нет и нет. Моделирование процессов

12.03.2021 20:06:18 | Автор: admin

Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего

Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном АРИС-ARIS и MS visio).

Уточнения. BPM (business process management, управление бизнес-процессами) - это тот, который из области системной инженерии (SE), который почему-то теперь называют BPA (анализ). Он же CASE, где S= "system" (не "software").

"Бизнес-процесс" - это синоним "процесс" и даже таким терминам как: операция, действие, активность, функция, процедура. Приставку "бизнес" указывают, чтобы отличать процессы класса "административные" - "деловые" (см. BPM CBOK) от химических и физических (других "природных") процессов. Любой процесс, который реализуется человеком или компьютером (программой, роботом), - это "бизнес-процесс", несмотря на то, что непосредственно к "бизнесу" отношения может и не иметь. Настолько вот запутан этот BPM, хотя в реальности он прост.

Задача

Она очень простая. Нужно простым образом формализовывать процессы, нас окружающие. Так формализовать, чтобы модели процессов были адекватны реальным процессам, но чтобы их визуализацию хоть как-то понимало большинство людей, первый раз слышащих слово "BPM". Формально "интуитивно понятных" BPM-нотаций - много (также как много рекламно-маркетингового шума о BPM), но взять особо нечего. Однако здесь важна не только сама нотация (IDEF\VAD\EPC\BPMN\UML и т.п.), а механизмы ее представления на экране: слои, вариативность "точек зрения" (view-шек, представлений) и т.п. На мой взгляд, лучшим вариантом пока остается EPC (Event-driven Process Chain), но не суть, - представленные ниже подходы могут применяться к другим нотациям.

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

1. Подходы к визуализации диаграммы

1.1 Слои модели

Они позволяют управлять сложностью внутри одной модели (схемы). Например, введем три категории: Документы (входящие и исходящие), функция, ресурсы (роли и инструменты). Для каждой категории - свой слой.

Нарисовал нам наш архитектор (специалист по моделированию процессов) схему:

Рис. 1 Процесс оформления заявления

Visio Stencil Library for EPC - не нашел, поэтому "как то так" (штатная EPC - вообще "никакая").

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

Путь к пониманию - это упрощение схемы, например, будем отключать слои. В правильном инструменте (BPM-Tool) должны быть кнопки управления слоями - категориями. По кнопке "отключить ресурсы" - будет скрыт слой "ресурсы", в котором показаны объекты схемы (модели) типа "Роль" {Работник; Начальник} и Инструмент {MS Word}. Уже схема стала менее нагруженной (правой части не стало).

Далее отключаем слой "Документооборот" (docflow) и остается только последовательность действий (workflow, Process Flow), который говорит, что нужно провести всего две операции.

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

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

Пример такой реализации возможен в MS Visio:

Рис. 2 Управление слоями в MS Visio

Инструмент управления слоями, как управление сложностью - давно норма в векторных графических редакторах, ГИС и других CAD-системах, например, AutoCAD.

1.2 Плавательные дорожки

Swimlane позволяют группировать процесс по разрезам "Исполнители" и "Инструменты" (в общем случае - в разрезе любой иной категории объектов).

Применительно к Рис. 1 "Процесс оформления заявления": отключили слой "документы", а оставшуюся часть (функции и ресурсы) представили в виде одной или двух Swimlane (опять же "по кнопке").

Рис. 3 Swimlane по ролям в горизонтальной плоскости

Применительно к рассматриваемому случаю возможны следующие комбинации Swimlane:

- две одинарные (горизонт, вертикаль) по ролям;

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

- две двойные, "шахматка", таблица (горизонт - роли, вертикаль - инструменты и наоборот).

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

Основная проблема "дорожек" в том, что когда "дорожки" не нагруженные, то "съедается" основная часть листа и плотность "упаковки" объектов в модели процесса становится мизерная (КПД бассейна, где загружены только две дорожки, а остальные пустые - низкое).

1.3 Объекты модели и их атрибуты, свойства

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

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

В Visio это могут быть данные фигуры и таблица свойств фигуры (ShapeSheet). Еще интереснее свойства хранить в отдельном файле Excel , например, связанном с visio (штатная функция visio). Такой подход позволяет иметь репозитарий свойств объектов в файле Excel и соответственно обширные инструменты поиска, сортировки и т.п. Любой BPM инструмент, включая АРИС, не имеет таких развитых возможностей для анализа как Excel , поэтому выгрузка в Excel интересуемой пользователя атрибутики была бы важным элементом любого BPM-инструмента.

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

1.4 Задание своей нотации (на примере новой ЕРС ver. 2)

Посмотрим на примере нотации ЕРС. Что же в ней улучшить? Все улучшения запишем в гипотетическую ЕРС2 нотацию.

Есть предубеждение, что Событийная цепочка процессов обязательно должна иметь строгое чередование "функция" - "событие". Это не так: события указываются только тогда, когда это действительно нужно.

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

Как показано в п. 1.1 "Слои модели": выделяем зону docflow, EPC-workflow и ресурсную зону. Docflow, а также любые другие входы и выходы функции (включая материалы, заготовки, полуфабрикаты и конечные продукты) - отображаем слева от функции (отдельная стрелка для всех входов, отдельная для всех выходов) с соответствующим направлением движения, а все ресурсы - справа от функции (без направленных коннекторов). Это позволит иметь стандартный "взгляд" на процесс и сразу фокусироваться на конкретной зоне.

В ЕРС2 будет классификация моделей: приведенная и мультиресурсная. В приведенной схеме будет к каждой функции привязано не более одной роли (инструмента), чтобы была однозначность по исполнителю (инструментарию), что важно не только для анализа, но и при построении Swimlane (каждому "пловцу - исполнителю" по выделенной дорожке).

Возможность задания своей нотации в инструменте моделирования означает подсказку (блокировку) при некорректном построении модели, как в момент отрисовки, так и через проверочный отчет построенной диаграммы. Например, в ЕРС2 предусматриваются следующие типы коннекторов: для входящих сущностей (входящие документы, материалы-заготовки), для выходящих (исходящие документы, продукты операции), соединитель потока (функции, события), соединитель ресурса. В объекте "функция" предусматриваются три "Connection Point" (visio):

- вверху и внизу объекта "функция" (и "события") - для указания структуры потока (очередность действий, событий);

- слева в овале "функция" два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);

- справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.

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

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

Вопрос: кроме как в visio, где можно задавать новые нотации и делать проверки на соответствие (валидность), аналогичные показанным выше?

1.5 Из таблицы - схему, а из схемы - таблицу

Если посмотреть на ЕРС схему (рис. 1), то видно, что она однозначно задается таблицей. Поля таблицы: вход, выход, функция, исполнитель, инструмент. Заполнили табличку, нажали кнопку "построить" - и схема сгенерировалась. Справедливо и обратное: по нарисованной схеме можно построить адекватную табличку без потери информации (lossless).

Механизм "Из таблицы - схему" в ARIS \ ARIS Express называется Smart Designer. Только он не умеет строить ветвление процесса. На всякий случай: поиск по "ARIS Smart Designer EPC", закладка "картинки".

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

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

Концептуально изложенный подход близок к выделенной в АРИС нотации "табличная ЕРС" (см. "Нотация ЕРС в виде таблицы"), но здесь реализация в виде обычной текстовой таблицы, т.е. ближе к ARIS Smart Designer. Причем логику процесса также можно указать в составе таблицы, например, как ссылка на предшествующий объект (этого нет Smart Designer, но не сложно добавить "что-то" для ЕРС2). Таблицу можно вставлять в текстовые регламенты word и макросом (VBA) генерить схему процесса ("не отходя от кассы") с дублированием конечно в общем каталоге моделей.

В теме автоматического создания диаграмм из таблицы (особенно Excel) нельзя обойти MS Visio Data Visualizer. Как обычно, - идея "на отлично" (идея далеко не новая), но реализация Видимо в погоне за максимальным универсализмом "выплеснулся ребенок BPM". Я ожидал увидеть что-то такое же простое, функциональное (мощное) и BPM-ориентированное как ARIS Smart Designer. Может это впечатление сложилось из-за отсутствия мастера автопостроения EPC. Кроме того, исключительная модель по подписке не позволяет популяризацию инструмента.

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

1.6 Из скрипта - схему, а из схемы - скрипт

Подход аналогичный генерации схемы по таблице (см. п. 1.5.), только используется язык, наподобие plant uml \ dot (graphviz). Структурные схемы (другие с простой нотацией) и UML строить уже можно, но вот EPC (лучше EPC2, т.е. задание языком специфических правил нотации) и другие со сложной нотацией - нет (красиво не получилось).

Применительно к graphviz: в случае, когда репозитарий объектов хранится в Excel, можно автоматически генерировать схемы, используя инструменты типа: Excel to Graphviz (sourceforge.net).

Пример простого VAD из dot:
digraph g {

rankdir=LR;

node [shape = cds];

Step1 -> Step2 -> Step3 -> Step4;

}

Посмотреть схему можно, вставив код в окно "Online Graphviz Generator":

http://fiane.mooo.com:8080/graphviz/

Кстати, редкий Online Graphviz понимает несокращенный набор параметров спецификации.

Кратко: LR - говорит, что схема строится "слева - направо" (для EPC ставим "сверху - вниз"), cds - это код объекта в виде "кораблика" (VAD). Далее через "->" указывает последовательность процессов. Можно задавать последовательно-параллельные структуры, подписи и тип стрелок, добавлять объекты "исполнители", "продукты" и другие "VAD-примочки", но при этом код становится сложным, а отсутствие нормального управления надписью (перенос, вписывание в фиксированный размер объекта и т.п.) ограничивают применимость инструмента.

Применять подход "скрипт -> схема" можно в сочетании с табличным представлением: например, скриптом VBA читаем поля заполненной пользователем таблички бизнес-процесса (см. 1.5 Из таблицы - схему ) и генерируем dot-последовательность, которую "скармливаем" локальному генератору dot (Graphviz устанавливается на компьютер) или Online Generator. Прямо в word- документе под табличкой "Процесс такой-то" размещаем "кнопочку" и пользователю даем возможность просмотра в графике того, что он ввел в табличку (как он описал в табличной форме свой процесс).

Из "BPM-связанного" особенно удобен dot для построения графов переходов. Если в модели есть docflow с документами со многими состояниями, то без схемы переходов состояний понимание многочисленных переходов осложнено, особенно когда смена состояний документа размазана по многим листам схемы. В итоге заполнив табличку и "скормив" её генератору dot мы увидим всевозможные переходы из состояний. Например, для документа "Отчет" возможны следующие состояния: Шаблон отчета - Шаблон отчета заполнен - Отчет согласован в отделе 1 - Отчет согласован в отделе 2 - Отчет подписан первой подписью - Отчет подписан второй подписью - Отчет оправлен регулятору - Отчет принят регулятором (возможны различные переходы из состояний).

В теме автоматического создания диаграмм из "текстового описания языком" нельзя не упомянуть про Object Process Diagram (OPD) \ Object Process Language (OPL). Тезисы у Object Process Methodology (OPM) вроде как BPM-ориентированные, но поверхностное знакомство с ним породило уверенность, что эта методология намного дальше от "workflow \ business process" (народа), чем те же plant uml \ dot (graphviz). OPCloud доступен тут: https://sandbox.opm.technion.ac.il/

Если немного помечтать, то настоящий BPM - инструмент должен из любого текстового "процессного" регламента (порядка действий) строить схему процесса. Когда это появится, то загрузив в такую систему многостраничные регламенты (листов под 200-300) мы обязательно увидим противоречивость и неоднозначность этих "пухлых" регламентов (несмотря на это, по ним как-то все работают же).

2. Другое

2.1 Навигация по связанным моделям (каталог моделей)

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

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

- по дереву моделей (treeview );

- по кликабельным объектам схемы (детализация - проваливаемся в низ, кнопка "выше" - переход к верхнеуровневой модели);

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

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

2.2 Разные фишки и отчеты по атрибутике

Поиск по названиям моделей, атрибутам. Задание правил отбора, например, по диапазону значений последнего редактирования модели. Выгрузка данных фильтрации \ сортировки во внешний файл (отчет), причем разного формата (например, excel для анализа, pdf для презентабельности) и т.п.

Правила работы с одноименными объектами (разрешение конфликтов), например, при наименовании нового объекта система смотрит - использовался ли одноименный объект и при выявлении такового предложит варианты, например, подтвердить или переименовать. У объекта в терминах АРИС только один Definition (Определение объекта, образ), но сколько угодно Occurrence (Отображение объекта, экземпляры на схемах).

2.3 Специфические отчеты

Отчеты могут быть разнообразны (зависит от воображения), но в первую очередь, нас будут интересовать выгрузки в распространенные формы. Универсальный генератор отчетов "на все случаи жизни" видимо проблема, но инструменты создания отчетов должны быть изначально в среде моделирования.

Для примера рассмотрим матрицу ответственности\ участия RACI. Требуется автоматическая генерация усеченной RACI-матрицы (здесь показано только для участников процесса, но часто плюс владельцы процесса) по имеющейся, например, VAD-диаграмме (value added chain diagram). Набор ключевых "мега процессов" компании показан в виде VAD и нужно по ним построить (синхронизировать) матрицу участников (RACI по одной только роли "участник процесса").

Рис. 4 Построение RACI матрицы

Алгоритм построения таблицы на VBA Visio\Excel может быть следующий:

1) Создаем в таблице Excel новую строку и в поле "Ключевые процессы" подставляем значение с активного листа visio из объекта типа "название мега процесса".

2) Далее циклом пробегаем по всем VAD-элементам схемы (листа) и через связь (объект "соединитель" для связки с объектами "исполнитель") находим связанные объекты типа "исполнитель" (участник подпроцесса).

3) Находим соответствующее название подразделения в шапке таблицы и на пересечении с процессом ставим символ участия (признак).

4) Переход к следующему листу visio.

Когда в организации десятки подразделений и около сотни "мега процессов" (их выделение достаточно субъективно), то задача синхронизации схем мега-процессов и матрицы участия подразделений в таких ключевых процессах становится достаточно трудоемкой.

2.4 Упаковка необъятной схемы процесса в печатный лист

Когда рисуют гигантскую "портянку" из "тучи элементов" на одной схеме, а потом нужно ее распечатать (А4, А3) или представить в ином интерфейсе (без скролинга такой "портянки"), то возникает ступор. Должна быть поддержка многостраничной схемы и элементов перехода между страницами (в том числе, кликабельными).

2.5 Разное

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

Авто-размещение объектов на схеме: набросал невпопад объекты на лист (главное правильно связи указать и никого не забыть) и нажал кнопку: "расположить как надо" и система сама оптимально и красиво разместила объекты на схеме (в visio функции выравнивания и распределения фигур).

Открытые стандарты хранения и экспорта \ импорта (внешний графический импорт \ экспорт как минимум в visio), как самих графических объектов модели, так и их атрибутов. К сожалению, тот же MS visio так и не научился нормально экспортировать схемы в pdf и svg (например, всплывающие подсказки).

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

Заключение

Устаревшие подходы, реализованные в "современных" платных инструментах моделирования не адекватны времени. За механизацией пришли модные: "информатизация", потом "автоматизация", а теперь и "цифровизация" (аж Digital Transformation / digital disruption и совсем "свежий" Digital process Automation), но возможности инструментов моделирования процессов за три десятка лет почти не изменились. Функциональность древних ARIS, BPwin и т.п. практически не осовременилась в современных BPMS, несмотря на то, что интерес к классическому моделированию процессов постоянно растет, т.к. проблема замены текстовых регламентов на что-то прогрессивное - в целом так и не решена (диаграммы рабочих процессов не заменили текст). Имитационное моделирование и исполняемые модели (также направления, process mining, enterprise architecture - ЕА и др.) - не в счет, рассматриваем "классическое моделирование процессов" - оно же просто "формализация процессов".

Дождаться Open Source системы, в которой было бы реализовано указанное выше, - в обозримом будущем - маловероятно, поэтому, направление улучшайзинга для себя вижу как связку: visio VBA (core, графика) + Excel (как репозитарий для хранения атрибутов моделей, а в будущем и атрибутов графических объектов, инструменты аналитики) + web (publisher & collaboration).

Динозавр - монстр АРИС до сих пор остаётся продуктом 1 в данном сегменте, несмотря на то, что он "заморозился" во времени (в части toolset) и ничего нового в этом направлении не предлагает. АРИС (1994г) и многочисленные visio-надстроенные инструменты (Business Studio, BPM-Х, Orbus iServer и десяток аналогичных) хорошо показали саму концепцию моделирования процессов, которая неизменна десятилетиями. Концептуально подходы понятны, но вот для построения моделей процессов из free взять нечего: через BPMN описать сложные процессы компании - это утопия, если нужно чтобы пользователь понимал нарисованное. Вроде бы удобный трамплин для амбициозного стартапа

Если в CASE, где S="software", еще наблюдается вялотекущая "движуха", например, UML-UML2- SysML или "всяко исполняемое" (no code\ low code), то направление CASE, где S="system" в части BPM (не EA), - фактически "замерло на месте", а робкие попытки, что методологического плана, что инструментального - прежде всего Open Source инструменты "классического" моделирования процессов - скорее отождествляются термином "застой". Правда может я чего-то не заметил.

Немного поутихнет мода на BPMN2 (фетиш в плане замещения нотации ЕРС) и мы вернёмся к "вечному", к классическим подходам BPM, т.к. другого ничего пока так и нет (задачу описания небольших процессов - не рассматриваем). Вернувшись к исходной точке описания процессов, следует смотреть в сторону чего-то интуитивно понятного "простому смертному": бухгалтеру, кассиру, секретарю и т.п., т.е. не программисту. Скорее всего, вернемся к "старине" ЕРС (т.е. фактически к "разбитому корыту") и начнем двигаться к нотации "ЕРС+" (показано на примере ЕРС2) и более гибким (см. предложенные выше фишки) и открытым (free, Open Source) инструментам моделирования. Ориентация на человека, а не машину - ключевой вектор развития. Нотации и инструменты должны быть более "человечными", схемы процессов должны создавать не "специально обученные люди", а сами участники процесса, возможно, даже не подозревая об этом и непосредственно не рисуя процессы.

В 2000-ном году мной использовались ровно такие же подходы и ровно те же инструменты моделирования (основные: ARIS toolset, MS visio), что и сейчас, но тогда была настолько интенсивная "движуха в мире ВРМ", что казалось "вот-вот и прогресс всё поменяет", но это оказалось иллюзией. "Старику ARIS" (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово "cloud"), но похоже перемены придут еще совсем не скоро и светлое будущее обычного BPM откладывается

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

Подробнее..

RPA инструменты и не только

06.06.2021 16:09:40 | Автор: admin

Однажды на работе мне поставили R&D задачу создать бота, который будет "ходить" по сайту, выбирать товары, заполнять формы и оплачивать покупки. На тот момент мы писали часть Antifraud системы, которая позволяла детектировать ботов в браузере. И с этого момента все началось...

Оглавление

  1. Коротко о RPA

  2. Open source проекты

  3. Платные сервисы

  4. Test Automation

  5. RPA vs Test Automation

  6. Парсинг сайтов и RPA

  7. BPM и RPA

  8. Безопасный RPA...

  9. Пример работы бота на Python

  10. Как детектировать бота?

  11. Выводы

Коротко о RPA

RPA (Robotic process automation) - это система, которая позволяет автоматизировать рутинные задачи (заполнение формы, перенос почты, и пр.), также можно сделать бота, который будет постоянно мониторить цены у конкурента, но это уже совсем другое... Если какое-то действие повторяется, то стоит задуматься над автоматизацией. Но не стоит пытаться автоматизировать все вокруг, хотя этого иногда очень хочется.

Более четкое определение:

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

За время создания своего бота я нашел несколько направлений RPA:

Направления в RPAНаправления в RPA

Open source проекты

Начнем сразу с open source проектов, т.к. они представляют большой интерес.
Рассмотрим инструменты относительно языков программирования:

RPA open sourceRPA open source

Конечно это не все инструменты, но по крайней мере основные, которые мне удалось найти. Я Python разработчик, поэтому рассмотрю только те инструменты, которые попробовал на практике.

Selenium & rpaframework

Объединил 2 технологии в 1 короткий обзор т.к. использовал их для одной и той же задачи: создание бота, который выбирает товары, добавляет их в корзину и оплачивает покупки. Цель: сдетектировать и заблокировать бота, используя fingerprint и треки мыши. О том как детектировать ботов будет в разделе "Безопасный RPA...".

Selenium

SeleniumWebDriver это инструмент для автоматизации действий веб-браузера. В большинстве случаев используется для тестирования Web-приложений, но этим не ограничивается. Очень часто с помощью данного инструмента создаются различные боты.
Selenium IDE - инструмент для создания сценариев быстрого воспроизведения ошибок; расширение Chrome и Firefox, которая будет выполнять простую запись и воспроизведение взаимодействий с браузером.

RPA Framework

RPA Framework - это набор библиотек и инструментов с открытым исходным кодом для RPA, предназначенный для использования с Robot Framework и с Python. Имеет синхронизацию с Selenium и Playwright, библиотека для автоматизации Chromium, Firefox и WebKit с помощью единого API. Входит в набор инструментов Robocorp для автоматизации с открытым исходным кодом.

3 in 1 (Desktop / Web / Mobile)

Robocorp

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

TagUI

TagUI - бесплатный инструмент RPA от AI Singapore, финансируемой программой по ускорению развития ИИ. Проект TagUI является открытым и бесплатным. Его легко настроить и использовать, он работает в Windows, macOS и Linux.

TagUI RPATagUI RPA

Из всех инструментов мне больше всего понравился RPA Framework, у которого есть возможность работать с Playwright, также в этом фреймворке очень удобные selector в отличие от Selenium, что позволяет гораздо быстрее писать код.

Пример на Selenium и на RPA Framework

Selenium

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysfrom webdriver_manager.chrome import ChromeDriverManagerdriver = webdriver.Chrome(executable_path=ChromeDriverManager().install())driver.get("https://www.google.com/")elem = driver.find_element_by_xpath("/html/body/div[1]/div[3]/form/div[1]/div[1]/div[1]/div/div[2]/input")elem.send_keys("Python news")elem.send_keys(Keys.RETURN)driver.close()

RPA Framework

from RPA.Browser.Playwright import Playwrightfrom Browser.utils.data_types import KeyActionlib = Playwright()lib.open_browser("https://www.google.com/")lib.fill_text(selector="input", txt="Python news")lib.keyboard_key(KeyAction.press, "Enter")lib.close_browser()

На мой взгляд у RPA Framework более удобное API.

Платные сервисы

Сказать что их много значит ничего не сказать. Платных Enterprise версий огромное количество. Но проблема в том, что многие организации не понимают истинной разницы в возможностях одного программного обеспечения RPA и другого. Возможно, они также слышали, что RPA предназначена только для очень крупных корпораций и что минимальные первоначальные инвестиции в лицензирование могут достигать 100 000 долларов в год, что теперь не всегда так.

RPA productsRPA products

Список ведущих поставщиков RPA на основе матрицы пиковых значений Everest Group для поставщиков технологий RPA 2020:

Everest группирует инструменты RPA в три основных сегмента в зависимости от их возможностей, влияния на рынок и способности успешно поставлять продукт. Everest также выделяет UiPath, Automation Anywhere, Blue Prism, Intellibot и Nividous в качестве лидеров.

UiPath vs Automation Anywhere vs Blue Prism

Компания Blue Prism, основанная в 2001 году, была пионером в секторе RPA и использовала термин Robotic Process Automation. Четыре года спустя генеральный директор UiPath Дэниел Дайнс технически основал UiPath как компанию под названием DeskOver. Однако только в 2015 году она действительно родилась и была переименована в RPA-компанию.

В таблице ниже представлен краткий снимок каждого из трех инструментов RPA с точки зрения доходов, размера, сотрудников и оценки:

VSVS

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

Спустя годы на рынок вышли более доступные конкуренты, такие как UiPath и Automation Anywhere с такими же (или лучшими) возможностями, повышенной гибкостью и простотой внедрения. В результате RPA была демократизирована для компаний любого размера во многих отраслях, включая малые и средние организации.

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

  1. UiPath - 4.6 / 5 звезд с 4722 отзывами

  2. Automation Anywhere оценивает 4,5 / 5 звезд с 4310 отзывами

  3. Blue Prism 4,4 / 5 звезд по 158 отзывам

Что делает UiPath самой популярной платформой RPA?

UiPath превратился в единственную платформу RPA на рынке, созданную для поддержки полного жизненного цикла автоматизации. Портфель продуктов компании продолжает оставаться в авангарде инноваций, постоянно расширяя свои традиционные возможности RPA за счет включения таких инструментов, как интеллектуальный анализ процессов, встроенная аналитика, улучшенные компоненты AI Fabric, RPA на основе SaaS и автоматизация тестирования.

UiPath также считается одним из самых быстрых решений RPA в отрасли - часто в 3-4 раза быстрее, чем другие продукты RPA.

Другие ключевые сильные стороны UiPath:

  1. Long Running Workflows

  2. Machine Learning and Predictive Analytics

  3. Seamless Interconnectivity

  4. Process Document Understanding

  5. Citizen Development

  6. Customer Satisfaction

  7. Flexible Licensing Model and Low Cost of Entry

Оригинал статьи со сравнением: https://www.auxis.com/blog/top-rpa-tools

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

G2 GridG2 GridМини обзор популярных и не очень RPA

UiPath

Самое замечательное в UiPath - это простота использования.

UiPath прост в установке и имеет возможности разработки на основе пользовательского интерфейса. Подробное онлайн-руководство поможет быстро освоиться. Согласно Quadrant Review компании Gartner, UiPath имеет первоклассную команду поддержки клиентов, и в целом UiPath идеально подходит для компаний, стремящихся к быстрому внедрению RPA.

GUI UiPathGUI UiPath

Automation Anywhere

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

GUI Automation Anywhere GUI Automation Anywhere

Blue Prism

Blue Prism, старейший инструмент в индустрии RPA, в последние годы неуклонно растет.

Blue Prism специализируется на сквозной RPA для компаний из списка Fortune. Blue Prism также предлагает высококлассных роботов. Роботы не только очень сложные, но и обладают глубокими возможностями создания сценариев для настройки расширенных сетей RPA. Имеет отличные возможности отладки и потрясающую масштабируемость.

GUI Blue PrismGUI Blue Prism

Microsoft Power Automate

Microsoft Power Automate предоставляет простое и эффективное решение RPA. Самым значительным преимуществом Microsoft Power Automate является простота настройки. Данные из экосистемы Microsoft легко доступны. Легко управлять оркестрацией робота.

WinActor

WinActor - это инструмент RPA, разработанный NTT Group. Он широко используется в таких отраслях, как разработка программного обеспечения и финансы.

GUI WinActorGUI WinActor

Test Automation

Автоматизация тестирования помогает разработчикам и тестировщикам экономить время и увеличивать охват тестированием за счет автоматизации повторяющихся тестовых случаев.

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

Automation Testing Tools

Инструментов ни сколько не меньше чем у RPA.

Вот небольшой список:

Инструмент

Open source

Платная

Selenium

+

Appium

+

SoapUI

+

TestProject

+

Cerberus Testing

+

Katalon Studio

+

IBM Rational Functional Tester

+

Telerik Test Studio

+

TestComplete

+

Ranorex

+

Kobiton

+

Subject7

+

HPE Unified Functional Testing (UFT)

+

Сводная картинка по некоторым инструментам:

QA Automation toolsQA Automation tools

RPA vs Test Automation

Коротко: это практически одно и то же.

RPA и Test Automation можно рассматривать как одно и то же. Компании используют их для автоматизации задач, экономии затрат и освобождения времени сотрудников для других дел.

Сходства:

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

Различия:

  • сценарии тестирования, созданные для автоматизации тестирования, зависят от тестируемой системы (SUT).

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

  • RPA инструменты не зависят от программного обеспечения, в котором запущен процесс.

Парсинг сайтов и RPA

Цели у компаний, которые занимаются парсингом сайтов, разные, но тем не менее такие инструменты есть и некоторые из них являются полноценным RPA инструментом (например, Octoparse).

Process Bots VS Search Bots

Process Bots VS Search BotsProcess Bots VS Search Bots

Сильные стороны RPA:

  • Low Code UX

  • Управление входами и выходами через UX

  • Работа с авторизацией для бизнес-приложений

  • Передача данных в бизнес-процессе

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

Сильные стороны поискового робота:

  • Масштабирование для одновременной обработки десятков тысяч страниц

  • Отсутствие конфигурации и автоматическая обработка для множества типов веб-страниц

  • Поисковые роботы автоматически адаптируются при изменении страниц

  • Богатая индивидуальная конфигурация

  • Всестороннее чтение HTML страницы (Имя автора; UPC продукта)

  • Автоматическое извлечение настроения из текста

  • Извлечение связанных сущностей из текста (организации, местоположения, люди и т.д.)

Но какие боты лучше?

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

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

Сегодня все наши приложения находятся в облаке. А конвейеры данных сильно зависят от неструктурированных данных из интернета. С появлением RPA вывод используемых нами приложений стал значительно более динамичным. Ключевое различие между поисковыми и технологическими роботами заключается в том, что поисковые боты созданы для адаптации к постоянно меняющимся веб-страницам, а RPA прерывается, когда сайты меняются, а точнее когда меняется дом-дерево в html разметке.

Теперь возьмем поискового бота с поддержкой AI. Вводим один сайт например, в Crawlbot Diffbot, ждем несколько минут, и тысячи страниц распознаются и анализируются как страницы продуктов. Загружаем данные в формате JSON или CSV, либо загружаем приложение или панель инструментов с выбранными результатами. Основная технология, лежащая в основе этого варианта использования, возможно будет чем боты RPA. Поисковые боты сами ускоряют чтение и классификацию Интернета!

Инструменты для парсинга

Scrape.do

Scrape.do - это простой в использовании инструмент веб-парсера, предоставляющий масштабируемый, быстрый API-интерфейс прокси-парсера для конечной точки. По рентабельности и функциональности Scrape.do занимает первое место в списке. Scrape.do - один из самых недорогих инструментов для парсинга веб-страниц.

Scrapingdog

Scrapingdog - это инструмент для очистки веб-страниц, который упрощает работу с прокси-серверами, браузерами, а также с CAPTCHA. Этот инструмент предоставляет HTML-данные любой веб-страницы за один вызов API. Одна из лучших особенностей Scraping dog - это наличие API LinkedIn.

ParseHub

ParseHub - это бесплатный инструмент веб-скребка, разработанный для извлечения онлайн-данных. Этот инструмент поставляется в виде загружаемого настольного приложения. Он предоставляет больше функций, чем большинство других скребков, например, вы можете очищать и загружать изображения / файлы, загружать файлы CSV и JSON. Вот список других его функций.

Diffbot

Diffbot - это еще один инструмент для парсинга веб-страниц, который предоставляет данные, извлеченные с веб-страниц. Этот сборщик данных - один из лучших сборщиков контента. Он позволяет автоматически идентифицировать страницы с помощью функции Analyze API и извлекать продукты, статьи, обсуждения, видео или изображения.

Octoparse

Octoparse выделяется как простой в использовании инструмент для парсинга веб-страниц без кода. Он предоставляет облачные сервисы для хранения извлеченных данных и ротации IP-адресов для предотвращения блокировки IP-адресов. Вы можете запланировать парсинг в любое определенное время. Кроме того, он предлагает функцию бесконечной прокрутки. Результаты загрузки могут быть в форматах CSV, Excel или API.

ScrapingBee

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

Luminati

Luminati - это веб-парсер с открытым исходным кодом для извлечения данных. Это сборщик данных, обеспечивающий автоматизированный и настраиваемый поток данных.

Scraper API

Scraper API - это прокси API для парсинга веб-страниц. Этот инструмент помогает управлять прокси-серверами, браузерами и CAPTCHA, поэтому вы можете получить HTML-код с любой веб-страницы, выполнив вызов API.

Scrapy

Еще один в нашем списке лучших инструментов для парсинга - Scrapy. Scrapy - это платформа для совместной работы с открытым исходным кодом, предназначенная для извлечения данных с веб-сайтов. Это библиотека для парсинга веб-страниц для разработчиков Python.

Import.io

Инструмент для парсинга веб-сайтов с оперативным управлением всеми веб-данными, обеспечивая точность, полноту и надежность. Import.io предлагает конструктор для формирования собственных наборов данных путем импорта данных с определенной веб-страницы и последующего экспорта извлеченных данных в CSV. Кроме того, он позволяет создавать более 1000 API-интерфейсов в соответствии с вашими требованиями. Есть приложение для Mac OS X, Linus и Windows.

BPM и RPA

Основная функция BPM-системы это организация правильного взаимодействия участников бизнес-процесса.

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

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

CAMUNDACAMUNDAСервисы BPM с интеграцией RPA

Camunda

Платформа Camunda обеспечивает подход на основе жизненного цикла к проектированию, организации, анализу и мониторингу ваших RPA-ботов в том виде, в каком они работают сегодня.Кроме того, Camunda предлагает архитектурный путь вперед, который в будущем заменит ботов RPA на API / микросервисы.

Основные преимущества:

  • Проектирование сквозного процесса

  • Согласование сценариев RPA

  • Оперативноенаблюдение задействиями ботов RPA

  • Аналитика RPA

ELMA

В BPM-системе ELMA робот участвует впроцессе наравне собычными пользователями. В гибких бизнес-процессах ELMA роботы могут постепенно заменять пользователей системы задача зазадачей. Освободившиеся отскучной работы сотрудники смогут перераспределить это время исвой опыт наболее интересные творческие иполезные длякомпании задачи.

Выгоды длябизнеса отиспользования RPA + BPM:

  • Снижение издержек нарутинные операции.

  • Масштабирование бизнеса безрасширения штата.

  • Освобождение времени сотрудников наболее интеллектуальный труд.

  • Лучший Customer Experience засчет качества искорости сервиса.

ProcessMaker

ProcessMaker - это простое в использовании программное решение для управления бизнес-процессами (BPM) и рабочими процессами. Сочетает корпоративную разработку с низким уровнем кода и ведущую в отрасли интеллектуальную автоматизацию рабочих процессов.

Безопасный RPA...

Взлом RPA

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

Риски безопасности, на которые стоит обратить внимание:

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

  • Операционные риски или риски исполнения: развертывание правильной операционной модели необходимо для уменьшения функциональных проблем или проблем с производительностью.

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

  • Раскрытие конфиденциальных данных:malware проникает в систему и создает сценарий при котором данные пользователей утекают в сеть.

  • Отказ в обслуживании: создания необходимых условия для остановки работы бота.

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

Проблема безопасности данных может быть разбита на два тесно взаимосвязанных момента:

  • Безопасность данных

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

RPA для пентеста

Посмотрим с позиции пентестера. Мы можем с помощью RPA создать скрипт, который будет циклически проверять страницы на уязвимости. Рассуждая дальше, мы можем подготовить целую армию роботов, чтобы симулировать атаки на различные API и сайты. Понятно, что не все можно автоматизировать, но основные сценарии, которые повторяются для каждого сайта, можно попробовать.

Продолжение следует...

В следующей статье мы создадим своего бота, рассмотрим какие есть алгоритмы детектирования ботов, которые написаны на Selenium и с помощью RPA. Создадим свой алгоритм, подведем итоги.

Подробнее..

Перевод Как приручить событийно-ориентированные микросервисы

10.10.2020 12:11:24 | Автор: admin
Как приручить событийно-ориентированные микросервисы

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

TL;DR: А вот и нет! Вы столкнетесь с препятствиями связанными с пониманием и управлением потоком событий.

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



Хореография микросервисов


Предположим, что следующие сервисы и события формируют вашу схореографированную систему:


Как приручить событийно-ориентированные микросервисы

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


  • Как менять поток событий?
  • Как избежать потерю наглядности потока? Как поддержать его понятность?
  • Как управлять SLA и стойкостью общего потока? Как определить если что-то пошло не так? Как запустить повтор операции? Как улучшить систему?
  • Как избежать жесткой связанности (например, необходимость знания о регистрации клиента при проверке на кредитоспособность)?

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



Изменение потока событий


Предположим, что вам необходимо добавить проверку на судимости. Основная идея схореогрефированных систем часто состоит в возможности добавления микросервисов без изменения чего-либо еще. Вы легко можете добавить сервис для проверки судимостей, который будет реагировать на определенные события, но для этого придется как минимум изменить сервис для работы с пользователями.


Как приручить событийно-ориентированные микросервисы

Таким образом ваша система оказывается не настолько свободно связанной как вы бы могли ожидать.


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


Как приручить событийно-ориентированные микросервисы

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


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



Потеря наглядности?


Следующее препятствие состоит в понимании того, что происходит в вашей архитектуре. Событийно-ориентированные системы имеют непредсказуемое поведение, опыт работы с которым можно получить только на практике, вы не сможете понять данный аспект просто проводя статический анализ кода. Стефан Тилков описал это как: Что чёрт возьми сейчас произошло, Джош Вульф писал: Система, которую мы заменяем, использует пиринговую хореографию, которая требует знаний в различных кодовых базах для её понимания. И наверное лучшее описание данной проблемы пришло от Мартина Флауэра в Что вы имеете ввиду под Событийно ориентированными?:


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

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


  1. Распределенное отслеживание (например Zipkin или Jaeger)
  2. Озёра данных или инструменты для аналитики (например Elastic)
  3. Процессная аналитика (например ProM)
  4. Слежка за процессами с использованием автоматизации рабочего потока (например Camunda)

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



Слежка за процессами с использованием автоматизации рабочего потока


Вы можете добавить ваш собственный компонент для чтения всех событий и поддержания определенного поведения.


Как приручить событийно-ориентированные микросервисы

Поведение может означать изменение состояния отдельных сервисов.


Как приручить событийно-ориентированные микросервисы

На этом моменте скорее всего будет иметь смысл отслеживать весь поток событий.


Как приручить событийно-ориентированные микросервисы

Это уже позволяет вам использовать инструменты из механизма рабочего потока для мониторинга SLA, как на примере:


Как приручить событийно-ориентированные микросервисы

Но другим отличным преимуществом слежки за процессами является возможность использования такого поведения как таймеры:


Как приручить событийно-ориентированные микросервисы

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


Если мы обратим внимание на слежку за общим потоком, мы сможем понять контекст и сможем получить лучшую перспективу при повторной операции:


Как приручить событийно-ориентированные микросервисы

Вы можете даже добавить таймер для прерывания регистрации, если она занимает слишком много времени:


Как приручить событийно-ориентированные микросервисы

В докладе на тему слежки за процессами на Kafka Summit San Francisco 2018 (см. Слежка и оркестрация микросервисов с Kafka и Zeebe), я продемонстрировал конкретный пример подобного розничного процесса.


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


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



Как управлять SLA и стойкостью общего потока


Но в первую очередь давайте взглянем на управление этого потока. Кто им обладает и куда он выгружен?


Люди думают о механизмах рабочих потоков как о централизованных и тяжелых инструментах, но это не совсем так. В микросервисных архитектурах, механизмы это библиотеки используемые внутри одиночного микросервиса. (Я говорил об этом в рамках Сложные потоки событий в распределенных системах на QCon London; см. также Избегая BPM монолит).


Как приручить событийно-ориентированные микросервисы

Я дал пример (Java и Spring Boot) в моем докладе 3 частых ловушки в интеграции микросервисов, где я использую Camunda, легкий и простой в использовании, для повторов операций с сохранением состояния (исходный код на GitHub). Нет никакой необходимости в централизации или оркестрации потоков, являющихся посторонними для вселенной микросервисов.


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


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


Как приручить событийно-ориентированные микросервисы

Связывание по событиям и операциям


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


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


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


Как приручить событийно-ориентированные микросервисы

Оркестрация внутри микросервисов


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


Как приручить событийно-ориентированные микросервисы

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



Сравнение уровней связности


Давайте вернемся к изменению, когда мы внедряли дополнительную проверку на судимость с разными подходами:


Как приручить событийно-ориентированные микросервисы

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

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



Итог


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



Этот пост изначально был опубликован на InfoWorld. Также недавно я выступал с докладом по этой теме на QCon NYC (Презентация).

Подробнее..

Recovery mode Отличительные особенности и основные этапы внедрения процессного управления

12.03.2021 14:20:14 | Автор: admin

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

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

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

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

Ключевой особенностью процессного управления является совершенствование основных видов деятельности, повышение качества выходов и квалификации сотрудников. Циклы непрерывного совершенствования, изложенные Эдвардсом Демингом (PDCA) или к концепции six sigma (DMAIC) должны быть реализованы в компании, которая внедряет процессное управления.

Как внедрять процессное управление у себя в компании? Для того, чтобы внедрить процессное управления необходимо ПОСЛЕДОВАТЕЛЬНО пройти четыре основных этапа: бессистемный, системный, измеряемый и совершенствуемый. Давайте рассмотрим характерискики каждого из этапов.

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

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

Классификация бизнес-процессов:

  • Процессы управления.

  • Основные процессы.

  • Обеспечивающие (вспомогательные) процессы.

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

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

Обеспечивающие процессы это процессы, которые осуществляют поддержку эффективной работоспособности основных и управляющих бизнес-процессов. В отличие от основных процессов, обеспечивающие не представляют ценности для конечного потребителя, а их клиентами являются внутренние заказчики. К обеспечивающим процессам можно отнести: бухгалтерский и налоговый учет, административно-хозяйственное обеспечение, маркетинг, юридическую поддержку, HR, IT и прочее.

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

  • Минимально возможное количество.

  • Измеримость.

  • Контролируемость.

  • Улучшаемость.

На совершенствуемом этапе, когда вы знаете как работает ваша система процессов компании, когда вы провели измерения и выявили уязвимые, не устраивающие вас участки процессов, пора приступать к мероприятиям по оптимизации бизнес-процессов. Для этого необходимо четко сформулировать видение развития компании (стратегия развития, система сбалансированных показателей и т.д.) и донести ее до сотрудников. Также основными инструментами по оптимизации бизнес-процессов выступают: цикл Деминга (цикл PDCA Plan-Do-Check-Act) или методология DMAIC (Define-Measure-Analyze-Improve-Control). Цикл PDCA представляет собой алгоритм последовательности действий, необходимых для повышения качества бизнес-процесса: планирование, реализация, контроль и реагирование (корректировка). Методология DMAIC основана на цикле Деминга и представляет собой алгоритм с более расширенной последовательностью действий, нежели PDCA: определение, измерение, анализ, совершенствование и контроль.

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

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

  • Стандартизация работы процесса (сокращение ошибок в работе сотрудников).

  • Контроль выполнения эффективности операций.

  • Обучение сотрудников.

  • Анализ и совершенствование бизнес-процессов.

  • Внутренний аудит компании.

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

Подробнее..

Разработка и исполнение бизнес-процесса Разработка программного обеспечения в Bizagi BPM

07.11.2020 18:20:02 | Автор: admin

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

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

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

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

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

В качестве средства BPM была выбрана Bizagi. Она удовлетворяет нашим условиям выбора. Эта система является бесплатная, прекрасно интегрируется с различными веб сервисами, пользователи прекрасно интегрируются с Active Directory, система использует операционную систему семейства Windows, SQL базу данных и IIS веб сервис. Система проста для разработки в ней бизнес-процессов и удобна в использовании. Нотация для моделирования будет использоваться BPMN 2.0

В среде моделирования Modeler будет произведено моделирование бизнес-процессов. В среде проектирования Suit для этих процессов будет спроектирована база данных, спроектированы графические формы, будут заданы бизнес правила, заданы группа пользователей. В Engine будут произведены пуско-наладочные работы.

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

Бизнес-процесс Разработка программного обеспечения с техническим заданием будет автоматизировать бизнес-процесс начиная от момента подачи заявки клиента и заканчивая приемкой.

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

После разработки бизнес-процесса необходимо разработать модель данных.

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

После разработка модели данных необходимо разработать визуальные формы.

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

Условия:

RazrabotkaPO.idKontsepsiya.Utverzhdenie is equal to true

RazrabotkaPO.idKontsepsiya.Utverzhdenie is equal to false

RazrabotkaPO.Statusrazrabotki is equal to false; DorabotkaPOTZ.Statusrazrabotki is equal to true;

RazrabotkaPO.Statustestirovaniya is equal to true;

RazrabotkaPO.Statustestirovaniya is equal to false;

После определения бизнес правил определяем исполнителей задач.

У нас будут существовать следующие роли: chief manager (руководитель проекта), devOps (системный администратор), manager (менеджер), programmer (программист), stakeholder (внешнее лицо), tester (тестировщик), admon viewer (администратор).

Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей.

Определяем условия для всех функций:

Or Role==Stakeholder or Role == Admon Viewer;

Or Role==Manager or Role == Admon Viewer;

Or Role==Chief manager or Role == Admon Viewer;

Or Role==Programmer or Role == Admon Viewer;

Or Role==DevOps or Role == Admon Viewer;

Or Role==Analyst or Role == Admon Viewer;

Or Role==Tester or Role == Admon Viewer;

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

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

Разработанная модель данных бизнес-процесса Технологическое требование представлена ниже

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

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

Условия:

Tekhnologicheskoetrebova.ready is equal to true;

Tekhnologicheskoetrebova.ready is equal to false;

Tekhnologicheskoetrebova.status_analyst is equal to true;

Tekhnologicheskoetrebova. status_analyst is equal to false;

На этапе определения Activity Action (Events) на кнопку Сохранить в графическую форму процесса Выполнение добавляем следующие выражения:

Currenttask в поле номер заявки будет подставляться системный номер заявки;

CurrentData в поле дата запроса будет добавлять системная дата;

Выражение:

<TekhnologicheskoeTrebova.Nubertrebovanie> = Me.Case.CaseNumber;:

<TekhnologicheskoeTrebova.Requestdate> = DateTime.Now; После определения бизнес правил определяем исполнителей задач.

У нас будут существовать следующие роли: programmer (программист), stakeholder (внешнее лицо), devops (системный администратор), admon viewer (администратор), analyst (аналитик).

Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей. Определяем условия для всех функций

Or Role==Stakeholder or Role == Admon Viewer;

Or Role==Manager or Role == Admon Viewer;

Or Role==Chief manager or Role == Admon Viewer;

Or Role==Programmer or Role == Admon Viewer;

Or Role==DevOps or Role == Admon Viewer;

Or Role==Analyst or Role == Admon Viewer;

Or Role==Tester or Role == Admon Viewer;

Для запуска бизнес-процессов в корпоративной сети необходимо развернуть серверную операционную систему Windows, настроить DNS сервер, установить IIS сервер, развернуть базу данных.

В качестве серверной операционной системы была выбрана Windows Server 2012 R2. В качестве сервера базы данных был выбран SQL Server.

После установки СУБД устанавливаем оснастку IIS и проверяем работоспособность веб сервера.

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

Проверка работоспособности бизнес-процессов

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru