Статьи

Поиск последовательных шаблонов (Sequential Pattern Mining) и построение ассоциативных правил в проекте Apache Spark

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

Для поиска подобных ассоциативных правил необходимо сначала находить последовательные шаблоны (Sequential Pattern Mining) – цепочки купленных товаров или запрошенных файлов, и затем исследуя их строить устойчивые ассоциации.

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

Одним из наиболее эффективных алгоритмов поиска ассоциативных правил является алгоритм FP-growth (https://basegroup.ru/community/articles/fpg). Его название можно перевести как «выращивание популярных (часто встречающихся) предметных наборов». Этот алгоритм позволяет не только избежать затратной процедуры генерации кандидатов, но и уменьшить необходимое число проходов по базе данных предметных наборов до двух.

В основе метода лежит предобработка базы транзакций, путем преобразования ее в компактную древовидную структуру, называемую Frequent-Pattern Tree – дерево популярных предметных наборов (откуда и название алгоритма). В дальнейшем для краткости будем называть эту структуру FP-дерево. К основным преимуществам данного метода относятся:

  1. Сжатие БД транзакций в компактную структуру, что обеспечивает очень эффективное и полное извлечение частых предметных наборов;
  2. При построении FP-дерева используется технология разделения и захвата (divide & conquer), которая позволяет выполнить декомпозицию одной сложной задачи на множество более простых;
  3. Позволяет избежать затратной процедуры генерации кандидатов, характерной, например, для алгоритма «a priori».

Идея алгоритма PrefixSpan

(http://ijaiem.org/Volume2Issue2/IJAIEM-2013-02-20-024.pdf)

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

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

Работа с алгоритмами FPgrowth и PrefixSpan

Действия:

А) Скачиваем предоставленные тестовые файлы с указанного диска.

Немного о выборках:

Имеем шесть выборок с разными параметрами (см. рис. 4.2):

— среднее число транзакций (T) для неоднородных баз или точное число транзакций для однородных баз (С) в клиентских последовательностях,

— среднее число предметов в транзакциях (I),

— количество клиентских последовательностей (D).

Копируем файлы с выборками в hadoop. Делаем так же, как уже делали в лабораторной работе № 2 (пункт 2.2.-> Создание таблиц):

hadoop fs -copyFromLocal /home/cloudera/Desktop/название_документа_с_выборкой /user/cloudera/

получаем:

Рис. 4.3. Результат копирования файлов с выборками.

Б) Тестируем алгоритм FP-growth

Запускаем Apache Spark командой spark–shell (в разных версиях Spark разные команды, ещё одна из них: spark2–shell) в терминале системы и ждём пока появится строка scala> (в нижней части экрана на рис. 4.4)

Рис. 4.4. Результат запуска Spark.

Вводим в терминал системы код заранее написанной программы:

import org.apache.spark.mllib.fpm.FPGrowth

import org.apache.spark.rdd.RDD //импортируем библиотеки

val data =

sc.textFile(«/user/cloudera/название_документа_с_выборкой «)//загружаем датасеты

val transactions: RDD[Array[String]] = data.map(s => s.trim.split(‘ ‘))/ /преобразовываем датасеты в нужный формат

val fpg = new FPGrowth()//заводим переменную, отвечающую за работу алгоритма

  .setMinSupport(0.2) //Изменяемое значение параметра MinSupp

  .setNumPartitions(10) FP-growth где указываем MinSupp и NumPartitions

val model = fpg.run(transactions)//запускаем алгоритм FP-growh с указанными выше параметрами

model.freqItemsets.collect().foreach { itemset =>

  println(itemset.items.mkString(«[«, «,», «]») + «, » + itemset.freq)

}

//Печатаем найденные последовательности

val minConfidence = 0.8 //задаём MinConf

model.generateAssociationRules(minConfidence).collect().foreach { rule =>

  println(

    rule.antecedent.mkString(«[«, «,», «]»)

      + » => » + rule.consequent .mkString(«[«, «,», «]»)

      + «, » + rule.confidence)

}//Для полученных последовательностей ищем ассоциативные правила и выводим их.

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

:load /home/cloudera/Desktop/название_файла_с_программой

Код этой программы без комментариев, чтобы просто “копипастнуть”.

import org.apache.spark.mllib.fpm.FPGrowth

import org.apache.spark.rdd.RDD

val data = sc.textFile(«/user/cloudera/c10d1k «)

val transactions: RDD[Array[String]] = data.map(s => s.trim.split(‘ ‘))

val fpg = new FPGrowth().setMinSupport(0.05)

val model = fpg.run(transactions)

model.freqItemsets.collect().foreach { itemset =>

  println(itemset.items.mkString(«[«, «,», «]») + «, » + itemset.freq)

}

val minConfidence = 0.5

model.generateAssociationRules(minConfidence).collect().foreach { rule =>

  println(

    rule.antecedent.mkString(«[«, «,», «]»)

      + » => » + rule.consequent .mkString(«[«, «,», «]»)

      + «, » + rule.confidence)

}

В результате выполнения получаем (рис. 4.5).

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

val t0 = System.currentTimeMillis()
и получаем время, которое было на момент запуска программы. Далее в конце программы (до вывода результатов) выполняем команду:  println(System.currentTimeMillis() – t0).  Результаты заносим в заранее созданную для этого Excel–таблицу (рис. 4.6).
 Рис. 4.5. Результат запуска программы с алгоритмом FPGrowth.


Рис. 4.6. Время работы алгоритма FPGrowth. 
Если еще осталось время, можно, изменяя минимальные поддержку (MinSupp) и достоверность (MinConf), получить результаты для разных случаев.
 

В) Тестируем алгоритм PrefixSpan

Вводим код программы в терминал системы:

import org.apache.spark.mllib.fpm.PrefixSpan //импортируем библиотеки
 
val sequences = sc.parallelize(Seq(
  Array(Array(1, 2), Array(3)),
  Array(Array(1), Array(3, 2), Array(1, 2)),
  Array(Array(1, 2), Array(5)),
  Array(Array(6))
), 2).cache() //задаём последовательности
val prefixSpan = new PrefixSpan()
  .setMinSupport(0.5) //Изменяемое значение параметра MinSupp
  .setMaxPatternLength(5) 

//заводим переменную, отвечающую за работу алгоритма PrefixSpan, где указываем MinSupp и MaxPatternLength

val model = prefixSpan.run(sequences) )//запускаем алгоритм PrefixSpan с указанными выше параметрами

model.freqSequences.collect().foreach { freqSequence =>
  println(
    freqSequence.sequence.map(_.mkString("[", ", ", "]")).mkString("[", ", ", "]") +
      ", " + freqSequence.freq)

}//Печатаем найденные последовательности

Выборки приходится вставлять непосредственно в код (3-я строчка) после команды:   val sequences = sc.parallelize (Seq(.

Чтобы не работать руками, пишем на любом языке программирования парсер для стандартных форматов. Если есть трудности с написанием, то пишем этот парсер в любом текстовом редакторе, например, NotePad++.

Можно распарсить выборку и самостоятельно Формат входных данных для алгоритма  JavaRDD<List<List<Integer>>>

Пример. Есть выборка:

1 2 3

4 5 6

7 8 9

Открываем файл с выборкой в Notepad++. Открываем замену символов. Заменяем пробелы на запятые. Заменяем начало строки на — Array(Array(. Конец строки заменяем на — )), Копируем полученное в код программы и запускаем.

Результаты так же заносим в excel-таблицу и файл.

Здесь можно также изменять минимальную поддержку (MinSupp).

4.3. Сравнение алгоритмов

Сравниваем время работы алгоритмов на одних и тех же выборках. Находим отличия.

Статья «Business Studio 5. What`s new?»

12 октября 2020 — официальный старт продаж новой версии системы бизнес-моделирования Business Studio 5. Среди ключевых нововведений – возможность управления жизненным циклом модели и поддержка мультиязычности. Об этих и других нововведениях читайте в статье «Business Studio 5. What’s New?»

Для более подробного ознакомления с возможностями системы Business Studio 5 мы приглашаем Вас на официальную презентацию новой версии, которая пройдет 8 и 9 октября 2020 в формате онлайн.

НОТАЦИИ ДЛЯ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

В настоящий момент существует несколько конкурирующих стандартов для моделирования бизнес-процессов. Нотация управления бизнес-процессами (BPMN), нотация исполняемый язык бизнес-процессов (BPEL), расширенная цепочка событийных событий (eEPC), методология функционального моделирования (IDF0, IDF3). У каждой из данной нотации есть свои преимущества для тех или иных целей, и преимущества использования конкретного программного продукта для описания бизнес-процессов в соответствующих нотациях.

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

  • использование контекстной диаграммы;
  • поддержка декомпозиции;
  • доминирование;
  • выделение 4 типов стрелок (вход, выход, механизм, управление).

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

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

Для декомпозиции верхнеуровневых бизнес-процессов используется нотация IDF3.

Нотация IDEF3 — важнейшая после IDEF0 и предназначена для описания потоков работ (Work Flow Modeling). В течение длительного
времени IDEF3 широко использовалась для создания моделей бизнес-процессов организации на нижнем уровне — при описании работ, выполняемых в подразделениях и на рабочих местах. Данная нотация являлась прототипом для создания нотации Aris eEPC.

Моделирование в нотациях IDF0, IDF3 приобрело популярность в программном продукте Erwin Business Process. Сейчас в данных нотациях можно моделировать в программном продукте Business studio, который создан в России. Программные продукты Erwin и Business studio являются дорогостоящими платными решениями (с 30 дневным бесплатным режимом). Нотация не служит для исполнения бизнес-процессов, а служит только для их анализа.

Нотация ARIS eEPC– расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

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

Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, графики Ганта в системе MS Project.

Данная нотация используется в программном продукте – Aris Express (бесплатная версия), Aris Toolset (платная версия), Business studio (платная версия).  Нотация не служит для исполнения бизнес-процессов, служит только для анализа бизнес-процессов.

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

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

Нотация используется как в бесплатных решениях (Bonita BPM, Bizagi и др), так и в платных решениях (Pega BPM, IBM BPM, Elma BPM и др.). Нотация может служить для моделирование исполняемых бизнес-процессов и не исполняемых.

BPEL (англ. Business Process Execution Language) — язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций.

В общем виде конфигурация BPEL-проекта выглядит следующим образом:

  • BPEL-визуальный редактор;
  • Сервер управления бизнес-процессами.

Основные файлы BPEL-проекта:

  • .bpel — логический синтез и координация веб-служб. Фактически алгоритм исполнения бизнес-процесса. (его графическое представление напоминает блок-схему и диаграмму потоков данных в одном лице).
  • .wsdl — описание интерфейсов для обмена сообщениями. «Как достичь веб-службы» (WSDL).
  • .xsd — описание структур данных проекта (XML Schema).

Пример описания бизнес-процесса представлен ниже:

<process name=»mathProcess» targetNamespace=»http://example.com/ws-bp/math»

 xmlns=»http://docs.oasis-open.org/wsbpel/2.0/process/executable»

 xmlns:math=»http://manufacturing.org/wsdl/math»>

    <partnerLinks>

        <partnerLink name=»Math» partnerLinkType=»math:exampleMath» myRole=»mathService» />

    </partnerLinks>

    <variables>

        <variable name=»numIn»   messageType=»math:unsignedInt»/>

        <variable name=»numOut»  messageType=»math:unsignedInt»/>

        <variable name=»num»     type=»xsd:unsignedInt»/>

    </variables>

    <sequence>

        <receive partnerLink=»Math» portType=»math:mathPort» operation=»secondDegree» variable=»numIn» createInstance=»yes»/>

        <assign name=»LoopCounterIncrement»>

          <copy>

             <from>$numIn.request</from>

             <to variable=»num»/>

          </copy>

          <copy>

             <from>$num * $num</from>

             <to variable=»numOut» part=»response»/>

          </copy>

        </assign>

        <reply operation=»secondDegree» partnerLink=»Math» portType=»math:mathPort» variable=»numOut»/>

    </sequence>

 </process>

Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.
Стандартные операции: 
  • Action: выполняет или вызывает выполнение операции, включающей обмен входящими и исходящими сообщениями.
  • Assign: присваивает новое значение показателю.
  • Call: запускает процесс и ждет его завершения.
  • Compensate: инициирует компенсацию для указанных процессов.
  • Delay: выражает промежуток времени.
  • Empty: ничего не делает.
  • Fault: выдает сообщение об ошибке в текущем контексте.
  • Raise: активизирует сигнал.
  • Spawn: запускает процесс без ожидания его завершения.
  • Synch: синхронизирует по сигналу.

В основном, язык BPEL используется в программном продукте Bizagi, Pega BPM, IBM BPM, JBPM. Нотация исключительно служит для исполнения бизнес-процессов.

После проведенного анализа нотаций для моделирования бизнес-процессов можно выделить следующие особенности:

  1. Программные продукты, где используются рассмотренные нотации, кроме BPMN, являются платными. Стоимость может доходить до нескольких тысяч долларов.
  2. Нотация IDF0 используется для описания верхнеуровневых бизнес-процессов, нотация IDF3 и eEPC служит для описания потока работы. Нотации используются в Erwin Business modeler и Aris. Данные нотации идеально читаются и подходят для анализа системы, бизнес-процессов.
  3. Нотация BPMN используется в нескольких профессиональных BPM системах и служит для моделирования исполняемых и не исполняемых бизнес-процессов. Чтение нотации для обычных работников затруднительно.
  4. Нотация BPEL используется программистами, чтение обычными пользователями затруднительно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Условия:

DorabotkaPOTZ.idKontsepsiya.Utverzhdenie is equal to true

DorabotkaPOTZ.idKontsepsiya.Utverzhdenie is equal to false

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

DorabotkaPOTZ.Statustestirovaniya is equal to true;

DorabotkaPOTZ.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.

SQL Server является одной из наиболее популярных систем управления базами данных (СУБД) в мире. Данная СУБД подходит для самых различных проектов: от небольших приложений до больших высоконагруженных проектов. SQL Server характеризуется такими особенностями как: 1) производительность. SQL Server работает очень быстро; 2) надежность и безопасность. SQL Server предоставляет шифрование данных; 3) простота. С данной СУБД относительно легко работать и вести администрирование.

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

Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP (т.е все основные протоколы). По данным компании Netcraft на июнь 2015 года, почти 22 млн сайтов обслуживаются веб-сервером IIS, что составляет 12,32 % от общего числа веб-сайтов, остальные веб-серверы используют Apache, Nginx. Производим экспорт базы данных (формат bak) на разрабатываемой машине и импортируем ее на сервер через MSSQL Server Management

Проверяем работоспособность IIS и портала BPM Bizagi

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

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

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

Международная межбанковская система передачи платёжных документов SWIFT

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

В 1968 г. был зарождён данный проект. Целью проекта было обеспечение участвующих в проекте банков и других финансовых организаций в организации защищённой сети для передачи финансовых сообщений. Система начала полноценно функционировать в начале 1970-х гг. В 1987 г. был преодолён барьер в 1 млн сообщений в день.

В качестве соучредителей выступили 248 банков из 19 стран мира, Штаб-квартира находится в Бельгии, недалеко от Брюсселя.

По состоянию на 2015 год, членами Swift сообщества являются более 11 тысяч финансовых организаций в более чем 200 стран мира, и примерно 1/11 из этих компаний являются корпорациями, например, с государственным участием или без государственного участия (Например, Apple, Microsoft, Госкорпорация «Росатом», ПАО «Ростелеком» и другие). Примерный оборот ежедневных сообщений составляет 30 миллионов, примерно в денежном эквиваленте это десятки миллиардов долларов в день.

Адресация абонентов в системе SWIFT происходит по коду Business Identifier code, присваивается в соответствии со стандартом ISO 9362.

ISO 9362 — стандарт, устанавливающий универсальный метод идентификации участников финансовых расчётов. Официальное название стандарта — «Банковское дело. Банковские телекоммуникационные сообщения. Идентификационные коды банков».

Стандарт создан на основе разработанного компанией SWIFT метода идентификации банков — членов сети SWIFT. При этом компания SWIFT закреплена в роли уполномоченного органа ISO по регистрации кодов BIC.

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

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

Иногда идентификация в системе SWIFT именуется как SWIFT-BIC, SWIFT ID или SWIFT code. 

Финансовые сообщения формируются по формату SWIFT MT.

Основные дата центры SWIFT расположены в Америке и Европе. Эти центры связаны с региональными центрами, которые устанавливаются в странах, вступивших в сообщество SWIFT. Сообщение от банка отправителя поступает по открытым или закрытым каналам связи в региональный центр. Ответственность за передачу сообщения до регионального центра несёт инициатор сообщения. В региональном центре все сообщения проверяются на соответствие стандартам SWIFT MT, накапливаются, шифруются и передаются по назначению. В системе применяется многоуровневая защита информации, которая обеспечивает сохранность и конфиденциальность передаваемых данных. Используются криптографические методы, соответствующие стандартам ISO. Ежедневно SWIFT передаёт платёжные поручения суммарной оценочной стоимостью более $6 трлн. Каждый год SWIFT передаёт около 1,8 млрд сообщений о совершении платежей.

MT101 – это запрос на перевод, позволяющий осуществить электронный перевод средств с одного счета на другой. Средства переводятся со счета клиента, заказавшего перевод, на счёт банка или финансовой организации получателя.

Допускается применение следующего набора символов:

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ – ? : ( ) . , ‘ + { }
CR LF Space

  • фигурные скобки {} не могут быть использованы в сообщении, а служат только разделителем для определения различных структурных блоков SWIFT
  • Тире “-“ не должно быть первым символом любой стороки

Тэг 20 – Номер перевода:

  • Обязателен
  • Записывается как :20:
  • 16 символов

Тэг 21 – Номер, заданный отправителем:

  • Опционально
  • Записывается как :21R:
  • 16 символов

Тэг 28D – Номер сообщения/Итого сообщений:

  • Обязателен
  • Записывается как :28D:
  • 5n/5n

Тэг 50C или 50L – Инструкции:

  • Опционально
  • Записывается как :50C: или :50L:
  • Зависит от типа выбранного тэга 50C (BIC) или 50L (35 символов)

Тэг 50F или 50G, или 50H – Информация отправителя:

  • Опционально
  • Записывается как :50F: или :50G:, или :50H:
  • Зависит от типа выбранного тэга 50F, 50G, 50H:
    :50F:
    • 35 символов (номер счета)
    • 4х35 символов (имя и адрес)

:50G:

  • /34 символа (счёт)
  • BIC (8 или 11 символов)

:50H:

  • /34 символа (счёт)
  • 4х35 символов

Тэг 52A или 52C – Информация об обслуживающей счёт отправителя организации:

  • Опционально
  • Записывается как :52A: или :52C:
  • Зависит от типа выбранного тэга 52A или 52C:
    • — :52A: — BIC (8 или 11 символов)
    • — :52C: — /34 символа

Тэг 51A – Отправляющая организация:

  • Опционально
  • Записывается как :51A:
  • BIC (8 или 11 символов)

Тэг 30 – Требуемая дата исполнения

  • Обязательно
  • Записывается как :30:
  • Дата в формате ГГММДД

Тэг 25 – Авторизация:

  • Опционально
  • Записывается как :25:
  • 35 символов

Детализация транзакции:

Тэг 21 – Номер транзакции:

  • Обязательно
  • Записывается как :21:
  • 16 символов

Тэг 21F – Номер операции конвертации:

  • Опционально
  • Записывается как :21F:
  • 16 символов

Тэг 23E – Код транзакции:

  • Опционально
  • Записывается как :23E:
  • 4-х символьный код и опциональное продолжение до 30 символов:
    • можно использовать только перечисленные 4-х символьные коды: CHQB, CMSW, CMTO, CMZB, CORT, EQUI, INTC, NETS, OTHR, PHON, REPA, RTGS, URGP
    • Если требуется добавить символы после кода, то требуется вставить”/”. Например:23E:URGP/ITSGETTINGLATE

Тэг 32B – Валюта/Сумма транзакции:

  • Обязательно
  • Записывается как :32B
  • 3-х символьный код валюты (ISO 4217) и 15 цифр, определяющих сумму

Тэг 50C или 50L – Инструкции:

  • Опционально
  • Записывается как :50C: или :50L:
  • Зависит от типа выбранного тэга 50C (BIC) или 50L (35 символов счета)

Тэг 50F или 50G, или 50H – Информация отправителя:

  • Опционально
  • Записывается как :50F: или :50G:, или :50H:
  • Зависит от типа выбранного тэга 50F, 50G, 50H:
    :50F:
    • 35 символов (номер счета)
    • 4х35 символов (имя и адрес)

:50G:

  • /34 символа (счёт)
  • BIC (8 или 11 символов)

:50H:

  • /34 символа (счёт)
  • 4х35 символов

Тэг 52A или 52C – Информация об организации, обслуживающей счёт отправителя:

  • Опционально
  • Записывается как :52A: или :52C:
  • Зависит от типа выбранного тэга 52A или 52C:
    • — :52A: — BIC (8 или 11 символов)
    • — :52C: — /34 символа

Тэг 56A или 56C, или 56D– Банк посредник:

  • Опционально
  • Записывается как :56A: или :56C:, или :56D:
  • Зависит от типа выбранного тэга 56A или 56C, или 56D

Тэг 57A или 57C, или 57D– Банк получателя:

  • Опционально
  • Записывается как :57A: или :57C:, или :57D:
  • Зависит от типа выбранного тэга 57A или 57C, или 57D:
    • : 57A: — BIC (8 или 11 символов)
    • : 57C: — /34 символа
    • : 57D:
      • /34 символа(счет)
      • 4х35 символов

Тэг 59 или 59A – Получатель:

  • Обязательно
  • Записывается как :59: или :59A:
  • Зависит от типа выбранного тэга 59 или 59A:
    :59:
    • /34 символа (номер счета)
    • 4х35 символов (имя, адрес)

:59A:

  • /34 символа (номер счета)
  • BIC (8 или 11 символов)

Тэг 70 – Информация о платеже:

  • Опционально
  • Записывается как :70:
  • 4х35 символов, могут быть использованы следующие коды: /INV/ , /IPI/ , /RFB/ , /ROC/ /TSU/

Тэг 77B – Данные для регулятора:

  • Опционально
  • Записывается как :77B:
  • 3х35 символов:
    • строка 1 – 8 символов Код/Страна/Текст
    • Строка 2-3 — дополнительный текст

Коды:

  • BENEFRES – Страна получателя
  • ORDERRES – Страна отправителя

Тэг 33B – Валюта/Сумма в заявлении на перевод:

  • Опционально
  • Записывается как :33B:
  • 3-х символьный код валюты (ISO 4217) и 15 цифр, определяющих сумму

Тэг 71A – Расходы по платежу:

  • Обязательно
  • Записывается как :71A:
  • 3-х символьный код, допустимо:
    • BEN – все транзакционные расходы несёт получатель
    • OUR – все транзакционные расходы несёт отправитель
    • SHA – транзакционные расходы разделяют стороны платежа

Тэг 25A – Счет, с которого списываются расходы по платежу:

  • Опционально
  • Записывается как :25A:
  • 34 символа

Тэг 36 – Курс обмена

  • Опционально
  • Записывается как :36:
  • 12 цифр

В нижеприведённом примере сообщения SWIFT MT101 указано, что сумма 123,45 EUR оплачена со счета GB12SEPA12341234123412 в банке BANKGB01XXX поставщику (Vakurin Andrey) на его счёт GB12SEPA12341234123498 в банке BANKGB02XXX. В назначении платежа указано, что оплата по инвойсу INV-0001

:20:123456789
:28D:1/1
:50H:/GB12SEPA12341234123412
ORDERING CUST NAME
ORDERING CUST ADDR LINE 1
ORDERING CUST ADDR LINE 2
ORDERING CUST ADDR LINE 3
:52A:BANKGB01XXX
:30:160211
:21:11FEB2016INV1
:23E:URGP
:32B:EUR123,45
:57A:BANKGB02XXX
:59:/GB12SEPA12341234123498
Vakurin Andrey
SUPPLIER ADDR LINE 1
SUPPLIER ADDR LINE 2
SUPPLIER ADDR LINE 3
:70:INV-0001
:77B:/BENEFRES/GB
:71A:SHA

Система SWIFT планирует постепенно переходить от формата SWIFT MT к сообщениям формата SWIFT MX, которые спроектированы по методологии ISO 20022 и содержат самые актуальные требования.

Разработка схемы взаимодействия АРМ КБР

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

  • ЦБРФ.61209-049301«Руководством по обеспечению информационной безопасности»;
  • ЦБРФ.61209-049201 «Автоматизированное рабочее место клиента Банка России. Руководство пользователя»;
  • ЦБРФ.61209-049202 «Автоматизированное рабочее место клиента Банка России. Руководство администратора»;
  • ВАМБ.00106-019301 «СКАД «Сигнатура» версия 5. «Сигнатура-клиент» версия 5. Руководство администратора информационной безопасности».

АРМ КБР/ АРМ КБР СПФС – это специализированное программное обеспечение работников банков или крупных государственных организаций для подготовки и отправки финансовых сообщений в платежный контур центрального банка. Данное ПО позволяет проставлять электронную подпись на финансовые документы, проводить проверку и расшифровку электронных сообщений, поступивших из Банка России. В своей работе АРМ КБР/ АРМ КБР СПФС использует формат финансовых документов УФЭБС. Типы сообщений бывают как платежные сообщения, так и информационные (создание тестового сообщения, запрос технической информации и тд).

Для обработки электронное сообщение должно быть преобразовано в УФЭБС на АРМ КБР или преобразовано в АБС клиента и отправлено на АРМ КБР.

Электронные сообщения при работе в ручном режиме помещаются в каталог АРМ КБР c://uarm3/exg/cli. Встроенный компонент «Входной контроль» выполяет анализ поступившего ЭС. Если сообщение успешно прошло валидацию, то оно попадает во вкладку «введеные», если сообщение не прошло валидацию, то оно попадает во вкладку «Забракованное». При работе в автоматическом режиме сообщение попадает в выходную папку.

После помещения во вкладку «введеные» данному сообщению проставляется закрытый код и код аутентификации (электронная подпись директора и контролера), после успешного подписания сообщение помещается в папку c://uarm3/exg/apr и ожидают сигнала для дальнейшей отправки в платежной контур платежной системы Банка России. Подготовленные документы для обмена перемещаются из папки c://uarm3/exg/apr в папку c://uarm3/exg/out для выполнения отправки. Помещенные ЭС в папку exg\out отправляются через протокол HTTP (внутри выделенного канала VPN), аутентификация выполняется с помощью пары «логин-пароль».

Принятые сообщения из контура платежной системы принимаются в папку c://uarm3/exg/inc, после принятия сообщения выполняется проверка КА и ЗК подписи. При успешной проверки распакованное сообщение попадает в папку c://uarm3/exg/chk.

Если используется собственная АБС в банке, то принятое электронное сообщение расшифровывается транспортной подписью и перекодируется из base64. Открытое сообщение в открытом виде передается в АБС, где на его основании формируются бухгалтерские проводки, изменяющие остатки на счетах.

В процессе работы АРМ КБР ведет логирование своей работы , и в случае возникновения критической ситуации или сбоя программы она немедленно сообщает это администратору информационной безопасности.

В случаи выхода из строя канала связи предусмотрена доставка электронных сообщений на ОМНИ (отчуждаемый машинный носитель информации) с помощью курьера. Работа АРМ КБР/ АРМ КБР СПФС представлена на рисунке

Для ввода АРМ КБР/ АРМ КБР СПФС в локальную вычислительную сеть предприятия необходимо организовать и обеспечить защищённое подключение ПК АРМ КБР в ЛВС клиента, предполагающее отсутствие технической возможности доступа к ПК АРМ КБР из внешних, по отношению к ЛВС клиента, сетей, в том числе из сети Интернет.

Для решения указанной задачи необходимо обеспечить:

  • защиту ЛВС клиента от сетевых атак из внешних сетей, в том числе из сети Интернет, путём применения межсетевого экрана, который должен осуществлять фильтрацию сетевого графика и соответствовать требованиям руководящего документа ФСТЭК России «Средства вычислительной техники, Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации» по 4 классу защищённости;
  • реализацию таких схем конфигурирования ПК АРМ КБР, при которых обеспечивается невозможность вброса данных в обход заданного технологического цикла обработки данных.

Созданные файлы разработанным модулем будут помещаться в папку cli, если сообщение собственного формата, то в папку ed501in.

Разрабатываемый модуль передатчик «ПС БР» может работать как на АРМ КБР, так и на дополнительном изолированном АРМ.

Дополнительная защита от НСД обеспечивается прямым VPN соединением между организацией и ЦБ РФ. IP адреса организации используют те, которые выделяет ЦБ РФ для конкретной организации.

Унифицированные форматы электронных банковских сообщений

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

Основными задачами формата является стандартизация обмена между клиентскими автоматизированными банковскими системами и системой Центрального Банка. Формат упрощает безналичный расчёт на территории Российской Федерации и взаимодействия с системой ЦБ, упрощает существующие форматы электронных сообщений, переходит к современным стандартам обмена коммерческой информацией в электронном виде.

Альбом УФЭБС разработаны на языке разметки XML. В таблице приведены основные форматы документов.

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

Обмен сообщениями сокращённого формата допускается между воинскими частями, предприятиями и организациями Министерства обороны Российской Федерации

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

Если формируется распоряжение на бумажные носители, но платёжная система Банка России составляет электронное сообщение ED101, ED103, ED104, ED105, ED109, ED110, ED111 и направляет участнику на сформированное распоряжение в бумажном виде. Если из-за недостатка денежных средств распоряжение не может быть исполнено, но оно помещается во внутридневную очередь, где хранится до исполнения в течение операционного дня. Если пользователь захочет данное сообщение вывести из очереди, то он отправляет сообщение ED205 или ED805. Не исполненное сообщение в течение операционного дня возвращается пользователю со статусом не исполнено. При достаточном количестве средств платёжное сообщение исполняется в соответствии с регламентом, после чего Банк Росси отправляет участнику подтверждающий документ. В нижеприведённом примере сформировано платёжное поручение (формат Ed101).

<? Xml version=»1.0″ encoding=»WINDOWS-1251″?>

<ED101 xmlns=»urn: cbr-ru: Ed: v2.0 » EDNo=»1000″ EDDate=»2020-06-17″ EDAuthor=»4525000010″ TransKind=»01″ Priority=»5″ Sum=»2400000″ PaymentPrecedence=»60″ SystemCode=»05″ PaytKind=»4″ ReceiptDate=»2018-07-02″ ChargeOffDate=»2018-07-02″>

  <AccDoc AccDocNo=»10″ AccDocDate=»2018-07-02″/>

<Payer PersonalAcc=»00000000000000000000″ INN=»00000000000″>

                   <Name>Компания 1</Name>

                   <Bank BIC=»044525545″ CorrespAcc=»30101810300000000545″/>

         </Payer>

         <Payee PersonalAcc=»4070281001010000000″ INN=»00000000″>

                   <Name>Компания 2</Name>

                   <Bank BIC=»00000000″ CorrespAcc=»30101810145333333333″/>

         </Payee>

         <Purpose>ОПЛАТА ПО ДОГОВОРУ 35889-ОТ 20.05.2020 Без учёта НДС 4000 РУБ</Purpose>

</ED101>

В блоке Payer содержатся данные дебитора (плательщика), в блоке Payee содержатся данные кредитора (получателя средств).

В нижеприведённом примере сформировано платёжное поручение (формат Ed501, сообщение свободного формата), согласно стандарту iso:std:iso:20022:tech:xsd:pain.001.001.06

<?xml version=»1.0″ encoding=»UTF-8″?>

<Document xmlns=»urn:iso:std:iso:20022:tech:xsd:pain.001.001.06″>

         <CstmrCdtTrfInitn>

                   <GrpHdr>

                            <MsgId>10836708462_pain_MSG_20181221_00123</MsgId>

                            <CreDtTm>2019-07-01T12:10:58+03:00</CreDtTm>

                            <NbOfTxs>1</NbOfTxs>

                            <InitgPty>

                                      <Nm>Компания 1</Nm>

                                      <Id>

                                               <OrgId>

                                                         <Othr>

                                                                  <Id>7706664260</Id>

                                                                  <SchmeNm>

                                                                            <Cd>TXID</Cd>

                                                                  </SchmeNm>

                                                         </Othr>

                                               </OrgId>

                                      </Id>

                            </InitgPty>

                   </GrpHdr>

                   <PmtInf>

                            <PmtInfId>10836708462_pain_PKG_20181221_00010</PmtInfId>

                            <PmtMtd>TRF</PmtMtd>

                            <PmtTpInf>

                                      <InstrPrty>NORM</InstrPrty>

                                      <SvcLvl>

                                               <Cd>NURG</Cd>

                                      </SvcLvl>

                            </PmtTpInf>

                            <ReqdExctnDt>2019-07-01</ReqdExctnDt>

                            <Dbtr>

                                      <Nm>Компания 1″</Nm>

                                      <PstlAdr>

                                               <Ctry>RU</Ctry>

                                     </PstlAdr>

                                      <Id>

                                               <OrgId>

                                                         <Othr>

                                                                  <Id>333333333</Id>

                                                                  <SchmeNm>

                                                                            <Cd>TXID</Cd>

                                                                  </SchmeNm>

                                                         </Othr>

                                               </OrgId>

                                      </Id>

                            </Dbtr>

                            <DbtrAcct>

                                      <Id>

                                               <Othr>

                                                         <Id>000000000000000000000</Id>

                                                         <SchmeNm>

                                                                  <Cd>ACC</Cd>

                                                         </SchmeNm>

                                               </Othr>

                                      </Id>

                                      <Ccy>RUB</Ccy>

                            </DbtrAcct>

                            <DbtrAgt>

                                      <FinInstnId>

                                               <ClrSysMmbId>

                                                         <ClrSysId>

                                                                  <Cd>RUCBC</Cd>

                                                         </ClrSysId>

                                                         <MmbId>044533333</MmbId>

                                               </ClrSysMmbId>

                                               <Nm>ПАО «ПРОМСВЯЗЬБАНК»</Nm>

                                               <PstlAdr>

                                                         <Ctry>RU</Ctry>

                                               </PstlAdr>

                                      </FinInstnId>

                            </DbtrAgt>

                            <DbtrAgtAcct>

                                      <Id>

                                               <Othr>

                                                         <Id>00000000000000000000</Id>

                                               </Othr>

                                      </Id>

                            </DbtrAgtAcct>

                            <CdtTrfTxInf>

                                      <PmtId>

                                               <InstrId>10836708385_pain_PMT_20190419_00005</InstrId>

                                               <EndToEndId>7309</EndToEndId>

                                      </PmtId>

                                      <PmtTpInf>

                                               <SvcLvl>

                                                         <Cd>NURG</Cd>

                                               </SvcLvl>

                                      </PmtTpInf>

                                      <Amt>

                                               <InstdAmt Ccy=»RUB»>4000</InstdAmt>

                                      </Amt>

                                      <ChrgBr>DEBT</ChrgBr>

                                      <CdtrAgt>

                                               <FinInstnId>

                                                         <ClrSysMmbId>

                                                                  <ClrSysId>

                                                                            <Cd>RUCBC</Cd>

                                                                  </ClrSysId>

                                                                  <MmbId>044525593</MmbId>

                                                         </ClrSysMmbId>

                                                         <Nm>АО «АЛЬФА-БАНК»</Nm>

                                                         <PstlAdr>

                                                                  <Ctry>RU</Ctry>

                                                         </PstlAdr>

                                               </FinInstnId>

                                      </CdtrAgt>

                                      <CdtrAgtAcct>

                                               <Id>

                                                         <Othr>

                                                                  <Id>00000000000000000000</Id>

                                                         </Othr>

                                               </Id>

                                      </CdtrAgtAcct>

                                      <Cdtr>

                                               <Nm>Компания 2</Nm>

                                               <PstlAdr>

                                                         <Ctry>RU</Ctry>

                                               </PstlAdr>

                                               <Id>

                                                         <OrgId>

                                                                  <Othr>

                                                                            <Id>7706664333</Id>

                                                                            <SchmeNm>

                                                                                     <Cd>TXID</Cd>

                                                                            </SchmeNm>

                                                                  </Othr>

                                                         </OrgId>

                                               </Id>

                                      </Cdtr>

                                      <CdtrAcct>

                                               <Id>

                                                         <Othr>

                                                                  <Id>0000000000000000</Id>

                                                                  <SchmeNm>

                                                                            <Cd>ACC</Cd>

                                                                  </SchmeNm>

                                                         </Othr>

                                               </Id>

                                      </CdtrAcct>

                                      <Purp>

                                               <Prtry>5</Prtry>

                                      </Purp>

                                      <Tax>

                                               <Cdtr>

                                                         <TaxTp>770601001</TaxTp>

                                               </Cdtr>

                                               <Dbtr>

                                                         <TaxTp>770601001</TaxTp>

                                               </Dbtr>

                                      </Tax>

                                      <RmtInf>

                                               <Ustrd> ОПЛАТА ПО ДОГОВОРУ 35889 ОТ 20.05.2020 Без учета НДС 4000 РУБ </Ustrd>

                                               <Strd>

                                                         <RfrdDocInf>

                                                                  <Tp>

                                                                            <CdOrPrtry>

                                                                                     <Prtry>POD</Prtry>

                                                                            </CdOrPrtry>

                                                                  </Tp>

                                                                  <RltdDt>2019-04-19</RltdDt>

                                                         </RfrdDocInf>

                                               </Strd>

                                      </RmtInf>

                            </CdtTrfTxInf>

                   </PmtInf>

         </CstmrCdtTrfInitn>

</Document>

В следующих блоках содержится следующая информация:

  • InitgPty содержит данные инициатора платежа;
  • Dbtr содержится данные дебитора (плательщика);
  • DbtrAcct содержится счёт дебитора;
  • DbtrAg содержатся данные банка плательщика (наименование банка, БИК банка);
  • DbtrAgtAcct содержится корреспондентский счёт банка;
  • CdtrAgt содержит банковские реквизиты получателя средств;
  • CdtrAgtAcct содержится корреспондентский счёт банка;
  • Cdtr содержится данные кредитора (получателя средств);
  • CdtrAcct содержится счёт кредитора;
  • Tax содержит ИНН дебитора и кредитора;
  • InstdAmt содержит необходимую информацию о сумме и приоритете платежа;

В рамках взаимодействия банков и их клиентов – юридических лиц для обмена финансовыми сообщениями и проверки их статуса существуют следующие форматы и схемы сообщений для обмена:

  • camt.052.001.08 BankToCustomerAccountReport — Промежуточное извещение об операциях по счету / BankToCustomerAccountReport;
  • camt.053.001.08 BankToCustomerStatement — Извещение об операциях по счету / BankToCustomerStatement;
  • camt.054.001.08 BankToCustomerDebitCreditNotification — Извещение о списании/зачислении / BankToCustomerDebitCreditNotification;
  • pain.001.001.09 CustomerCreditTransferInitiationRouble — Инициирование перевода денежных средств клиентом / CustomerCreditTransferInitiationRouble;
  • pain.002.001.10 CustomerPaymentStatusReport — Уведомление о результатах контроля на уровне банк-клиент / CustomerPaymentStatusReport

Формат ISO 20022

ISO 20022 — международный стандарт обмена электронными сообщениями между организациями финансовой отрасли.

В России данный стандарт подготовлен Федеральным бюджетным учреждением «Консультационно-внедренческая фирма в области международной стандартизации и сертификации — «Фирма «ИНТЕРСТАНДАРТ» совместно с Центральным банком Российской Федерации на основе собственного аутентичного перевода на русский язык международного стандарта ISO 20022-1:2013 «Financial Services — Universal financial industry message scheme. Part 1: Metamodel».

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

Самая актуальная редакция стандарта «Финансовые услуги — Универсальная схема сообщений для финансовой отрасли» была опубликована в мае 2013 года и состоит из следующих частей:

  • Метамодель (Metamodel);
  • UML-профайл;
  • Процесс моделирования;
  • Формирование схем XML;
  • Обратное проектирование;
  • Характеристики транспортировки сообщений;
  • Правила регистрации;
  • Формирование ASN.1;

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

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

В качестве синтаксиса ISO 20022 используется современный и гибкий язык XML. Схемы сообщений представляют собой XML-файлы (и схемы XSD), которые могут просматриваться с помощью программных средств различных разработчиков (например, XMLPad).

Стандарт включает следующие области:

  • Осуществление платежей и расчётов (создание платёжных документов, платёжный клиринг и расчёты, управление денежными средствами, ведение переписки по расследованиям и нештатным ситуациям);
  • Управление ценными бумагами (заключение сделок с ценными бумагами, расчёты и выверка расчётов, залоговые операции, клиринг по ценным бумагам, корпоративные действия и голосование по доверенности);
  • Осуществление торговых операций;
  • Работа с пластиковыми картами (кредитные и дебетовые), осуществление платежей по ним и управление транзакциями;
  • Работа с валютными операциями (конверсия).

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

Стандарт опубликован на сайте https://www.iso20022.org/ и является полностью открытым. В состав документации входит описание бизнес-процессов и различных сценариев по операциям, продемонстрированы XML-схемы сообщений и его XSD схемы, дополнительно размещены компоненты и элементы, которые включаются в сообщение.

Стандартом регламентируется порядок внесения предложений по разработке и развитию новых стандартов, их регистрации, внесение изменений в существующие сообщения путём официального оформления. Запрос для изменения текущих стандартов проходит официальные стадии согласования и утверждения как в ТК № 68   и Уполномоченном органе по регистрации, так и с локальными финансовыми сообществами отдельных стран.

Стандарт ISO 20022 был разработан Техническим комитетом № 68 Международной организации по стандартизации (ИСО).

SWIFT является уполномоченным органом по регистрации и сопровождению стандарта ISO 20022.

В развитии стандарта участвуют следующие организации: FIX Protocol Limited, ISDA, Omgeo, SWIFT, VISA;

В Российской Федерации внедрением стандарта ISO 20022 занимаются следующие организации:

  • Центральный Банк РФ;
  • Национальный расчётный депозитарий;
  • Национальный платёжный совет;
  • Российская Национальная Ассоциация SWIFT (РОССВИФТ);

Эксперты РОССВИФТ принимают активное участие в работе Подкомитета 3 и Технического Комитета 122 Банка России, а также Рабочей группы Подкомитета 3 по разработке стандартов Национальной платёжной системы с использованием сообщений ISO 20022.

Структура сообщения описывается следующим образом. Все бизнес сообщения передаются в XML конверте «PaymentMessages», формат которого описан в XML схеме PaymentMessages.xsd. XML конверт передаваемым участниками обмена, оформляется в виде файла в формате XML. При заполнении значений реквизитов в текстовых значениях полей используется кодировка кириллицы WIN-1251.

XML конверт имеет следующую структуру:

  • Корневой тег «PaymentMessages»
  • Блок «AppHdr» — Business Application Header (BAH) – прикладной заголовок электронного сообщения
  • Блок «Document» — Бизнес-сообщение – электронное сообщение, предназначенное для передачи бизнес данных между участниками обмена

Для корневого элемента PaymentMessages должен быть указан namespace «paymentmessages».

Пример указания namespace:

<PaymentMessages mlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» xmlns=»paymentmessages»>

Блок «AppHdr» указывается перед блоком «Document».

Таким образом, в XML конверте передаётся два блока: «AppHdr» (в нем передается служебная информация: отправитель, получатель, идентификатор сообщения, код формы и др. инф относящаяся к передаваемому документу) и блок «Document» — это бизнес-сообщение.

Формат блока «AppHdr» соответствует XML схеме head.001.001.01, namespace которой указывается в блоке «AppHdr». Правила заполнения блока «AppHdr» одинаковы для всех сообщений.

Пример указания namespace: <AppHdr xmlns=»urn:iso: std:iso:20022: tech: xsd: head.000.000.00»>.

Формат блока «Document» для каждого сообщения индивидуален и определяется атрибутом namespace (пространство имен), который соответствует XML схеме сообщения. Пример указания namespace: <Document xmlns=»urn: iso: std: iso: 20022: tech: xsd: pain.001.001.08″>

XML конверт должен валидироваться относительно XSD схемы конверта: PaymentMessages.xsd.

Заголовок Business application header (BAH) — head.001.001.01, далее AppHdr передается в XML конверте при передаче бизнес сообщения формата XML

Блок «AppHdr» указывается всегда после корневого тега, перед блоком «Document». Правила и перечень обязательных полей в блоке AppHdr приведены в Таблице

Таблица — Перечень полей и правила их заполнения в блоке AppHdr head.001.001.01

Поле/блокНаименование атрибутаxpathОбязательностьПримечание
FrОтправитель сообщения / From*/AppHdr/Fr/OrgId/Id/OrgId/Othr/IdОУказывается депозитарный код отправителя + */Othr/Issr=NSDR + */SchmeNm/Cd=NSDR
ToПолучатель сообщения / To*/AppHdr/To/OrgId/Id/OrgId/Othr/IdОУказывается депозитарный код получателя + */Othr/Issr=NSDR + */SchmeNm/Cd=NSDR
BizMsgIdrИдентификатор бизнес-сообщения / Business Message Identifier*/AppHdr/BizMsgIdrОУникальный идентификатор сообщения, который присваивается стороной, подготавливающей сообщение. Для сообщений, направляемых в НРД идентификатор сообщения должен удовлетворять требованиям: размер не более 16 символов; допускается использование в номере букв английского алфавита от A до Z(прописных), букв английского алфавита от a до z (строчных), цифр от 0 до 9, специальных символов (.,()+:?-/). Примечание: символы: -,/+ могут использоваться в любой позиции, за исключением первого символа.
MsgDefIdrИдентификатор сообщения в соответствии с ISO20022 / Message Definition Identifier*/AppHdr/MsgDefIdrОТип сообщения в соответствии с ISO20022. Формат: xxxx.NNN.NNN.NN, где x- прописные буквы латинского алфавита, N- цифры 0-9. Например: pain.001.001.08
BizSvcБизнес-сервис / Business Service*/AppHdr/BizSvcОКод формы документа. Например: PI011 или PI012 и др.
CreDtДата и время создания бизнес-сообщения / Creation Date*/AppHdr/CreDtОДата и время отправки сообщения. Время указывается по Гринвичу. Например:2015-06-01T13:00:00Z
RltdЗаголовок связанного бизнес-сообщения*/AppHdr/RltdНБлок */Rltd заполняется только в случае формирования сообщения MessageReject. Содержимое блока */Rltd копируется из блока */AppHdr исходного сообщения.

Пример заголовка AppHdr:

 <AppHdr xmlns=»urn:iso:std:iso:20022:tech:xsd:head.001.001.01″>

                   <Fr>

                            <OrgId>

                                      <Id>

                                               <OrgId>

                                                         <Othr>

                                                                  <Id>МС0126900000</Id>

                                                                  <SchmeNm>

                                                                            <Cd>NSDR</Cd>

                                                                  </SchmeNm>

                                                                  <Issr>NSDR</Issr>

                                                         </Othr>

                                               </OrgId>

                                      </Id>

                            </OrgId>

                   </Fr>

                   <To>

                            <OrgId>

                                      <Id>

                                               <OrgId>

                                                         <Othr>

                                                                  <Id>NDC000000000</Id>

                                                                  <SchmeNm>

                                                                            <Cd>NSDR</Cd>

                                                                  </SchmeNm>

                                                                  <Issr>NSDR</Issr>

                                                         </Othr>

                                               </OrgId>

                                      </Id>

                            </OrgId>

                   </To>

                   <BizMsgIdr>38545531A</BizMsgIdr>

                   <MsgDefIdr>pain.001.001.08</MsgDefIdr>

                   <BizSvc>PI011</BizSvc>

                   <CreDt>2017-04-27T10:57:00Z</CreDt>

         </AppHdr>

Само тело, например, кредитного перевод клиентских средств в формате ISO 20022 представлено ниже:

<CdtTrfTxInf>

<IntrBkSttlmAmt Ccy=’USD’>12500</IntrBkSttlmAmt>

<IntrBkSttlmDt>2009-10-29</IntrBkSttlmDt>

<Dbtr>

<Nm>Organization 1</Nm> <PstlAdr>

<StrtNm>Amstel</StrtNm><BldgNb>344</BldgNb>

<TwnNm>Amsterdam</TwnNm><Ctry>NL</Ctry>

</PstlAdr>

</Dbtr>

<DbtrAcct>

<Id>

<Othr>

<Id >8754219990</Id>

</Othr>

</Id>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>EXABNL2U</BIC> </FinInstnId>

</DbtrAgt>

</CdtTrfTxInf>

  • Ccy – наименование валюты и сумма
  • IntrBkSttlmDt – дата платежа
  • в блоке Dbtr указан плательщик
  • в блоке DbtrAcct указан счёт плательщика
  • в поле BIC указан банк получателя

Архитектура информационных систем. Гибкий процесс развития продуктов

Одно время стали довольно популярными обсуждения на тему: а как-бы нам использовать agile за границами ИТ. Несколько таких дискуссий вы, безусловно, найдете в группе FB GosAgile или в блоге Atlassian

Честно говоря, я не помню, чтоб в них было сказано что-то уж очень полезное. Возможно, я просто читал их недостаточно внимательно, а быть может авторы ограничивались слишком простой калькой с процессов разработки ПО. Ниже я опишу некую гипотезу о том, как мог бы выглядеть процесс new product development, адаптированный к современным реалиям посредством agile Lean и Kanban. В какой-то мере это будет продолжением статьи Чему ИТ может научить бизнес.

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

Давайте начнем с традиционного процесса развития новых продуктов и услуг, именуемого обычно new product development. На рисунке ниже, который я люблю показывать в своих презентациях, изображен один из вариантов такого подхода от известного разработчика инструментов корпоративной архитектуры и управления портфелем проектов компании PlanView. Вполне себе такой «водопадный» или каскадный процесс, именуемый еще порой как stage-gate approach. Самая правильная идея в этой картинке это, некая воронка инноваций, по аналогии с воронкой продаж, иллюстрирующая тот факт, что до финиша дойдут далеко не все, а задача проектного офиса не столько в том, чтоб запустить побольше продуктов, а наоборот – отсеять лишние, сконцентрировав скудные ресурсы организации на реализации самых перспективных идей.

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

Подробнее: https://mxsmirnov.com/2017/06/24/lean-product-development/https://vk.cc/868TtQ

Gartner Magic Quadrant for iBPMS Report.

mailservice

Intelligent business process management suites provide real-time insights to achieve better business outcomes and help business transformation leaders, business process directors and solution architects improve business outcomes through process reinvention and transformation.

Market Definition/Description

The intelligent business process management suite (iBPMS) market is the natural evolution of the earlier BPMS market, adding more capabilities for greater intelligence within business processes. Capabilities such as validation (process simulation, including «what if») and verification (logical compliance), optimization, and the ability to gain insight into process performance have been included in many BPMS offerings for several years.

 

https://www.gartner.com/technology/media-products/newsletters/bizagi/1-3KV9G7N/gartner.html